The beginning of the beginning of the end for the JCP
There is trouble brewing in the world of Java. The evidence is not so apparent at the moment, but it has the potential to rock the Java ecosystem to it's foundations if the issues are mishandled.
The principal issue is around the definition of 'standard' Java. By mutual agreement, companies and individuals contribute to the definition of new Java standards through the Java Community Process (JCP). The 'mutual agreement' of these contributors is written down as the Java Specification Participation Agreement (JSPA), which is the legal document describing the terms under which the contributions are made and can be used. Like all legal documents, it doesn't describe every last nuance of the community interaction, nor should it attempt to do so, but in general the JCP has worked because there has not been an unreasonable agent at play -- everyone has been participating for the general improvement of Java, and everyone benefits from the general improvement of Java.
So what happens when somebody tries to tip the balance of community participation in their favour? Would you expect other community members to cry foul? try to right the wrong? withdraw their collaboration? Well, yes!
It is well documented how Apache have written an open letter to Sun asking for a license to the the Java SE 5 JCK. So far, Sun have refused to grant such a license under terms that community members consider reasonable. The details of the unacceptable terms are not so important here, but if the majority of the community feels that the work they have contributed via the JCP is being misappropriated by an unreasonable agent, what do you think they are likely to do?
I suggest that unless Sun engage in a round of diplomacy and negotiation with the 'heavy-lifters' on the JCP Java SE/EE Executive Committee, such 'heavy-lifters' will decide pretty quickly that contributing to Java via the JCP is not a safe, smart thing to be doing, and the centre of gravity will move elsewhere.
In the current situation, Apache is the fall guy and the JCP members are watching carefully to see how the issue will be resolved. Whereas licensees normally negotiate with dollars behind closed doors, Apache are holding up (open source) principals and (now) negotiating in public. JCP members know that next time they could be the target
We can only speculate as to why Sun are taking the current position. Maybe it is a control thing -- their marketing certainly leads people to believe that Java == Sun, rather than Java is a result of contributions from many people that are brought together by Sun in the JCP.
Maybe it is the fear that the JCK is inadequate to ensure Java's value proposition of 'write once run anywhere' (WORA). There is a huge gap between being compliant (passing the JCK) and being compatible (behaving like the reference implementation). For WORA to work, Java developers have to code only to the specification, or every implementation has to behave the same way down to very small details. For so long, there has been only one game in town that developers have coded to the reference implementation, not the specification. So when Apache deliver a compliant implementation, and Sun have to admit that it is real Java, but it doesn't run half of the Java applications on the planet... what damage will that do to the Java brand?
So I further expect that Sun will try to migrate the work currently conducted "through JSR's in the JCP" to work being conducted "in projects in OpenJDK" -- that is, try to blur the distinction of the specification and the implementation. The goal being to ensure that there is only a single implementation. Of course, with only a single implementation the specification becomes moot -- the implementation does whatever it does.
That's how I get to my conclusion, that this may be the beginning of the end for the JCP. By granting a suitable license to Apache, Sun would demonstrate to the community that the JCP is more than a mechanism by which they attract contributions to a single implementation they control. They may be persuaded to do so, even if they would prefer not to.
[2007-07-09 Edited to remove duplication junk, maybe caused by using a dollar sign?]
Posts
8 comments:
I think an effective way of fixing JCP's problems (proprietary TCKs, NDAs, proprietary RIs, etc.) would be to vote off those organizations from the ECs in following elections that as spec leads are responsible for JSRs with proprietary RIs, TCKs or NDAs.
Dalibor, as you suggesting to get Sun out of the JCP?
(remember, you can't vote them out...)
If the EC doesn't act against JSRs that tie in proprietary software into open standards, then the most effective way to get the EC to act in the interests of the open source community would be to gradually replace through future elections those proprietary software vendors sitting on the EC that want to game the system in their favour, by individuals and organizations that don't want to do that, and openly oppose such games.
Even if Sun's EC seat is never up for elections (and assuming Sun continues to tie in proprietary TCKs into JSRs in the future), it'd be sufficient to vote in a blocking majority by replacing other vendors on the EC.
We can stand where we are today and throw rocks at the JCP for their history, but it is not at all obvious to me that the mega-corps involved would have invested so deeply in the advancement of Java without the proprietary, protectionist practices that were originally put in place. We should praise the JCP for having done it's job, and give credit where it is due.
In 2007, with OpenJDK bootstrapping itself, and Apache Harmony becoming a credible alternative implementation, the standards process must change to remove the old-school working and embrace the new open working practices. I'm an evolutionist rather than revolutionist, so I'd like to see the JCP adapt into a forum for the advancement of open standards in Java, taking its members with it. It will likely mean rewriting some agreements, kicking off a few people/organizations who don't want to change (as Dalibor said), and moving the power from a single entity to a representative group.
The time to start being more open is 'now'. The question is: can the JCP adapt quickly enough? Given the speed at which the mega-corps members can change, I have my concerns.
The mega-corps will follow the market. The market for standards these days increasingly favors open standards over closed ones.
The JCP is largely moving in that direction, as well, with Sun licensing all the core ME/SE/EE RIs as free software, IBM doing the same for 291, and most new JSRs opening up their communication channels, strawman proposals, and RI code for the general public.
The remaining barrier to participation are the proprietary TCKs.
What the JCP needs now is
* a well-formulated platform for JCP 3.0 that will allow people driving the change inside the mega-corps towards openness to build upon, and
* a faction on the EC with sufficient courage to drive that change in public, in face of potential opposition from proprietary software vendors.
I'd prefer doing all that in team with ASF, IBM, Sun, Red Hat, etc. eventually.
IMHO JSR291 is not a good example of the JCP becoming more open. The spec, impl, and tck work was not conducted in the JSR expert group, rather JSR291 was a formalization of work done outside the JCP(*). The existence of such "pointer JSRs" was condemned by a number of voters on that spec.
The goal should be to work in the open directly in the JCP. As things stand today contributions to a JSR are under the terms of the JSPA, and that is how contributions and JSRs have to be evaluated. Attempts to make things 'more proprietary' than the JSPA allows, or 'more open', are destined to be voted down. Examples from yesterday are JSR280 and JSR190.
I share your hope that the JCP can move its membership to a new model of openness. But with new JSRs being proposed, some in-flight, and some completed, it is going to be like changing the engine in your car as you drive down the autobahn. As I wrote in the original blog post, I see Sun moving to an open model by moving the work into OpenJDK/java.net projects and trying to convince the JCP members to follow.
(*) and only some of that in the open. The spec and TCK work was conducted within OSGi, a paid-up members-only organization, though the resulting licenses do appear quite 'friendly'.
I'd be surprised if attempts to make things more open would get voted down (at least I've never seen a JCP vote fail because the JSRs terms were too open, but I only follow the JCP sporadically).
Post a Comment