This is the third paper in the series, The Open Source Monopoly. The goal of the series is to expose a trend in open source that is leading to the creation of a new breed of 'effective' monopolies by commercial open source companies. In this paper, a solution is presented for how the open source community can reverse this trend and insure the long-term survival of the movement.
This paper has led to the establishment of the Openstructure Community.
The marginalization of open source
In the last paper, The Economics of Open Source, I noted that there seems to be an increasing split between the "professional" open source companies and the "pony-tailed faction" of original open source developers and users. One of the many things that the movement has struggled with is to define how money is to be made from open source. An obvious way is for companies to offer paid support services for open source products - there are plenty of examples of this. But the dual-licensing model popularized by Trolltech, MySQL and Sleepycat is becoming increasingly prevelant. While I think this is a bad sign for open source, it is also the natural progression of the technology industry in which a new category of brand names have sprung up to create an effective monopoly of the movement.
While open source developers continue to code away, their movement is being reconfigured and dominated by the commercial open source companies. The latter seem to have forgotten that it is the thousands of individual developers and adopters who are responsible for the marketing term "open source". Instead, the focus of these companies is on the growing number of large IT organizations looking to open source as a cure for the traditional ills of IT. They hope to sway these organizations by branding themselves as the new face of open source.
How to avoid brand-name thinking
I've spent some time in the previous papers outlining the role that brand creation has to do with open source. Now I wish to address exactly why this is not a good thing for open source.
Brand name thinking boils down to the belief that a well-established name automatically guarantees a certain amount of quality and longevity for the product. It establishes a trust in the user for the product. We see this every day in the consumer market. Companies spend billions to get their name in front of consumers and for one simple fact: as consumers, we really don't have the ability to decide whether or not a product will work for us. While it may seem very sophisticated to do comparison or feature shopping, most people still make brand-name decisions. Even if they go through the exercise of comparing features and prices, they still ultimately choose based on what makes them feel "right". That is the point of a brand name. It establishes a feeling of trust which, when all else fails, is going to drive decision-making.
Now there are of course people who think beyond the brand names and buy less known products because they really are thinking about how to meet specific needs. This is why products that aren't brands can stay in the market, albeit a more limited one. However, in the majority of cases, you will find the same consistent brands in people's shopping baskets, driveways or tool sheds. Is this a bad thing? For the brand name companies no. For quality products that never make a name for themselves and end up forced out of the game, yes (the Packard automobile is an example). For consumers who end up with high costs and poor quality from the brand name, yes.
It is the same in the IT world. Quite frankly, a great deal of this could be avoided if IT managers admitted one dirty little secret: it is very hard to understand technology! That is why the industry is so rife with buzzwords. Most decision makers have a hard time articulating business needs and an even harder time evaluating IT products that will fulfill those needs. It actually takes a great deal of smarts to do this. We all think we are doing it, but it is much, much harder than it looks. As a result, our thinking inevitably drifts into a series of feature or quality buzzwords that we cling to like a drowning man clings to a stray plank. We seize on words like "TPM", "throughput", "query optimization", (to use terms from the database world) and then use these to evaluate the features lists of competing products. I'll bet there are many IT managers out there who don't really know whether these features are pertinent to their needs or not. They believe that they must have them and that one they get the product with the most features, the business needs will be magically solved.
The most important point I can make here is this: if you cannot articulate your business needs and identify IT products that can help you fulfill those needs, you end up thinking in terms of concepts. When you think in terms of concepts, whether feature buzzwords or more general buzzwords like "mission critical" or "enterprise interoperability", your thinking is divorced from your needs. And when that happens, the marketing departments have got you. No matter how objective you think you are, you will inevitably find yourself choosing a brand name.
Being objective is supposedly the goal in critical thinking. But as I pointed out in "The Open Source Monopoly", you actually should be subjective, which is much more difficult. If your thinking is not rooted in the subjective needs of your business, you loose any ability to judge whether one product is better than another for your business. You then become concerned with external "facts" or concepts like the buzzwords I just mentioned. Objectivity is a game played very well by marketing folks: any brand name can always "prove" that their product is better based on objective criteria.
You might think that I'm being overly harsh to IT managers in accusing them of brand-name thinking. I do realize that many IT managers are concerned with valid questions such as: "will this product be around for the long term?", "can I get adequate support on this product?", "will this product interoperate with other products I have so as not to incur additional integration expenses?". With questions like this, it is hard not to think in terms of brand names. The brand names promise all these things: longevity, support, interoperability. This is, for example, why a Wall Street company is more likely to choose Red Hat over White Box Linux, or MySQL over PostgreSQL.
The fact of the matter is that the marketplace drives the industry. If IT managers demand the right things, the industry has no choice but to provide them. I believe that after the decades of waste in IT it is time for a new level of accountability. Since there are so many permutations possible in technology, there are many more pitfalls. Therefore, IT departments should be held to a higher standard than other aspects of a business.
The mission of an IT organization should be very clear: "to use technology as a tool for enabling business functions". That is the standard of accountability. To fulfill this standard, all IT personnel should be trained to understand the company's business needs and to know how to derive technology requirements from them. This seemingly basic training will save companies from many a bad choice.
Being grounded in the facts of your business means that you can't be swayed by false promises nor deceived by buzzwords. As an IT manager, you can go out to the industry and choose only products that will fulfill your business requirements. You can cut through the marketing hype and see if there is really something there. You can, for example, find that a Red Hat solution may not serve your needs as well as a Debian platform with a solid support company to back you up. You may find that the Java middleware architecture model being marketed by JBoss adds layers of complexity to your business without any true value. Conversely, you may find that moving your data warehouse to MySQL will save you huge sums of money, even though you may still pay for licenses.
The Product Infrastructure
A good product, whether open source or not, does me as a business owner absolutely no good if I don't know exactly what it does, how to use it, how to use it well and how to use it securely. In my opinion, the greatest criticism of open source is that projects become all about their products and very little about what I call the "Product Infrastructure". The Product Infrastructure is the information and support around a product that is designed to maximize its usability.
Each day dozens of open source projects announce new releases or creations. This emphasis on more and more products, and newer and better releases, is a serious hindrance to usability. Personally, I would rather see a product line completely frozen in the interests of good documentation and support procedures. I think that it is time we step back from the frenetic pace of development and look at what IT departments really need. What they need are not more products, but the infrastructure around them that helps us use them.
When Wall Street companies look at open source products, the reason why they are more likely to choose the brand names that I have talked so much about is that these brand names are willing to provide the product infrastructure. JBoss, for example, provides Tomcat support and hires Tomcat developers in order to gain legitimacy. I don't think that the brand names should be the only ones providing these services. There is no reason why the same open source community that developed the products could not also provide product infrastructure services commercially. It requires a new evolution in community development but one which I think we are all capable of.
Openstructure: an infrastructure for open source products
Accordingly, I'd like to define a new term "Openstructure". This term encompasses all the support services required to make open source products usable for the long run. It is an approach to looking at the product as a whole, not just from the development side. Specifically, it includes:
a.. premier documentation
b.. training services
c.. tiered support services
d.. integration services
e.. security alerts
f.. intuitive administration and operator interfaces
g.. interoperability testing
h.. load testing
i.. release criteria
j.. configuration standards
These services should not be limited to commercial companies providing 24x7 support: everyone in the open source chain needs to participate. Projects, for example, can concentrate on documentation and solid release criteria. Support companies can provide the support services and feed information back into the projects. Integration consultants can build interoperability matrices or "best practices" guides that can help inform decision makers of what products work well together. By taking care of the entire process, we as a community can insure the viability of our products for the long haul. And we can prevent large companies who are open source in name only from coopting the movement while we are too busy looking at our vi or emacs sessions.
There are already plenty of companies making money by providing support for open source products. That is quite legitimate, so long as these companies actually have skills in these areas. It takes a lot more than reading the documentation on the Apache Tomcat site in order to provide Tomcat support services. You don't have to be a project contributor, but you'd better know that source code as well as have the experience of installation and managing production Tomcat installations.
What I'm after, however, is something more. Two years ago, a colleague and I began working on the outlines for an organization I call the Digital Masons Guild (no relation to Freemasons). The mission of this organization is to provide exactly the kind of openstructure services I am talking about. The manifesto of the Digital Masons Guild reads as follows:
--------------------------------------------------------------------
Digital Masons is a guild of software artisans who have pooled their skills in order to provide world-wide and world-class software development services. As members of the Digital Masons Guild, we hold to the following principles:
1. Our guild is based on the belief that, thanks to the Internet, an organization of worldwide software professionals can act as a single team.
2. We choose only members who possess outstanding technical skills, a holistic grasp of the software development lifecycle, a deep understanding of business requirements, a commitment to quality and, above all, the highest professional integrity.
3. A fundamental principle of our mutual association is that we share our experiences, design skills and software components for each and every project we work on.
4. While our market is global, our structure enables us to deliver localized services to our clients.
5. We believe that the combined intellectual and technological resources of our organization, along with a flexible and nominal cost operating structure, offers our clients significant benefits over traditional consulting options.
6. We believe that not only has open source software reached the same maturity as proprietary software, but it offers organizations significant cost benefits in today's economic climate.
7. We believe in a paradigm of software applications composed of modular components and based on open source platforms but customized to client requirements and backed up with long-term support options.
8. Our goal is to bring true long-term value in technology to our clients. We are committed to avoiding technology choices that are merely trends or will lead to a "lock-in" to a real or effective monopoly.
--------------------------------------------------------------------
This manifesto can also be found at http://digitalmasons.org. within a few days, you'll find additional documentation there as well. If you are interested in participating or have constructive suggestions please contact me.
This effort is only a beginning - I'd like to see much more. In particular, I think it would be a great idea for leading open source organizations like the Apache Software Foundation or FreeBSD Foundation to sponsor such groups. I do not think this is contrary to their mission; instead, it complements it. I believe that if large IT organizations find out that they can receive infrastructure services from ASF for Apache, Tomcat and Geronimo, for example, they would be far more likely to convert from proprietary solutions to ASF products. And if they see that ASF is dedicated to enterprise-level stability and interoperability in their products, and works closely with openstructure organizations from various Linux projects to insure that, they would be sold.
A new entrepreneurship
More than anything else, the open source movement represented a new class of entrepreneurs: people who found a way to express their creativity and genius in technology. These people saw the dangers that proprietary monopolies posed to the freedom of the individual to innovate. They did not want to end up as operators of giant Microsoft or IBM shops. They wanted to figure out better ways to do things and be able to make a serious difference in their work. And they did.
Since the beginning, however, the open source movement has been conflicted about money. Some have pushed for a radical interpretation of the "free" nature of open source, trying to devise a means for insuring that the freedom to innovate and create would never again be threatened. Many people mistake this interpretation as tantamount to a contempt for making money. That is missing the point completely. I believe people like Richard Stallman are more concerned with the future of the movement than anything else. Unlike many in the movement, they do not believe in the "they would never do that" argument. Instead, they are concerned that the freedom and entreprenurship of the open source movement will some day be gone and that with it will go their livelihoods. This is a valid concern. And as I have shown, this is all the more valid given that we are watching a new breed of monopolies in the making, one that will someday threaten the job of the software developer.
What I am proposing is that we can, as a community, figure out a way to keep our freedoms alive. We do not have to watch commercial open source companies turn open source into a marketing term designed to get them taken seriously by the IT departments of Wall Street firms. We can build up a infrastructure that cannot be coopted by venture capitalists. We can grow our own names, not by slick marketing, but by a reputation for sheer brilliance, responsiveness and innovation. We can get our names in front of those companies who are considering the move to open source. And we can insure that open source-based enterprises work: not just now, but for the long haul. We can do this because, as a community, we won't be going away and we can guarantee that the products we build, we will also support.
A call to open source project groups
Accordingly, I'd like to issue a call to open source project groups to consider the benefits of developing a support community. We've seen how well people can work together to produce quality software. Now these same people can work together to support that software and enable organizations all over the world to move to an open source platform and avoid being locked-in to a new breed of big name companies.
I also urge project groups to carefully consider the need for new projects or versions. The more projects there are, the less any one will stand out. The more versions that are produced, the more room there is for integration failure or the opening up new security or performance holes. I would also call on projects to develop release criteria, such as those implemented in many IT departments. These criteria should be documented publicly along with release test results and should include such things as integration testing, regression testing and load testing.
More than anything else, open source projects should spend time in making sure their products are as easy to use as possible. Microsoft has succeeded in part because they have been able to create user interfaces that are easier to use than their Unix-based counterparts. There is no reason why the combined geniuses of open source developers cannot do better! I would love to see a new open source project that worked on the specifications for application user interfaces. These specifications could cover GUI applications as well as server applications. I think it is also time to come up with an open standard for server management, something that does a much better job than options like JMX.
A call to IT managers
Sanity in IT departments can only be achieved through a fundamental rethinking of the purpose of IT and technology. The foundations of this thinking are your business needs and how technology can be used to fulfill them. While I offer specific consulting on these subjects, much can be achieved simply by taking an honest look at out-of-control IT expenses and projects! There are many ways to make IT more efficient if you are willing to be honest about your problems.
The promise of open source is real and is being seen in companies all over the globe. Open source is a solid move with immediate cost benefits. But beware of vendor lock-in. Look past the big names and find out what other options exist. If you find a non-profit organization with a really good product, consider supporting its efforts to provide product infrastructure services. This will help keep the open source community vibrant and healthy.
A call to commercial open source companies
From my earlier critique of commercial open source companies, you might think that I don't like any of their products. Actually, I do. I like Berkeley DB quite a bit, and although I like PostgreSQL better, I have happily used MySQL for many years. I'm also pretty experienced in RedHat Linux and Fedora. I believe they all have value. For this reason, I believe that commercial open source companies should focus on the products and not in spinning them a certain way. Really, if a product is open source only because the source code is available, DON'T CALL IT THAT! Instead, rely on the strengths of the product itself.
One thing that I do like about commercial open source is that the prices are relatively low. If I was in the market for an embedded database, for example, I wouldn't hesitate to pay Sleepycat licensing fees. I have no problem with paying for something of value, nor should anyone else. It is when a serious and true movement like open source is turned into just another marketing term that I have a problem.
Honesty in business may not seem to get you very far, certainly not as far as doing whatever you have to do to get a profit. But I think that could change. If the IT side of business starts waking up to the realities of technology, I believe they could demand a greater accountability and openness from the industry. And there is no better way to be "open", than to avoid the kind of marketing double-talk that you find on the websites of most of the companies I have discussed. Be open by being honest!
--------------------------------------------------------------------
Openstructure: A Call for Open Source Reform is Part 3 of The Open Source Monopoly written by Lajos Moczar. Part 1 introduced the idea that the current state of open source is headed for an effective monopoly run by a few select companies, while Part 2 explored the economic models of these companies in more detail.
This article was first published on 1/21/05.
This paper has led to the establishment of the Openstructure Community.
The marginalization of open source
In the last paper, The Economics of Open Source, I noted that there seems to be an increasing split between the "professional" open source companies and the "pony-tailed faction" of original open source developers and users. One of the many things that the movement has struggled with is to define how money is to be made from open source. An obvious way is for companies to offer paid support services for open source products - there are plenty of examples of this. But the dual-licensing model popularized by Trolltech, MySQL and Sleepycat is becoming increasingly prevelant. While I think this is a bad sign for open source, it is also the natural progression of the technology industry in which a new category of brand names have sprung up to create an effective monopoly of the movement.
While open source developers continue to code away, their movement is being reconfigured and dominated by the commercial open source companies. The latter seem to have forgotten that it is the thousands of individual developers and adopters who are responsible for the marketing term "open source". Instead, the focus of these companies is on the growing number of large IT organizations looking to open source as a cure for the traditional ills of IT. They hope to sway these organizations by branding themselves as the new face of open source.
How to avoid brand-name thinking
I've spent some time in the previous papers outlining the role that brand creation has to do with open source. Now I wish to address exactly why this is not a good thing for open source.
Brand name thinking boils down to the belief that a well-established name automatically guarantees a certain amount of quality and longevity for the product. It establishes a trust in the user for the product. We see this every day in the consumer market. Companies spend billions to get their name in front of consumers and for one simple fact: as consumers, we really don't have the ability to decide whether or not a product will work for us. While it may seem very sophisticated to do comparison or feature shopping, most people still make brand-name decisions. Even if they go through the exercise of comparing features and prices, they still ultimately choose based on what makes them feel "right". That is the point of a brand name. It establishes a feeling of trust which, when all else fails, is going to drive decision-making.
Now there are of course people who think beyond the brand names and buy less known products because they really are thinking about how to meet specific needs. This is why products that aren't brands can stay in the market, albeit a more limited one. However, in the majority of cases, you will find the same consistent brands in people's shopping baskets, driveways or tool sheds. Is this a bad thing? For the brand name companies no. For quality products that never make a name for themselves and end up forced out of the game, yes (the Packard automobile is an example). For consumers who end up with high costs and poor quality from the brand name, yes.
It is the same in the IT world. Quite frankly, a great deal of this could be avoided if IT managers admitted one dirty little secret: it is very hard to understand technology! That is why the industry is so rife with buzzwords. Most decision makers have a hard time articulating business needs and an even harder time evaluating IT products that will fulfill those needs. It actually takes a great deal of smarts to do this. We all think we are doing it, but it is much, much harder than it looks. As a result, our thinking inevitably drifts into a series of feature or quality buzzwords that we cling to like a drowning man clings to a stray plank. We seize on words like "TPM", "throughput", "query optimization", (to use terms from the database world) and then use these to evaluate the features lists of competing products. I'll bet there are many IT managers out there who don't really know whether these features are pertinent to their needs or not. They believe that they must have them and that one they get the product with the most features, the business needs will be magically solved.
The most important point I can make here is this: if you cannot articulate your business needs and identify IT products that can help you fulfill those needs, you end up thinking in terms of concepts. When you think in terms of concepts, whether feature buzzwords or more general buzzwords like "mission critical" or "enterprise interoperability", your thinking is divorced from your needs. And when that happens, the marketing departments have got you. No matter how objective you think you are, you will inevitably find yourself choosing a brand name.
Being objective is supposedly the goal in critical thinking. But as I pointed out in "The Open Source Monopoly", you actually should be subjective, which is much more difficult. If your thinking is not rooted in the subjective needs of your business, you loose any ability to judge whether one product is better than another for your business. You then become concerned with external "facts" or concepts like the buzzwords I just mentioned. Objectivity is a game played very well by marketing folks: any brand name can always "prove" that their product is better based on objective criteria.
You might think that I'm being overly harsh to IT managers in accusing them of brand-name thinking. I do realize that many IT managers are concerned with valid questions such as: "will this product be around for the long term?", "can I get adequate support on this product?", "will this product interoperate with other products I have so as not to incur additional integration expenses?". With questions like this, it is hard not to think in terms of brand names. The brand names promise all these things: longevity, support, interoperability. This is, for example, why a Wall Street company is more likely to choose Red Hat over White Box Linux, or MySQL over PostgreSQL.
The fact of the matter is that the marketplace drives the industry. If IT managers demand the right things, the industry has no choice but to provide them. I believe that after the decades of waste in IT it is time for a new level of accountability. Since there are so many permutations possible in technology, there are many more pitfalls. Therefore, IT departments should be held to a higher standard than other aspects of a business.
The mission of an IT organization should be very clear: "to use technology as a tool for enabling business functions". That is the standard of accountability. To fulfill this standard, all IT personnel should be trained to understand the company's business needs and to know how to derive technology requirements from them. This seemingly basic training will save companies from many a bad choice.
Being grounded in the facts of your business means that you can't be swayed by false promises nor deceived by buzzwords. As an IT manager, you can go out to the industry and choose only products that will fulfill your business requirements. You can cut through the marketing hype and see if there is really something there. You can, for example, find that a Red Hat solution may not serve your needs as well as a Debian platform with a solid support company to back you up. You may find that the Java middleware architecture model being marketed by JBoss adds layers of complexity to your business without any true value. Conversely, you may find that moving your data warehouse to MySQL will save you huge sums of money, even though you may still pay for licenses.
The Product Infrastructure
A good product, whether open source or not, does me as a business owner absolutely no good if I don't know exactly what it does, how to use it, how to use it well and how to use it securely. In my opinion, the greatest criticism of open source is that projects become all about their products and very little about what I call the "Product Infrastructure". The Product Infrastructure is the information and support around a product that is designed to maximize its usability.
Each day dozens of open source projects announce new releases or creations. This emphasis on more and more products, and newer and better releases, is a serious hindrance to usability. Personally, I would rather see a product line completely frozen in the interests of good documentation and support procedures. I think that it is time we step back from the frenetic pace of development and look at what IT departments really need. What they need are not more products, but the infrastructure around them that helps us use them.
When Wall Street companies look at open source products, the reason why they are more likely to choose the brand names that I have talked so much about is that these brand names are willing to provide the product infrastructure. JBoss, for example, provides Tomcat support and hires Tomcat developers in order to gain legitimacy. I don't think that the brand names should be the only ones providing these services. There is no reason why the same open source community that developed the products could not also provide product infrastructure services commercially. It requires a new evolution in community development but one which I think we are all capable of.
Openstructure: an infrastructure for open source products
Accordingly, I'd like to define a new term "Openstructure". This term encompasses all the support services required to make open source products usable for the long run. It is an approach to looking at the product as a whole, not just from the development side. Specifically, it includes:
a.. premier documentation
b.. training services
c.. tiered support services
d.. integration services
e.. security alerts
f.. intuitive administration and operator interfaces
g.. interoperability testing
h.. load testing
i.. release criteria
j.. configuration standards
These services should not be limited to commercial companies providing 24x7 support: everyone in the open source chain needs to participate. Projects, for example, can concentrate on documentation and solid release criteria. Support companies can provide the support services and feed information back into the projects. Integration consultants can build interoperability matrices or "best practices" guides that can help inform decision makers of what products work well together. By taking care of the entire process, we as a community can insure the viability of our products for the long haul. And we can prevent large companies who are open source in name only from coopting the movement while we are too busy looking at our vi or emacs sessions.
There are already plenty of companies making money by providing support for open source products. That is quite legitimate, so long as these companies actually have skills in these areas. It takes a lot more than reading the documentation on the Apache Tomcat site in order to provide Tomcat support services. You don't have to be a project contributor, but you'd better know that source code as well as have the experience of installation and managing production Tomcat installations.
What I'm after, however, is something more. Two years ago, a colleague and I began working on the outlines for an organization I call the Digital Masons Guild (no relation to Freemasons). The mission of this organization is to provide exactly the kind of openstructure services I am talking about. The manifesto of the Digital Masons Guild reads as follows:
--------------------------------------------------------------------
Digital Masons is a guild of software artisans who have pooled their skills in order to provide world-wide and world-class software development services. As members of the Digital Masons Guild, we hold to the following principles:
1. Our guild is based on the belief that, thanks to the Internet, an organization of worldwide software professionals can act as a single team.
2. We choose only members who possess outstanding technical skills, a holistic grasp of the software development lifecycle, a deep understanding of business requirements, a commitment to quality and, above all, the highest professional integrity.
3. A fundamental principle of our mutual association is that we share our experiences, design skills and software components for each and every project we work on.
4. While our market is global, our structure enables us to deliver localized services to our clients.
5. We believe that the combined intellectual and technological resources of our organization, along with a flexible and nominal cost operating structure, offers our clients significant benefits over traditional consulting options.
6. We believe that not only has open source software reached the same maturity as proprietary software, but it offers organizations significant cost benefits in today's economic climate.
7. We believe in a paradigm of software applications composed of modular components and based on open source platforms but customized to client requirements and backed up with long-term support options.
8. Our goal is to bring true long-term value in technology to our clients. We are committed to avoiding technology choices that are merely trends or will lead to a "lock-in" to a real or effective monopoly.
--------------------------------------------------------------------
This manifesto can also be found at http://digitalmasons.org. within a few days, you'll find additional documentation there as well. If you are interested in participating or have constructive suggestions please contact me.
This effort is only a beginning - I'd like to see much more. In particular, I think it would be a great idea for leading open source organizations like the Apache Software Foundation or FreeBSD Foundation to sponsor such groups. I do not think this is contrary to their mission; instead, it complements it. I believe that if large IT organizations find out that they can receive infrastructure services from ASF for Apache, Tomcat and Geronimo, for example, they would be far more likely to convert from proprietary solutions to ASF products. And if they see that ASF is dedicated to enterprise-level stability and interoperability in their products, and works closely with openstructure organizations from various Linux projects to insure that, they would be sold.
A new entrepreneurship
More than anything else, the open source movement represented a new class of entrepreneurs: people who found a way to express their creativity and genius in technology. These people saw the dangers that proprietary monopolies posed to the freedom of the individual to innovate. They did not want to end up as operators of giant Microsoft or IBM shops. They wanted to figure out better ways to do things and be able to make a serious difference in their work. And they did.
Since the beginning, however, the open source movement has been conflicted about money. Some have pushed for a radical interpretation of the "free" nature of open source, trying to devise a means for insuring that the freedom to innovate and create would never again be threatened. Many people mistake this interpretation as tantamount to a contempt for making money. That is missing the point completely. I believe people like Richard Stallman are more concerned with the future of the movement than anything else. Unlike many in the movement, they do not believe in the "they would never do that" argument. Instead, they are concerned that the freedom and entreprenurship of the open source movement will some day be gone and that with it will go their livelihoods. This is a valid concern. And as I have shown, this is all the more valid given that we are watching a new breed of monopolies in the making, one that will someday threaten the job of the software developer.
What I am proposing is that we can, as a community, figure out a way to keep our freedoms alive. We do not have to watch commercial open source companies turn open source into a marketing term designed to get them taken seriously by the IT departments of Wall Street firms. We can build up a infrastructure that cannot be coopted by venture capitalists. We can grow our own names, not by slick marketing, but by a reputation for sheer brilliance, responsiveness and innovation. We can get our names in front of those companies who are considering the move to open source. And we can insure that open source-based enterprises work: not just now, but for the long haul. We can do this because, as a community, we won't be going away and we can guarantee that the products we build, we will also support.
A call to open source project groups
Accordingly, I'd like to issue a call to open source project groups to consider the benefits of developing a support community. We've seen how well people can work together to produce quality software. Now these same people can work together to support that software and enable organizations all over the world to move to an open source platform and avoid being locked-in to a new breed of big name companies.
I also urge project groups to carefully consider the need for new projects or versions. The more projects there are, the less any one will stand out. The more versions that are produced, the more room there is for integration failure or the opening up new security or performance holes. I would also call on projects to develop release criteria, such as those implemented in many IT departments. These criteria should be documented publicly along with release test results and should include such things as integration testing, regression testing and load testing.
More than anything else, open source projects should spend time in making sure their products are as easy to use as possible. Microsoft has succeeded in part because they have been able to create user interfaces that are easier to use than their Unix-based counterparts. There is no reason why the combined geniuses of open source developers cannot do better! I would love to see a new open source project that worked on the specifications for application user interfaces. These specifications could cover GUI applications as well as server applications. I think it is also time to come up with an open standard for server management, something that does a much better job than options like JMX.
A call to IT managers
Sanity in IT departments can only be achieved through a fundamental rethinking of the purpose of IT and technology. The foundations of this thinking are your business needs and how technology can be used to fulfill them. While I offer specific consulting on these subjects, much can be achieved simply by taking an honest look at out-of-control IT expenses and projects! There are many ways to make IT more efficient if you are willing to be honest about your problems.
The promise of open source is real and is being seen in companies all over the globe. Open source is a solid move with immediate cost benefits. But beware of vendor lock-in. Look past the big names and find out what other options exist. If you find a non-profit organization with a really good product, consider supporting its efforts to provide product infrastructure services. This will help keep the open source community vibrant and healthy.
A call to commercial open source companies
From my earlier critique of commercial open source companies, you might think that I don't like any of their products. Actually, I do. I like Berkeley DB quite a bit, and although I like PostgreSQL better, I have happily used MySQL for many years. I'm also pretty experienced in RedHat Linux and Fedora. I believe they all have value. For this reason, I believe that commercial open source companies should focus on the products and not in spinning them a certain way. Really, if a product is open source only because the source code is available, DON'T CALL IT THAT! Instead, rely on the strengths of the product itself.
One thing that I do like about commercial open source is that the prices are relatively low. If I was in the market for an embedded database, for example, I wouldn't hesitate to pay Sleepycat licensing fees. I have no problem with paying for something of value, nor should anyone else. It is when a serious and true movement like open source is turned into just another marketing term that I have a problem.
Honesty in business may not seem to get you very far, certainly not as far as doing whatever you have to do to get a profit. But I think that could change. If the IT side of business starts waking up to the realities of technology, I believe they could demand a greater accountability and openness from the industry. And there is no better way to be "open", than to avoid the kind of marketing double-talk that you find on the websites of most of the companies I have discussed. Be open by being honest!
--------------------------------------------------------------------
Openstructure: A Call for Open Source Reform is Part 3 of The Open Source Monopoly written by Lajos Moczar. Part 1 introduced the idea that the current state of open source is headed for an effective monopoly run by a few select companies, while Part 2 explored the economic models of these companies in more detail.
This article was first published on 1/21/05.
Comments