Part I, Starting a JSR and Expert Group
Driving a JSR requires a substantial commitment of time and attention, which may and probably will go beyond a compensated work activity into a voluntary labor of love.
Such activity brings its own reward, however. Developers realize they are extending a technology that will have an impact on engineering processes or on things people use every day -- phones, televisions, and navigation systems, for example.
 |
|
| Linda De Michiel |
 |
It goes without saying that if a person wants to lead a JSR, he or she must be prepared and suited for the role of Spec Lead. Star Spec Lead Linda DeMichiel of Sun Microsystems notes that Spec Leads need experience with the technology and ability to gather support for the technology, recruit motivated Experts, guide an international team, and make appropriate technical decisions in the community’s best interest. She feels that the challenge of developing a Reference Implementation (RI) and Technology Compatibility Kit (TCK) is best met by having “an organization behind you."
 |
|
| Ed Burns |
|
Those who are already active Experts or Observers or who are helping their organizations with the JSR have placed themselves in a good position to become a future Spec Lead. For example, Ed Burns, a senior staff engineer at Sun Microsystems, was developing the RI for JSR 127, Java Server Faces, when he was invited to step up to help the existing Spec Lead, a Sun colleague. Now Ed is also a Star Spec Lead of JSR 252, Java Server Faces 1.2.
 |
|
| Antti Rantalahti |
|
In the same vein, Antti Rantalahti, a research manager at Nokia Research Center, was acting as Nokia's technical lead in the Nokia-led JSR 135, Mobile Media API. He found it “quite natural to take on the Spec Lead responsibilities in the new JSRs in the same content area.” He is the Star Spec Lead for JSR 135, JSR 234, Advanced Multimedia Supplements, and JSR 272, Mobile Broadcast Service API for Handheld Terminals.
 |
|
| Volker Bauche |
|
Working for a company that takes its membership in the JCP program to heart is like being in a Spec Lead incubator. Star Spec Lead Volker Bauche is a senior software technologist and team lead in the software technology department of BenQ Corporation. He says BenQ has a team that manages Java ME standardization, among other tasks. New JSRs to be filed by BenQ are discussed in the team, and once the content is defined, it is decided who should become Spec Lead. BenQ Spec Leads are not permitted to manage more than two JSRs at a time, so the company has a growing need for new Spec Leads.
Education and training can be helpful credentials. Among the 23 Star Spec Leads profiled by the JCP PMO, three have the equivalent of a bachelor’s degree, fifteen hold at least one master’s degree, and four have attained PhDs. While upper education is certainly a value add, some aren’t convinced that a formal degree is necessary. In a meritocracy, Spec Leads gain influence and respect by virtue of their past contributions, professional knowedge, and skills. In fact, not all Spec Leads have college degrees. Some are inspired by their own burning interest in the technology or the industry, a personal motivation that compels them to do the necessary research and development on their own or in the context of their day job.
 |
|
| David Nuescheler |
|
David Nuescheler, the chief technology officer (CTO) of Day Software, is the Star Spec Lead for JSR 170, Content Repository for Java Technology API, and JSR 283, Content Repository for Java Technology API Version 2.0. He says, “I think the important thing about becoming a Spec Lead is to be passionate about a topic. Once you are a Spec Lead, other qualities are required, but I believe my submission was a passionate act to change something for the better of our industry and standardize the very many, very different content repository APIs.” Although Spec Leads may represent a company or organization, they are expected to act in the best interest of the JSR. David believes a Spec Lead needs to be a mediator and diplomat, “trusted by the Expert Group to be neutral.”
Passion can help sustain a Spec Lead in what can be a very long road. Although David initially estimated the JSR 170 effort would take nine months, someone from the PMO doubled his time frame, but it actually took a little over four years to complete. And still he came back for more with JSR 283.
If a Spec Lead doesn’t somehow inherit a JSR, he or she can come up with their own. David wanted access to a standardized content repository interface in Java, but there was none, so he turned to the JCP program, “the ideal standardization body,” and submitted his JSR. Antti sees opportunities on every hand in multimedia, where “we just try to provide Java with the same features the native smart phone applications have. In the future, it's an issue of how deep the Java application must get into the system.”
Ed Burns suggests asking three questions to identify areas where new JSRs are needed: Where are customers confused by many similar technologies or products? Would the Java platform benefit by having a standard in this space? Would Java license-holders benefit by having a standard in this space? (Obviously, if a JSR doesn’t have buy-in from major Java licensees, who are typically the primary players in the JCP program, the technology isn’t going anywhere.)
In years past, it was much easier to create new JSRs, Volker says, because there was so much that was not covered by existing APIs. He says, “Today the problem is not so much to find a ‘white area’ on the Java ME map -- there are still many of them -- but to define an API that covers such a white area without interfering with other, existing APIs.” For new ground, he suggests looking at Java SE since applications that were once limited to desktop computers could now run on mobile devices, except that the current Java SE APIs don't fit well, if at all. Non-Java APIs, such as BREW or even Microsoft libraries, are also a source of ideas for new JSRs.
To make sure a JSR will fly with an overwhelmingly positive vote in the EC, Ed advises submitters to make sure the JSR is “novel” and to give compelling answers to questions 2.5, “What need of the Java community will be addressed by the proposed specification?” and 2.6 “Why isn't this need met by existing specifications?” It has also become necessary to have an unofficial champion who is well regarded by the JCP program and the Java development community and who will speak up in favor of the submission and the submitter’s Spec Leadership skills and qualifications. Antti recommends contacting EC members even before filing the proposal to solicit initial feedback and get any opposing views to agree before the vote. Volker says it’s “necessary” to compile a diverse list of companies representing various business areas -- device manufacturers, software providers, and operators, for example -- to support the JSR.
While Spec Leads are important in developing Specifications, an Expert Group won’t get far without Experts to hash out the technology. In his early days, David recruited people he knew personally in the industry. He has decided it would’ve been better to have recruited more companies that were already active in the JCP program “since they have the mindset to participate and have already filed all the paperwork with the JCP PMO.”
Volker finds that when a few “celebrity companies” recruited from the JSR’s list of supporters are brought on board, interest in the Expert Group rises quickly.
Because JSRs spring from a need to standardize existing technology, Ed likes to have stakeholders participate as Experts. He also feels that it helps to have at least one Expert who is technically familiar with the content, but whose forte is building consensus.
David prefers a technical, developer-oriented Expert Group, which he has found will generate more factual discussions and drive consensus more easily. He says, “Basically, I have almost a requirement that someone who is actively involved in the Expert Group understands Java technology from a developer’s perspective.”
Antti agrees. Having better developer insights can lead to more user-friendly design decisions, he says.
If at all possible, kick off the Expert Group with a face-to-face meeting of at least two days, Volker recommends. Informal get togethers with the Expert Group are necessary, Volker says. As an Expert in someone else’s group, he “had the experience once that the most important decisions during an F2F were taken at night in the pub. Most of the conversation afterwards was handled via phone calls and email lists. It makes life much easier to have a face in mind,” Volker says. For geographically diverse groups, he suggests trading off where additional face-to-face meetings will take place over the course of the JSR effort.
An initial phone conference can also work as a kick-off, David says, if the geographical distribution, size, and working model of the Expert Group prevents a quorum of Experts from being able to participate in a face-to-face meeting.
Experts who miss the initial launch activity and join later can have difficulty grasping the working model and recognizing individuals in the Expert Group. David has found that a "Welcome to the Expert Group & Initial Directions" FAQ was useful to bring them up to speed.
Spec Leads aren’t left to fend for themselves. The JCP program offers training workshops for anyone interested in taking on this responsibility. Moreover, the JCP website offers an easy-to-use guide that includes necessary forms, tips, and recommended procedures for writing and submitting a JSR, forming and expanding an Expert Group, and navigating the various reviews, drafts, ballots, and releases. Case studies and success stories offer sample experiences to learn from as well.
Proceed to part 2...
|
