Collaboration: Developing the JSR Components on a Hosted Website
By Susan Mitchell
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:
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, email@example.com, 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.
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.
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.
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.
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