Fan Mail from a Flounder

I found the comments about my recent series “Why Your Future Depends on Open Source” really interesting and wanted to share my perspective on them. Several of them offer thoughts that are very common regarding open source’s strengths and weaknesses, which make them ideal jumping-off points to discuss open source myths and realities.

Community and Contribution

A couple of people commented that open source makes support difficult and that if you make changes to the source code of a product you have to contribute those changes back to the community.

This conflates a couple of issues. The first is the requirements of open source licenses. Generally speaking, only certain licenses require you to contribute your changes to the community and then only if you distribute those changes to other entities (this definition of distribute may change with the upcoming GPL3 license). So you often don’t have to contribute your changes back to the community — making the coercive element one commentor described actually non-existent. Whether you should contribute them back is another issue — one that’s very important.

If you modify a program in any non-trivial way, you should seriously consider contributing your changes to the mainstream code base. And the reason why goes beyond altruism. If you have a set of code changes that extend an open source product, you will have to repeatedly apply those changes to successive releases of the product. By working with the development team to get your changes accepted to the mainstream code line, subsequent releases will come with your changes already inside. This lets you avoid the manual, mistake-prone, boring work of cutting and pasting code time and again. 

On the other hand, limiting community contribution to the issue of where you keep your source code changes misses the big picture about open source, which brings us to the second conflated issue.

Community extends well beyond source code and programming. You can contribute to an open source community by creating documentation. Or you can have your employees spend time on forums and mailing lists, answering questions. You can have someone in a non-US office help with translation. The point is that there is much more to open source than code, and there are many ways to help the community. 

Licensing and Costs

One commentor took me to task for focusing only on licensing costs and ignoring other costs that are part of the overall cost structure of implementing a software product. He called for detailed studies that look at every aspect of cost.

While not unmindful of non-licensing costs, it’s hard to generalize about them. They tend to be very specific to a given software infrastructure, organizational skill set, and even attitude toward technology use.

While you often hear how difficult it is to hire open source-savvy people and how much more difficult it is to use open source software, both of which raise the cost of using open source, I believe those factors are context-specific. There are plenty of commercial software products that are difficult to use. And hiring a specific set of skills tends to get easier over time as the technology gets more widely used.

One reason I focus on licensing costs is that they are obvious and not subject to differing opinion — one person may say Linux is difficult to administer while another will aver that it requires less hands-on work, so is cheaper overall to keep up and running. Licenses, on the other hand, come with a price written in black-and-white.

Moreover, one of the reasons to focus on licenses is that the trends in license costs dramatically illustrate a major theme of the series of posts: margins are coming down, which will force a series of changes in behavior, for both vendor and user.

Somewhat akin to this topic was the observation that a commentor made that one of the benefits of open source I overlooked was the fact that source code availability makes it easier for an organization to achieve what it wants from a product — that it can chart its own course without having to wait (fruitlessly, in many cases) for the vendor to deliver a needed feature.

This is very true, although not what I was focusing on in the series of blog posts. The reality is that most organizations do not modify open source products — they are open source users, not creators. Consequently, most organization’s future does not rely on source code access to open source products.

However, I believe that source code availability is a vital aspect of open source software, in that source code availability represents an option for the user base as a whole. In this sense, source code availability has value because it provides user flexibility and thereby freedom from vendor lock-in — even if the option is never exercised.

Support

One or two commentors observed that open source reflects support issues — that no-one provides guaranteed support, and therefore open source is flawed. This supposed lack of guaranteed support is sometimes characterized as open source lacking “one throat to choke” (a rather infelicitous phrase, and one that does not speak very well of the relationship between user and vendor).

It is definitely the case that most open source products lack a vendor standing behind them. The question is, does that cause the product to be less poorly supported for users in real-world use scenarios?

These comments were stated as though commercial software support is somehow a gold standard that open source software can’t aspire to. My experience has been that commercial software support is quite variable — across companies and even across individual support engineers.

I certainly have found many open source products with very good support from the community. For organizations that prefer commercial support, many open source products have companies that stand ready to provide it. Overall, the issue of open source support is a canard. It’s more important to look at a specific open source product’s support infrastructure and assess its trustworthiness than to make a blanket statement about open source support in general.

Conclusion 

Overall, most of the comments offered specific observations or objections that, while containing a nugget of truth, did not vitiate the main thrust of the series — that open source software represents a sea change in the economics of IT and that every organization — whether vendor or user — needs to respond to it.