The Artima Developer Community
Sponsored Link

Leading-Edge Java
Should More Individuals Join the JCP?
by Frank Sommers and Bill Venners
May 25, 2006

<<  Page 2 of 2


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, 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.


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.

Talk back!

Have an opinion about the individual's role in developing Java standards? Discuss this article in the Articles Forum topic, Should More Individuals Join the JCP?.


Ken Arnold's blog post about the JCP, JCP Wants You, Sort of, It Thinks...:

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.

<<  Page 2 of 2

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use