Author: Mark Stone
Be clear on your goals. Know how to separate the myths from the reality about open source. Know which realities will help you reach your goals.
The choice to release software to open source is based on one of two very general reasons: either to gain a marketing benefit, or to gain a software development benefit. The marketing benefit derives from the fact that open source software is freely available (“free” as in beer). The development benefit derives from the fact that the source is freely modifiable and redistributable (“free” as in speech). Some open source releases involve a gray area, where both marketing effects and development effects come into play.
Open source marketing
Any time you give something away for free, you are looking to make money off something else as a result. In this case, the free software compliments a core asset (usually also software). By increasing the market share of the compliment, you increase the market size of the core asset.
This isn’t a strategy that is exclusively the domain of open source. When Netscape wanted to increase the size of its Web server market in the mid-’90s, it believed that one way to do that was by increasing the market share of its Web browser. The Web browser was given away at low or no cost in hopes of increasing demand for the Web server. Microsoft gives away IIS for free in the hopes of increasing its share of the Web server market, thus creating an increase in market size for all the application serving technologies that sit on top of IIS (and for which Microsoft does charge).
One of the problems with giving something away for free is getting people to trust that the software they’re getting is reliable, or at least free of exploits. Here open source has a distinctive marketing advantage, since the source code is open to inspection.
Open source can also play a pre-emptive role in marketing. A low- or no-cost product in a given market means very low margins for a new competitor trying to enter the market. Given the high cost of commercial software development, there is little incentive to enter a market where a strong open source competitor already exists. We see this in at least two areas with open source: Sleepycat Software’s Berkeley DB dominates in the embedded database realm and is very tough to compete against on price.
In another area, we see relatively few commercial Web servers, given that Apache is free and has more than 50 percent market share. Instead software vendors tend to bundle Web serving in as one layer of a more complex application serving stack (this is the approach used by Microsoft and BEA for example).
Marketing and development: The gray area
A classic dilemma in marketing strategy is this: Is it better to own a closed standard, or lead an open standard? The revenue benefits of owning a closed standard can be significant, but only if that standard is widely adopted. The challenge with this approach is to encourage adoption. Some companies succeed admirably at this approach; Microsoft and Oracle come to mind. An open standard is likely to lead to greater competition, hence lower margins. So the business challenges of finding sustainable revenue are greater. On the other hand, market adoption is much less of a problem. Companies are less reluctant to adopt an open standard, and an open standard that gains momentum is likely to encourage other vendors to participate in standardization.
Open source comes down squarely on one side of this debate, since open source software is an extreme case of an open standard: Not just the interfaces are exposed, but the entire body of source code. Furthermore, competing vendors are more likely to participate in an open source process, not just an open standards process, because there are no hidden components that may be changed out from under them.
Your goal in open sourcing software might be, then, to achieve a dominant or at least strong position around an open standard. This is a marketing strategy in its aim: to lead an open standard rather than own a closed one. But it is a development strategy in its execution; you will have succeeded in achieving standardization only when engineers at other vendor companies buy into and participate in the development process.
IBM has adopted this approach around both Linux and Apache. In these cases IBM recognized successful open source projects that were already well on their way to becoming standards. IBM simply jumped in front of a parade that was already under way. Of course IBM doesn’t make money directly from Linux or Apache. The key was to recognize that the server operating system and the Web server are two layers in a larger software stack. By adopting open source at the bedrock level of the stack, IBM could provide revenue-generating value higher up the stack while reassuring customers that they are not vulnerable to vendor lock-in at the core.
In a different context, HP has spearheaded the Common Unix Printing System (CUPS), a collaboration between several major vendors with a stake in the printing business. CUPS is an open standard, and indeed CUPS is licensed under the GPL. Choosing an open source license was the easiest way for HP to get participation from other vendors, and really created an open standard that is industry-wide. While HP and other participating companies don’t make money off CUPS directly, the assurance customers have from knowing their printing infrastructure is based on open standards helps drive printer sales for all the participating companies.
Building an open standard via open source requires the participation of engineers from outside your company. Notice, however, that it does not require very many participants. In the case of CUPS, a few engineers at HP and each of the other leading companies is enough to provide the critical mass needed to really turn the effort into an accepted standard.
Notice also that developer participation from the open source community at large is not really required. While outside participation may be a fringe benefit, the key to standardization is vendor participation. In this context, open source development does not really differ from more traditional forms of software development that work through consortia or standards bodies.
Open source development
Finally, your motivation for going open source may be simply to leverage the software development advantage. While this is a common desire, it is in fact the most difficult goal to achieve. Partly this is because saying you want to “leverage the software development advantage” doesn’t really answer the question. Why do you want to leverage that advantage? What are you trying to accomplish? If the answer is that you want to cut costs by getting outside developers to do the work for you, then you are doomed to failure. We’ll see why later.
Let’s look now at a couple of examples of good reasons for leveraging open source development.
Sun Microsystems makes OpenOffice available as open source. Partly they are motivated by traditional marketing objectives: market penetration and market pre-emption in their competition with Microsoft. But in large part they are looking for development help. Here’s a specific example:
In the international market there are many developing nations that have yet to advance their IT infrastructure to the point where they’ve settled on a standard desktop productivity suite. At the same time, there are dozens of languages in which such a suite needs to work if it is to reach all markets. The development effort to add a new language is laborious, expensive, and often yields very little return for the productivity suite vendor.
On the other hand, those potential customers who work in one of these niche languages (such as Basque) have a high motivation to have a productivity suite available in their language, to the point where they may be willing to contribute the development effort needed. To harness this development effort, the vendor needs to release access to the source code, along with permission to modify and redistribute. In other words, they need to go open source.
This is precisely what Sun has done with OpenOffice, and indeed there are now 37 native language projects within the overall OpenOffice development effort (including Basque). Sun simply could not afford to provide the in-house engineering effort needed to make all this happen on its own. Open source provides a clear solution to the problem.
So one answer to the question “Why go open source?” might be to get development work for a niche module whose market size doesn’t warrant an internal development effort.
How IBM is using Eclipse to its own benefit
Let’s look at a different example. IBM has released its Eclipse software under an open source license. Eclipse is a powerful development environment for Java developers, and prior to its release the open source community really didn’t have a comparable Java development tool. IBM’s motivation is partly marketing; there is some reason to think that customers using Eclipse are more likely to turn to IBM for other solutions in their application development stack. If that were IBM’s only aim, however, simply making Eclipse freely available would suffice. In fact a large part of IBM’s motivation is looking for development help.
As is often the case in open source, the target audience for Eclipse collapses the user/developer distinction. The very people who have an interest in using Eclipse are the ones who have a vested interest in evolving Eclipse and often have the skills needed to contribute improvements back to the Eclipse project.
The users of Eclipse are the people most likely to see where innovation is needed and what direction innovation should take. They are also the ones most likely to find bugs. Because they are themselves developers, they can act directly to add new features or bug fixes if they have access to the source code. Because they will use Eclipse in more ways that IBM could have anticipated, both innovation and error correction will happen in ways that IBM could not have foreseen or managed on its own.
So one answer to the question “Why go open source?” might be to get innovation and error correction in unanticipated directions.
Notice a couple of points about these examples. First, nothing about the decision to go open source in either of these cases alleviates the need to have a strong engineering team in-house with the vendor working on the core project. In fact, since outside contributors are an extra communication link to manage, and because outside contributions must be checked and managed, the likely outcome of going open source is that development costs for a project will go up, not down. If you aren’t prepared to spend more on development than you’re spending already, then don’t go open source.
Second, the kind of development help the vendor is looking for by going open source is very specific to the type of software involved and to the intended market for it. There is no universal answer to why open source development is a good thing. The obvious, though often unstated corollary is that open source development isn’t right for every kind of software project. It isn’t a one size fits all solution.
Netscape experience should teach lessons
In spring of 1998, Netscape made the decision to release the source code to the Netscape browser as the open source Mozilla project. The problem was that at that time Netscape’s browser was like many large pieces of commercial software that had undergone rapid release cycles: It was a large, monolithic piece of code with many add-ons that were really kludges rather than clean solutions to a problem. Understanding the code was difficult for anyone hadn’t live through the evolution of the code to its incarnation at that time, and modifying the code was difficult without affecting the whole.
After six months and a dwindling level of participation from outside developers, the engineering team realized they needed to rewrite the layout engine from the ground up to remove the kludges and provide a modular base that would enable different outside development teams to participate without interfering with each other. The resulting Gecko engine has turned a failing project into a success, but at the cost of over a year of lost development time and the loss of one of Netscape’s lead engineers, Jamie Zawinski.
Code modularity is the key to many successful open source projects (Linux, Apache, the re-vamped Mozilla, to name a few). Modularity matters because of the organizational nature of development teams.
The popular view of open source development contrasts the traditional cathedral view of software development with the so-called bazaar view of open source development. This metaphor suggests that traditional software development is a top-down process of tightly controlled development processes and small teams working in isolation. By contrast, the metaphor suggests, open source is a bottom-up free for all with many developers participating. The metaphor is seductive: Why settle for the development efforts of a small team of five or six people when you could harness the development energy of hundreds or even thousands?
The problem is that open source development doesn’t actually work this way. Nothing about the methods and practices of open source overcomes the limitations famously discussed by Fred Brooks in “The Mythical Man-Month” almost 30 years ago.
Brooks notes that adding personnel to a software engineering project increases the amount of work done linearly. However, each added person creates additional communication links with previous members of the team, and these communication links become part of the project that must be managed. The result is that the amount of work to be done grows exponentially with added personnel thus creating a vicious and self-defeating cycle. This pattern is summarized in the oft-quoted Brooks’ Law: “Adding manpower to a late software project makes it later.”
Handful of developers works best in open source projects
No software development project functions well with more than about 12 core developers. Open source is no exception. Since its inception, SourceForge.net — the world’s largest repository of open source software — has kept a steady ratio of about 10 registered developers for each registered project (currently at 892,000 developers and 85,000 projects). That’s strong evidence that even open source projects don’t scale well past a handful of developers.
Apparently large-scale projects such as Linux are in fact a series of smaller projects organized in modular fashion. Someone interested in improving Linux’s USB support, for example, can work independently of and without interfering with someone interested in IPv6 support in Linux.
An excellent example of the open source organizational structure is the Debian Project. Every part of Debian is broken down into packages. Each package has a maintainer. The maintainer may not actually be one of the core developers, but the maintainer is at least responsible for knowing who the core developers are, what the other tendencies of that package are, both below (depends on) and above (depended on by), and who the maintainers are for those related packages. In this way there is a dedicated team of volunteers assuring that modularity is both maintained and coordinated, and assuring that teams involved with individual packages have channels of communication to other teams.
This kind of role-based hierarchy and modular structure is in fact the organizational scheme recommended by Brooks and others to avoid the pitfalls described in “The Mythical Man-Month.” The magic of open source may well be open source’s immunity to the corporate tendency to let business concerns supercede software engineering discipline. It isn’t that open source is doing something right that others don’t know how to do; it’s that open source avoids doing so many things wrong.
One organizational consequence of open source practices is the need for strong leadership. Don’t expect to just “throw the code over the wall” and have others take it up and improve it. Open source projects are in fact very hierarchical and fail without a strong central vision communicated by strong central leadership. If your company is preparing to release code as open source, then the community expects that leadership to come from you.
Taking the next step
In summary, you can think about a kind of checklist to go through before you commit your company to an open source release:
- What are you hoping to achieve by releasing code open source? Specifically, are you looking for a marketing advantage or a development advantage?
- What core asset will enjoy improved revenue when complimented by an open source release?
- If you are pushing your release as an open standard, who are the other key vendors whose participation you require?
- Have you budgeted for an increase in development time and money as a result of this open source release?
- Is the source code sufficiently modular, and sufficiently readable to someone not yet familiar with the project?
- Are your engineers prepared to coordinate the communication effort with outside developers, understanding that this will likely take the form of a number of smaller outside teams rather than a single “bazaar”?
- While being open to unexpected innovations, are your engineers prepared to communicate a strong central vision of where the project is going?
If you can comfortably answer all these questions, then you’re ready to take the next step.
Mark Stone is a free-lance IT writer based in Northern California.
Category:
- Management
