Open letter to the JCP Executive Committee calling for JCP reform

November 01, 2010

Seizing the opportunity of a new Executive Committee (EC) under a new regime, I'd like to issue a call for reform of the Java Community Process (JCP) to allow it to produce more iterative and timely technology and live up to it's name as a "community process", rather than acting as the "corporate process" many believe it is today [1].

Goals and current problems

The goal and of this call to action parallels a statement made by Mark Little, CTO of JBoss and member of the EC, in response to questions for the 2010 EC candidates [2].

We believe that the EC still has an important role to play in the future of Java, and working within the EC is the best place to push for change and improvements. Java is certainly more "open" now than it was a decade ago, but it's not as open as [...] other standards bodies [OMG, OASIS, W3C and IETF]. We would like to see that change.

Indeed, the central problem with the current JCP is lack of transparency and openness. Although the JCP defines itself as "the open, participative process to develop and revise the Java technology specifications, reference implementations and test suites", it's not very open nor participative in practice. The community is almost entirely excluded when developing so called "open standards".

The root cause of this problem is that the Expert Group (EG) mailinglists are not open to the public (save a few exceptions, notably JSR-303 and JSR-311). The mailinglists are where the bulk of the technology design takes place. The private mailinglists don't merely close the doors to the general public. EG members from one JSR can't even read the correspondence of another JSR.

Feedback is one directional, from community to EG. All the general public can see are the drafts of the JSRs. They don't know how the EG arrived at that draft, meaning they aren't able to study the discussions that went into it. The EG may reciprocate by publishing another specification draft, with or without the feedback incorporated.

While companies and major Java leaders are involved in the JCP, individuals from the Java community have to really fight to be included or provide feedback. Let us not forget the significance of their participation, as Mark Little points out.

A strong JCP and a strong EC should be to the benefit of the entire Java community and not just to a select few.

The JCP also fails to respect the nature of software development. Instead of following an iterative process, JSRs target big-bang releases that have no clear continuum to the next generation. These major shifts in the platform make it increasingly harder for consumers to carry out migrations. Smaller releases would be easier to adopt. There are also huge lapses between releases, which is time for the technology to fall out of date.

How can we expect to define a unified and consistent platform that integrates well if the technologies bundled are created in different campuses at different times? The decisions that occur behind close doors effectively turn off would be participants and consumers. The community becomes frustrated because they don't know what's going on.

It's true that progress can emerge even from even a crippled process. There's no doubt that Java EE has been experiencing a revival since the release of Java EE 6, but with no clear target for EE 7, how long can the honeymoon last? Bill Burke cites how a small company like Red Hat has been able to make a big impact on the JCP standards [3]. He provides this evidence to make the point that the JCP is salvageable. Great, so let's salvage it and get it moving again.

The call for reform

I propose that the JCP redefine itself as:

"An open, community-oriented standards organization that produces standard technical specifications for Java technology in order to keep it competitive and to bring value and choice to businesses worldwide. These goals are achieved by honoring the nature of software development, which means fostering a collaborative, evolutionary process where change of all types (addition, revision and deprecation) is inevitable and standards are snapshots in a timeline along that evolution.

Standards produced by this process are published under and open, non-clickthrough license, which applies to the specification documents, the APIs, the reference implementations (RIs) and the compatibility test suites (TCKs). A fair voting system is used to maintain a balance of power and there is complete openness of process and membership.

The goal of this organization, above all else, is to produce timely, iterative, high-quality standards, which means never standing in the way of progress nor precluding proposals or ideas that may lead to a better way forward."

To make it very clear what changes I'm calling for, I've itemized them below, ranging from "must have" to "nice to have".

Must haves:

Specifications must be published under and open, non-clickthrough license, which covers the specification documents, the APIs, the reference implementations and the compatibility test suites
Specifications should be free to use and implement (no TCK fees)
Specifications must provide a non-clickthrough specification document, stored in an open VCS system and easily viewable online by anyone (a nightly build of the spec would be sufficient of the document is created by for-pay software)
Specifications should be required to publish API binaries, sources, and JavaDocs to Maven Central
Specifications must have public issue trackers, open source TCKs and public mailinglists for all JSRs, and require information about these resources to be public and easy to find
Expert Groups (EGs) should not be automatically disbanded after a final release of a spec (maintenance releases are an extremely important part of a JSR's evolution)
Maintenance releases should be easier to initiate (and get approved); the software process should be iterative
Names of individual representatives, and the company they represent, should be listed on the specification page; it should be clear who the representatives are
There should be an official process for deprecating or removing a technology; old technologies currently die a slow unused death, dragging the platform down, and leaving complexity in its wake as vendors are required to pass the TCKs; let's not hide behind the term "pruning"
All specification communication must be considered public, and should be archived, unless initiated privately by a member of the community

For accessibility:

Specification documents should be made available in HTML format for easy web access; PDFs should merely be one viewing option, not the only one
Specifications should provide end-user, user-case driven documentation for a technology (for instance like the first half of the Weld reference guide and the Java EE tutorial)
Decent and familiar social business software should be used for jcp.org to make it truly a community (jcp.org is extremely difficult to use and poorly organized)
jcp.org should host all the specification artifacts (specification document, API, reference implementation and TCK) (there is currently too much burden on developer to find them)
Specification artifacts should require no more than two clicks to begin said download, with no login required

Nice to have:

Periodic EC meetings should be open to the public
Platform releases (i.e., Java EE) should occur at regular, scheduled intervals, every 6 months or so, with clear paths for ratification and deprecation of JSRs.
The JCP should be an independent organization, similar in structure to the Eclipse foundation; it should be run and funded by donations/investments rather than petty membership fees
JSRs must be allowed to compete with each other, or standards evolution merely excludes and fragments participation within the Java community (for instance, one view technology is not sufficient)

Support and endorsement

The evidence of a general call for JCP reform is widespread.

Earlier this year, Mark Little, Red Hat's representative on the EC, called for a more open process, with everyone acting as peers. [4] He reinforced those statements in his follow-up to questions posed to the EC candidates. [2] IBM states on their standards page that they will "begin or end participation in standards bodies based on the quality and openness of their processes, membership rules, and intellectual property policies." [5] Bob Sutor has said that IBM expects to see "long needed reforms in the JCP [...] to make it more democratic, transparent, and open." [6] In an open letter from the CTO of SAP, Vishal Sikka, he calls for more openness in the JCP, saying "To ensure the continued role of Java in driving economic growth, we believe it is essential to transition the stewardship of the language and platform into an authentically open body that is not dominated by an individual corporation." [7] Darryl K. Taft published an editorial in eWeek outlining 15 guidelines for making Java better, one of which included setting the JCP free. [8] Doug Lea made a firm statement a few weeks ago that the JCP is no longer a credible standards organization [9]. And we cannot forget the long-standing open letter from the Apache Software Foundation to Sun asking to have the IP rights restrictions on the Java SE TCK removed. "[F]ailure to comply with your contractual obligations poses serious risk to the credibility of the JCP as an open standards organization, and the reputation of Java itself as an open technology." [10]

There are numerous other public statements on the web of calls for JCP reform.

Summary

I'm calling for reform of the JCP. I want the JCP to be accountable to its namesake, a "community process." The fact that the JCP claims to be open but does not uphold this promise tarnishes it and causes people to lose trust. It's a tragedy that the technology is way ahead of the process.

But hope is not lost. A few fundamental changes would drastically improve the effectiveness and credibility of the JCP. As Mark Little has said, "we would like to see the JCP continue to evolve and address those issues which we all know tarnish it."

I hope that the new EC is brave enough to rise to this challenge.

Signed,

Dan Allen
Lincoln Baxter, III

This call to action represents my personal viewpoints. I am not speaking on behalf of my current employer, Red Hat.

Refer to the corresponding entry on PetitionOnline to find a count of the signatures.

References

Posted at 02:32 PM in Java | Permalink

mojavelinux.com: Open Source Advocacy