by Susan Mitchell
The upgrading of the JCP program to version 2.6 (JCP 2.6) met a
tremendous need perceived by Java developers and enthusiasts, JCP
members, spec leads, and Executive Committee members. The primary
benefit of JCP 2.6 is the transparency it now requires, freeing
expert groups to reveal much more about a given Java Specification
Request (JSR) as it is being developed. With the mandated increase
in transparency, java.net saw an opportunity to support the specification
effort by creating a JSR community.
Once upon a time, Daniel Steinberg, now editor-in-chief of java.net, was one of the many people who hammered out Project Montague, the original code name for java.net. Launched during JavaOne
2003, java.net is now respected as the source for Java technology collaboration. The Project Montague team "always wanted a JSR community," but the JCP program rules at the time did not
permit expert groups to conduct business in a transparent fashion. The release of JCP 2.6 was a watershed moment that enabled the birth of the JSR community on java.net.
"As soon as I heard about JCP 2.6, I realized that a JSR community would be allowable, and I wanted to make sure that they happened on java.net," says Steinberg. He quickly reached out
to numerous people who were ready to help implement the concept. "I exchanged email with Doug Lea [on the JCP Executive Committee] after seeing a panel discussion at JavaOne 2003. I emailed
JCP Chair, Onno Kluyt and finally met with him last November at ApacheCon and followed up with Aaron Williams, JCP PMO Manager. I had conversations with Michael Nascimento Santos about him leading
such a community. And then there was the long process of making sure everything was done correctly. This phase consisted of a lot of hard work being done by our site producer Sarah Breen and
the java.net product manager Christian Cheline working with Aaron, Onno, and Michael."
When it comes to Java technology experience and interest, Santos is well credentialed. At the time he was invited to lead the fledgling JSR community, Santos was involved with java.net and helped
coordinate SouJava, one of the largest Brazilian Java user groups (JUGs). He is a Sun Certified Programmer for the Java 2 Platform 1.4, a Sun Certified Web Component Developer for J2EE, and a Sun Certified Mobile Application Developer. Santos has signed a JSPA and contributes to the JCP as an individual expert on JSR 207 Process Definition for Java and JSR 250 Common Annotations forthe Java Platform.
In his other life, Santos is a senior technical consultant for Summa Technologies do Brasil, which was awarded the Duke's Choice Award by Sun Microsystems for "extreme innovation" of Java technology in 2004. Santos was "more than glad" to accept the responsibilities of JSR community manager.
Because JSR information can be sensitive, some may wonder how much
insight Santos has into projects hosted by the JSR community. "The
only way I can get unrestricted access to a project is if one of
the project owners makes me a project owner. Besides knowing who
the project owners are, the only thing I am able to access for all
projects is the public description, message from owner, and public/private
parent project and status," says Santos. Project owners can
limit how much insight he has into their projects, "as long
as there's some acceptable degree of transparency."
A project can maintain appropriate transparency when its owner takes
at least one of the following actions:
Santos' privileges regarding regular projects such as JSRs allow him to initially approve/reject a project or to re-parent one anytime (which doesn't affect end users). He can also access java.net
management projects and change anything on the JSR community home page at any time.
- keeps a mailing list for general public discussion
- sends frequent announcements regarding issues under discussion and currently proposed solutions
- uses issuezilla to openly provide corrections or suggestions to the spec
- makes RI code freely available
- makes TCK code freely available
The JSR community was created to help JSRs achieve maximum transparency and openness, as mandated by JCP 2.6. Currently, although a draft release through the JCP program normally includes a feedback alias, only the expert group sees that feedback, leaving respondents unaware of each other's contributions. But if a group wants the best output possible, they'll prefer informed input. By leveraging java.net infrastructure, an expert group can get the Java community to participate in the process more easily.
For example, an expert group can get feedback early through public mailing lists where they can publish decisions or even unresolved issues and get more people to participate in them. Moreover,
in a group discussion, the expert group can discern more easily whether a feature is important to just the sole individual who suggested it or to the number of people who seconded his request.
In this way, someone on the mailing list can offer an opinion, giving the rest of the community the opportunity to voice their agreement or not, providing the group with a broad sense of what a
plurality of people really think.
The tools available for the JSR community on java.net complement
those hosted by the JCP program on jcp.org. To satisfy the JCP 2.6
requirement of creating a JSR transparently, spec leads will certainly
want to equip themselves with the following essential tools and
services now at http://community.java.net/jsr/:
Public mailing lists are especially useful in that they give subscribers
the opportunity to comment while offering insights into the topics
under debate by an expert group, updated spec status, and dates
for when drafts will be available. "We give complete freedom
to the expert groups so they can use whatever they want from java.net,
to the degree they want," says Santos. Some groups may feel
it's better to conduct most discussions privately and then post
to the public mailing list once the discussion has matured. Or they
may be concerned about protecting intellectual property or copyrighted
material in general. Expert groups can restrict access so that only
they have access to the Concurrent Versioning System (CVS), issue
tracker, forums and other resources when necessary. And when it
makes sense, they can offer these facilities to the general audience.
- file sharing for distributing releases
- mechanism for granting access to open-source reference
implementations and TCKs
- source code repository
- version control of the specification, Reference Implementation
(RI), and TCK
- issue tracker organizes posted notices about specification
bugs, and mistakes
- public and private mailing lists, forums, announcements,
and news groups
"We don't force expert groups to disclose any information they think shouldn't be made public. We want to make getting in contact with the community easier," Santos says.
Aside from time, there is no cost for joining the JSR community.
Most people do not join the community directly partly because they
don't have to belong to the JSR community to have access to its
resources. Those who do join typically get involved with specific
sub-projects of the JSRs they are interested in. Others might join
to promote the JSR community needs as a whole and to improve its
operation. JCP spec leads, however, ought to jump into the JSR community
with both feet. The upside is huge in terms of efficiencies gained
and the likelihood of ending up with a stronger specification, RI,
"The current community goal is to get more JSRs
to join so we can discuss and define the process and governance at a community
level," says Santos. "We want people to tell us what
they think about the JCP program and the way the JSRs are being conducted at
java.net, so everyone can do a better job and get better results."
An expert group that wants to join the community follows the normal java.net project
submission process, where a spec lead creates a username, proposes a project, and
explains that it is a public
project for a JSR. Santos approves the project, helps organize the project in a
way that meets the specific goals, and announces to the java.net community that
the expert group has joined the JSR
community. When a new project joins, Steinberg typically announces it in his today blog on the main page of java.net.
After a JSR has been approved as final by the JCP program, the expert group can continue to collect community input in preparation for the next version. Any mistakes can be recorded there, leading
to what might become a maintenance review.
Sun staff engineer Ed Burns is the co-spec lead for JSR 252, and the JSR252 project page. Burns heard about
the JSR community through the grapevine, that is, from a fellow spec lead who is now a satisfied JSR community member. "As a specification lead for the Java Server Faces
expert group, I think java.net is very well suited to satisfying section 2.16 of the JCP 2.6 program, which calls for transparency in expert group operations."
Burns planned to use java.net features such as their issue tracker and file-sharing section to allow for more transparency. "Practically speaking, the source code repository and the issue tracker are two things that we would have to have done on our own if it weren't for having these available to the JSR community on java.net."
Burns is still trying to figure out whether such transparency actually increases the quality of the specification by eliciting more and better user feedback. "That's what we're
hoping for, and it's too early to tell that," he says.
Liz Kiener, the JSR program manager for the JCP Program Management Office (PMO) is an important person for a spec lead to know. She has eyed java.net with interest "because it
provided tools that would be useful for JCP program spec leads and expert groups. When the JSR community began, that was the trigger that I needed to be involved. It's a very good collaboration
tool for spec leads."
By joining the JSR community, Kiener wanted to be introduced to participants as a way of letting spec leads know they can contact her with questions if they need help going through
the JCP program process. In her role with the JCP, Kiener facilitates collaboration between the spec leads of related JSRs such as JSR 176 and Tiger, through events including JCP
program training sessions, and by JCP updates and the PMO news. "I provide an environment similar to a mentor program where seasoned spec leads give advice to new and future
spec leads on how to go through the process and solve typical problems. This saves new spec leads time -- they don't have to reinvent the wheel," says Kiener.
The JCP PMO and JSR community look forward to their close collaboration. Kiener now belongs to the JSR community and can log into it. "We link to each other's sites. I note
in my JCP program training presentations that the JSR community is available on java.net," she says.
The opportunities for organized transparency that have opened up through the JSR community are impressive, and the price is right. In a nutshell, the JSR community offers spec
leads the essential tools and services for making the development of JSRs more efficient and transparent: public and private mailing lists, forums, announcements, and news groups, file sharing, source code repository, version control, and issue tracking.
Now is a great time for JCP spec leads, experts, and members to step into the JSR community and step up to shape its future. Members are always welcome to suggest improvements, and
Burns, for one, hopes the community will have access to more collaborative tools in the future. On his wish list are a shared white board information space that everyone can access
during a virtual expert group meeting and live public and private chat rooms for each JSR project.
Santos has plans of his own, to "promote integration between
members and give them even more of an active voice soon" by
making the JSR community home page a source of news about the JCP,
JSRs, and related subjects. He will also start a general jsr-community
mailing list for project owners in order to keep them informed of
the rules, foster discussion of pertinent issues, and permit them
to drive the community's evolution.