Sponsored Link •
Probably the main point made by all the spec leads we spoke with was the importance of fostering communication within the group to draw out the collective wisdom of the experts:
Kimmo Loytana: The most important thing is to get the whole expert group involved, and have real active discussion.
Ekaterina Chtcherbina: Where I see the value of the JSR lead is to support effective means for communication and exchange of opinions. Every spec lead does that in a different way. In our case, we try to [facilitate] regular communication sessions, conference calls, face-to-face meetings, reply to emails, and motivate people to provide their opinions and feedback.
Kimmo Loytana: Lead the work so that all the issues are actively discussed and decisions are made together.
Jere Kapyaho: It's mostly about communication. The expert [group] participants can't typically devote themselves full time to the [JSR] work. They are doing other tasks asynchronously . . . We're geographically separated, mostly on different sides of the Atlantic, and you get time differences, so email is the most reliable communication method.
Andreas Ebbert: I see my role as a moderator and enabler between the experts. Instead of telling them, "OK, we're doing this, what's your comment on that," it's better to entice them to communicate actively. The expert group members have to know that their opinions are valued in the group . . . Email is the only communication means left [in my case], because my expert group spreads from Australia to India, Europe to California. It's hard to find a good time for teleconferences. We still have them every week, but you don't get the whole expert group on the teleconference because of the time zone problems.
Vincent Perrot: Face-to-face meetings and communication with the architects coming from different companies is crucial. We try to meet face-to-face as much as we can. That's where we can see real progress on the JSR. Phone calls are good enough if you know each other. But face-to-face meetings help synchronize our work, and help ensure we're working on the right goals. The JCP provided us with a Web site to share information, but now Java.net is what we use most. We share code in their CVS, and you can create your own hierarchy of documents.
Several spec leads mentioned the importance of continuously driving the progress forward, as well as keeping everyone informed of that progress:
Kimmo Loytana: The spec lead has to lead the work and keep the schedule so the JSR is able to finish its work in a reasonable time.
David Nuescheler: If you have to take a decision as a spec lead, take that decision and then stick with it.
Kimmo Loytana: You have to go through a lot of meetings . . . we've been holding weekly conference calls, face to face meetings at a couple of places, so that all those in the expert group know what's going on and have a chance to comment on it.
Jere Kapyaho: You really need to keep the expert group up to date of what you're doing, when you're going to publish drafts of the specification, of what you're doing about the comments they sent in. I don't think anyone would want to be sending comments into a black hole and not being able to find out what's happened to [those comments]. You really need to acknowledge the comments from the expert group, and then tell them what you're doing about them, and when the issue is going to be resolved. Or just telling people when you're having the next meeting. You would think these are small things, but these things count.
David Nuescheler: Make sure everyone knows what's going on. People in the expert group don't know the process that well. They need to see the next steps.
Vincent Perrot: Make things as transparent as possible. You are not trying to hide things, anyway, so just share information with others. That encourages everbody to contribute. My very first experience in leading a JSR speaks to that. At that time, there were just two companies, each a leader in that domain. At the beginning, we had a face-to-face meeting, a dinner, as a way to start the JSR, but we didn't share any information with each other. After the dinner, I went back to the office, and during the night I coded the first [draft] of the JSR, which was very basic. Next day, I showed people the possible interfaces we were going to work on. And then, magically, the [expert group members] at each company started to chip in with comments: "Why do you throw an exception here?" And then others would reply, "Well, that's what the standard says, but this is how we actually implement it." And then others would comment, "Yeah, that's how we implement that, too." Then, all of a sudden, the expert group members from different the companies that were previously not talking to each other just started exchanging information. And then the JSR became very successful.
We also heard that while it is important to strive to accomodate everyone's business agendas, you should strive to not allow political compromises to be at the expense of the technical merit of the result:
Jere Kapyaho: In the J2ME space, there is definitely competition on the surface. When you have an expert group with people from Nokia, Siemens, Motorola, there will be different and sometimes even conflicting interests. Luckily, we're mostly working on a technological level. We don't get much wrangling over market interests. Of course, we do have to develop APIs that fit with our [product] portfolio. But, in the end, it's the technological decisions that impact the API—what's better for the developer. We don't let the market interests impact the API. Often, you have to make architectural decisions at the beginning of the JSR, and some of those choices might not be very good for the developer. You know the joke about the camel being a horse designed by committee. If you're not careful about that, you may end up with an API that doesn't fit into anyone's idea.
David Nuescheler: Each [expert group member] has a business agenda, and it's important to cover as many business agendas as possible without losing the technical credibility. So it's as much a diplomatic as a technical mission to get the first version of a JSR done. You have to find the balance, the consensus. . . A JSR is always a technical challenge, but is also, at the same time, a political discussion to make sure all parties involved in the JSR are satisfied, that all requirements are covered from the involved parties. In our JSR, 42 experts were involved, representing over 20 organizations . . . It boils down to trying to be non-confrontational, trying to build consensus. The JCP is very much about compromises. Make sure everybody is on board about certain topics, that everyone can live with the compromises . . . Before taking a vote on things, try to build consensus.
Lastly, we heard that it is beneficial to seek guidance from those who have gone before:
Jere Kapyaho: I'm actually the second generation of the Nokia spec leads. I've had the benefit of standing on the shoulder of giants, so to speak. Other Nokia spec leads before me would have deserved this award a lot more than I. I was lucky to have a lot of excellent people to ask stupid questions from, in addition to having my own instincts of how to lead this group of a wild bunch of experts that possibly want to pull in different directions based on by their agendas, companies, and maybe individual interests, too.
What we personally learned from these JSR spec leads is that you have to have a strong, but still realistic and not overly ambitious vision when starting a new JSR. You have to know all the important players in the domain, and be able to convince them to work with you on the JSR. Once your expert group is in place, don't attempt to do all the work yourself: Instead, delegate as much work as possible to your expert group members, while keeping them informed of what's going at any time. You also need to be very responsive; for instance, reply to emails right away. A healthy doze of diplomatic ability is also crucial for success, as you will need to reach consensus without compromising on the technology.
Have an opinion about the design patterns topics discussed in this article? Discuss this article in the Articles Forum topic, Seven Secrets of the JSR Spec Leads.
 Information about the Star Spec Lead Program and links to detailed bios of the 2005 star spec leads is available here: http://jcp.org/en/press/news/star
Frank Sommers is a Senior Editor with Artima Developer. He also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank is also president of Autospaces, a company dedicated to providing service-oriented computing to the automotive software market.
Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima Developer. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.