Why JCP 2.6 may placate disenchanted community members — for awhile

Fifteen months ago, I wrote in a Builder.com article that the Java Community Process (JCP) was either going to have to make its movements more transparent to the community at large and steer clear of political potholes or risk becoming an albatross of epic proportions. In June, JCP leaders were asked at a JavaOne panel discussion if change was indeed in the offing. They said yes, but couldn’t be specific about how much change was coming. Now, at last, the community is actually seeing some progress.The JCP, the only community IT organization that uses version numbers for its rulebook, last week announced JCP 2.6, which includes provisions for making the process from idea to product delivery much more community-minded.

Sun Microsystems, the gatekeeper for Java and home of the JCP program office, called JCP 2.6 “the most transparent and accessible iteration in the program’s evolution to date. The process enhancements give earlier access to draft specifications to a broader group of developers and add more value at each level of participation. This makes it easier and more rewarding for developers to get involved in the Java technology standards definition process.”

Sun said this new rulebook version better services developers’ needs by adding new efficiencies to the process. JCP 2.6:

• sets the stage for both JCP and non-JCP members to contribute their input to an early review Java Specification Request (JSR) cycle, creating a more open and inclusive community;
• provides spec leads with new processes and tools that make it easier for them to drive more accessible JSRs and better communicate information about specifications to the community; and
• encourages spec leads to enter review periods sooner, enabling a more efficient process and results that benefit from a broad public input.

Essentially, the biggest change in the overall process is that the public window for examining each proposal’s code (in each JSR) is opened wider, with the available start time sooner and the closing later.

“Basically, we’ve opened the public time for evaluating each JSR from six to nine months, and it (the window) takes place much earlier in the process,” JCP assistant program director Aaron Williams told NewsForge.

“What we’d like to see happen more often is at-large community members joining expert groups, and more developers from expert groups becoming spec leads or initiating JSRs,” Williams said. “But they’ve been wary of the process. They just weren’t sure what they were getting into.”

Williams said the internal community Web page for each JSR will now be accessible by interested community members outside the expert group with password authentification.

The main problem not addressed, and the most difficult problem of all, is politics. Companies with the biggest investments in J2EE — IBM, BEA, Oracle, and Borland, for example — were perceived as being able to get JSRs passed more quickly and efficiently, particularly if they directly involved one of their current products. For example, in 2001 BEA was thought to have railroaded through a JSR it had championed to improve several of its servers, much to the dismay of many community members.

Will the more transparent process stop things like that from happening? Nobody really knows.

Perceptions = reality?

Active membership in the JCP can be extremely valuable for an IT company, in terms of directly helping to advance the Java standard and for bringing international attention, respect, and prestige to the company itself. But, as is inevitable in large organizations, politics caused an unseemly stench in the JCP. Some of the perceptions that were (and, in fact, still are) worrying community members include:

• JCP was losing its focus. It was no longer seen as a solutions-oriented community but instead as a rubber stamp to sanction specifications championed by larger corporations — the ones who have the financial and legal muscle to lobby for specifications that eventually mean profits for themselves. BEA Systems and IBM were two companies often accused of this activity.
• It was paying lip service to smaller players, such as individuals and start-up companies.
• If you were not a voting member of the JCP, the online organization was far from transparent — which ostensibly is the goal of such an open standards community.
• An independent developer with a good idea had to get the backing of a larger organization (Apache Software Foundation, Free Software Foundation, etc.) to get a standard established.

“Fewer and fewer new people are involving themselves directly with JCP,” Matt Liotta of Montara Software, an Atlanta-based maker of Web content development systems, said. “Instead, they are hooking up with groups like Apache and getting their wares to become de facto standards. Later, Apache pushes these implementations into the JCP under its own name.”

Other Java developers, such as author and Java columnist Sue Spielman of Switchback Software of Denver, Colo., have other viewpoints. Spielman says there have been so many JSRs proposed that they have “exploded the Java API. While this isn’t necessarily a bad thing, it certainly is a challenge to the Java developer who tries to stay up on the happenings in the JCP. This could very well be one of the reasons that in the eyes of the developers, the JCP is bloated and crawling at a snail’s pace. It has become impossible for anyone to keep up on all of the JSRs that are currently in proposal and various review stages.”

So, thanks to JCP 2.6, it looks like the organization is finally beginning to make a U-turn back toward those who made it go in the first place — developers, the people who actually come up with the ideas. Will it soothe some of the hard feelings of the past? Time will surely tell. We’ll mark the calendar and revisit this in about six months.