Why Would You Pay for Free Software?

By Charlie Schluting | Oct 14, 2009 | Print this Page
http://www.enterprisenetworkingplanet.com/linux_unix/article.php/3843776/Why-Would-You-Pay-for-Free-Software.htm

We all know we can use open source software without paying, but the real question is: what compels people to buy free stuff? Most widely used free and open source software can also be purchased. We are not speaking of alternative commercial licensing, in this context. We are talking about purchasing support contracts and add-ons for open source software. While you certainly do not need to purchase support services, there may be benefits beyond the obvious ones.

Many popular open source software projects turn into businesses. Not because they use a crack dealer's business practices—getting you hooked on using the software, then demanding money for upgrades or support—but most often because of external pressures to develop features. If a large company depends on a piece of open source software but finds it is missing one critical feature, the company will often persuade the developers of the software to focus resources on implementing the feature. This is done with money, obviously.

After developers implement a new feature and make a few dollars, they often begin developing a business plan. If one company paid, others might too. They invariably offer commercial licensing and support services to other customers, and then develop some non-free add-on products to sell. This is most always the startup process for open source companies, and this evolution frequently creates viable businesses with a full suite of open and closed source software, along with a large consulting department.

But while it is true that most open source software companies make ends meet from non-free components, there are also some that survive just selling the free parts.

Reasons for Buying

A few reasons for purchasing a support contract for free software might include:

  • dependence on product
  • crappy product
  • good product
  • insurance
  • supporting the developers

Dependence on a product and insurance go hand-in-hand. If you rely on an excellent piece of software, no matter how excellent it is, something might someday go wrong. When that happens, who better to call than a small company where support engineers will have access to the actual developers? Of course, you also have a service level agreement (SLA) with that company, guaranteeing a certain response time.

More often than we like to admit, we are stuck with a crappy product. It is the only option, it would cost too much to replace, or we cannot admit to choosing poorly. Whatever the reason, we need help just making the crappy product behave as advertised, so support is required.

Conversely, a good product may also elicit a need to purchase support, but for very different reasons. Aside from insurance or an SLA, we may feel a certain obligation to support the developers. First, they wrote a wonderful piece of software that we depend on and that saves us untold amounts of time. Second, we need to ensure that the project will continue. Finally, we may wish to "sponsor" certain features, rather than code them ourselves.

Reasons Against Buying

Why not spend your budget on support you may never use? Here are a few reasons:

  • incapable of support
  • crappy product
  • good product
  • spite

Unfortunately, the SLA mentioned in the previous section will never mention anything about the quality of support. Receiving a response from an inept person within 60 minutes does absolutely no good. If you have to repeat, and—heaven forbid—explain what you are talking about to the person multiple times, you are better off solving the problem on your own. This is a common experience with most large companies, and open source companies often sadly fall victim to cost cutting and poor service too. The good news is that many smaller companies employ extremely bright people, and they often function at all levels of the organization. Ask for a better SLA, or even ask that unresolved issues be addressed directly by a developer within 24 hours; some companies will actually commit to that. If a company will only commit to a "response time" and has no customer references, you probably don't want to buy (unless you have to).

Crappy software, we imagine, is a good reason not to buy ancillary products or support services. If the software is crappy enough to warrant a no-buy decision, you are likely in the position to switch to an alternative product; lucky you!

Surprisingly, good software is frequently a major reason not to buy. Why purchase support if it always works as advertised? The only reason, if you don't need the insurance of an SLA, would be to support the project. The vast majority of users of open source products fall into this category, which is fine, as long as some percentage of people support the project.

Finally, we have spite. Software developers are not known for their charming nature or tactful mailing list replies. If a project is run by a completely wild character, people often shy away from supporting the project. Chances are the project will eventually fail due to coordination and teamwork issues, but even if not, who wants to support such behavior? What if you submit a support ticket and it gets escalated to one of those well-known, hot-tempered developers? Nobody wants that.

You may notice that we failed to mention "horribly crippled software, unless you pay" products. These simply are not open source projects, and are not worth considering.

There are many reasons to support individual developers or their budding companies if they are kind, produce a useful product, and truly offer something of value.

The majority of open source software businesses that have existed at least a few years have found a niche to occupy and flourish in. Open source software companies often provide surprisingly stellar support services. Just do your homework, and beware: the big-company shockingly-bad-support service is not always limited to big companies.


When he's not writing for Enterprise Networking Planet or riding his motorcycle, Charlie Schluting works as the VP of Strategic Alliances at the US Division of LINBIT, the creators of DRBD. He also operates OmniTraining.net, and recently finished Network Ninja, a must-read for every network engineer.