A lot of my time is spent evaluating technology, and I have a confession to make: the licensing is one of the least spectacular bits to review. It’s certainly relevant, and always one of the things we discuss, but it rarely makes the top-10 issues in a review.
As a student, I spent some time studying information technology law, and I’m still intrigued by the legal technicalities of Apache, GPL, LGPL, and other open source licenses. I will also, from time to time, read the fine print of commercial licenses. Your legal department will probably want to do the same. But you should ask yourself this: is the license really a decisive factor when picking software?
Oddly enough, with open source, it often is. In many European countries, governments are actively pushing for the use of “open source” and “open standards.” On a superficial level, that makes a lot of sense. Who’d want vendor lock-in, or extortion by an integrators’ truck system? Think of all the advantages. Who doesn’t want global interoperability? How could you possibly resist the ability to shape and mold software to your liking? And best of all, it’s free!
Of course, in reality, things aren’t quite so black and white. First of all, I have to keep repeating that open source isn’t gratis (“think of free as in free speech, not as in free beer”). The “free” refers to a model of development and innovation, not to a matter of cost. Get out your calculator and tell me this: what’s more expensive over the course of three years. Software that’s $30K up front, with a 15% annual maintenance and support fee; or software that’s “free,” but with $15K a year in “gold support”? Or, if you’re planning on doing it yourself, one FTE? It’s just an example, but you get the point — it’s very hard to do an enterprise implementation cheap, whichever way you turn it. Large companies like IBM aren’t in open source because they’ve suddenly become philanthropists.
So maybe the real reason is development. You can take the open source software and change it. That may be true, but “closed source” doesn’t mean to say you can’t modify the code that’s on your servers. It’s usually a bad idea — your changes may be lost with the next update — but then again, the same could happen with open source software’s next release. Sure, often you can’t really touch compiled commercial code; but how many actually modify and recompile open source C? If you’re a software company, developing on the basis of open source, you may want to actively participate in an open source community and help develop the code. But if you’re not, all you may want out of the community is free support: see the previous paragraph.
In reality, not only is there a large gray area between black and white, there are plenty of zebras, as well. There’s commercial open source, there’s shared source, there’s community open source, there’s community editions, there’s open sourced commercial software. There’s open source without much of a community, and commercial closed source with a large and active community. There’s a lot of mature and stable open source software, and a lot of new and untested commercial software. It’s hard to apply any clichés to such a broad spectrum.
There’s only one thing you can generalize: open source is a specific kind of license. And discussions about which license is better are rather academic. What you’d want to decide on is what your software should do, if and how you want to customize it, and how easy it is to get support when you need it. That means doing your homework, and finding out the real story: you’ll certainly want to know what’s behind the facade. And that’s something that applies to software under any license.
This post was previously published on the blog of my former employer, the Real Story Group, an industry analyst firm specializing in vendor neutral reviews and advice.