Every volunteer organization, no matter how beneficial or altruistic, faces a similar challenge: motivating participants to continue their work in the face of numerous pressures to spend time, energy, and resources on that rather than this. Until recently, the Java Community Process (JCP) standards organization has simply observed this phenomenon in the Spec Leads and members of Expert Groups who work together to develop Java Specification Requests (JSRs). Even though all par­ticipants have something to gain from their work on these efforts, it is not uncommon for competing interests to draw their attention away from time to time or even permanently.

In 2007, the JCP Program Management Office (PMO) began a discussion at the Executive Committee (EC) level to figure out a way to address this issue, which is one piece of an overall interest in increasing transparency within the JCP program. As JSRs stalled, the PMO sought effective ways to address those situations. In previous years, the PMO had contacted Spec Leads about projects that seemed dormant, asking them with ever more urgent emails and phone calls to resume the effort. Those communications met with three types of responses: a rededication to the work, a passing of responsibilities to a more available person, or a consistent refusal to respond.

Every JSR’s homepage reports the current status with a label such as In Progress, Rejected, or Final. By 2008, the PMO had developed a new label, Inactive, which was applied to dormant JSRs. JSRs are defined as Inactive when they have had “no stage posting in 12 months.” In other words, a JSR’s home page on the jcp.org website should indicate that it has progressed to a new stage -- Early Draft Review, Public Review, Public Review Ballot, and so on -- at least every year and a half. The PMO, with the EC, began using this mechanism in order to see how well it might remotivate stalled efforts, as well as to encourage feedback from Spec Leads and the community regarding how to deal with Inactive JSRs. As information is gathered, the PMO is considering whether and how to formalize the strategy into the JSR procedures of an upcoming version of the JCP.

Heather VanCura Chilson, the PMO Group Manager, says, “The intent is to increase the community's ability to understand where the JSR is in terms of development and to motivate spec leads to continue their JSR and publish a milestone, or withdraw it, or find a replacement Spec Lead if there has been a decline in interest or resources.” The PMO’s seminal presentations made on this topic to the Executive Committee during the 25-26 September 2008 face-to-face meeting and the 9 December 2008 teleconference are available for anyone to read.

As JCP protocols change over the years, the dynamic of the Expert Group also changes, sometimes in unexpected ways. We’ve come a long way from the days when it was acceptable to develop a JSR behind closed doors. In those days, the only insights the community might have into how quickly a JSR was being developed -- and would be available for implementation -- was often the timeline indicated by the stage postings. Now that Expert Groups are required to carry on in the open, and the process can be more iterative than linear, Spec Leads like Stephen Colebourne don’t feel the need to make formal postings or announcements. Stephen says JSR 310, Date and Time API, which he co-leads, went inactive “primarily because the JCP stage required was not as significant to an open-access project as to a closed project.”

Clearly, just because a JSR receives an Inactive label doesn't necessarily mean nothing is happening. Peter Dibble, for example, says that JSR 282, which he leads, “has been continuously active since it started, but we have been releasing our work in the form of alpha and beta Reference Implementations, with release notes. The JCP doesn't see that as activity, so we showed up as Inactive.” According to the JSR 282 webpage, the project was approved late in 2005, then persisted in the stage of Expert Group Formation through 2008, when it caught the attention of the PMO. The three year interval since the last stage posting looked like a tremendous amount of silence to the PMO, the community, and whoever else might have checked out the JSR’s progress. The Inactive label was applied based on the perceived lack of progress, and Peter was notified of the change in status through an email from the PMO.

On the other hand, some JSRs really are asleep. For Jim Davis, co-Spec Lead of JSR 48, WBEM Services Specification, his Expert Group took an intentional siesta for at least three reasons. First, they waited to build on a new specification that was not yet published by the standards organization Distributed Management Task Force (DMTF). Second, Jim left the employ of Sun Microsystems, on whose behalf he had submitted the original JSR in January 2000. Third, he co-founded his own business, WBEM Solutions, which took all his attention. Still, because he had continued in the same field, he was talking to people who wanted him to finish the JSR. He contacted the JCP PMO and Sun Microsystems, and received permission to move forward on it. The Inactive label wasn’t in use at that time. It was only later, when the JSR was waiting again on another specification to be released with particular features desirable for JSR 48, that the PMO let Jim know that the effort was officially considered Inactive, having reached Public Review as of August 2006.

Jean-Marie Dautelle

Oddly, success too soon can reduce the motivation to achieve formal closure. Jean-Marie Dautelle is co-Spec Leads for JSR 275, Units Specification. According to Jean-Marie, after the project came to “a standstill, a point in time with nothing happening,” JSR 275 was assigned the Inactive label. The number of emails related to the work had declined from a few each day to a few each month. A percentage of those emails were from people who worried about the JSR’s lack of momentum. “We had an unfinished Reference Implementation (RI), an unfinished draft specification, and no energy to reach the finish line. Our unofficial, incomplete RI was still very usable and very much used by the community. There was less incentive to fill in the blanks and complete the necessary paperwork for the JSR.”

It?s not surprising that there would be a spectrum of responses to the PMO?s way of handling Inactive JSRs. Some Spec Leads are annoyed at seeing their efforts declared ?Inactive? in a public forum, especially when they feel progress never stopped. For example, one Spec Lead refused to participate as a source for this article since he maintains his JSR is quite active, despite lack of progress in terms of passing an official milestone.

Stephen Colebourne

Stephen Colebourne had a more objective reaction when he realized JSR 310 had incurred the Inactive status label. At first, he was not compelled to take any remedial steps to reactivate the JSR, since his view was that ?the issue wasn't especially relevant to the project.? In fact, Stephen defends the length of the process. He says, ?While Joda-Time already existed, it had a variety of issues that made it unsuitable for direct inclusion in the JDK. There were also potential licensing issues. As such, a fresh start was needed. The end result is a much better API, but it has taken a long time.? For now, Stephen is keeping his eye on the future day when JSR 310 will be complete. ?Until then, it?s business as usual for an open-access project,? he says. ?Effectively, JSR 310 is in permanent Early Draft Review.?

In contrast, when Jim Davis received the emailed notification of the Inactive status, he felt “a little embarrassed that I hadn't been a bit more proactive in working with the PMO. I thought it was pretty good that they kept JSR 48 on the list as long as they did.” Jim also feels pressure from outside to keep the ball rolling: “There's a lot of interest, more from the client community than the implementation community. Each year I give a talk at the Management Developers Conference (MDC), and I usually have a full room. We offer our own implementation of the library in a product that people have been using as a kind of long term beta, and IBM has an implementation of it in open source. The number of people using it in the industry has just gone up every year, so there's a big demand right now to see a final spec,” even though the API is already a de facto standard in the industry.

Peter?s approach had been to create the Reference Implementation (RI) from the start, which apparently threw the timing of all the stages out of whack. Even so, he says, ?I strongly believe that RIs are the best way to make sure the spec is doing well, and the community knows what it's doing.? However, he knows that it?s one thing to focus an effort around an RI, and another to know when to show your work in an officially recognized way. Peter has learned to go through the required motions to keep the In Progress label.

Werner Keil

Sometimes the best response is to call for help. Jean-Marie and his co-Spec Lead, Werner Keil, decided that finishing the job was the right thing to do, so they worked to ?reenergize our troops. We asked for help on our thornier issue -- unit parsing -- and got it thanks to Eric Russell, who was not an Expert Group member,? says Jean-Marie. To maintain the renewed interest of the community, the work has continued with full disclosure. However, for other reasons beyond the scope of this article, ongoing efforts have moved outside of the JCP program purview, and are revealed with complete transparency at two locations. Project documents are posted on java.net. The build history and change tracker are generously hosted on a website owned by GeoAPI, an Expert Group member and JSR 275 early adopter.

More than anything, getting back on track requires the will to do so. Peter found a simple antidote to the Inactive label. He put a recent set of release notes through Early Draft Review so some of the Expert Group?s work would get an official JCP time stamp and return JSR 282 to an In Progress status. That?s all it took. ?Now that we?re deep into 2010, we'll do that again pretty soon to get another stamp,? says Peter.

Although Stephen had been circulating drafts of the specification, at some point he also decided it was time for a more formal EDR. Once that milestone was achieved, the Inactive label was lifted, replaced by the In Progress label, good for another 12 months.

It’s always good to let the PMO know what is going on. When Jim Davis and the Expert Group were waiting for the release of some essential technology to incorporate in JSR 48, they responded to the PMO’s Inactive notification by explaining the timeframe for when they expected to be able to continue. According to Jim, the PMO responded, “That's fine. One reason we send out the emails is to inform you and see who yells.”

Soon after that, IBM decided to get involved again in JSR 48. ?They gave us a lot of feedback, and we had to do an update because of it. We're just at the point where we're doing final testing and getting ready for final release, finally -- it's only been 10 years or so! Most people are just waiting for us to publish it and be done with it,? says Jim. Now the Expert Group has completed the specification and is working on the last requirement, a Conformance Test Suite (CTS), which is the older JCP 2.1 terminology for what is now called a Technology Compatibility Kit (TCK).

To keep the Inactive label away, Peter suggests, ?Write your RI and TCK early, and keep it in line with the Expert Group?s thoughts. And try to get an EG as good as mine.? Peter looks forward to releasing the spec and moving on, probably to RTSJ version 2.0.

Jim agrees that thinking about the CTS/TCK up front is best. “We did it as an afterthought, which was a mistake.” As for the specification, he recommends, “Do it quick and often. I wish I'd done a version 1.0 and gotten it out the door and then done a version 2.0 later, instead of trying to work so much in the community and get them involved. If I were doing it today, within a year I'd have the first spec out. I wouldn't let it go any longer than that.”

From his own challenging experience, Jean-Marie has found value in taking certain specific actions. For one, create a roadmap; dates may slip, but not as much as they would without such a plan. To make the schedule more achievable, divide the work into smaller tasks, assigned to Expert Group members. Use a tool such as JIRA or other issue tracker to distribute the work, set deadlines, track progress, and allow people to review and comment on what is being done. Maintain a public Wiki as an easy way for EC members and others to follow progress and give feedback before the ballot. Jean-Marie says, ?We managed to get out from our Inactive status, but our Public Draft was not approved by the EC. Valid issues were raised, which took us by surprise.?

Stephen keeps his focus on development of the technology itself rather than issues of time management. He recommends that Spec Leads always keep their project open-access through mailing lists, source code, blogs, and so forth. As he puts it, ?that way the JCP program itself is not overly significant except when it needs to be.? He also cautions Spec Leads to keep aware of potential licensing issues. In particular, he says, ?Do not simply accept patches and contributions from anyone without obtaining the Intellectual Property.?

The Spec Lead Guide has a page devoted to the issue of the Inactive label. It’s reassuring to know that publishing a milestone is the simple antidote to regaining the preferred In Progress status. On the other hand, the Inactive label is not the worst thing than can happen: if a JSR remains continuously Inactive for eighteen months, it is at risk for withdrawal from the JCP program.