Sun Microsystems recently announced its intentions of finally publishing Java under an Open Source license. But what does that actually mean? We'll take a quick look at what it means to be "Open Source," how the Java language specification compares to other more formal language standards, and the importance of the brand and certification programs. We'll then look at what benefits Sun may get from distributing Java as Open Source and at some of the problems that will have to be addressed.
Open Source Software
The Open Source Initiative defines Open Source software and a license must meet 10 criteria to be considered an "Open Source software" license. Essentially, it's a way of thinking about licensing software. It boils down to some very simple ideas about access to source code and the ability to modify the software and distribute those modifications. It encompasses the concept of Free Software as defined by the Free Software Foundation around a set of software "freedoms," such as the freedom to study how a program works and adapt it to your own needs.
Open Source software is typically developed in a collaborative community, either under a strong leader who coordinates the development community, or a meritocratic process where a developer earns the leadership role in the community like the process favored by the Apache community. Some companies build businesses based on Open Source software projects, generally ones they control. For example, MySQL (the company) maintains MySQL (the database engine).
In these cases, the software has a copyright, is owned, and is therefore licensable. Free and Open Source software is not "public domain" in any sense of the phrase.
Software developed in successful Open Source collaborative communities shows all the hallmarks of well-developed software from other processes. Essentially good software is developed by good software developers regardless of the licensing strategy. So Open Source software has just as much potential to be well-structured, have well-defined stable interfaces, and be delivered through a disciplined process that encompasses software inspection, mandatory version control, and automated building and testing as software developed in other ways. Where Open Source differs from other well-developed software is in the collaborative community. The best developers interested in the software can participate in its creation and evolution regardless of where they live or work. This provides a number of benefits:
- Many people see the source code. Software inspections regardless of how informal prove to be much more effective at finding bugs than testing.
- The code is used and tested in a broad base. This expansion of the "test" bed tends to shake out bugs faster and hardens the software.
- A diversity of expertise and experience can be leveraged. This applies both to improving the code base, as well as to innovating on the code base to take it in new and interesting directions.
Sun has been an active participant in the Open Source software world since its inception. The original SunOS operating system was a Berkeley Unix derivative that came out of the collaborative efforts around Unix in the early days. Sun has contributed heavily to the accessibility features in the Gnome desktop. Most recently it has opened the Solaris source code base under its own OSI-approved Open Source license (the Common Development and Distribution License or CDDL) and has been developing the OpenSolaris community. So Sun definitely has experience with Open Source, both contributing to other and developing its own communities.
Let's shift gears for a moment and take a look at Java and the Java Community Process from a standards perspective, as that has been Java's history to date.
Standards (Open and Otherwise)
A specification is simply a document describing some interface for interoperability. Lots of companies publish specifications to enable customers and partners to interoperate software with their products better. In such cases, where the specification is published by a single commercial entity, it typically benefits the company by encouraging add-ons to its product.
A standard is a specification that has been put through some form of consensus process by a collection of interested parties. It may be a formal government-supported de jure process with checks and balances to ensure that the consensus isn't anticompetitive collusion. It may be an industry or trade organization (CBEMA, ECMA, IEEE) with a broad interest in an area, e.g., computing standards. It may be an industry group with a narrower focus (e.g.. OASIS, W3C, IETF). The consensus process has rules that define such things as participation, acceptance, interpretation, amendment, and withdrawal.
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.
That is not to say that there won't be challenges. As with any large code base that exists in a commercial product, all will have to be inspected carefully from a number of angles. Obviously Sun won't want any immature code released, but Sun also has to ensure that all code licensed in from the outside can be released and manage that process.
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
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
