Given the choice between two products that are identical in functionality, time to market, and quality but different in terms of costâ€"one free and one notâ€"I would absolutely choose the free option. But the decision between licensed software and open source software (OSS) is not such a choice. OSS rarely offers the same functionality, time to market, and quality. When it does, you should certainly go with it, but more often than not, it doesn't. The reason for this is fairly simple: lack of funds in OSS development shops.
One of the problems with the paid license vs. OSS debate is deep-seated conviction on both sides, especially in the anti-Microsoft camp. As you consider these arguments, I ask you to keep an open mind.
The midsize company
This analysis is focused on a typical midsize company, which is defined as having annual revenues of up to US$200 million. Midsize companies are further characterised as being increasingly susceptible to competition. Best business practices dictate that companies in this phase should be focused on growing into global enterprises. Growth means devouring market share by the mouthful, which entails spending money to gain competitive advantage.
Four primary factorsâ€"which have been called "the four horsemen"â€"require consideration when deciding on a solution:
- Time to market
- Quality
- Total cost of ownership (TCO)
- Flexibility
Time to market
The lack of full-time resources (or the reliance upon voluntary efforts) in an open source project typically results in longer development cycles for the product and subsequent upgrades to reach the market. Time to market is one of the most important considerations in today's competitive marketplace. These delays, when compared to the option of purchasing available licensed software, result in lost opportunity cost. This opportunity cost increases the real cost of OSS. OSS adopters will typically wait much longer to receive the same functionality offered by licensed software, and that wait can be costly.
Quality
Reliance on OSS means greater risk exposure on a couple of fronts, namely quality and documentation. Because OSS projects lack the injection of funds that accompany licensing, many open source developers find themselves unable to afford products to improve quality, such as Parasoft's Jtest and Compuware's Boundschecker. The result is that OSS products typically haven't been exposed to the same degree of scalability and performance testing as their licensed software counterparts.
The same lack of funds results in OSS projects that deliver subprofessional documentation. This can usually be remedied if you are prepared to pay for OSS consulting services and/or documentation, but that flies in the face of -free"â€"which brings me to my next point.
Total cost of ownership
I believe that one of the biggest fallacies surrounding the decision to implement open source software is the notion that OSS is -free." Of course, you can download the source code free of charge. But what about the cost of support and maintenance? Some pundits argue that the initial purchase cost of software constitutes 20 percent of total cost of ownership, with 80 percent going toward maintenance. In fact, support and maintenance are often available with OSS, but they're certainly not free.
If you do not already have access to developers well versed in OSS platforms and development tools, you will have to retrain your team (good luck finding enterprise-quality training for PHP) or bring in outside guns to make modifications or fix the eventual bug. Furthermore, there is a dearth of experts in OSS compared to experts in licensed software. Chances are you will have to spend a good deal of time and money training staff to support OSS products.
So although a PHP-based open source content management system may be great for a startup, the time necessary to learn and implement such a system might end up costing a midsize company more money in lost opportunity than the initial cost savings could justify. Remember: Opportunity cost can be greater than any licensing fee, and midsize businesses must always consider this as they look to grow.
Flexibility
OSS provides utmost flexibility because developers have full access to the source code. From a developer's perspective, this can be great, but from a business perspective, it introduces a lot of risk. Here's a hypothetical: What if Oracle was open source? Just because you could modify the source code, should you? Open source flexibility is beneficial only if you absolutely need it. Sometimes you do not want people muddling with the black box. Back to the hypothetical: Oracle worksâ€"don't fix it. In short, open source flexibility may detract from business objectives.
OSS flexibility may also play into your maintenance costs. If you decide to change the source code, you have essentially broken the leash with the OSS provider. It will become increasingly difficult to take advantage of free bug fixes and upgrades. The cost of your modifications will escalate because you now have to maintain much more code, without the help of the OSS provider.
You get what you pay for
OSS definitely has a place in enterprise computing, and for some organisations, such as a startup where upfront licensing fees are prohibitive, it may be the best choice. But although it's hard to generalise, midsize businesses should consider time to market, quality, TCO, and functionality before deciding on a solution. The decision will typically be swayed by one of these horsemen. You should compare each licensed software product to the available OSS options. If your key horsemen for the OSS option match the licensed product, by all means go open source. But if they don't, go licensed.
Let me leave you with one final thought. Suppose you own a midsize business doing US$3 million a week. Which database management system do you choose as the back endâ€"MySQL/Postgresql (OSS) or Oracle/SQL Server (licensed)? Could the real cost of OSS be just as simple as sacrificing peace of mind?
Errors, ommissions and flawed logic:
1) Jonathan states:
"But the decision between licensed software and open source software (OSS) is not such a choice. OSS rarely offers the same functionality, time to market, and quality."
...
This is facetious at best, and plainly wrong otherwise. The Linux and BSD Unix kernels are superior to Windows 2000 and XP on any metric that matters. Apache is superior to IIS. SQUID is superior to Microsoft's web cache product. PHP is superior to ASP.vbScript. Need I go on?
Yes, PostgreSQL does not offer the same features as Oracle. but it offers 80% of the features of Oracle, and the 80% that are actually used by most enterprises. By analogy, I don't go out and spend $400,000 on a mobile home when all I need is a 4-door sedan to drive around the city. Investigate PostgreSQL and MySQL. Commercial support contracts are available. They are powerful and stable products. If they do what you need, use them.
2) Jonathan states:
"The lack of full-time resources (or the reliance upon voluntary efforts) in an open source project typically results in longer development cycles for the product and subsequent upgrades to reach the market."
...
Can you show me the evidence?
Firstly, you will find that between them, IBM, Red Hat, SUN, Suse, SGI, NEC and dozens of other firms are paying for Open Source code to be written and maintained, in contra to your assumption above.
Secondly, you make your choice of platforms and tools to deploy based on what the features and status of these tools and platforms is right here, right now. If Apache has all the features you need and a quality reputation, you deploy it. You do no need to wait around for a successive 'development cycle' to make an appearance. And in case you have no sense of history in IT, you will note that many many IT firms, which publish feature roadmaps for technology, are more than likely to renege on those plans come future years. Anyone remember Microsoft's COM and DCOM vision? How about their DNA vision? How about the original, non-Internet form of MSN and Blackbird?
3) Jonathan states:
"If you do not already have access to developers well versed in OSS platforms and development tools, you will have to retrain your team (good luck finding enterprise-quality training for PHP)"
...
There are over 4 million sites (according to netcraft.com) worldwide which are deployed with PHP. Does Jonathan suggest that these were all conjured up by neophytes? Look, I personally know over 40 solid PHP developers right here in Melbourne. If you are having problems finding PHP people, my email address is below.
5) Jonathan states:
"Open source flexibility is beneficial only if you absolutely need it."
...
This is like saying that Democracy is beneficial only when you need it.
The issue here is that _you_don't_know_when you_may_need_it_!
It's best to have the freedom and the code access upfront. Yes, in almost all circumstances, you probably will not ever need to fiddle with the internals of MySQL, but who knows? Perhaps, maybe, one day, you are running a version which you can't upgrade for some reason, and for which support is no longer available. And one day, a security exploit becomes known for that platform. What do you do sans source code access to find and fix the errant code? For people who have a long-time exposure to this industry, you will recognise that this scenario (or close facsimilies) occurs on an unnervingly regluar basis.