Open Letter for JCP Reform
The votes are in, and the people have spoken. They are mad as hell and they want change. No, not those elections—I am talking about the JCP elections. There are two categories of seats for each “executive committee” (SE, EE, and ME). “Ratified” seats are picked by Oracle and need to be ratified by the JCP members with a simple majority. Anyone can be nominated for open seats, and the top vote getters are elected. Don't blame Oracle for this dual system. It was invented by Sun, presumably to ensure that some (most?) faces at the table will be friendly ones.
Sun, to my recollection, never abused their privilege, and nominated organizations (and occasionally people) with credibility in the community. Oracle had a bad start, however. Their nominations were Apache, Red Hat and Hologic. Ho-who? That's what Stephen Colebourne and others asked. Apparently, their major claim to fame is that they are a customer of the Java-based Oracle E-Business Suite product. In the end, it didn't work. Hologic wasn't elected (33% for, 42% against, 25% abstentions). And Oracle looked (evil|clueless) trying to defend their choice with disingenuous statements.
In the dull world of the JCP, that was pretty exciting. Also, interestingly, the top vote getter for the SE open seat was Google. Yes, the same Google that is being sued for using a bastardized version of SE in Android.
By the way, did you know that you can join the fun? Just about anyone can be a JCP member with full voting rights. It is free for individuals. The hardest part, if you don't work for yourself, is to get your employer to sign the legal paperwork.
There is of course a question whether any of this matters. Doug Lea, who had a seat on the SE executive committee, recently decided to leave because he believes “that the JCP is no longer a credible specification and standards body”.
He refers to rule violations in the JCP process and Oracle's refusal to do anything about them. He is a bit vague on the details, but it isn't hard to find examples. For example, look at the SE 6 JSR:
7. Nothing in the licensing terms will prevent open source projects from creating and distributing their own compatible open source implementations of Java SE 6, using standard open source licenses.
So, why isn't Apache Harmony able to produce their own compatible open source implementation? This article explains the gory details quite clearly.
And even without rule violations, the JCP has had very mixed success. Everyone can point to some really questionable pieces of Java technology that were designed by a JCP committee.
While I wholeheartedly agree that the JCP is far from perfect, I am afraid we will be stuck with it for a while, and we should have a stab at making it work better. Dan Allen and Lincoln Baxter published an open letter listing the many grievances that they have with the process. They have been tireless participants in JCP expert groups as well as implementors of resulting specifications, so they know what they are talking about.
Among the many points that they make, three stand out.
- The specifications that the JCP produces need to be freely implementable.
- The deliberations of the committees producing the specifications need to be transparent
- The “specification request” process needs to be reformed to reflect the iterative nature of software development
The first point will be hardest to achieve because that's where the money is. The test suites (TCKs in JCP parlance) are expensive to develop and maintain. Right now, Oracle is taking on that expense on its own. In the future, there should be a more equitable sharing of the work. More importantly, Sun wanted to protect its ME licensing revenue, so they put in “field of use” restrictions that did not allow third party implementations of Java in the mobile and embedded space. That's why Android runs on Dalvik, not on Java. My guess is that Oracle isn't just going to give up on that revenue, and we'll have to wait until it dries up—which, given the near-total lack of progress in ME, shouldn't take too long.
The second point ought to be easy to address. For starters, every committee should use an open mailing list for committee deliberations. For example, the JSR 314 mailing list has been readable to all for quite some time (thanks to Ed Burns!). Every few weeks, some JSF issue comes up where I scratch my head why something was designed in a particular way, and usually a quick search through the mailing list archive clears up the issue. Todo: A public archive. The best for now seems this mirror.
Getting broader participation also needs work. Not everyone can write to the JSR 314 list—for obvious reasons, they want to focus on their task without flame wars and homework questions. There is a public forum on the JCP list (using the worst forum software known to man), and it is getting essentially no use.
It doesn't help that every JSR cobbles together its own tools for participation. The JCP has done a very poor job providing a technical infrastructure. But that's fixable, and I hope that those JSRs who in the past have chosen to hide from the public will see the light.
The third point is perhaps the most fundamental. Right now, a JSR is formed when a new technology is deemed worthy of inclusion in the Java platform. It does its work and then disbands. Later, a different JSR picks up the work for producing the next update, and then it disbands. With some technologies, this has actually worked—JSF had a good mix of continuity and change that made it keep up with the times and atone for sins of the past. But with others, the process stinks. Look at client-side UI. Is anyone in charge? Is there any vision for the future? Any mechanism for deprecating what is no longer useful? Java is now old enough that some serious deprecation needs to happen for it to move forward.
Check out the open letter and, if you agree with its spirit, consider signing it. And if you ever write your own open letter, stay away from specific minutiae in the demands, so that potential signers don't have t worry whether their signature means absolute agreement with every single item. For the record, I signed the letter even though I think that Maven Central repos for the reference implementations are “nice to have”, not “must have” :-) There are people in the JCP who want to make things better, and they need the backing of the community to move forward.