Find JSRs
Submit this Search

Ad Banner

Spec Lead Guide
Case Studies

Operating a Consensus-Driven Small Expert Group: JSR 80 Case Study
JSR 80

Boyd Dimmock

Specification lead Boyd Dimmock guided the development of JSR 80 with an expert group of ten corporate and individual members from around the world. With a simple email, web site, and telephone infrastructure, she led by consensus, employing polling techniques, a professional tone, and an even-handed manner to see her team through the challenges inherent to the task.

At IBM in Raleigh, NC, senior technical staff member, Boyd Dimmock, saw the handwriting on the wall: Universal Serial Bus (USB) rules. Or it will pretty soon. Already every laptop now shipping includes a USB port to enable hot plug-ins of external disk drives, speakers, joysticks, entertainment systems, security cameras, and so forth. While the serial port has a Java extension, there was none for the up-and-coming USB until Dimmock got the ball rolling as JSR 80 specification lead.

"We thought that going into the future there would be great business need for at least having the level of functionality for USB port that already exists for serial," says Dimmock. "There are a variety of real needs in the industry to use USB, but the Java (TM) programming language currently can't get you there." IBM, for example, has a point-of-sale (POS) cash register with USB ports, so the company's business motivation was strong to enable business partners to develop applications that could use USB-connected peripherals to enhance their solutions.

About a year ago, Dimmock proposed JSR 80. Its goal was to create a Java interface to USB devices. The interface would allow programmers to write a device service in the Java language and make it portable across platforms. With such a service, USB device attachments could be integrated into the business logic of the solution.

Recruiting Experts

Dimmock recruited participants for the JSR 80 expert group from a variety of sources. In addition to posting the JSR on the Java Community Processs (SM) Program (JCP) web site (, she had a notice sent of the proposed work to a USB users group ( and to some of the retail industry standards groups who had significant interest in USB. The expert group remained open for an extended period of several months, during which people applied to join by submitting their credentials.

Dimmock knew what kind of expertise was required for the team to succeed. She explains, "We were looking for people who were already designing for the Universal Serial Bus. We thought that between Sun and IBM, we would bring enough knowledge of Java technology to the table. So we were looking for people who understood the technology that we were interested in, and typically these were people who were doing USB work in some other language."

Dimmock acknowledged everyone who applied, and she accepted nearly anyone who professed some knowledge of USB. After being accepted, however, some were never heard from again; after several months, Dimmock removed their names from the roster. Ultimately, the JSR 80 expert group included four participants from Sun Microsystems, three from IBM, and one each from Fujitsu Limited, Wincor-Nixdorf, and Apple Computer. In addition, five individuals served on the expert group.


The original JSR 80 schedule called for release of the community draft in November, 2000, but the expert group missed that date by six months. Why? "Well, we had several unexpected technical issues to arise, and I think we took the high road in working to pursue an excellent design to resolve them," Dimmock explains. "It was also true that none of the expert group members were truly full-time on this effort, and they were managing other commitments concurrent with the JSR 80 work. The USB architecture is complex, and the API is certainly nontrivial."

In addition, the original dates were put in place without a great deal of project management rigor. "We were optimistic, and I guess I felt that missing an aggressive target was as good as making a padded conservative date. We had a conference call on March 22 that was pivotal in our agreement that the version of the spec that we had was adequate for an initial release of the API," says Dimmock. She adds, "Of course, some compromises had to be made, since we are still thinking of ways to make the API better. Some things will need to wait for a second release. I would also say that the quality of the community draft, which we heavily invested in, brought the public specification out sooner."

Overall, the timeline for Dimmock's group was actually:

Executive Committee approved JSR 80 September 2000
Group membership remained open from September to December 2000
Developed community draft from September 2000 to April 2001
Community reviewed the spec April through May 2001
Developed public draft May through July 2001
Public reviewed the spec July through September 2001
Developed final draft of the spec by September 2001
Final specification release is expected September 2001
TCK/RI release is targeted for October 2001
Professional Communication

Dimmock launched the expert group with a face-to-face meeting held at her home location, but she was disappointed in the low turnout. "Other than the IBMers who already worked in Raleigh, we just had two other participants. We realized that people did not have the travel funds and travel time to invest," says Dimmock. From then on, the group relied on email and conference calls as their primary means of communication.

Conference call meetings were more successful in terms of turnout. A week in advance, all the experts were invited to participate by dialing in at a specific time. Calls were typically held when Dimmock felt there were key decisions to make, and she wanted to give participants an opportunity for voice debate in order to build consensus.

Email was an essential forum for communication. The alias mailing list that the JCP set up enabled group-wide conversation about specific technical issues. "A lot of mornings I would come in, and there would be ten notes in the reader," Dimmock recalls. One topic, for example, was the great debate about how to make the Java API generic enough to communicate with anyone's external hardware. That discussion lead to the next thread on how to test successful communication with anyone's hardware. Through the email discussions, group members identified some appropriate boards to use for testing.

Email is not necessarily the best means of communication, however. When people feel strongly about a topic, emotions can heat up their messages. In addition, frustration levels may rise when a person deals with someone who is not known personally, who is time zones away, and who represents another culture. To counteract these tendencies, Dimmock modeled a professional tone in her own communication and expected the same of her colleagues. "We worked very hard at keeping the communications professional on the alias. In fact, we had some discussions along the way," Dimmock understates. She adds that it's just not helpful to technical discussion to imply 'I'm smarter than you are' with ego-centric remarks.

Dimmock's professional ethic also requires that she treat group members even-handedly and openly. Especially in an inter-industry work team, Dimmock believes that "you have to acknowledge the other party's right to speak and demand that everyone listens." It's easy to pick favorites, she says, but that's a recipe for disaster as it breeds hostility among members. Dimmock deliberately avoided the hub-and-spokes method of communication, where individuals talk only to the leader. "I try to direct my communications to the alias more so than to individuals, so that everyone at least sees what the discussions are and has an opportunity to influence what's going on," she says.

For the benefit of those lurking without comment in the group, Dimmock would occasionally poll the experts, usually during a conference call. If it had been a while since a given company had spoken up, Dimmock might ask, "Are you still interested in this JSR? What position would you take on [a particular point]?" It's to be expected that a few experts participated consistently, with the majority contributing more sporadically. When lurkers would join a conference call and respond to a direct question, Dimmock took it as an encouraging sign that they'd been more or less monitoring group discussions and hadn't commented because they were content with the decisions being made.

Occasionally communications would grind to a heated deadlock. To get things moving again, Dimmock would warn, "We are never going to get done if you guys can't come to some agreement on this point." Then she would pick a side, not necessarily reflecting her own technical preference. Ultimately, the group always reached consensus, even when it meant someone had to give in. The closest Dimmock ever came to declaring, "I'm the spec lead and this is how it's going to be!" was with her own IBM guys when they were reluctant to follow the group's decision.

Historical Perspective

As a project winds through its various debates, decisions, and deadlines, it becomes increasingly useful to refer back to a formal history. Dimmock sighs, "We didn't set up -- and I somewhat regret this -- a mechanism where all emails were traced, some forum where we kept a historical perspective." She assumes most participants created their own records, but there is no formal repository of threaded email discussions or of the conference call minutes that were emailed to the alias from the early discussions.

The need for a complete history became more apparent to Dimmock when, very late in the process, one corporation withdrew an employee from the expert group and inserted a new person in his stead. The new member will read the spec, of course, but there's no formal history of the project for him to research why decisions were made and who participated in them. In such a situation, it will be hard for the newcomer to catch up with the team.

Dimmock Dispenses Advice

Spec leads, keep the communication channels wide open and avoid picking favorites.
Experts, be professional with your comments and resist implying "I'm smarter than you are"; be willing to listen to others' suggestions.
Potential JCP members, the JCP process is an excellent opportunity to influence the standard to be used by millions of programmers.
JCP administration, licensing issues sometimes prevent participation by those who have excellent technical abilities.

Team Accomplishments

Dimmock is no lone ranger. As spec lead, she wrote not one line of code. "My participation has been at a higher, what-are-we-trying-to-do-here level," she says. Strong technical participants at IBM and Sun provided the deep, multiple skills needed to hammer out the API. Much of the test board work was done by a knowledgeable Swede who could explain to his colleagues how testing was done. "The primary author of the API is Michael Maximilien of IBM, and he deserves a lot of credit for our progress."

The JCP PMO helped out, too, by working through the expert group's need for dual web sites. "We have set up a web site where we are going to release the Java code under an open source license," says Dimmock. Several URLs link the standard JSR 80 web site with the open source web site While the standard web site is fairly static (primarily tracking the status of the JCP process), the technical news, information, architectural documents, specifications, and such will flow from the latter web site.

Dimmock admits that the JCP's well-defined timeline has been "a driving force" to get the JSR out. "Certainly I think the spec is better for having had multiple companies participate in it than it would have generated by only one. Questions are asked early in the development that maybe we might have missed with just a single implementation group. The inter-company open participation in the design makes for a better spec," she says.

JSR 80 Home Page