I recently read an article titled “How Open Source Nearly Killed My Business.” In it, the author laments the adoption of open source, and how the burden of customizing and managing the code far outweighs the benefits it provides. I want to take a few minutes to point out some open source myths and misconceptions presented, and provide some context on those points that (in my opinion) the author presents legitimate arguments in a misleading fashion.
There Are Hidden Costs Involved
It’s no secret that the “Free” in “Free and Open Source Software” applies only to the acquisition costs. The author focuses most of his argument on open source applications, comparing buying a finished application to buying a house, versus buying open source as “everything you need to build a house.” For a specific example, he cites “invoicing companies.”
The Total Cost of Ownership
It should not surprise anyone that a low (or non-existent) purchase price doesn’t translate into a low Total Cost of Ownership. If someone buys me a car (please) I understand that I will still need to pay for insurance, gas, and maintenance. Likewise, I don’t think anyone expects SAP or other ERP applications to be perfect for their enterprise “out of the box.” The same is true with open source applications.
In past roles, I’ve used Moodle as a platform for eLearning courses. It’s a great tool, but I chose not to use the default UI (we branded it for our company) and required some customization around course curricula and approvals. We didn’t have a need for a full-time resource to manage these customizations. We could have used an in-house developer supported by the very strong Moodle community, but instead opted to hired a third-party to create and maintain the code. All for a fraction of the cost of a commercial solution.
The same is true in the open source component world. Acquisition costs are zero, but you must rely on the community or your internal expertise for support. This doesn’t argue for abandoning open source, however. Instead, it is your responsibility to understand the acceptable criteria for the open source you use. The size and vibrancy of the open source community should be part of this criteria. If you choose to integrate “Sally and Joe’s Open Source Extravaganza” from their homepage instead of one with a long track record and active community, you should acknowledge the “operational risk” that comes with this.
Here, I agree with the author. He cites our Future of Open Source Survey, which states most companies have no formal policy for selecting and approving open source. This, however, is not an argument for avoiding open source any more than not looking both ways is an argument against crossing the street.
The answer is to manage the open source you elect to use. This includes maintaining an inventory, or bill-of-materials, for the open source used in your applications.
Let’s be clear, software has vulnerabilities. Period.
You don’t avoid vulnerabilities by using commercial software. Indeed, the chart below shows the vulnerabilities in open source versus commercial software over the past several years from the National Vulnerability Database. As is clear, vulnerabilities in commercial code comprised over 60% of the total vulnerabilities. This is in spite of the fact that it is far simpler to examine open source (since the code is publicly available).
Again, the answer isn’t to avoid open source. The answer is to track it and monitor sources like NVD for new vulnerabilities. After all, you can’t defend yourself against risks you aren’t aware of.
It Infringes on Intellectual Property
It’s true that someone could copy and paste proprietary code into an open source project. The same is true for commercial software. One could argue that the incentive is greater to do this in commercial code, where financial gains can be realized from “stealing” code.
The author cites an opinion (unverified) from a 2006 magazine article stating that parts of open source “are much more likely than homegrown software to have been copied from someone’s proprietary code.” The article provides no evidence for this statement, and I suspect copyright owners of proprietary code would be quick to identify cases like this (again, since they would have access to empirical evidence in the open source code).
The Business Model is Broken
The author’s evidence that the business model is broken is based on a venture capitalist’s statement that “there will never be another company like Red Hat” (e.g., a large, successful software company based on open source).
This sets a high bar; Red Hat has sales greater than $2 billion annually and a market cap of around $13 billion as of this writing. That said, there are some that I would love to have a founder’s stake in, including GitHub, SugarCRM, HortonWorks and Drupal. I suspect if Google spun out Android as an independent company, its market cap would be pretty attractive as well.
The Real Value of Open Source
The author’s argument also presumes that everyone in open source has a profit motive, and that only open source applications provide value. This has never been the case. Developers have contributed to open source for years out of interest in the project’s technology. With the exception of “commercial open source,” these are volunteers who contribute their coding and support expertise because of their interest in the project’s goals. They are doing what they love, but not for money.
Further, the real value of open source to most software companies is that it lowers development costs and accelerates time to market. Open source components eliminate the need to “rebuild the wheel” when adding common functionality. Organizations using open source recognize that contributing back to these projects is good for their business, and is viewed as a benefit by employees. This is why we see the number of open source projects growing each year. At Black Duck, we now track over 2 million unique open source projects.
Lots of benefits, few downsides. If you think that open source nearly killed your business, maybe it’s time to look at other possibilities. It might not be the open source.