As Sun open-sources Solaris, and another software development "community" is tugged into being around it, critics are saying - Red Hat's general counsel Mark Webbink in particular - that the strategy will fail.

"It is much harder to build a community around pre-existing software than one might believe," Webbink declared, in a statement to the press. (Red Hat and Sun are particularly fierce rivals just now, as anyone knows who has not been asleep in a cave for the past 12 months.)

Sun on the other hand is adamant about the importance of such a community. "The opensolaris.org Web site will be the center for OpenSolaris activity," it writes on the site's main page, adding: "Community involvement and input is critical to the success of the OpenSolaris program. If you want us to update you on major events such as the availability of buildable Solaris source code, please provide us with your e-mail address in the text box on the right."

It set me thinking whether "community involvement" is actually the philosopher's stone that everyone seems to think it is. Sometimes I find myself wondering, for example, what those who had the idea of naming the "Java Community Process" (JCP) were smoking. How much better it might have been, in hindsight, to have called the JCP just the JC, the Java Council - or some such name that allowed it to achieve its aim of cultivating a wider participation in the specification of new and existing Java APIs, the "process" part, without burdening it with the additional notion of "community" which to this day seems to be as much a bane as a boon.

Unlike that other JCP, the Japanese Communist Party, which was founded in 1922, the Java Community Process was founded only in 1998 and has guided the development and approval of Java technical specifications since then. James Gosling was quoted in 1999 as saying the JCP was all about "getting the managers out of the room and letting the technical people do their thing." A noble aim, as any developer would agree; though it's by no means clear that managers are without a role to play, and many are indeed active in the JCP.

In last month's JDJ David Parsons, Ilan Kirsh, and Mark Cranshaw looked at the Java Technology for the Wireless Industry specification, a recent example of the JCP seeking to help establish a set of industry-wide goals and expectations for Java-based applications and services through the JSR-185 Java Technology for the Wireless Industry (JTWI). And in this issue we have a full-fledged feature looking at the JCP from various perspectives, not least that of its current chairman and longtime JDJ contributor and advisor, Onno Kluyt.

Java architect and instructor Allen Holub recently wrote "bad standards are destructive. Just look at created-by-committee junk like EJB and JSF" - and in the same opinion piece declared: "My outsider view of the Java Community Process is that it doesn't work."

But the JCP community is an important place for developers to be involved in. With the JCP version 2.6 in place now, the community gets even more opportunity to influence and contribute to standards while they are being developed.

Probably Churchill's observations about democracy apply. "Democracy is the worst form of government," he famously said, adding "except for all those others that have been tried." As with democracy, so with the JCP. And so, too, with OpenSolaris.org. While everything could always be better, things could be an awful lot worse.

So if a community - whether it is the JCP, OpenSolaris.org, or anything else - isn't the way you'd like it to be, first join it; then change it. As the playwright Henrik Ibsen once wrote: "A community is like a ship, everyone ought to be prepared to take the helm."

• Java Technology for the Wireless Industry
• JSR Update: A Web Services and XML Special Round-Up