The economic purpose of a standard is to encourage and enable multiple implementations of the subject specified, i.e., it is the opposite of a company specification that directly benefits the company's own ecosystem. A standard is designed to increase choice and benefit consumers. A successful standard has to have multiple implementations that conform and interoperate. If there's only one implementation then it's just a vendor specification, regardless of the process it was put through to get a stamp of approval.

Sun created the Java Community Process (JCP) to manage and maintain the evolution of the Java language. While it's easy to claim that the JCP is "controlled" by Sun, the JCP actually has more in common with an industry group building standards than a vendor-controlled specification to enhance a vendor's own ecosystem. The JCP has members well beyond Sun. It has a well-defined, consensus-based process to manage the myriad Java-related specifications. Membership is open to all to participate. Its purpose is to encourage multiple implementations of Java and not simply add-ons to Sun's Java world.

The hard part of any standards organization is how best to measure and warrant that an implementation conforms to the specifications to protect the value of the standard's brand in the marketplace. How does one best signal to the marketplace that a subject is what it claims to be? Conformance measurement and certification is an expensive process. Sun, through the JCP, has put in place an expensive process to certify that Java technologies delivered by anyone do indeed meet the specifications. Certifications are always taken on by the group that stands to gain the most (or lose the most in some cases). Essentially the group that cares makes the investment and develops a program to certify things against the standard.

POSIX was a standards effort defined by the IEEE that undertook to define an operating system interface in the C language to support application portability. The IEEE didn't handle conformance measurement however. The U.S. National Institute of Standards and Technology developed the certification to support U.S. government procurements. The IETF skips expensive certification processes after the fact, and instead uses the reality that they define networking standards to require that an RFC has two independent interoperable implementations to gain standards status. The people who economically need measurable conformance take responsibility for putting the system in place.

So too is the case with Java. This is as true for proprietary product specifications and their certification programs as it is for industry and de jure standards. The vendor stands to lose the most with respect to its proprietary specification's brand in the ecosystem, as any industry standard has to gain from the value of demonstrating that multiple implementations conform.

Standards AND Open Source Software
Standards exist to enable multiple implementations of a technology. Open Source software to a certain extent represents the one true implementation of a technology. When there's one true implementation there's no need for a standard. For example, there'll never be a Perl language standard. But the interaction is actually more subtle.

Standards typically occur in mature spaces where there's a wealth of experience and expertise. When it comes time to create a technology standard, the vendors in the space will pick a shared technology base from which to create a standard. Every vendor would love to claim its technology is the standard, and often make claims to having the "de facto" standard, essentially such a ubiquitous technology that it's a "standard in fact." The real world doesn't work that way however, regardless of how it's marketed. When true standards are delivered, they come from a shared technology base so that none of the participants feels another has a market-dominant starting position.

The standard will differ from that core shared technology base, but not so much that the shared base doesn't quickly morph to conform to the new standard, and the collection of vendors can quickly bring products to market. In today's world, Open Source software projects represent that shared technology base out of which standards can be delivered to facilitate multiple implementations.

This is a somewhat odd position then for Sun with Java. As the keeper of a primary reference implementation, and the creator of the standards development organization, it would seem Sun is in an odd place. Indeed, it's almost as if the process is working backwards.

Open Source Java
So what will Open Source Java mean? First remember that this effort hasn't been driven by Sun, but demanded by the community around Java. Whether the demands are valid or not, or indeed politically motivated or not, there are still good things to be had from the process.

Sun has driven the Java standardization process through the JCP for some time and has a strong collaborative community and process, supported by a strong certification and branding program. Delivering Java technologies as Open Source still makes sense, however, even if the standard has led the implementation so to speak.

As a primary reference implementation, it will provide the following benefits to the entire Java community, Sun included:

• It will harden the primary implementation for Sun's and the community's benefit. Allowing others to tinker and explore will uncover new and interesting problems, which can then be addressed.
• It will enable new innovation. Many claim Java's day is done. Allowing new implementors to explore the primary production base will invariably lead to new ideas and innovation on the platform.
• As new code enters the source base, it will likely come in at a very high level of quality. Even if Sun developers act as the primary committers for the foreseeable future a high level of inspection will be brought to bear on code coming in from the outside. For new work delivered from the inside, the inspection by the community will likely be equally vigorous.

Sun already supports a strong development community around OpenSolaris and hopefully that experience can be leveraged by the "OpenJava" team. Likewise, Sun already supports a strong collaborative community in the Java Community Process, so it has a great channel to begin its Open Source efforts when it figures out how it intends to publish what sources. It began the release of Java EE 5 with the GlassFish project, and now time will tell if it can harness all its collective experience in Open Source software, standards, and the JCP to bring about a complete Open Source Java world.

References