Tags: OpenJDK
Last night I attended, at Java ONE, a talk by David Schlesinger of ACCESS, formerly of PalmSource. What drew me was the title, about building open source communities, and I hoped to gain a little insight about the process since that's my job right now, to build a community related OpenJDK quality.
During his talk he touched on Quality several times. In his job the software his team puts together ends up in smart phones (e.g. the Treo) and the quality expectation for a cell phone is completely different from the quality expectation in the typical open source project. He had a lot of ideas to share which I found very interesting.
I think the key is a word he's borrowed from Japanese Samurai movies. Tsujigiri is when a Samurai tests a new sword on a random passerby.
Typical OSS quality processes are like that.. Quality is negitiable. "Open Source Software: 80% as good as the last guy who worked on it needed it to be" .. etc, he had several good quips like that.
But that's not what a cell phone user is willing to put up with. You just want your cell phone to work. In the U.S. it's the law that a cell phone must always be able to call '911' (the emergency phone number) even if you haven't paid your bill in 6 months.
And the Java platform cannot have that level of quality. Listen to yesterdays Keynote presentation (JavaONE 2007 home page, the video replay should be there "soon") and you'll hear some high level exec from NASDAQ talk about their reliability requirements. There are large organizations running hugely mission critical applications, using the Java platform. It's critical that the quality remain high or the Java platform will lose those users.
David said: Commercial organizations can make significant contributions to quality. Commercial organizations have a tradition of focused quality, testing regimines, policies, etc, geared to keeping the software at high quality. However he presented the model as the upstream project follows the typical OSS quality practices (unit tests and ad-hoc usage) while the commercial entitity is downstream and sending information upstream. For instance the downstream commercial entity might perform certification or use expensive analysis tools, and have the freedom to send data to the upstream project.
In the case of the OpenJDK we have an existing quality team who is following the sort of focused quality and testing regimines which David talked about. However we are looking to you, the users of the Java platform, to help and collaborate with us to improve Java quality even more.
The model that is resonating for me now is this problem ... there is qualms among many in migrating from one JDK release to another JDK release. Clearly there is information that isn't being captured in the current model. That there are application compatibility problems which are known in the field by application developers, and the information is not getting back to us at Sun. If we can work together to gather this information it should result in a test suite which can help us all feel better about migrating to new releases earlier.
Source:
weblogs.java.net
