http://www.galatea.com/opensource.html
"The Open Source Monopoly" was originally published as a single paper. It has since become the first in a series of three. The second paper, The Economics of Commercial Open Source, looks in more detail at the economic models of companies like Red Hat Inc., JBoss and MySQL AB. The third paper, Openstructure: A Call for Open Source Reform presents some solutions to the current trend in open source and offers a challenge to the open source community for reform.
Last month I wrote an article on Apache Geronimo for JavaWorld called "A First Look at Apache Geronimo." In the summary, I stated that "Geronimo aims to be the first J2EE-certified open source J2EE server." As can be imagined, that statement generated a flurry of emails and responses, most of which claimed that in fact, JBoss was the first open source J2EE certified server.
In my reply to some of the reader feedback I received, I clarified that I did not consider JBoss open source in the same way Apache Geronimo is open source. That statement led to more controversy and so I decided to respond fully in a separate article. This paper is my response.
While it may seem a minor issue, the JBoss-Geronimo issue is symptomatic not only of problems with open source, and its definition, but with how we handle computer technology in general. As I will show in this paper, JBoss is by no means in the spirit of open source and should not be considered an open source product. But more, the fact that a company like JBoss can consider itself an open source company is a disturbing sign that the true meaning and intention of the open source movement has fallen victim to the very issues that engendered its inception.
The official definition of "open source"
Let's first consider the meaning of the term "open source". This term was actually once a service mark of the Open Source Initiative (OSI), a non-profit organization. While they now use the service mark of "OSI Certified", they continue to provide an official "Open Source Definition". Under the terms of this definition, software can be called "open source" if it and its source code can be freely modified and redistributed. The redistribution rights do not preclude a company selling such software for profit.
The OSI certifies various software licenses as open source or "OSI Certified" licenses. If you, as a company, want to call your software "OSI Certified Open Source Software", you need to submit your license to the OSI for approval. If approved, your license gets added to the list and you have a new marketing term to use for your products. Currently, Sun Microsystems is going through this process for their "Common Development and Distribution License" (CDDL) for Solaris 10. The list contains dozens of other licenses already.
Under the terms of the OSI definition, JBoss as well as other software along that model are indeed technically considered "open source" just like products from the Apache Software Foundation (ASF) or GNU are. But the real question to ask, is whether we should consider them open source and whether the OSI is in fact doing us a service with their definition. To answer this question, let's look at open source models.
The clash of the models
From its beginnings as a backwater movement among hard-core Unix users, open source has been embraced by an ever-growing community of developers and users. Today, open source projects abound - just look at the staggering numbers of projects listed on sourceforge.net or freshmeat.net. But some clear lines have been drawn as well, so much so, that we can distinguish two main types of development models: the Volunteer Model and the Commercial Model.
In the Volunteer Model, open source software is developed by volunteers donating their time and expertise to collaborate on a specific project (sometimes, however, these volunteers are actually employees paid to work on these projects by their companies). While there are often different roles assigned to various project members, decisions are usually made based on consensus and a desire of all concerned to develop quality software. It is this model which is, of course, what started the open source movement in the first place. And it is this model which underlies most open source projects today.
Non-profit organizations like the Free Software Foundation (FSF), Apache Software Foundation (ASF) and FreeBSD Foundation are based on the Volunteer Model. What they add to the model is the umbrella of a brand-name. Projects developed under these umbrellas are usually very active, have a large user community and enjoy a certain reputation for reliability and quality. These organizations differ primarily in their area of focus and/or license terms.
The Commercial Model was born after open source became a movement; in fact, it seeks to capitalize on the publicity and popularity of the movement. In this model, for-profit organizations often release formerly proprietary code as open source. There are many examples of this. One of the first was Netscape Communications, which released its browser source code in 1998 to form the basis of the Mozilla project (the Mozilla Foundation was created in 2003 as a non-profit organization with startup money from Netscape). One of the most recent is Sun Microsystems, which just announced that Solaris 10 will be released under an open source license.
Under the Commercial Model, for-profit organizations also start brand-new open source projects of their own. Such is the case with JBoss. The model basically works like this: the company creates or sponsors an open source product and its development community. This means that, in addition to a core set of paid employees, the company utilizes volunteers to develop the product. Core product decisions are made by the company, however. In a sense, the company is getting its development work done for free under the guise of open source.
Of course, since the product is released as open source, anyone can download and use the product subject to certain restrictions. This means that the development community does in some way benefit from the work they do. But the real beneficiary is the company which ends up with a product from which it can reap revenue from paid support, consultancy and training services. Increasingly, we are seeing cases where the company eventually creates for-sale versions of the software, also known as "dual-licensing". Such is the case, surprising to many, of MySQL. For years a free product, the revenue model finally kicked in and the software became a commercial product. Yes, you can still download it for free, but you'd better pay attention to the fine print. Both the MySQL open source and commercial license pages have language suggesting (at the least) that you should get a commercial MySQL license if you want to use it as part of internal applications within your own company!
Lest you think that such radical interpretation of the GNU General Public License (GPL) would never happen, keep in mind that there were probably many people who thought SCO was a great company to work for or buy from. Just because a company looks trustworthy one minute, does not mean they won't attempt to sue your pants off when their revenue stream needs help. Or, in our merger-prone world, what happens if one of our favorite open source companies is acquired by the likes of HP, IBM or Oracle? If MySQL could consider it possible to require a commercial license for internal corporate use of MySQL, is it really unthinkable that RedHat and JBoss wouldn't consider the same down the road? And if you'd built your IT infrastructure around those products, what kind of position would that put you in? And, even if this turns out not to be the case, will large-scale IT departments really take the risk of not acquiring a commercial license?
As a long-time user of open source software, this Commercial Model is what concerns me the most. I don't deny anyone the right to make money - we all need it. But what I detest, however, is anyone who embraces a movement for marketing or strategic purposes and then ends up doing the same things as the supposed enemies of the movement. This is why I have a problem with JBoss and other such companies. What I'm talking about, in the end, are monopolies.
The changing face of monopolies
Open source proponents like to think of their movement as radical, revolutionary, industry-shattering. And yes, it has certainly changed the face of many IT departments. But has open source really changed the industry or did the industry just adapt to incorporate it? What we have seen in the past eight years is nothing more than a dialectic in action.
Open source sprang up as a reaction to the monopoly of propriety software that was expensive and often slow to change. A company in the 80s, for example, would often end up buying all their software from one vendor, thereby getting "locked in" to that vendor. The vendor software was proprietary and closed - as a user, you never knew what happened inside the black box. Conversely, open source software was open to all for development, viewing and using. You could download an open source version of UNIX from one place, compiler tools from another, and desktop applications from a third. You could fix things you didn't like, add features you needed and redistribute your changes with little or no restriction. The word in those heady days was freedom, and it looked like it had a promising future.
Marxists will tell you that the dialectic is a good thing: out of two opposing principles a third is born, better than the previous two. Both philosophically as well as practically, however, that is not the reality. What really happens is that one side is essentially rebranded as it subsumes the other. Take the monopoly model of the 80s and 90s. Pure evil, to the open source movement. But where did they go? Let's look at RedHat, a leading open source company. They talk about "solutions" and building "an ecosystem around Linux and open source technology". Sure, I may be "free" to pick other software, but doesn't RedHat want what IBM wanted in the 80s? To gently push me into a network of interlocking software and hardware components all under the same brand name? Monopoly rebranded.
Probably most of my readers' hackles have been raised by the suggestion that there is more in common between IBM, Sun, Microsoft, JBoss and RedHat than not. But you have to look beyond the specifics in order to see the similarities. A monopoly in the 80s is not the same thing as it is today. In the 80s, you could create a monopoly by selling hardware that only ran with your software and software that only ran on your hardware. You wouldn't call it a monopoly, of course, you'd call it a "solution". But, like anything, monopolies have evolved. Now we have brand-name monopolies and marketing monopolies. As a developer, I know what open source software is out there and have the knowledge (and so far, the freedom) to pick and choose what I need. But corporate management often doesn't have the perspective that developers do. Instead, what they see are a select number of brand-names promising a homogenous and integrated open source platform. Just like in the 80s, they pick and choose the "solution" that seems to fit their needs. Once they've picked a "solution" or "ecosystem", they are now effectively "locked in". This may not be an enforced monopoly, but it certainly is one in practice.
Obviously, the early open source developers would never have imagined that their movement would someday be subsumed by the commercial model they worked so hard to escape. But that sublimation is taking place before our eyes. In a few years, the open source movement will be characterized by a handful of large corporations essentially owning the monopoly on the IT infrastructure in organizations all over the world. Not much different than the 80s, it is? Yes, the Apache Software Foundation and others will keep on, but I'll be willing to bet you'll see more of their products rebranded and re-released by the open source monopolies. And yes, sourceforge.net will continue to have tens of thousands of active projects, but very few will have any kind of serious impact on IT.
In 1997, Eric Raymond wrote his paper "The Cathedral and the Bazaar", generally considered the seminal paper in the open source movement. I find it ironic that shortly after writing this paper, Mr. Raymond was invited to help Netscape Communications create its open-source strategy. I'm sure it was a flattering position for a small-time UNIX developer to find himself in, being invited to hobnob with the top executives of one of the major Internet companies of the day. I'm afraid it was too flattering. While Mr. Raymond saw this as a "real-world test of the bazaar model in the commercial model", it was in reality the beginning of the commercial world's rebranding of itself under the open source moniker. And today, where is Mr. Raymond? He is president of the Open Source Initiative; the same organization that happily applies the term "open source" to companies like JBoss, RedHat, Sun and others. I understand his thinking: you must engage commercial companies in the process of the revolution in order for the revolution to succeed. But that is rather like asking a dragon to light your stove. Sure, he'll light a whale of a fire, but then he'll eat you for dinner in front of it.
The problem of products
The reason why open source is failing is because it never got out of a product-based understanding of technology. When you think in terms of products, you introduce a certain disconnect with reality. Instead of thinking: what tools do I need in order to do this job, you think "which is the best product". This is not how we think in other aspects of our businesses. If you have a plumbing business and you need to fix cast iron pipes, you know you need some sort of a pipe wrench. Given the sizes of pipes you deal with, you can figure out what size pipe wrench you need, go to a supply store, and buy it. You don't think about creating a homogenous and integrated set of tools in your toolbox! You buy what you need and never think twice about it. To put it another way, you deal with individual tools that fulfill individual needs - not "solutions" made up a tool suites.
In the computer world, however, we have lost this practical basis of thinking. We now are constantly engaged in what is actually an abstract exercise in determining "the best". It is a seductive argument - after all, don't we want the best possible database, car or mortgage rate? It is more enticing because we believe that we are being "objective" and therefore highly evolved. In fact, however, we have traded the reality of our own subjective needs for somebody else's subjectivity disguised as objectivity! There is no objectivity when anyone can present a product as "the best". If you don't know your own needs any more, how can you possibly distinguish? The only way is through some artificial means like popularity or price.
Is MySQL better than PostgreSQL? It is more popular - is that the same thing? It has better marketing - is that the same thing? In my business, I need a database that I can link to with my commercial, for-sale product. The MySQL license seems to preclude that. So, MySQL is not good for my business. I choose PostgreSQL. No, it is not more popular, but it works perfectly for me and in fact is technically preferable.
While it may seem a minor point, understanding what your business NEEDS is the critical difference between success and failure in IT. Basing decisions on what you need leads to a mode of thinking that judges technology options based on what works in fulfilling those needs. Anything else and you can always become the victim of a better marketing campaign.
In the 90s I was a high-end Sybase database contractor. In almost every shop I worked in, there was some sort of database conversion. One client moved from Sybase to Informix. Another moved from Sybase to Oracle. Another moved from Ingres to Sybase. Stop for a moment and think: were all those decisions made based on business needs? I'm sure that was the official explanation. But take, for example, a conversion I witnessed in a Fortune 500 company that went from Sybase to Oracle. In the Database Administrator (DBA) shop, Sybase DBAs went home at 5pm and showed back up the next morning at 9am. They had issues to attend to, of course, but they lived a fairly normal life. The Oracle DBAs, on the other hand, were always pulling all-nighters. Their problem queue was so deep it took days to respond to outages. So was Oracle or Sybase a better technical solution? The DBAs would tell you Sybase was the better. But it didn't matter because the corporate management fell victim to a better marketing campaign from Oracle. And that was possible because they lost sight of what was important: their business.
Cost too is part of a marketing campaign, believe it or not. It sounds so grown-up and reasonable to make choices based on pricing. But pricing is all in how you spin it. Most of the database conversions I witnessed in my career were ostensibly based on the fact that the new option would save considerable amount of money. But here again, who says so? Marketers. You can make anything look cheaper on paper. But look down the road a few years. If Oracle requires more DBAs because it is technically inferior, then what does the cost picture look like? Or what happens when the new version of Oracle is released which requires bigger servers? This happens all the time - just look at Microsoft. Any more, new products almost always require new hardware.
The new ketchup
In his paper on their economic model, RedHat co-founder Robert Young addressed the problem of making money in open source. He noted that the success of major brand-name products has everything to do with their ability to redefine a product in their terms. He uses the example of Heinz ketchup, which (at least at the time) owns 80% of the ketchup market. It is not the case that Heinz makes a better ketchup than their competitors; the fact is that Heinz has made their brand synonymous with ketchup. And this is what RedHat seeks to do: if you think Linux, you end up thinking RedHat.
The idea of the brand name is THE American marketing strategy. Create a brand and market it mercilessly. Spend half your revenue on getting that name in front of consumers until indeed, your name is completely identifiable with the type of product you sell. Quality? Whether the product is the best for all consumers? Not your concern and not even an issue in the strategy. If you don't believe me, take a look at the first dozen brand names that come to mind in any industry. Then look at the products from their competitors, the guys running a distant third or fourth. Chance are, you'll see a noticeable improvement in quality or suitability. But you'll never know, will you, if the brand name is always in your face? And if you don't know, eventually, you'll stop caring.
If Heinz marketing can successfully get most of the American market to "choose" their product, so be it. It is a matter of taste, and not so very important in the big scheme of things. But what happens when you turn over your computing enterprise to a brand name? Should you be entrusted by your stockholders to make critical IT decisions when you can be influenced far more easily by a brand name than than your company's business needs? This is what I see happening with RedHat, MySQL, JBoss and others, just like it has happened with IBM, HP, Sun and Microsoft. They are making their name synonymous with open source - re-branding open source. In the process, I fear that user needs will be inevitably sacrificed. Better products do exist outside the brand name; in fact, as a general rule, the better products always exist outside of the brand name club. But if users only see names, those products might as well not exist.
Brand-name thinking creates technology monopolies. In the heyday of propriety software, we can all remember how many an IT shop became locked into a technology direction that did not end up serving their business needs. Just because the buzzword today is open source does not mean that anything has changed. It is just as alive and well as it was twenty years ago. If the open source "revolution" was supposed to change this, it failed. Instead, we are now seeing the emergence of the open source brand names and the inevitable lock-in that they will create. A new generation of an old problem.
Version mania
While I'm sort of portraying the open source movement as a victim of corporate greed, it has its own share of blame. If products are not the answer to business needs, then more products are even worse. In a post to my Geronimo article, a reader asked why the ASF had to reinvent the wheel with another J2EE server when a solid product like JOnAS already had quite a history. It is a valid question, and one I asked a founding member of the Geronimo project at ApacheCon 2003. The answer I got was licensing: the Geronimo team wanted a J2EE server under the ASF license. At the time, I accepted the answer, but I understand the poster's concern. JOnAS is a very good product and one I have used for years myself. Rather than worrying myself about the latest and greatest, I think it is more important to understand the business case for the products and then get on with the business of using them.
This endless cycle of development has a particularly obnoxious manifestation in the open source world: version mania. I have been working with Apache projects for many years. At no time have I seen such short and frantic release cycles as I do today. Look at the 1.3 line of the Apache web server - it took six years to get to version .33. But the 2.0 line has taken only four years to get to .52. Apache Tomcat is another good example: version releases sometimes happen within three or four weeks of each other!
This version mania can have only two effects: product instability and integration nightmares. I remember the early days of the 4.0 line of Apache Tomcat. There were some serious memory problems! If you were so unfortunate as to happen upon the project during one of those releases, you'd be in for a bad shock. And now something similar is happening with the Tomcat 5.5 line. After getting burned a few times myself, I have developed my own strategy: once I pick a solid version of an open source product I stick with it no matter what the next hot evolution is. Only for security updates do I consider upgrading, and only then after a serious amount of regression testing. I'm just glad I don't run a large open source-based enterprise without a well-developed implementation and upgrade policy that eliminates the effects of version mania. I'd probably never get sleep.
Advice
I didn't write this paper as a warning of impending danger to the open source movement. I didn't even write it as a prediction. All I'm doing is bringing to light what is already happening and will continue to happen. It won't affect the activities of companies like RedHat, JBoss or MySQL. As more organizations convert to open source these companies will continue to grow and other like them will arise.
All I can offer is advice. If you are a business owner, take a look someday at how much you've spent on technology. Was it worth it? Did you ever subject your technology department to the same rigor you'd expect from your factory or accounting divisions? Did you end up with software tools you could use for decades without having to reinvest because somebody played golf with a new software vendor's sales rep and now wants to switch technologies? If not, perhaps you need to go back to the roots of your business and try to understand what your core needs are. Then find the tools that support those needs. Don't read technology magazines! Sure, new technology sounds sexy. Half of it will disappear within eighteen months. The other half will end up costing you way more than you could ever justify.
If you are in IT management, the best advice I can give you, besides to stop reading technology news, is to talk to your developers. Get to know the people at the bottom of the pyramid - the people actually doing the work. In almost every company I ever consulted with, those were the people who could tell you whether something was going to work or not. If they say a technology is too complicated or buggy, just maybe they know something the marketing people don't want you to know. Think of it as a safety net that can keep you from making bad decisions.
If you are a developer using open source technology, I encourage you to think outside the marketing box. Do a bit of researching before deciding that RedHat or JBoss or MySQL is the "best". They are the most popular and widely-known; that I don't dispute. But that has absolutely no intrinsic relationship to their quality or suitability for your own needs. Take a look at alternatives like Debian, the BSD distributions, JOnAS and PostgreSQL (to name only a few). Keep your eye on license terms, community vibrancy, support options, and, particularly, security and stability. After all, regardless of the scope of your development effort, you may well be building an open source infrastructure for the long haul!
Above all, as I hope I've shown in this paper, it is YOUR OWN NEEDS that you should know best and which should influence your decisions. Be a bit smarter than the competition and don't fall for big names because they are big names or have big marketing budgets. "Know thy business" and you shall know all.
Afterword
In Part 2 of the paper, The Economics of Commercial Open Source, I will examine the strategies used by commercial open source companies and why I believe these practices are bad for the open source movement. In Part 3, Openstructure: A Call for Open Source Reform, I will present ways in which the open source community can address the dangers posed by these practices.
--------------------------------------------------------------------------
Addendum: Dual Licensing, MySQL and Monopolies (posted on 1/12/05)
Since this article was published, there have been some comments that open source does not face any danger from the dual-licensing model that companies like MySQL, RedHat and Sleepycat use. It has been pointed out that the GPL is sufficient protection to insure that the source code from these companies continues to be free and redistributable. While I foresee problems with the interpretation of GPL, perhaps those defending the use of GPL by dual-licensing companies will be proved correct. But that is not the point of my article. The core issue that I am bringing up is the emergence of a new class of brand names in technology.
As a developer, I may know that the "Red Hat Application Server" is really JOnAS rebranded. I can go to the ObjectWeb site, download the source code and build JOnAS myself. But my perspective is not the perspective of IT upper management. They don't know things like that. Above the sea of open source options they are (typically) only aware of the big names with hefty marketing budgets. They will see RedHat, for example, and will buy RedHat. They will see MySQL, and buy MySQL. They will implicitly have a certain "trust" in the brand name and a "distrust" for the lesser-known (or hardly-known) distros that repackage the same code.
Any large commercial vendor ends up creating (directly or indirectly) a network of consultancies and integrators that help implement the vendor's software. The biggest names in the system integration world base their business around the biggest names in the commercial software world. And it will be no different with open source. The open source consultancies that will rise to the top will most likely be "preferred vendors" or "partners" with the big names in the commercial open source world. What this means is that if IT upper management looks for help in building an open source-based enterprise, they will most likely end up with consultants recommending the biggest names.
I hope my point is clear here: when I talk about an "open source monopoly", I am talking about an effective monopoly: one created by an evolution of the marketplace in which, inevitably, a few big names dominate. Sure, as a small business I can build and use my own copy of JOnAS and JBoss. As a small consultancy, I can recommend and implements products like PostgreSQL, JOnAS and Debian. But the wave of the future is the brand. And as long as people substitute brand-name thinking for a hard-nosed, down-to-earth approach, they will choose the name. In every other industry, the lion's share of the market inevitably is owned by no more than four companies. It is no different with computer technology and will be no different with open source.
If we want to avoid this fact of life, then we need to revamp our way of thinking about technology and its role in fulfilling business needs. Without a basis in reality, all you are left with is brand names.
-------------------------------------------------------------------------------------------
The Open Source Monopoly was written by Lajos Moczar, President of Galatea IS Inc. and author of several books and articles on open source technologies. Originally published on 1/7/05, it is now a three-part paper. Part 2, The Economics of Commercial Open Source, and Part 3, Openstructure: A Call for Open Source Reform are now available.
You are welcome to send corrections or insightful comments regarding this article to Lajos at lajos@galatea.com.
This article was first published on 1/7/05 with minor corrections on 1/10/05.
References (in order of appearance)
1.. "A first look at Apache Geronimo", by Lajos Moczar. JavaWorld, 12/13/04, http://www.javaworld.com/javaworld/jw-12-2004/jw-1213-geronimo.html
2.. JBoss Inc. Home Page. http://www.jboss.org
3.. Apache Geronimo Project Home Page. http://geronimo.apache.org
4.. Open source Initiative (OSI) Home Page. http://opensource.org
5.. The Open Source Definition. http://opensource.org/docs/definition.php
6.. OSI Approved Licenses. http://opensource.org/licenses/
7.. Apache Software Foundation Home Page. http://www.apache.org
8.. Free Software Foundation Home Page. http://www.fsf.org
9.. FreeBSD Project Home Page. http://www.freebsd.org
10.. Mozilla Organization Home Page. http://www.mozilla.org
11.. Red Hat Inc. Home Page. http://www.redhat.com
12.. MySQL AB Home Page. http://www.mysql.com
13.. "The MySQL License Question", by Timothy R. Butler, Open for Business, 8/13/04. http://www.ofb.biz/modules.php?name=News&file=article&sid=325. The current MySQL license can be found at http://www.mysql.com/company/legal/licensing/opensource-license.html.
14.. GNU General Public License. http://www.gnu.org/licenses/licenses.html#GPL
15.. Quotes from RedHat come from: http://www.redhat.com/truthhappens/index.html
16.. "The Cathedral and the Bazaar", by Eric S. Raymond. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. Specific quotes regarding Netscape come from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s13.html
17.. PostgreSQL Home Page. http://www.postgresql.org
18.. JOnAS Project Home Page. http://jonas.objectweb.org
19.. "How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry", by Robert Young. Reprinted from Open Sources: Voices from the Open Source Revolution, published by O'Reilly & Associates, 1999. http://www.press.umich.edu/jep/04-03/young.html
20.. Apache HTTPD Project Home Page. http://httpd.apache.org
21.. Apache Tomcat Project Home Page. http://jakarta.apache.org/tomcat
22.. For other articles relating to open source, see: http://www.galatea.com/library/topics?tid=405
"The Open Source Monopoly" was originally published as a single paper. It has since become the first in a series of three. The second paper, The Economics of Commercial Open Source, looks in more detail at the economic models of companies like Red Hat Inc., JBoss and MySQL AB. The third paper, Openstructure: A Call for Open Source Reform presents some solutions to the current trend in open source and offers a challenge to the open source community for reform.
Last month I wrote an article on Apache Geronimo for JavaWorld called "A First Look at Apache Geronimo." In the summary, I stated that "Geronimo aims to be the first J2EE-certified open source J2EE server." As can be imagined, that statement generated a flurry of emails and responses, most of which claimed that in fact, JBoss was the first open source J2EE certified server.
In my reply to some of the reader feedback I received, I clarified that I did not consider JBoss open source in the same way Apache Geronimo is open source. That statement led to more controversy and so I decided to respond fully in a separate article. This paper is my response.
While it may seem a minor issue, the JBoss-Geronimo issue is symptomatic not only of problems with open source, and its definition, but with how we handle computer technology in general. As I will show in this paper, JBoss is by no means in the spirit of open source and should not be considered an open source product. But more, the fact that a company like JBoss can consider itself an open source company is a disturbing sign that the true meaning and intention of the open source movement has fallen victim to the very issues that engendered its inception.
The official definition of "open source"
Let's first consider the meaning of the term "open source". This term was actually once a service mark of the Open Source Initiative (OSI), a non-profit organization. While they now use the service mark of "OSI Certified", they continue to provide an official "Open Source Definition". Under the terms of this definition, software can be called "open source" if it and its source code can be freely modified and redistributed. The redistribution rights do not preclude a company selling such software for profit.
The OSI certifies various software licenses as open source or "OSI Certified" licenses. If you, as a company, want to call your software "OSI Certified Open Source Software", you need to submit your license to the OSI for approval. If approved, your license gets added to the list and you have a new marketing term to use for your products. Currently, Sun Microsystems is going through this process for their "Common Development and Distribution License" (CDDL) for Solaris 10. The list contains dozens of other licenses already.
Under the terms of the OSI definition, JBoss as well as other software along that model are indeed technically considered "open source" just like products from the Apache Software Foundation (ASF) or GNU are. But the real question to ask, is whether we should consider them open source and whether the OSI is in fact doing us a service with their definition. To answer this question, let's look at open source models.
The clash of the models
From its beginnings as a backwater movement among hard-core Unix users, open source has been embraced by an ever-growing community of developers and users. Today, open source projects abound - just look at the staggering numbers of projects listed on sourceforge.net or freshmeat.net. But some clear lines have been drawn as well, so much so, that we can distinguish two main types of development models: the Volunteer Model and the Commercial Model.
In the Volunteer Model, open source software is developed by volunteers donating their time and expertise to collaborate on a specific project (sometimes, however, these volunteers are actually employees paid to work on these projects by their companies). While there are often different roles assigned to various project members, decisions are usually made based on consensus and a desire of all concerned to develop quality software. It is this model which is, of course, what started the open source movement in the first place. And it is this model which underlies most open source projects today.
Non-profit organizations like the Free Software Foundation (FSF), Apache Software Foundation (ASF) and FreeBSD Foundation are based on the Volunteer Model. What they add to the model is the umbrella of a brand-name. Projects developed under these umbrellas are usually very active, have a large user community and enjoy a certain reputation for reliability and quality. These organizations differ primarily in their area of focus and/or license terms.
The Commercial Model was born after open source became a movement; in fact, it seeks to capitalize on the publicity and popularity of the movement. In this model, for-profit organizations often release formerly proprietary code as open source. There are many examples of this. One of the first was Netscape Communications, which released its browser source code in 1998 to form the basis of the Mozilla project (the Mozilla Foundation was created in 2003 as a non-profit organization with startup money from Netscape). One of the most recent is Sun Microsystems, which just announced that Solaris 10 will be released under an open source license.
Under the Commercial Model, for-profit organizations also start brand-new open source projects of their own. Such is the case with JBoss. The model basically works like this: the company creates or sponsors an open source product and its development community. This means that, in addition to a core set of paid employees, the company utilizes volunteers to develop the product. Core product decisions are made by the company, however. In a sense, the company is getting its development work done for free under the guise of open source.
Of course, since the product is released as open source, anyone can download and use the product subject to certain restrictions. This means that the development community does in some way benefit from the work they do. But the real beneficiary is the company which ends up with a product from which it can reap revenue from paid support, consultancy and training services. Increasingly, we are seeing cases where the company eventually creates for-sale versions of the software, also known as "dual-licensing". Such is the case, surprising to many, of MySQL. For years a free product, the revenue model finally kicked in and the software became a commercial product. Yes, you can still download it for free, but you'd better pay attention to the fine print. Both the MySQL open source and commercial license pages have language suggesting (at the least) that you should get a commercial MySQL license if you want to use it as part of internal applications within your own company!
Lest you think that such radical interpretation of the GNU General Public License (GPL) would never happen, keep in mind that there were probably many people who thought SCO was a great company to work for or buy from. Just because a company looks trustworthy one minute, does not mean they won't attempt to sue your pants off when their revenue stream needs help. Or, in our merger-prone world, what happens if one of our favorite open source companies is acquired by the likes of HP, IBM or Oracle? If MySQL could consider it possible to require a commercial license for internal corporate use of MySQL, is it really unthinkable that RedHat and JBoss wouldn't consider the same down the road? And if you'd built your IT infrastructure around those products, what kind of position would that put you in? And, even if this turns out not to be the case, will large-scale IT departments really take the risk of not acquiring a commercial license?
As a long-time user of open source software, this Commercial Model is what concerns me the most. I don't deny anyone the right to make money - we all need it. But what I detest, however, is anyone who embraces a movement for marketing or strategic purposes and then ends up doing the same things as the supposed enemies of the movement. This is why I have a problem with JBoss and other such companies. What I'm talking about, in the end, are monopolies.
The changing face of monopolies
Open source proponents like to think of their movement as radical, revolutionary, industry-shattering. And yes, it has certainly changed the face of many IT departments. But has open source really changed the industry or did the industry just adapt to incorporate it? What we have seen in the past eight years is nothing more than a dialectic in action.
Open source sprang up as a reaction to the monopoly of propriety software that was expensive and often slow to change. A company in the 80s, for example, would often end up buying all their software from one vendor, thereby getting "locked in" to that vendor. The vendor software was proprietary and closed - as a user, you never knew what happened inside the black box. Conversely, open source software was open to all for development, viewing and using. You could download an open source version of UNIX from one place, compiler tools from another, and desktop applications from a third. You could fix things you didn't like, add features you needed and redistribute your changes with little or no restriction. The word in those heady days was freedom, and it looked like it had a promising future.
Marxists will tell you that the dialectic is a good thing: out of two opposing principles a third is born, better than the previous two. Both philosophically as well as practically, however, that is not the reality. What really happens is that one side is essentially rebranded as it subsumes the other. Take the monopoly model of the 80s and 90s. Pure evil, to the open source movement. But where did they go? Let's look at RedHat, a leading open source company. They talk about "solutions" and building "an ecosystem around Linux and open source technology". Sure, I may be "free" to pick other software, but doesn't RedHat want what IBM wanted in the 80s? To gently push me into a network of interlocking software and hardware components all under the same brand name? Monopoly rebranded.
Probably most of my readers' hackles have been raised by the suggestion that there is more in common between IBM, Sun, Microsoft, JBoss and RedHat than not. But you have to look beyond the specifics in order to see the similarities. A monopoly in the 80s is not the same thing as it is today. In the 80s, you could create a monopoly by selling hardware that only ran with your software and software that only ran on your hardware. You wouldn't call it a monopoly, of course, you'd call it a "solution". But, like anything, monopolies have evolved. Now we have brand-name monopolies and marketing monopolies. As a developer, I know what open source software is out there and have the knowledge (and so far, the freedom) to pick and choose what I need. But corporate management often doesn't have the perspective that developers do. Instead, what they see are a select number of brand-names promising a homogenous and integrated open source platform. Just like in the 80s, they pick and choose the "solution" that seems to fit their needs. Once they've picked a "solution" or "ecosystem", they are now effectively "locked in". This may not be an enforced monopoly, but it certainly is one in practice.
Obviously, the early open source developers would never have imagined that their movement would someday be subsumed by the commercial model they worked so hard to escape. But that sublimation is taking place before our eyes. In a few years, the open source movement will be characterized by a handful of large corporations essentially owning the monopoly on the IT infrastructure in organizations all over the world. Not much different than the 80s, it is? Yes, the Apache Software Foundation and others will keep on, but I'll be willing to bet you'll see more of their products rebranded and re-released by the open source monopolies. And yes, sourceforge.net will continue to have tens of thousands of active projects, but very few will have any kind of serious impact on IT.
In 1997, Eric Raymond wrote his paper "The Cathedral and the Bazaar", generally considered the seminal paper in the open source movement. I find it ironic that shortly after writing this paper, Mr. Raymond was invited to help Netscape Communications create its open-source strategy. I'm sure it was a flattering position for a small-time UNIX developer to find himself in, being invited to hobnob with the top executives of one of the major Internet companies of the day. I'm afraid it was too flattering. While Mr. Raymond saw this as a "real-world test of the bazaar model in the commercial model", it was in reality the beginning of the commercial world's rebranding of itself under the open source moniker. And today, where is Mr. Raymond? He is president of the Open Source Initiative; the same organization that happily applies the term "open source" to companies like JBoss, RedHat, Sun and others. I understand his thinking: you must engage commercial companies in the process of the revolution in order for the revolution to succeed. But that is rather like asking a dragon to light your stove. Sure, he'll light a whale of a fire, but then he'll eat you for dinner in front of it.
The problem of products
The reason why open source is failing is because it never got out of a product-based understanding of technology. When you think in terms of products, you introduce a certain disconnect with reality. Instead of thinking: what tools do I need in order to do this job, you think "which is the best product". This is not how we think in other aspects of our businesses. If you have a plumbing business and you need to fix cast iron pipes, you know you need some sort of a pipe wrench. Given the sizes of pipes you deal with, you can figure out what size pipe wrench you need, go to a supply store, and buy it. You don't think about creating a homogenous and integrated set of tools in your toolbox! You buy what you need and never think twice about it. To put it another way, you deal with individual tools that fulfill individual needs - not "solutions" made up a tool suites.
In the computer world, however, we have lost this practical basis of thinking. We now are constantly engaged in what is actually an abstract exercise in determining "the best". It is a seductive argument - after all, don't we want the best possible database, car or mortgage rate? It is more enticing because we believe that we are being "objective" and therefore highly evolved. In fact, however, we have traded the reality of our own subjective needs for somebody else's subjectivity disguised as objectivity! There is no objectivity when anyone can present a product as "the best". If you don't know your own needs any more, how can you possibly distinguish? The only way is through some artificial means like popularity or price.
Is MySQL better than PostgreSQL? It is more popular - is that the same thing? It has better marketing - is that the same thing? In my business, I need a database that I can link to with my commercial, for-sale product. The MySQL license seems to preclude that. So, MySQL is not good for my business. I choose PostgreSQL. No, it is not more popular, but it works perfectly for me and in fact is technically preferable.
While it may seem a minor point, understanding what your business NEEDS is the critical difference between success and failure in IT. Basing decisions on what you need leads to a mode of thinking that judges technology options based on what works in fulfilling those needs. Anything else and you can always become the victim of a better marketing campaign.
In the 90s I was a high-end Sybase database contractor. In almost every shop I worked in, there was some sort of database conversion. One client moved from Sybase to Informix. Another moved from Sybase to Oracle. Another moved from Ingres to Sybase. Stop for a moment and think: were all those decisions made based on business needs? I'm sure that was the official explanation. But take, for example, a conversion I witnessed in a Fortune 500 company that went from Sybase to Oracle. In the Database Administrator (DBA) shop, Sybase DBAs went home at 5pm and showed back up the next morning at 9am. They had issues to attend to, of course, but they lived a fairly normal life. The Oracle DBAs, on the other hand, were always pulling all-nighters. Their problem queue was so deep it took days to respond to outages. So was Oracle or Sybase a better technical solution? The DBAs would tell you Sybase was the better. But it didn't matter because the corporate management fell victim to a better marketing campaign from Oracle. And that was possible because they lost sight of what was important: their business.
Cost too is part of a marketing campaign, believe it or not. It sounds so grown-up and reasonable to make choices based on pricing. But pricing is all in how you spin it. Most of the database conversions I witnessed in my career were ostensibly based on the fact that the new option would save considerable amount of money. But here again, who says so? Marketers. You can make anything look cheaper on paper. But look down the road a few years. If Oracle requires more DBAs because it is technically inferior, then what does the cost picture look like? Or what happens when the new version of Oracle is released which requires bigger servers? This happens all the time - just look at Microsoft. Any more, new products almost always require new hardware.
The new ketchup
In his paper on their economic model, RedHat co-founder Robert Young addressed the problem of making money in open source. He noted that the success of major brand-name products has everything to do with their ability to redefine a product in their terms. He uses the example of Heinz ketchup, which (at least at the time) owns 80% of the ketchup market. It is not the case that Heinz makes a better ketchup than their competitors; the fact is that Heinz has made their brand synonymous with ketchup. And this is what RedHat seeks to do: if you think Linux, you end up thinking RedHat.
The idea of the brand name is THE American marketing strategy. Create a brand and market it mercilessly. Spend half your revenue on getting that name in front of consumers until indeed, your name is completely identifiable with the type of product you sell. Quality? Whether the product is the best for all consumers? Not your concern and not even an issue in the strategy. If you don't believe me, take a look at the first dozen brand names that come to mind in any industry. Then look at the products from their competitors, the guys running a distant third or fourth. Chance are, you'll see a noticeable improvement in quality or suitability. But you'll never know, will you, if the brand name is always in your face? And if you don't know, eventually, you'll stop caring.
If Heinz marketing can successfully get most of the American market to "choose" their product, so be it. It is a matter of taste, and not so very important in the big scheme of things. But what happens when you turn over your computing enterprise to a brand name? Should you be entrusted by your stockholders to make critical IT decisions when you can be influenced far more easily by a brand name than than your company's business needs? This is what I see happening with RedHat, MySQL, JBoss and others, just like it has happened with IBM, HP, Sun and Microsoft. They are making their name synonymous with open source - re-branding open source. In the process, I fear that user needs will be inevitably sacrificed. Better products do exist outside the brand name; in fact, as a general rule, the better products always exist outside of the brand name club. But if users only see names, those products might as well not exist.
Brand-name thinking creates technology monopolies. In the heyday of propriety software, we can all remember how many an IT shop became locked into a technology direction that did not end up serving their business needs. Just because the buzzword today is open source does not mean that anything has changed. It is just as alive and well as it was twenty years ago. If the open source "revolution" was supposed to change this, it failed. Instead, we are now seeing the emergence of the open source brand names and the inevitable lock-in that they will create. A new generation of an old problem.
Version mania
While I'm sort of portraying the open source movement as a victim of corporate greed, it has its own share of blame. If products are not the answer to business needs, then more products are even worse. In a post to my Geronimo article, a reader asked why the ASF had to reinvent the wheel with another J2EE server when a solid product like JOnAS already had quite a history. It is a valid question, and one I asked a founding member of the Geronimo project at ApacheCon 2003. The answer I got was licensing: the Geronimo team wanted a J2EE server under the ASF license. At the time, I accepted the answer, but I understand the poster's concern. JOnAS is a very good product and one I have used for years myself. Rather than worrying myself about the latest and greatest, I think it is more important to understand the business case for the products and then get on with the business of using them.
This endless cycle of development has a particularly obnoxious manifestation in the open source world: version mania. I have been working with Apache projects for many years. At no time have I seen such short and frantic release cycles as I do today. Look at the 1.3 line of the Apache web server - it took six years to get to version .33. But the 2.0 line has taken only four years to get to .52. Apache Tomcat is another good example: version releases sometimes happen within three or four weeks of each other!
This version mania can have only two effects: product instability and integration nightmares. I remember the early days of the 4.0 line of Apache Tomcat. There were some serious memory problems! If you were so unfortunate as to happen upon the project during one of those releases, you'd be in for a bad shock. And now something similar is happening with the Tomcat 5.5 line. After getting burned a few times myself, I have developed my own strategy: once I pick a solid version of an open source product I stick with it no matter what the next hot evolution is. Only for security updates do I consider upgrading, and only then after a serious amount of regression testing. I'm just glad I don't run a large open source-based enterprise without a well-developed implementation and upgrade policy that eliminates the effects of version mania. I'd probably never get sleep.
Advice
I didn't write this paper as a warning of impending danger to the open source movement. I didn't even write it as a prediction. All I'm doing is bringing to light what is already happening and will continue to happen. It won't affect the activities of companies like RedHat, JBoss or MySQL. As more organizations convert to open source these companies will continue to grow and other like them will arise.
All I can offer is advice. If you are a business owner, take a look someday at how much you've spent on technology. Was it worth it? Did you ever subject your technology department to the same rigor you'd expect from your factory or accounting divisions? Did you end up with software tools you could use for decades without having to reinvest because somebody played golf with a new software vendor's sales rep and now wants to switch technologies? If not, perhaps you need to go back to the roots of your business and try to understand what your core needs are. Then find the tools that support those needs. Don't read technology magazines! Sure, new technology sounds sexy. Half of it will disappear within eighteen months. The other half will end up costing you way more than you could ever justify.
If you are in IT management, the best advice I can give you, besides to stop reading technology news, is to talk to your developers. Get to know the people at the bottom of the pyramid - the people actually doing the work. In almost every company I ever consulted with, those were the people who could tell you whether something was going to work or not. If they say a technology is too complicated or buggy, just maybe they know something the marketing people don't want you to know. Think of it as a safety net that can keep you from making bad decisions.
If you are a developer using open source technology, I encourage you to think outside the marketing box. Do a bit of researching before deciding that RedHat or JBoss or MySQL is the "best". They are the most popular and widely-known; that I don't dispute. But that has absolutely no intrinsic relationship to their quality or suitability for your own needs. Take a look at alternatives like Debian, the BSD distributions, JOnAS and PostgreSQL (to name only a few). Keep your eye on license terms, community vibrancy, support options, and, particularly, security and stability. After all, regardless of the scope of your development effort, you may well be building an open source infrastructure for the long haul!
Above all, as I hope I've shown in this paper, it is YOUR OWN NEEDS that you should know best and which should influence your decisions. Be a bit smarter than the competition and don't fall for big names because they are big names or have big marketing budgets. "Know thy business" and you shall know all.
Afterword
In Part 2 of the paper, The Economics of Commercial Open Source, I will examine the strategies used by commercial open source companies and why I believe these practices are bad for the open source movement. In Part 3, Openstructure: A Call for Open Source Reform, I will present ways in which the open source community can address the dangers posed by these practices.
--------------------------------------------------------------------------
Addendum: Dual Licensing, MySQL and Monopolies (posted on 1/12/05)
Since this article was published, there have been some comments that open source does not face any danger from the dual-licensing model that companies like MySQL, RedHat and Sleepycat use. It has been pointed out that the GPL is sufficient protection to insure that the source code from these companies continues to be free and redistributable. While I foresee problems with the interpretation of GPL, perhaps those defending the use of GPL by dual-licensing companies will be proved correct. But that is not the point of my article. The core issue that I am bringing up is the emergence of a new class of brand names in technology.
As a developer, I may know that the "Red Hat Application Server" is really JOnAS rebranded. I can go to the ObjectWeb site, download the source code and build JOnAS myself. But my perspective is not the perspective of IT upper management. They don't know things like that. Above the sea of open source options they are (typically) only aware of the big names with hefty marketing budgets. They will see RedHat, for example, and will buy RedHat. They will see MySQL, and buy MySQL. They will implicitly have a certain "trust" in the brand name and a "distrust" for the lesser-known (or hardly-known) distros that repackage the same code.
Any large commercial vendor ends up creating (directly or indirectly) a network of consultancies and integrators that help implement the vendor's software. The biggest names in the system integration world base their business around the biggest names in the commercial software world. And it will be no different with open source. The open source consultancies that will rise to the top will most likely be "preferred vendors" or "partners" with the big names in the commercial open source world. What this means is that if IT upper management looks for help in building an open source-based enterprise, they will most likely end up with consultants recommending the biggest names.
I hope my point is clear here: when I talk about an "open source monopoly", I am talking about an effective monopoly: one created by an evolution of the marketplace in which, inevitably, a few big names dominate. Sure, as a small business I can build and use my own copy of JOnAS and JBoss. As a small consultancy, I can recommend and implements products like PostgreSQL, JOnAS and Debian. But the wave of the future is the brand. And as long as people substitute brand-name thinking for a hard-nosed, down-to-earth approach, they will choose the name. In every other industry, the lion's share of the market inevitably is owned by no more than four companies. It is no different with computer technology and will be no different with open source.
If we want to avoid this fact of life, then we need to revamp our way of thinking about technology and its role in fulfilling business needs. Without a basis in reality, all you are left with is brand names.
-------------------------------------------------------------------------------------------
The Open Source Monopoly was written by Lajos Moczar, President of Galatea IS Inc. and author of several books and articles on open source technologies. Originally published on 1/7/05, it is now a three-part paper. Part 2, The Economics of Commercial Open Source, and Part 3, Openstructure: A Call for Open Source Reform are now available.
You are welcome to send corrections or insightful comments regarding this article to Lajos at lajos@galatea.com.
This article was first published on 1/7/05 with minor corrections on 1/10/05.
References (in order of appearance)
1.. "A first look at Apache Geronimo", by Lajos Moczar. JavaWorld, 12/13/04, http://www.javaworld.com/javaworld/jw-12-2004/jw-1213-geronimo.html
2.. JBoss Inc. Home Page. http://www.jboss.org
3.. Apache Geronimo Project Home Page. http://geronimo.apache.org
4.. Open source Initiative (OSI) Home Page. http://opensource.org
5.. The Open Source Definition. http://opensource.org/docs/definition.php
6.. OSI Approved Licenses. http://opensource.org/licenses/
7.. Apache Software Foundation Home Page. http://www.apache.org
8.. Free Software Foundation Home Page. http://www.fsf.org
9.. FreeBSD Project Home Page. http://www.freebsd.org
10.. Mozilla Organization Home Page. http://www.mozilla.org
11.. Red Hat Inc. Home Page. http://www.redhat.com
12.. MySQL AB Home Page. http://www.mysql.com
13.. "The MySQL License Question", by Timothy R. Butler, Open for Business, 8/13/04. http://www.ofb.biz/modules.php?name=News&file=article&sid=325. The current MySQL license can be found at http://www.mysql.com/company/legal/licensing/opensource-license.html.
14.. GNU General Public License. http://www.gnu.org/licenses/licenses.html#GPL
15.. Quotes from RedHat come from: http://www.redhat.com/truthhappens/index.html
16.. "The Cathedral and the Bazaar", by Eric S. Raymond. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. Specific quotes regarding Netscape come from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s13.html
17.. PostgreSQL Home Page. http://www.postgresql.org
18.. JOnAS Project Home Page. http://jonas.objectweb.org
19.. "How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry", by Robert Young. Reprinted from Open Sources: Voices from the Open Source Revolution, published by O'Reilly & Associates, 1999. http://www.press.umich.edu/jep/04-03/young.html
20.. Apache HTTPD Project Home Page. http://httpd.apache.org
21.. Apache Tomcat Project Home Page. http://jakarta.apache.org/tomcat
22.. For other articles relating to open source, see: http://www.galatea.com/library/topics?tid=405
Comments