It's more difficult to find a "standard" definition of Open Standards, since (like standards themselves) there are many to choose from. (Wikipedia (http://en.wikipedia.org/wiki/Open_standard) provides a useful summary.) Nevertheless there is general agreement on the fundamental characteristics of open standards: they are developed through an open and transparent process that permits all interested parties to participate, and they are freely available for viewing or implementing without discriminatory or excessive licensing fees. The devil is in the details - and there are a lot of details. For example, some definitions require royalty-free licensing while others permit license fees so long as these are "Reasonable And Non Discriminatory" (RAND).

Since I'm the chair of a standards organization you won't be surprised to learn that I believe in standards. They make the world go round. It would not be possible to mail a package or send an email message, drive a car or take an airplane trip, shop for food in a supermarket, obtain medical treatment in a hospital, watch TV or movies, enjoy a sports game, or do any of the other things that the modern world offers without standards. The processes through which the JCP develops standards (JSRs), while they might not meet all of the criteria in the strictest definition of open standards (no standards organization gets a perfect score), are reasonably open. For example, participation is open to all, JSRs are developed through a well-defined process that requires public review, and the resulting standards are licensed royalty-free to those who wish to implement them.

The acceptance and success of open source development methodologies pose both a challenge and an opportunity for standards organizations such as the JCP. Some argue that standards are less necessary in an open-source world, or that the collaborative efforts of open source communities can develop "de facto standards" in a more agile manner than the more traditional standards bodies whose processes are necessarily more cautious and time-consuming. I believe that both open standards and open source are necessary; they can and should complement each other. Open standards are essential to enable multiple competing implementations, protecting against vendor lock-in. Large corporations rely on standards to build industrial-strength systems, and governmental organizations are requiring that software developed and deployed in the service of their citizens be built on open standards. (See for example the European Union's Interoperability Framework (http://europa.eu.int/idabc/en/document/3761) for pan-European eGovernment Services.) Open source development methodologies and licenses can indeed bring agility, innovation, and collaboration to standards-developing organizations, and for this reason they are being increasingly adopted.

The JCP does not mandate open-source processes or licenses but it does enable and encourage them. Several JSRs have already been developed in this manner (Doug Lea's JSR 166: Concurrency Utilities (http://jcp.org/en/resources/guide/166-casestudy) , for example) and it's likely that this model will increasingly be followed in the future. Last year Sun decided to open-source its implementations of the Java SE, Java EE, and Java ME platforms, hence the OpenJDK team's visit to FOSDEM that I mentioned at the start of this article. The implications of this change are significant, and many of them are still to be worked out, but it's clear that this is the way that many if not all JSRs will be developed in the future. Similarly, while the JCP does not mandate transparent processes, these too are encouraged. (Our Process Document (http://jcp.org/en/procedures/jcp2) requires that spec leads provide a "transparency plan" to ensure that the members and the public have insight into and can participate in the JSR development process.) Over the years the JCP has become more open and transparent, and I confidently expect these trends to continue.

Open standards and open source are a powerful combination. Each supports and strengthens the other. Many of the most successful open-source projects are based on open standards (the Apache web server, for example, implements a variety of W3C standards). Open-source implementations of open standards help to clarify problems in the specification and to promote their adoption. In fact, it has been suggested that open-source implementations might be essential to the success of open standards.

These issues will be explored in more detail during a panel discussion (http://qcon.infoq.com/london/presentation/Open+Source+and+Open+Standards) that I will be leading at the QCon conference in London on March 12.

JSR Roundup
As usual, a variety of JSRs made progress during the past month. JSR 254 (http://jcp.org/en/jsr/detail?id=254): OSS Discovery API, led by Nakina Systems, made its final release. Two JSRs entered the Final Approval Ballot stage: JSR 225 (http://jcp.org/en/jsr/detail?id=225): XQuery API for Java, led by Oracle, which provides a uniform interface to a variety of different implementations of the W3C XQuery (http://www.w3.org/XML/Query) specification, and JSR 286 (http://jcp.org/en/jsr/detail?id=286): Portlet Specification 2.0, led by Star Spec Lead Stefan Hepper of IBM.

Two JSRs entered Public Review (their Public Review Ballots will take place during March). JSR 262 (http://jcp.org/en/jsr/detail?id=262): Web Services Connector for Java Management Extensions (JMX) Agents, led by Star Spec Lead Eamann McManus from Sun, enables the use of Web Services to remotely access JMX instrumentation. JSR 290 (http://jcp.org/en/jsr/detail?id=290): Java Language & XML User Interface Markup Integration, also led by Sun, enables the creation of rich user interfaces on mobile devices by leveraging W3C XML markup specifications such as Scalable Vector Graphics and the Compound Document Format.

Finally, two more JSRs made maintenance releases: JSR 243 (http://jcp.org/en/jsr/detail?id=243): Java Data Objects 2.0, and JSR 248 (http://jcp.org/en/jsr/detail?id=248): MSA, the Java ME umbrella specification.

For more details about the JSRs mentioned in this column and about the other activities of the JCP, please visit our website (http://jcp.org/en/home/index).