Supporting Open Source

by Mark Stone

December's SDForum meeting brought together some of the leading names in Open Source. Many of the questions asked touch on a theme that has been a long-standing concern: what about support for Open Source software? This was surprising to me because, first, "support" wasn't even one of the conference topics, and second, the questions asked about support are ones I've been hearing for at least five years. Today I'll review some of the perspectives on Open Source support, and argue that the options are better than the proprietary alternatives. What I have to say here isn't particularly new, but the fact that the same questions continue to arise suggests that these ideas bear repeating.


Let's start with an analogy. Consider the automotive maintenance market. There are basically three "support" models for automobiles:


  • Do it yourself mechanics, people with the expertise to do their own auto repairs and maintenance. My high school buddy Ken, who generally had more engine parts from his '68 Firebird laid out in the garage than he had under the hood, would be an exmaple.
  • Local repair shops. My friend Greg runs Auto Tech, our town's best repair shop; Greg and his three mechanics do a booming business.
  • Dealerships. I bought my car from Central Valley Automotive, and they'd love nothing more than to have me sign up for an extended service contract with them.

Some interesting things to note right away: the existence of the local repair shop is only possible because the automotive industry is based on open standards. Wheels and tires come in standard sizes. Electrical power generation has been standardized around a generator - alternator - battery model that enables dozens of companies to offer equally batteries. In general, there is a large industry of "after market" parts suppliers that makes the market price competitive.


Second, note that dealerships actually make most of their profit off of service contracts. When I buy a new car, the dealership only makes a few hundred, maybe a thousand dollars above what the manufacturer charges. That money barely pays for the sales staff that sells me the car. The real money for the dealership comes on the overhead they charge for repair work, and on the profit from service contracts.


Finally, there is some evidence that the quality of dealership repairs is not as good when compared to local shops capable of doing the same repairs. I don't think this means that dealership mechanics are inherently less skilled. The real difference -- and this is a key point -- is that they don't work with the pressure of competition. Once you've bought the service contract, there's only one place you're going for repairs (unless you want to void the contract). There's no risk that you'll take the job to a competing shop, or even go to a competing shop for a second opinion.


In a standards-based, competitive market, how is it that dealership repair shops are able to prosper, given that they charge more for work of generally lower quality?


Two words: convenience and comfort.


The sad reality is that we live in a large, anonymous world where personal knowledge of who you do business with is often hard to come by. In a large, urban area we probably don't know or talk to many other customers of the same dealerships or repair shops that we frequent, and investing time to research who offers good quality and good value for customer service is an inconvenient process with an uncertain outcome.


We've been coached by advertisers to regard well known brand names as trustworthy and comforting. Brands offer us security and reassurance in an otherwise anonymous and uncertain world.


Many people think no further than that, and simply put their faith in the auto dealership. It gives them a single point of contact for all their problems, backed by the warm, fuzzy feeling of working with a known brand.


In fact, for any one living in a large urban area, there is probably a repair shop as close or closer than the dealership with a better mechanic and a lower price that can effectively handle all but a few repair issues.


The software world works in a sadly similar way.


The vendor of proprietary software functions much like the auto dealership. They are the provider of the product, have the power of the brand, and seem to most IT managers like the natural, indeed the only place to turn to for support.


In many cases, even with proprietary software, there are the equivalents of the local repair shop. Solaris and Oracle come to mind as two proprietary packages where there are many support alternatives beyond the software vendor. Some are large, established organizations like Taos, others are one man consulting firms in your neighborhood.


The world of Open Source is no different. There are single destination providers for software and service like IBM, HP, or Red Hat. There are dedicated service providers and individual consultants. This range of choices can be overwhelming, but it is fundamentally a good thing. It means that support for Open Source operates within a competitive marketplace, where competition provides some assurance of quality and price control.


When was the last time you got off of a tech support call with Microsoft and felt like you were getting the best value for your dollar?


One of the constant refrains I hear with regard to Open Source -- and here I'll use Linux as an example -- is that "Nobody owns it, so my boss has no one to hold accountable when things go wrong."


The misconceptions in this statement are many.


First, to return to the car analogy, such a statement is like saying "Nobody owns the internal combustion engine, so there's no one to hold accountable when things go wrong." In the car case, the obvious retort is that many vendors package their products around the internal combustion engine, and those vendors as well as third parties are all capable of providing support and accountability down to the engine level.


Likewise with Linux, many vendors package their software around the Linux kernel, and those vendors as well as third parties are all capable of providing support and accountability right down to the kernel level.


Second, it's a mistake to say that no one owns Linux. Every component of Linux, and indeed every piece of Open Source software has a copyright, and someone to whom that copyright is assigned. In this regard, Open Source software is no different from proprietary software. While it is true that there is no company to which the copyright on Linux is assigned, this is no different from many other pieces of core technology infrastructure that corporations rely on without question: TCP/IP, SMTP, ANSI C, SQL, HTTP,just to name a few.


In fact with proprietary software there is a real danger that a company will subject itself to sub-standard support for a key piece of software. Let's return to the car analogy for a moment.


When I purchase a car from a dealership and must then determine who to rely on for service, I initially face a competitive landscape:


  • I can sign a long term service agreement with the dealership
  • I can take my car to the dealership on a case by case basis, without signing a long term agreement
  • I can take my car to a local shop

So long as I keep my choices competitive, I enjoy the advantages of a free market system. Service providers, forced to compete, must make some effort to offer a fair price and reasonable quality, or else risk losing business.


The moment I sign that long term service agreement with the dealer, however, I have forgone the advantages of the free market system and voluntarily signed up to be on the short end of a monopoly relationship. I now have only one service provider I can go to, and thus no choice or control over the quality or pricing of service that I get.


Proprietary software functions in exactly the same way. If I don't sign a service agreement with the software vendor, then I may have some competitive choices (though not always). The moment I sign that service agreement, however, I have taken a potentially competitive free market situation and volunteered to enter into a monopoly relationship with the software vendor.


Why would any company put themselves in that situation unless they had no choice?


And that's what Open Source is all about: giving you choice. Because no single company owns the software, the options for support will always be competitive.


There is a further, and oft over-looked differentiator between Open Source software and proprietary software.


We often fall into the trap of anthropomorphizing corporations: treating them like individuals. In fact a corporation is not an individual, and hence when ownership is assigned to a corporation all of the intangibles we associate with an individual sense of ownership are gone. Those intangibles disappeared the moment employees signed their hiring documents, including the all too standard assignment of intellectual property rights to the employer.


The sense of ownership in Open Source is much more personal. The surest test of this is to look at the longevity of Open Source leaders and the projects they are associated with. Linus Torvalds still leads Linux after nearly fifteen years. Alan Cox is still a key member of the Linux kernel team after a decade or so. Brian Behlendorf still keeps his hand in the Apache project, as he has from the very beginning. Larry Wall is still the chief architect behind Perl, after more than a decade. Eric Allman still guides Sendmail, as he has from the beginning in 1981.


Developers in the world of proprietary software with this kind of dedication and personal committment are rare (an intriguing exception: David Cutler).


Do I draw comfort from knowing that a piece of software belongs to a company and that the company will be around for the long term? Perhaps, but it is a hollow comfort at best. Who at Oracle has worked on the core database since the first version? Probably no one. Who at Microsoft has been involved in Excel from the very beginning? Again, probably no one. The typical life cycle of proprietary software almost inevitably means that those working on the current version are working in part with code that they did not write, and whose authors have long since moved on. Is it any wonder that bugs proliferate, and support suffers?


By contrast Open Source developers are more personally involved in their projects, and stick with their projects longer, in large part because they own the software in a very real and personal sense. If my company has an issue with Apache, chances are someone on the Apache team has direct knowlegde of and a long history with the code in question. If my company has problems with a Debian package, I can get direct access to the package maintainer, and probably a list or organizations that provide support for the package in question.


This is a different model for software support than most companies are accustomed to. Different does not make it inferior, however. If trust, reliability, and accountability are the core of support, then support in Open Source should be regarded among our Best Known Practices for creating supported and supportable software.

Have support issues stopped deployment of Open Source in your company?


1 Comments

jwenting
2004-01-21 03:59:22
you'd be surprised...

Do I draw comfort from knowing that a piece of software belongs to a company and that the company will be around for the long term? Perhaps, but it is a hollow comfort at best. Who at Oracle has worked on the core database since the first version? Probably no one. Who at Microsoft has been involved in Excel from the very beginning? Again, probably no one. The typical life cycle of proprietary software almost inevitably means that those working on the current version are working in part with code that they did not write, and whose authors have long since moved on. Is it any wonder that bugs proliferate, and support suffers?


I work for a software company delivering several systems which have in some guise been on the market for 15-20 years.
We still have several of the original programmers of the package on staff, and we're only about 50 people strong.
In fact, of those 50 about a third have been with the company for 10 years or more, so for most if not all of the life of the current products.


I think the same is true in larger corporations as well (like Microsoft and Oracle).
For example, Steve Balmer and Bill Gates started Microsoft from scratch and wrote the first products in their own homes. They still work there (though I doubt they still have time to do much coding).
While younger employees are more likely to switch jobs on a whim (in fact, a few years ago it was sometimes frowned upon by career planners to stay with a company for more than 2 years if you're under 35) older employees tend to stick around.


Another example:
I worked for a major bank where also a good part of the team had been working on the same team (this was the development team for the entire IT infrastructure) since its original start over a decade earlier.


In OS projects there is probably about the same turnover in staff.
While the founders are likely to stick to the end, the younger members come and go as their interests shift.
The only difference is that they typically do not get paid (or if they get paid it's by an outside COMPANY, the kind you seem to despise so much) who pay them to contribute to that project only so long as it makes commercial sense for that company to support that project.
Many of the largest and most successful OS projects would in fact flounder rather quickly and messily if the companies supporting them were to withdraw their staff and financial resources.
The maintainers would have to leave to do other work that gets them money to pay the rent leaving the project leaderless with only a gaggle of constantly changing initiates trying to keep it going but failing because of lack of oversight.