DISCLOSURE: I work for a commercial Open Source Software company called Alfresco that earns revenue by selling commercial support for the software we freely distribute under an OSI-approved license.

A recent CMSWire post cited a study commissioned by a proprietary software vendor to show that Open Source Software is of lesser quality than proprietary. The person funding the survey is quoted as saying, “You certainly can’t use Open Source for something that’s the lifeblood of the company.”

I commented to one of my colleagues that it seemed like this guy just stepped out of a time machine from the 90’s and is still spouting anti-Open Source Software FUD that was dispelled years ago. And because the entire planet, except for this one guy, realizes that Open Source Software in fact runs the mission critical operations of many companies of all sizes and, basically, most of the Internet, the cloud, mobile phones, tablets, and countless other electronic devices, I shall not spend any more time on his nonsense here.

What the post did do, however, was to get me thinking about how companies make the decision to pay for commercial support of the Open Source Software they have deployed in their companies.

In talking it over with my colleague, Richard Esplin, we’ve come up with five drivers that companies think through when they decide whether or not to pay for commercial support of the Open Source Software they use. You can think of this like a scorecard. The higher a software packages scores across these dimensions, the more likely it is that the company will pay for support.

First, a couple of assumptions. Let’s assume that a company has the budget to pay for support. Companies and non-profits that don’t, don’t have the luxury of this decision–they make due. And, let’s further assume that commercial support for a given piece of Open Source Software can be obtained within that budget. Not all OSS has a commercial support option, or one that fits within their budget.

Now, the company is left with a decision: Do we pay for support or not?

Richard and I argue that this decision comes down to these five drivers:

Mission criticality

This one is simple: The more mission critical a piece of Open Source Software is to the business, the more it makes sense to pay someone to help keep that software running.

Switching Costs

If something goes wrong with a library I’m using as a developer, I may be able to find a similar library or I’ll just code around it. However, if my Open Source CRM, ERP, or ECM system fails, it is a different story. Those migrations don’t happen overnight. The higher the switching costs, then, the greater the need for someone to be there to help push through any issues that do arise.

Adoption

Are you one of millions of people using a particular piece of Open Source Software or one of ten? One of the benefits of Open Source Software over proprietary software is that “with enough eyes, all bugs are shallow”. If there is a huge population of people using the software, that means it has been used for a variety of use cases on a variety of platforms. The risk of a problem caused by using the software in a new and unique way is lessened. And a thriving community not only helps with finding and fixing bugs, it can also make it easier and cheaper to get trained up and to get ideas around approaches or to discover new use cases by engaging with that community.

If, however, the Open Source Software is narrowly-adopted, a lot of the benefit of the network effect is lessened. In that case, rather than crowd sourcing support, a company pays someone to do it.

Complexity

Open Source Software runs the gamut of complexity, from relatively simple libraries and small web applications to operating systems and databases and entire software suites. A company’s willingness to pay for support for software comprised of a few thousand lines of code that performs a small number of functions is going to be vastly different than that of a package comprised of millions of lines of code with hundreds of moving parts. Also consider some Open Source Software projects that are built on top of multiple layers of more foundational components, which are also Open Source.

The more complicated the stack (large code base, lots of moving parts, lots of layers and dependencies), the more it makes sense to pay a single vendor with deep expertise in the entire stack.

Cost of Self-Support

The final driver is the cost of supporting the software internally. In this case, I mean “cost” in the economic sense of the word, to be inclusive of the real dollars it costs to hire, train, and employ people with expertise in that software but also in terms of the opportunity cost experienced when a company spends their own fiscal and human resources on supporting the software instead of on other things. For a huge company with a deep bench of under-utilized people with technical skills in a certain area, for example, the cost of self-support may be relatively cheap. Companies where that is not the case are more willing to pay someone else to support the software because it is extremely costly for them to do it on their own.

Weigh Each Driver to Make a Decision

You can see how a strong score in one of these areas might offset a weaker score in others. For example, maybe you are using an Open Source Software package that is widely Adopted and has low Switching Costs but is of relatively high Complexity. Even if the Cost of Self-Support is high relative to what commercial support would cost, you might still not pay for support because you judge that the benefits of wide Adoption and low Switching Costs outweigh everything else.

Mission Criticality has the potential to trump the other drivers, though. A company whose existence depends on a piece of software that is completely unsupported appears wreckless, despite how low the actual risks may be when a package scores low on the other dimensions. Commercial support works like an insurance policy in this case.

All software breaks. Companies have to decide how they will deal with that when it happens. Companies may weight each of these drivers differently, but I think these five drivers are a good model of the decision at hand. And isn’t that the cool thing about Open Source Software? A company gets to make their own decision whether or not they want to pay for commercial support and from whom they want to buy it. I think that’s pretty awesome.