In a recent survey conducted by the Java Community Process (JCP) Program Management Office (PMO), 30 Spec Leads stated they were hosting development of the specification, RI, or TCK on a collaboration website. Two-thirds of those Spec Leads turned to java.net to support their efforts, but there are actually scores of technology incubators available to Spec Leads.

Several years ago, this opportunity was virtually unacknowledged by Spec Leads within the JCP program. They asked for more tools from the PMO when they didn't often find an acceptable mix of helpful services elsewhere. While it's true that from the very beginning, Spec Leads have been known to create parallel JSR webpages on their own websites, the use of websites that are intentionally conducive for collaboration and open-source development is rather recent.

Here are some case studies of Spec Leads who are blazing the trail into new online places that enable vigorous, transparent, and agile collaboration among Expert Group members, JCP community members, and the public:

• JSR 113: On conversations.com
• JSR 231: On JOGL Forum
• JSR 241: On codehaus.org
• JSR 243: On apache.org
• JSR 303: On hibernate.org

In his professional domain, Charles Hemphill is all about accessibility. As a Senior Speech Scientist working with Conversational Computing Corporation, he is involved in developing speech technology for mobile devices. As co-Spec Leads for JSR 113, Java Speech API 2.0, he and Steve Rondel are establishing a new Java standard for speech interfaces, enabling faster, easier, and potentially safer interactions with hardware and software.

Charles Hemphill

Another kind of accessibility has to do with information. The JCP Program Management Office (PMO) and Executive Committees (ECs) have been stressing the importance of conducting standards development in a way that allows the community to see what is going on as the effort continues. "Transparency is essential to community involvement. People need to know that we listen and respond to feedback," says Charles. He believes in operating transparently when possible, and he uses several websites to control the extent of the transparency.

For public communications that anyone can access, Charles relies on the regular jcp.org page, which allows downloads. That's where he posted the Public Review, Proposed Final Draft, and Proposed Final Draft 2. Moreover, anyone can ask a question or make a suggestion about the JSR by emailing the standard address that is listed on the webpage, jsr-113-comments@jcp.org, and the Spec Leads will reply.

Even more information is available to the public at the collaboration website, www.conversations.com. For example, anyone can download the latest drafts of the specification and free trial Reference Implementation (RI) for the PC. Anyone can also join and participate in the open developer forum, and there is no charge for the required registration.

Charles also maintains a website at www.jsapi2.org, which is password-protected to allow access only to Expert Group members. This is where most of the working information is posted, including the latest specification version under consideration (Javadoc), minutes of previous meetings, the agenda for the next meeting, a Bugzilla to track change requests, working examples, RI and Technology Compatibility Kit (TCK) documentation, and maintenance ideas.

Originally, Charles decided to use collaboration websites when they felt constrained in terms of services they wanted to deploy. Once they took their project elsewhere, they were able to install Bugzilla on jsapi2.org and use conversations.com to host downloads and forums. Charles cites "flexibility to rapidly try and implement beneficial features" as the most important asset in using a collaboration website, and he'd make the same choice if he had it to do all over again. "It was relatively easy and met our needs and the needs of the community," he says.



"All evolution of the JSR 231 project has been done in the open," says Spec Lead Kenneth Russell, Senior Staff Engineer at Sun Microsystems, Inc. JSR 231, Java Binding for the OpenGL API, has enjoyed a full, active, and transparent lifespan, which continues even now. Work on it started in 2003, followed by the approval of a Final Release in 2006, a Maintenance Release in 2007, and a second Maintenance Release in 2008. JSR 231 is scheduled to undergo substantial revision in the coming months, going forward in a two-pronged fashion as it has since its inception, with open information at java.net and open conversation at javagaming.org.

Ken Russell

Ken plans to carry on the project "in the most transparent way possible: in the form of an open source project at http://jogl.dev.java.net/." Open collaboration is a way of life for JSR 231; JOGL (Java Open Graphics Library) was one of the projects that launched with the java.net website. Ken continues relying on the java.net page to offer the public JOGL demos, documentation for implementing JOGL, the current nightly build, and examples of products using JOGL. A link takes contributors to the JOGL forum, where specific conversations help hammer out the scope and features of the technology.

When the Expert Group was actively working on the first release of JSR 231, they actively solicited feedback from the community through the JOGL forum at http://www.javagaming.org/index.php/board,25.0.html. This forum is still the primary discussion area for the project, and anyone is welcome to register and lurk or contribute. A nifty legend at the bottom of the page indicates the popularity of a topic based on the number of comments, and whether the thread is "locked," "sticky," or a poll. Ken gives credit to Chris Melissinos, Sun's Chief Gaming Officer, who runs javagaming.org on his own dime to encourage the growth of the Java gaming technology market.

Ken does not exploit the potential of the JCP.org webpage for JSR 231, although he keeps it up-to-date in terms of downloadable releases. "Since we have to go through a middleman to post content on the site, it is much easier for us to post information on jogl.dev.java.net or our forums. If we had more direct control over the JCP.org page we might utilize it more," he says. He finds that it's not necessary to advertise the JOGL forum to show contributors the way in. Although the sites are distanced from JCP.org, they get plenty of foot traffic when people do a Google search on jogl. http://jogl.dev.java.net/ is the number one site to match the query.



"Codehaus offers the best set of tools to develop an Open Source project: website, Confluence wiki, JIRA issue tracker, mailing lists, continuous integration server, download statistics, etcetera. And the administrators of the community are really helpful and responsive in case of need," says Guillaume Laforge, former Vice-President Technology at G2One, Inc., and now head of Groovy Development at SpringSource. With such a glowing review, it's unfortunate that few JCP Spec Leads besides Guillaume have set up shop on the collaborative website, http://www.codehaus.org.

Guillaume Laforge

In 2006, Guillaume assumed leadership of JSR 241, The Groovy Programming Language, to develop the project in an open, one-stop-shopping manner. Guillaume relies on the pragmatic benefit of developing a JSR through a collaboration website such as Codehaus. He says, "The more eyes, earlier on, with a practical and usable prototype, is key to the success of a project, compared to a formal theoretical specification nobody has ever implemented and used in the wild." More people seem to find the project on codehaus.org than they do the project's default page on JCP.org.

Guillaume has made use of many of the powerful services at his disposal through Codehaus. For example, some discussion and development about Groovy development takes place on two webpages through Confluence, an Enterprise wiki. The first webpage relates more to the specific progress of the JSR, and the second webpage encompasses more of an introduction to the documentation, modules, code samples, news, and discussion.

Most of the action actually takes place on the various mailing lists hosted at Codehaus -- the developer mailing lists, the JSR mailing list, and the user mailing list. The Groovy project mailing lists are hosted by the Codehaus Open Source community. Anyone who is interested can subscribe or search the archive.

Guillaume and the original Spec Lead of JSR 241 have not been able to devote as much time to developing the specification as they had hoped. Nevertheless, with the involvement of the community through Codehaus, progress has continued. Despite the fact that the jcp.org page lists the JSR's status as being in the "expert group formation" stage, the Groovy project is actually quite advanced. All parts of the JSR are being developed through the Groovy Open Source project. The downloads webpage includes development (unstable) releases and stable releases of the Javadoc, Reference Implementation (RI), and Technology Compatibility Kit (TCK). The Groovy RI and TCK are licensed under the open-source Apache Software License (ASL) 2.

Bugs and issues are tracked publicly through JIRA. The tracker offers charts, lists, and reports to reveal who is doing the fixes, the relative priority of the issues still on the table, the proportion of issues that have been resolved, and so on.

If he could do it all over again, "I'd stick to Codehaus knowing how great the community and infrastructure is," says Guillaume.



A thousand flowers are blooming in the open on the apache.org collaboration site, and JSR 243, Java Data Objects 2.0 - An Extension to the JDO specification, is one of them. Spec Lead Craig Russell, an architect with Sun Microsystems' Java Enterprise System, is overseeing the growth of this JSR, now in Maintenance Release 2. He says, "Openness and transparency are important for JDO so that users and vendors alike can be sure that no one group of vendors can dominate the evolution of the specification, and many kinds of databases and containers can implement and exploit its features."

Craig Russell

Practically all activities related to JSR 243 start from or are conducted on the apache.org collaboration website. This site is vast, but the public Apache JDO home page makes it easy for a person to approach JDO in whatever way is preferred. In addition to some general orientation information discussing "Why JDO?" and comparing it with alternatives, the well-organized site offers downloads, an explanation of the Apache License and guidelines for JDO usage, and links to the Technology Compatibility Kit (TCK).

One section of the home page's left navigation bar is devoted to the Community, which really means the public and anyone interested in JDO. This section features ways to get involved, an introduction to the project team of committers and contributors, an FAQ for newbies, and a Wiki that is one of the places where issues are discussed.

The public can subscribe to any of three open mailing lists that are pointed to from the home page: one for general discussion of the project, a second on which JDO developers "make the sausage," and a third for specific commits. The "commits" list is for anyone who is serious about monitoring the actual code repository. Comments are posted to the JDO-expert alias, to which any person may subscribe upon request.

Development continues, and links on the home page point out how to participate in it. Source code is managed by Subversion, and anyone can check code out of it. A page on coding standards gives explanations and examples of how to structure the code. Issue-tracking is done through JIRA, which makes the status clear. Frequent regular releases offer plenty of opportunities for observers to make comments on what is current.

Meanwhile, the JCP.org page continues to display the official status of the JSR. Craig updates it and posts downloadable drafts of the specification on JSR 243's formal webpage. "The jcp.org website is useful for the community to quickly find all of the official communications of the project according to the rules of the JCP program," says Craig.

Still, Craig encourages Spec Leads to visit the Apache Software Foundation (ASF) homepage and see if the vision of community, transparency, and collaboration fit the goals and working style of their Expert Groups. The Apache license, under which the specification jar files and TCK are distributed, protects the rights of contributors and users alike. The website's tools "allow ideas to be fully discussed and prioritized by the community," and specific changes "can be quickly resolved by all stakeholders, including both vendors and users," he says.



In developing a technology, sometimes a Spec Lead will choose a collaboration website to work on, and sometimes a collaboration website will choose a technology to work on. In the case of JSR 303, Bean Validation, the latter scenario prevailed. Bean Validation originally emerged from various validation frameworks, including the Hibernate Validator. The Hibernate community showed interest in the Bean Validation standardization process. "Hosting the RI, the issue tracker, and the feedback forum on hibernate.org was a natural choice to increase feedback and visibility," says Spec Lead Emmanuel Bernard, who is a core developer at JBoss, a division of Red Hat.

Emmanuel Bernard

In using hibernate.org, Emmanuel found the community, the development process, and the tools to be tremendous assets. His only wish is that he had started working openly on the specification much earlier in the process. "This would have provided better feedback early on and enhanced the chances of adoption by the Java community even further," he says. In fact, the decision to operate with transparency and "leverage the community" did not occur until after work on the Reference Implementation (RI) had begun.

Emmanuel appreciates the visibility offered by the project's JCP.org page, but he notes that it is not easy to customize. Moreover, it hasn't been difficult to pull participants into his Hibernate collaboration site. The Hibernate community and others typically find their way to the JSR 303's collaboration webpage through the blog of the Hibernate team. From there, viewers can use the left navigation "Bloggers" bar to migrate to Emmanuel's page or the right navigation "Tags" bar to jump to the Bean Validation page.

Either way, there are plenty of routes to Emmanuel's sneak peeks into the Bean Validation technology, the Feedback Forum, the current Reference Implementation in SVN (Subversion), and a JIRA issue tracker. In his "sneak peeks," Emmanuel explains with specific examples what the specification does, and offers an opportunity for viewers to make quick comments on the topic.

Having taken the plunge himself into a new way of doing things, Emmanuel now urges other Spec Leads to embrace transparency. He says, "The open source model of development has proved to be useful, including for developing specifications. One should not be afraid of using this model."



Go to Spec Lead Guide