The Meanings and Motivations of Open-Source Communities

Simon Phipps was recruited from IBM in 2000, and he has served in recent years as Sun's chief open-source officer. In that role, he oversaw the open sourcing of the Solaris Operating System and the Java platform, both projects that required many years from inception to completion. In the process, he has carefully observed and analyzed the economic, technological, historical, and psychological processes that make open-source communities possible.

In his "Liberating Java" session at the 2007 JavaOne conference and in many other presentations, Phipps has articulated the diverse perspectives that must be grasped in order to understand the dynamics that drive open source.

At the heart of Phipps's analysis is a process of decentralization that is affecting the lives of people across the globe. With the advent of the web and broadband, and with large-scale participation on networks, information can flow freely anywhere, any time, and from any direction. The Information Age is fast becoming the Participation Age as citizens communicate with governments, customers provide input to businesses, and -- of greatest significance for developers -- collaborative software ecosystems spring up everywhere, fundamentally altering the way software is produced.

"Not long ago, software was developed by hiring smart people, locking them in a room, and sliding pizza under the door until the job was done," observes Phipps. "Sun cofounder Bill Joy once said that you can't hire all the smart people. That didn't use to matter, because the ones you couldn't hire would work at some other centralized hub that did not touch your business. But today, all the smart people you can't hire are on a mailing list working on the same sort of software as you, and may be working against you."

In creating software that does not require the unique skills of a very few individuals, developers are more likely to be productive working in an open collaborative context than in one that is closed. The open-source world has come about not out of developers' desire to subvert the established order but simply because everyone has become interconnected, resulting in more effective ways to produce and maintain software.

According to Phipps, the commercial software market has undergone three distinct stages. Until the late 1970s it did not, in effect, exist as a separate entity. Software was bundled with hardware, supplied more or less for free, and served the sole purpose of making the hardware function. A contemporary example of this market would be the firmware supplied in digital cameras.

In the early 1980s, software and hardware became unbundled, as commercial software was created to run on different hardware platforms. For 20 years, software vendors grew in importance as they developed products in isolation and made money by charging for access to their technology. Many factors, including risk aversion, uncertainty, and a desire for simplicity meant that, other things being equal, the more users a program had, the more it was likely to have in the future.

Since the late 1990s, a new market has emerged that is dominated by a process in which users pay not to acquire and use software but rather for assistance in deploying and maintaining it. Increased flexibility and payment for value are the defining characteristics of the third software market.

In previous software markets, people became customers in order to become software users -- at the point of acquisition. In the new market, users become customers when they wish to buy something that enhances the value of the software they are already using, such as support or training.

Open-source communities follow a particular dynamic. They start when a creative developer produces a piece of software to meet a particular need, perhaps for a client or for themselves. The developer is committed to making the software work and uses it to create a free source commons. Soon, a second developer comes to realize that the software offers a starting point for one of his or her projects and modifies the software, fixes bugs, and uses it to solve a business problem.

"If the story ended there, it would be unremarkable," observes Phipps. "But the second developer realizes that every change they make has a life of its own and will need sustaining. Each change in the software will require regression testing, refactoring, and maintenance within the context of the larger body of code. So instead of hoarding changes in the belief that that is what makes them most valuable, developers contribute them back to the commons, benefiting others by the resulting enhancement and themselves by the engagement of the rest of the community to maintain the new code in context."

If developers keep their code for themselves, so many skills are needed that it becomes impossibly burdensome to maintain a fork.

"If you fork a code commons, you discover that the costs rapidly mount and you'll face the cost of creating proprietary software in a closed room," explains Phipps. "So instead of keeping the changes, developers contribute them back, not out of altruism but out of the realization that the best way to produce great software is to contribute back and avoid regression-test hell."

Someone may believe that he or she can rule the world by making the code base proprietary and producing, for example, the greatest application server of all time. But in the process of creating a proprietary product, they quickly discover that the cost of maintaining their code outweighs the benefits. So the process expands as more and more people deploy and develop the software, fix bugs, and contribute to the community. This reduces costs and leverages the network effects of the community.

For Phipps, this is the key dynamic in open-source communities: Open source is not about using software free of cost -- it is about creating valuable software and sustaining it by leveraging the network of other developers in the community. In so doing, developers are not abusing the community but simply collaborating in co-maintaining and co-developing software. The free in free and open-source software refers not to the fact that the software costs no money but to the fact that developers are free to use and improve it.

The track record of open-source communities supports Phipps's analysis. "The Apache Software Foundation," reports Phipps, "looked at their 10-year history and could not find a single example of someone forking an Apache code base and continuing with it as a fork without contributing code back in the end. Everyone either gives up or gives back -- there is no third way."

Phipps identifies three sometimes overlapping roles in the new world of open source.

Co-developers directly contribute to software development and may retain an interest in producing a version of the platform as a binary distribution themselves. Because co-developers contribute innovation to the code base and provide user value to binary distribution, they find the issues of licensing and governance of central importance. Without assurances that code contributions will be integrated, developers risk wasting time and money developing code for a platform. A business must be able to assure customers that code changes will be integrated into the commons.

"Think of it this way," says Phipps. "A code developer is like a chef in a communal kitchen, preparing food for many and also feeding themselves and their guests."

Deployer-developers use free access to a source-code commons to deploy the technology, when, for example, they port an application to an operating system or port an operating system to a hardware platform. Deployer-developers may require the ability to return changes to a source-code commons, and they will estimate the health of a project before working on its technology. Hence, deployer-developers find the governance of a project important but not central.

"A deployer-developer," says Phipps, "is like someone having a dinner at a restaurant. They're making a meal by selecting from different options on the menu. They may make a small contribution, like slicing some bread, but the focus is on assembling the meal."

Deployer-developers may choose not to contribute to the source-code commons when their business exists in a market that favors a proprietary or closed model. They are crucial to the health of a source-code commons because they increase the usage and value of a project.

Users make a threefold contribution to the open-source commons. First, they generate and share knowledge through mailing lists, community sites, and other means, thus making it easier for other users to take advantage of the software. Second, they submit bug reports, which contribute directly to the development process. And third, users attract co-developers to a source commons.

Although the user base constitutes the potential market for open-source software, the role of users is clearly different from that of paying customers. Some users, such as the majority of home IT users, are price sensitive, but for many, IT is strategic, business-critical, and competitive.

"Users love open-source software," explains Phipps, "It's not about getting free stuff -- it's about getting control over what you are using. They don't have to buy a bundle with a glossy box and a coupon book for future promised value. They're used to buying a license and being told it comes with indemnity, installability, documentation, training, and support. Then later, when they make a claim on any of these, they find that much of it is illusory and requires payment further down the value chain."

With open-source software, software trials can be conducted at no cost, reducing or eliminating speculative outlay. If something exceeds the skill of their staff, users may buy the services of a vendor or take risks on peripheral expenses.

"If you hear CIOs talking about reducing costs by not having to pay for software licenses any more," insists Phipps, "they've gotten it wrong. Open source is about getting control over what you do pay for, what you hire for, and what you don't pay for. It's a sustainable way of getting your costs under control as you deploy software."

According to Phipps, the trick to making money in open source is to turn competence in producing software into a competitive advantage in supplying the aftermarket with support and maintenance. Although the former does not guarantee the latter, active co-developers of software are more likely to provide higher levels of service to users, because they have the competence to alter the software as needed.

"There are few free riders in the business of open source," says Phipps. "It's difficult to capitalize upon the innovation unless you're engaged in ongoing development yourself. The value is ultimately derived from the developer's efforts, so the ability to make money on an open-source project is anchored to the committers of that project."

Phipps explains that, with open-source technology, whatever the absolute quality of a product, the relative quality will tend not to be much higher than the nearest rival product in any lucrative market over time. Users are likely to be less averse to risk than in previous software markets. Developers have an incentive to grow the user base and hence to grow the potential aftermarket for the vendor and for the vendor's co-developers. This translates into, among other things, zero or near-zero pricing for software acquisition.

"When you consider the infrastructure requirements in computer hardware and software, and the need for simplicity in sourcing IT infrastructure, the aftermarket for software, although not approaching the 100 percent profit level that legacy software companies expect from each new user, is still quite lucrative," says Phipps.

With five billion Java platform devices and six million Java developers, the potential for innovation and co-development has been enormously magnified with the open sourcing of the platform. The platform has been licensed under the GPL v2, which makes it easier to share code with other projects under the GPL and brings it closer to the values and spirit of the GNU/Linux community. According to a May 2006 Ziff Davis survey, the Linux platform will be the most frequently embedded operating system deployed by 2008.

"We've opened up the complete GNU/Linux market to the skills of developers," observes Phipps. "This is a point of phenomenal opportunity. There is no longer a barrier preventing the Java Runtime Environment from being on any computer on the planet."

And much is happening with Java technology across the planet: Brazil is making a massive investment in basic infrastructure using the Java platform -- an investment that Phipps hopes will lead to the first Java technology-powered economy. Increasingly, Asian countries, China and India in particular, are turning to open source.

The GPL v2 license also discourages forks, by forcing forking behavior to be performed in public. To distribute a binary, all of the source that goes with it must be made available. "If you are a monopolistic corporation trying to make a hostile fork of the platform, you cannot suddenly spring it on us," says Phipps.

The Classpath exception has been added to class libraries on the Java SE platform, which allows developers to combine applications with licenses without needing to carry the GPL licensing requirement to the derived work.

"My friends at the Free Software Foundation say that we've liberated the Java platform," comments Phipps. "We've also liberated the existing Java community. It's no longer trapped in the boxes it was in before -- it's able to spread the boundaries and get out. Who can say what will happen in the future?"

Simon Phipps's Blog
The Open-Source JDK Community
Linux and the GNU Project
Apache Software Foundation
Open-Source Software at Sun Microsystems