The Oceania metaphor is, of course, not the only one that may be helpful in grasping the new paradigm that open source software represents. Here are a few others that come readily to mind or have been suggested by other writers, summarized briefly for whatever insights they may contribute. Of these, the two that are perhaps the most insightful are the air traffic controller analogy (the first one explored below) and the construction industry metaphor. Of special interest from a historical perspective is “The Cathedral and the Bazaar”. If you find an analogy or metaphor doesn’t speak to you, just skim over it or skip it completely.
In his foreword to Karl Fogel’s “Producing Open Source Software,” Brian Behlendorf likens the coordinating an open source software project to being an air traffic controller, as opposed to being, say, a chief executive officer. An air traffic controller’s job involves lots of careful tracking of incoming and outgoing aircraft, taking into account their courses, altitudes, and speeds. What is especially important here is sequence – making sure that a departing flight will have cleared a runway before an arriving flight needs to use it. It’s crucial that arrivals and departures don’t conflict.
With an open source software project, it’s essential that newly contributed or revised pieces not break what’s working already. The project coordinator needs to understand what pieces need to be completed first so other pieces can use them. An air traffic controller has authority, but pilots have ultimate responsibility, so the controller must work cooperatively with the pilots to ensure safe and efficient flight operations, and frequent, clear communication is an important part of the process. The open source software project coordinator must likewise communicate well with the volunteer developers contributing code.
Cultural anthropologists who first studied the !Kung people of the Kalahari desert, a primitive hunting and gathering culture which survived well into the 20th century, used the terms “fission” and “fusion” to describe the periodic splitting and coalescence of loose-knit nomadic bands. They reported that when a difference of opinion arose within a band about which watering hole to move on to next, the band simply divided into two smaller ones which went their separate ways, apparently without any great conflict or acrimony. And if two bands happened to meet at the same watering hole, they simply merged to form a larger band. Does this sound like volunteers and open source software projects that fork, merge, and evolve?
An anthill is a large physical structure composed of countless tiny pieces constructed through the tireless efforts of many individual ants; an open source project is a large software assembly created through the contributions of many independent developers. An anthill bustles with purposeful activity, as does an active project.
Since we have already brought up treasure, it’s tempting to think of the aggregate body of free applications and public source code available from open source software projects as being like a range of mountains (“mountains of code”) with lodes of gold ore hidden here and there. Surely, one would think, there are some “veins” of code that would have great value if they could only be discovered?
This analogy fits from the standpoint that there are definitely examples of successful commercial software products built on a foundation of open source code. One such example would be Gentleware’s “Poseidon for UML,” which draws on the code base of the ArgoUML open source project (UML is Unified Modeling Language, a graphical language for software design) and adds various capabilities. By employing this strategy, Gentleware has been able to greatly reduce its software development costs and market a proprietary product competing in features with the Rational Rose and Borland Together integrated software development environments but at a substantially lower price.
On the other hand, hasn’t everything in these mountains of code been pretty thoroughly picked over already? Would all those who’ve worked on a particular project have been oblivious to any potential commercial applications?
And from a commercial standpoint this particular analogy breaks down rapidly because of the unique nature of the ore – mining it does not exhaust it! Using an open source code base as the foundation for a commercial software product doesn’t prevent a competitor from building a comparable product using the same code base.
However, from a user standpoint this analogy is a good one. Anyone considering purchasing a commercial software product would probably be well-advised to first search the Internet for a comparable free open source application that might be an adequate or even superior substitute.
In many respects the “Prospecting for Gold” analogy is just a terrestrial version of the Oceania metaphor, but it may speak to some people a little more.
Although those active in the open source software community have been well aware of its steady progress for decades, and although open source software has been on the scope of major players in the commercial software industry, including IBM, Sun, and Microsoft for at least a decade, the open source software paradigm itself is still not generally understood in the “world at large.” This is true even though the open source projects Linux and Firefox in particular have received widespread publicity in the general press. (It should be noted that although software of this nature has been evolving for decades, use of the term “open source” to describe it was first proposed in 1998, as mentioned earlier, so it’s not entirely surprising if it’s still not generally understood in its full implications.)
In his best-selling 2005 economics book The World is Flat, in which he discusses open source software as one of the “flatteners” that have leveled the global competitive playing field for high-tech industries (another is fiberoptic infrastructure), acclaimed New York Times columnist Thomas Friedman says, “the recognition that the world was flat was unnerving because I realized that this flattening had been taking place while I was sleeping, and I had missed it.” He continues, “I wasn’t really sleeping, but I was otherwise engaged,” focusing, like many others, on globalization and related economic and political forces. Friedman need not be too apologetic – he certainly had plenty of company. For example, as mentioned earlier, The Blue Ocean Strategy, which evidently aspires to be a comprehensive analysis of the contemporary business world, doesn’t mention open source software even once – it was definitely under Kim and Mauborgne’s radar!
One important reason for this omission may be the diffuse nature of open source software, with its breadth of applications and its spectrum of licenses. Another may be that open source software does not lend itself to hyperbole (see “The Construction Industry Metaphor” below), and hence does not gather the level of press coverage that commercial software does.
In some ways this metaphor may be a better one than “Under the Radar.” Those closest to the water’s edge are well aware of a rising tide, but its almost imperceptible advance can easily escape the notice of others whom it will eventually reach, and the impact of a rising tide can be profound. Open source software is being adopted little by little, and sometimes without being recognized as such, so its influence is increasingly more widespread and pervasive.
Some of its advocates might argue that open source software is the inevitable winner in the marketplace because of its quality and its unbeatable acquisition cost (zero dollars) – a powerful and unstoppable locomotive that can be ignored only at great peril. However, this locomotive is not of necessity a hurtling one – in fact, it may instead be creeping along. After all, in the “gray ocean” framework there’s no driving urgency to complete an open source software project because there’s no concern that a competitor will get there first. What is of overriding importance is, first, the process by which development progresses (so developers will continue to participate) and, second, the quality of the end product (so end users will adopt it).
Although the “Unstoppable Locomotive” metaphor may be of some relevance for the open source software industry as a whole, the fact that at least 90% of open source software projects fail is a clear indication that progress of the locomotive is erratic rather than steady.
In her foreword to Open Sources 2.0 entitled “Source is Everything,” Kim Polese employs a metaphor in which open source software is both a foundation and a stock of building materials – “bedrock” and “all the base infrastructural building materials you need, and then some.” She points out that “the portfolio of open source building materials now runs to 100,000 or more products,” each useful in its own right but with “little or no sale value,” and says, “You don’t need to make your own bedrock anymore,” as was so long essential in the commercial software industry, because now that market is “filling with useful open source commodities.”
One thing that’s worth noting here is the contrast between this rather mundane metaphor, which regards open source code bases as commodities, and the much more glamorous “Prospecting for Gold” analogy, which implies that certain individual projects may be “treasure,” presenting business opportunities in themselves if only they can be ferreted out. Rather than touting the business opportunities presented by building a commercial application leveraging on a specific open source code base, Polese sees a “vast and growing new marketplace opened by a growing abundance of open source building materials.”
Sports analogies are popular in the business world because they communicate well. However, I doubt that there’s a proper sports analogy for open source software development because open source software is competitive with commercial software, but not usually with other open source software products, so the best analogy would be opposing teams playing two different sports!
Even so, I’ll suggest curling as a sports analogy for open source software development because it’s slow-paced and depends on the careful delivery of stones, which is accomplished by the skill and aim of the thrower coupled with the advice and assistance of the skip and the sweepers. Clear communication between the thrower and the sweepers during the glide of the stone is essential in getting it to come to rest at the intended spot, and good sportsmanship is considered integral to the sport. The drama of curling is subtle and even as an Olympic sport it doesn’t attract a large viewing audience or create much excitement; like open source software, it doesn’t lend itself to hyperbole.
Now, returning to the idea of competition between open source software and commercial software as being like opposing teams playing two different sports, imagine a hockey team – quick, strong, brash – playing against a curling team. The hockey team is a swirl of frenetic activity, moving so fast that its players are almost a blur, lauded by breathless sportscasters, and urged on by the cheering crowd in the arena. With the curling team, it’s hard to see anything at all going on most of the time as its members discuss and set up their shots, and the players are largely anonymous and ignored by the sportscasters and the crowd. Once in awhile there’s a brief period of rather sedate activity when a throw is made and guided to its final placement.
Now suppose someone told you that the curling team would be the inevitable winner in this contest, and that nothing the hockey team could do could change the outcome? This is the argument that open source’s meticulous, deliberate development process gives it a commanding advantage over proprietary commercial software development.
Often cited as a key book about open source software, The Cathedral and the Bazaar by Eric Raymond contrasts the time-consuming, carefully-organized construction of a great cathedral, representing the traditional approach to software development, with the chaotic, loosely-coordinated activity of a bazaar, representing the open source approach. Whatever merits this theme may have in conveying differences in process when developed in detail, on its most superficial level it doesn’t strike me as especially apt either as a evocative metaphor or as an illustrative analogy.
As a metaphor composed of two images, to me the primary associations with the word “cathedral” are solidity and permanence, whereas I think of a bazaar as something fluid and ephemeral-the booths are insubstantial and are taken down at night. However, key attributes of open source software are quality, which translates to stability in the sense of freedom from crash-producing bugs, and permanence in the sense of longevity – the user isn’t always having to change to some new product. This sounds more like the cathedral. And a cathedral doesn’t need to be marketed much; everyone knows about it because it towers above everything around it. Certainly this is how the open source community would like to think of the Linux operating system. It’s the commercial software marketplace, with the deafening cries of the vendors, “Buy the best! Get the greatest! Download now – use your VISA card!” that the bazaar brings to mind as far as I’m concerned.
On the level of analogy, a cathedral is a structure which is the end result of a construction process, while a bazaar is a process that doesn’t result in the construction of anything. What’s of interest is comparing two different construction processes (traditional vs. open source software development) and their end products, so an analogy comparing a structure to a process is in this respect a fundamentally flawed one.
As I gain experience with open source software, the metaphor that begins to resonate most with me is “solid ground,” certainly one that fits well with the islands of Oceania. Whenever I find that an open source application, particularly a multiplatform one, is suitable for a particular task, I breathe a sigh of relief. Now I’ve found a way to do something that I can rely on in the future.