In this editorial, we argue that greater individual involvement in the JCP would lead
to better specifications, and that more individual developer members could provide a
healthy balance between vendor perspectives and those of users.

In his JavaOne keynote, Sun's new CEO Jonathan Schwartz credited the Java Community
Process (JCP) for Java's widespread use and industry acceptance, but lamented that
there are not enough individual members of the JCP:

This is not a heavy-weight corporate kind of environment. You go to JCP.org, you
register as an individual . . . We want to make sure that all voices are heard in the process
. . . This is not about corporations defining a technology platform, this is about users and
citizens and developers defining that platform.

In a recent blog entry, Ken Arnold responded that the JCP is still a corporate-heavy
organization, and pointed to lack of individual representation as an important reason for
the relatively few individual JCP members:

Obviously there are simply too few actual individuals on the EC [executive committees] . .
. . Two of sixteen [executive committee members] in one case, and zero of sixteen in
another, isn't much representation for us individuals who are being pushed to sign up. If
we sign up, where is our practical representation as major stakeholders? . . . In political
terms, this is an oligarchy, a governing system where the final decisions are in the hands
of an elite . . . As individuals we should join, but the JCP needs a more open system that
allows all stakeholders, not primarily the largest, a part in the final decisions.

While joining the JCP as an individual member is free, Arnold suggests
the eleven-page legal document individual applicants must sign is an impediment.
Even if that barrier were lowered, how would an individual
developer benefit by joining the JCP? And how would the JCP benefit from more
individual members?

Time Demands of the Reference Implementation and TCK

We gained some insights into the issue of individual JCP membership while moderating a
JavaOne panel on the JCP. The panel included several members of the JCP executive
committees and a few spec leads, and among the topics discussed was the JCP's
relationship to other Java communities and individual developers.

According to JCP chair Onno Kluyt about 65% of the 1050 members are individuals,
the rest represent commercial or non-profit organizations. While an individual's most obvious
benefit of joining the JCP is the ability to vote on executive
committee members, a more exciting reason is to participate on expert groups that
develop the JCP specifications.

Each expert group specification lead is free to decide the manner in which his or her JSR specification
work is conducted, as well as the license for the expert group's end products (which may
be an open-source license). What the specification lead is not free to decide, though, is just
what those products are. For every specification, the JCP mandates a reference
implementation (RI) as well as a technology compatibility kit (TCK)—a set of automated tests used to verify
the conformance of other implementations to the spec.

The requirement for a working RI and TCK distinguish the JCP
from other standards bodies, and ensure that the specification defines a realistic and
useful system. The result is that for every finished JSR, there is a working
implementation—something you can test and download, provided the expert group's
license allows for free distribution. However, this requirement also puts the onus on the
expert group members to produce the RI and TCK along with
the specification document.

The RI and TCK requirements are probably the biggest impediment against individual members.
JCP members representing themselves on expert groups seldom have the time to dedicate
to writing the large amounts of code often required for the RI and
TCK. One of the panelists, Hani Suleiman, CTO of Formicary and one of the two individual
executive committee members, noted that:

Joining an expert group . . . is a much bigger investment [than joining Java.net, for
instance]. There's a much higher barrier to entry [and] most developers will not want to
do that because it expects a lot of them. It's a big investment personally. For a company,
they need to dedicate resource to it, towards furthering a spec. Which is why the JCP will
always be much smaller than Java.net.

Because not just discussion, but real work is expected of the expert group members, the
JCP's requirements for a RI and TCK may seem to favor large
companies with significant resources to dedicate to the process. More recently, however,
expert groups increasingly take advantage of open source communities to develop the
reference implementation.

Glassfish, for instance, is the reference implementation of Java EE 5 (JSR 244), and is
developed as an open-source project on Java.net.
According to the project's online
documentation, the Glassfish community has over 100 contributors, noting that "The
number of Sun and Oracle engineers working on this product is comparable in size to
other application server developer communities today." Anyone, including individual
java.net members who are not JCP members, can request a contributor account from the
project lead.

JAXB and JAX-RPC are other examples of JSRs that develop their reference
implementations that way. JSR 170, the Java Content Repository API, in turn, chose the
Apache community to develop its reference implementation and TCK. And perhaps the
best-known Apache-developed reference implementation is Tomcat, which serves as the
official reference implementation for the Servlet and JSP specs.

The Value of User Feedback

Even when a JSR expert group chooses a not strictly open-source license for
release of its source code and other artifacts, the expert group benefits from early
feedback. Graham Hamilton, Sun's JCP Executive Committee representative,
noted the value of community feedback to the Mustang community on java.net, built
around the early release versions of JDK 6:

With the Mustang community . . . we're able to make early-access implementations [of
Java SE 6] available . . . and we get feedback about the spec as it's evolving. Sometimes
developers give us very direct feedback, that's very valuable to an expert group. I guess
one benefit is for a broader group of people giving feedback, rather than just [getting
feedback from] an expert group.

If non-JCP member developers can already partake in creating the code for a JSR
reference implementation and TCK—arguably the most labor-intensive components of a
JSR--how would developers benefit from joining the JCP proper?
JCP chair Kluyt put it this way:

There are two kinds of developers. Those that are interested in what the plumbing looks
like and [want to] help create the plumbing; and those that want to build solutions on top
of [that plumbing] . . . I don't think it's practical to assume that half a million developers
will be personally motivated to help develop the EJB spec [for instance]. There is some
natural filtering that happens [between] developers who want to be active developing the
standard versus those developers that are primarily interested making use of the standard.

Asko Komsi, Director of Industry Relations for Nokia, and lead of several Java ME JSRs,
pointed out the different roles various Java communities play:

If you really want to work on plumbing, then it's a good idea to join the JCP. [Otherwise]
there are organizations like, for instance, Nokia's developer community supporting
developers from an application developer's point of view, and we have about 2.5 million
members. We can handle that many people.

But could the JCP handle a large influx of new members? Ken Arnold ponders how the
JCP could make a standard with, say, 1.5 million JCP members: "While it is a smart
question, it will only actually matter when the JCP's question is: 'Given that we need to
have smaller companies and individuals, how will we make a standard with 1.5 million
JCP members?' When posed that way, it will be solved." JCP chair Kluyt is not so sure:
"Just as no open source software project can tolerate millions of committers, neither can
the Java community survive with a 1.5 million spec leads."

Whether the JCP can scale up is an open question. What all current JCP members seem to
agree, though, is that more individual participation will benefit the JCP. Sun's Hamilton
put it this way:

A large number of fairly active practitioners [are] participating. These are the people
actually using the technologies they're helping to create. That ultimately leads to a very
focused set of advice. These people are very passionate about how they want to use the
technology.

EC member Suleiman noted that:

You can see that in a lot of the expert groups now that there is a very active search by the
spec leads who will go out to make sure that a number of expert group members are
practitioners: people who have an expertise in this area in terms of users, people who
adopt the technology, not just people who provide it.

Sun's Hamilton agreed:

We also want technical experts who come at it more from a technology user perspective
as opposed to just the vendors who will be creating the technology. Having individual
experts who are willing to commit time to JSRs is incredible valuable. But it's quite hard
to find people who are willing to spend the time to really impact a JSR.

Indeed, having too many experts providing input into a specification runs the risk not
only of producing a result resembling a camel (a horse designed by committee), but also
of producing specs that don't address the average user's needs. Hamilton put it this way:

We have to remember that we're designing specs for non-experts . . . You have to
consciously think that not everyone is interested in the most exotic corner cases. Most
people are interested in the simple cases. Our job as experts is actually to make things
simple for common use-cases. Yes, we can have fun worrying about the corner cases, but
making the simple cases simple is a big challenge as experts.

In our opinion, more such user-experts would result in better specifications. The
communities built around the implementation are really about those implementations, not
so much about the specifications. For instance, one would join the Glassfish community
to download and use the Java EE 5 reference implementation, not necessarily as a means
to provide feedback into some of the Java EE 5 specifications.

We're confident that the spec leads we met during this JavaOne look after the business
interests of their employer on their respective expert groups. That's their job. But each
one of them also impressed us as smart, competent engineers who care about technology.
In our opinion, the value of greater individual involvement in the JCP may not be so
much to improve the balance between commercial and purely technical interests, but
more to improve the balance between vendor perspectives and those of users.

The JCP's next task is to become more inclusive, and allow for early feedback from users
of JSRs, not just for expert feedback. This can be accomplished by expert groups giving
greater visibility into discussions taking place among experts, and by having mechanisms
for user feedback and comments on those discussions.

Conclusion

In his blog post, Ken Arnold noted that:

People seem more worried about the possibility of pointless feedback than
about missing valuable feedback. That's just weird. I've lived in many public design
situations, and the occasional problem child is many times overweighed by the value of
the feedback of passionate people you didn't think to involve, or the massive feedback of
casual users who, as outsiders, can tell you when you aren't doing things that serve them.

While it is true that too many cooks in the kitchen can slow down the development of
JSRs and place a bigger burden on already busy spec leads, expert groups would still
benefit from members that provide user feedback on the specification itself.

Resources

About the authors

Frank Sommers is a Senior Editor with Artima Developer.
Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.
He is an elected member of the Jini Community's Technical Advisory Committee.

Bill Venners is president of Artima Software, Inc. and editor-in-chief of
Artima Developer. He is author of the book, Inside the Java Virtual
Machine, a programmer-oriented survey of the Java platform's architecture
and internals. His popular columns in JavaWorld magazine covered Java
internals, object-oriented design, and Jini. Bill has been active in the Jini
Community since its inception. He led the Jini Community's ServiceUI project,
whose ServiceUI API became the de facto standard way to associate user
interfaces to Jini services. Bill also serves as an elected member of the Jini
Community's initial Technical Oversight Committee (TOC), and in this role
helped to define the governance process for the community.