There are lots of businesses built around free and open source software. Why should you give them any money?
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 practicesgetting you hooked on using the
software, then demanding money for upgrades or supportbut 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
- dependence on product
- crappy product
- good product
- 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
Reasons Against Buying
Why not spend your budget on support you may never use? Here are a few
- incapable of support
- crappy product
- good product
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, andheaven forbidexplain 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.