Whether it's a prescriptive environment like the JCP or a less prescriptive one like OpenJDK and other open source software forums, communities have a lot in common.

Companies, organizations, and individual developers join or participate in certain communities - and not in others - driven by expectations of benefiting from the effort, influencing and/or leading it. The idea of joining the JCP could be motivated by the desire to make your work part of a standard, actively leading an industry in a certain direction and being recognized as a thought leader or to have one's products as closely aligned with the emergence of new standards and be seen as a market leader.

In the case of open source software communities one could want to benefit from the fruits of the commons and be better able to focus your key resources on your product's differentiation.

In either case, the active participant will enjoy advantages over those that don't participate or are passive in their participation. In the case of the JCP your advantage as spec lead and expert group member may come from being able to predict the direction of a new standard better than your competition and make product roadmap decisions accordingly. In the case of open source communities you may enjoy faster time-to-market and a better ability to react to changing market conditions due to the momentum of open source development.

While all communities attempt to attract active participation by enabling these and other benefits for those who contribute, these communities also draw boundaries around these benefits. The JCP does that through its requirement on using all the intellectual property gathered that's applied to developing compatible implementations and by timing the release of use rights. Open source communities that use the GPL have a similar concept: your derivative work must use the same terms as the community is developing the software under. Over time this balance between benefit and obligation may move about. The JCP used to assume that Sun would have final copyright ownership, and it doesn't anymore. The JCP used to assume that all implementations derived from Sun's, and it doesn't anymore. Similarly, the Apache software license has changed over time and the Free Software Foundation is discussing version 3 of the GPL license.

A community attracts interest in part because of the structure outlined above. And the amount of active participation has a lot to do with timing. Spec leads in the JCP have learned that their JSRs often progress as fast through the process as they go. In other words, the spec lead must lead: by the rate at which she generates working drafts, the expert group will respond, act. and react. For open source software communities the attention of and access to those with committer status determines the feel of the community - and the ease of knowing where to start.

Where does the community need help, where are my skills best aligned with the work that needs to be done? The spec lead and expert group for JSRs, the current developers of an open source project must both guide newcomers. There's a risk of being too nice. "We need help everywhere!" may not be a good answer to a newly interested party trying to decide how to get involved. What do you want reviewed, what is the "to do" list for the project? Getting involved in any community has its own learning curve. Those with a steep curve may be seen as elitist because of the effort required to get into the club.

A frequent question that spec leads in the JCP get is: "When will you be ready?" The broad emotion behind this query is one that also features in open source projects: "Is anything happening here?" To show a pulse and a heartbeat is key to the success of community efforts. Communities survive on volunteers: a spec lead can develop that document elsewhere, a developer can spend his time elsewhere. Participants try to persuade other participants to "work" for them, for free. For such a social contract to work, expectations must be met. If you ask for feedback you should get it. If you provide feedback you should expect to be drawn in. If you get feedback you should expect to act on it.

As usual you can send your thoughts and comments to onno@jcp.org.