Now that we’ve set forth the Oceania metaphor and briefly explained its key images, let’s go through it more carefully, first to see what this metaphor captures about open source software and then to see what it leaves out.
In his 2005 book Producing Open Source, Karl Fogel reports that in 2004 there were almost 80,000 open source projects hosted on SourceForge alone; others are hosted on FreshMeat and some projects have their own websites. It seems safe to say that there were over 100,000 open source software projects in existence at the time of this writing (late 2006).
The gray ocean is an allusion to the popular 2005 business book The Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant by W. Chan Kim and Renee Mauborgne. In the metaphor developed by these authors, the market universe can be divided into two kinds of oceans – “red oceans” that are already in existence and “blue oceans” that are waiting to be created.
Kim and Mauborgne say, “Red oceans represent all the industries in existence today. This is the known marketspace. In the red oceans, industry boundaries are defined and accepted, and the competitive rules of the game are known . . . cutthroat competition turns the red ocean bloody.”
“Blue oceans, in contrast,” they continue, “are defined by untapped market space, demand creation, and the opportunity for highly profitable growth . . . in blue oceans, competition is irrelevant because the rules of the game are waiting to be set.” They cite Cirque de Soleil, Southwest Airlines, and Dell Computer as examples of companies that have created their own regions of “blue ocean” – untapped demand beyond the reach of competitors. The Apple iPod and iTunes might be another example.
Within the open source industry, projects tend to avoid direct competition for cultural reasons as well as practical ones, which would certainly seem not to place open source software in a red ocean. On the other hand, since competition is not irrelevant, simply avoided, it would be difficult to argue that software in this category operates in a blue ocean. And to further complicate matters, an open source project can quite deliberately compete head-on with even a major commercial product, the Linux operating system vs. Microsoft Windows being one example, which is exactly what one expects to find in a red ocean.
So in the Oceania metaphor the ocean is gray because neither red nor blue seems to fit, another indication that we are indeed dealing with a new paradigm. Interestingly, Kim and Mauborgne do not even mention open source software in their analysis of the business world – it’s apparently under their radar, to bring in another metaphor that will be discussed later.
Karl Fogel estimates that 90% to 95% of open source projects fail in the sense that visible work on them has been halted without producing running code. He points out that in some cases work has simply shifted to another project to avoid duplication of effort.
Certainly this book is far from the first document to refer to open source software as “treasure.” One recent example is Chris Jenkins’s 2003 article “Top Technology for Less: The Hidden Treasure of Open Source Software,” which appeared in Catalyst magazine (published by the Ohio Society of Certified Public Accounts) and discusses the potential of open source software for small and medium-sized businesses.
The swamps are there to provide the raw material for the Big Ball of Mud that any large software project is apt to turn into with the passage of time.
The reference here is to the 1991 paper provocatively entitled “Big Ball of Mud” by Brian Foote and Joseph Yoder.
Although this paper isn’t specifically related to Java or any of the other platform-independent programming languages often used for open source software projects, it’s of particular interest and repays rereading and close study. Among other things, it points out that architecture in general relates more to esthetics than to functionality, leading to the perhaps unpalatable but thought-provoking conclusion that what is unesthetic can actual work quite well.
Foote and Yoder draw analogies to urban planning and suggest that a software system that is a “Big Ball of Mud” – “a casually, even haphazardly structured system . . . [whose] organization, if one can call it that, is dictated more by expediency than design” – can arise for any of a number of reasons. “The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition” as a consequence of unregulated growth and repeated, expedient repair. “Still, this [expedient] approach endures and thrives.” “It is certainly a pervasive, recurring solution to the problem of producing a working system in the context of software development.”
One particularly insightful observation is that once a Big Ball of Mud has arisen, internal forces within an organization will militate against rearchitecting it, at least up to a considerable point. The authors also point out that “a complex system may be an accurate reflection of our immature understanding of a complex problem.”
A particularly disquieting argument made by the authors is that esthetic architecture actually impairs functionality and it’s certainly difficult to think of successful large software systems that couldn’t be characterized as “Big Balls of Mud.”
Naturally, the authors do not advocate building systems that are Big Balls of Mud; indeed, they argue that “If you think good architecture is expensive, try bad architecture.” They argue that big, ugly systems often emerge from throwaway code and/or piecemeal growth in response to changing requirements, leading eventually to a situation in which “Once simple repairs become all day affairs as the code turns to mud.” This certainly fits with Brook’s observation that “All repairs tend to destroy structure, to increase the entropy and disorder of a system.”
Despite the value they place on architectural design, the authors advocate focusing first on features and functionality, and then on architecture and performance: “In other words, it’s okay if the system looks at first like a Big Ball of Mud, at least until you know better.” They place their advice in the context of the approach to software development known as Extreme Programming, especially with regard to rigorous testing and the emphasis on feedback and continuous integration as opposed to extensive planning, which is in fact how most open source projects proceed.
Yes, the swamps are actually quite important. As Foote and Yoder point out, a Big Ball of Mud makes “swamp guide” a valuable role. Perhaps the most significant employment opportunity in the open source industry is to become an acknowledged expert on a particular project.
Anyone who wants to make use of that code base (as opposed the application itself) for their own purposes, commercial or non-commercial, is faced with the tradeoff of investing their own or their staff’s time coming up to speed on the code base or contracting for the services of someone who’s already in a good position to help them out.