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 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 http://jcp.org/ja/jsr/detail?id=80 with the open source web site http://oss.software.ibm.com/developerworks/projects/javaxusb. 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.