Recently, Michael Skok wrote that “open source is eating the software world.” As general partner at North Bridge Venture Partners, Skok should know. He’s witnessed the power of open source as an entrepreneur and VC. And he’s seen the positive, long-term adoption trends revealed by the annual “Future of Open Source” survey sponsored by his firm and others.
While not entirely hyperbole, Skok’s claim raises a fundamental question: Should you let open source eat your software world? Maybe.
If you’re an ISV or if software development is central to your company, some degree of open source adoption is almost a foregone conclusion. But if software development is not a core competency for your company, then using commercial software may still make sense.
In the spirit of full disclosure, my company develops commercial software. We are also one of the vendors who’d get displaced if IT departments decided to replace packaged IT management software with freely-available, open source alternatives. So I’ve got a dog in this fight, so to speak. I’m just not convinced that this particular fight is “winner takes all.” Here’s why.
Build or Buy – You Pay Either Way
As suggested above, not everyone has the desire or the skills to support, maintain and even enhance a software solution. And that’s what you’re doing with open source: You’re responsible for maintaining, enhancing and customizing the application to meet your needs.
Think of commercial software as a house and open source software as everything you need to build a house — raw lumber, nails, sheet rock, windows, plumbing fixtures and the rest. You can spend your money and buy the house, or you can spend your time and build the house. Either way, you pay for your house.
Like a do-it-yourself house, you are on your own if something goes wrong with your homegrown, open source application. Yes, you’ll find plenty of free help online. Too much help, perhaps, and that may lead to one or more wild goose chases as you hunt down and fix the problem yourself (think many, many trips to the Home Depot). But that’s a key dividing line between buying commercial software and building your open source solution.
Free, open source software may be a cost-effective alternative on the front end of an application development project, but you’ve got to factor in the costs of the ongoing maintenance and support as well as the up-front development to get the project’s true cost — not to mention business risk.
Swapping Application Lock-in for Vendor Lock-in
One of the chief advantages of open source software is that it frees you from vendor lock-in, which makes it extremely difficult and expensive to switch off a vendors’ proprietary commercial app. In fact, “freedom from vendor lock-in” ranked as the number one reason to adopt open source software in the 2011 and 2012 Future of Open Source surveys. In the 2013 survey, “freedom from vendor lock-in” was number two, edged out by “better quality software” in the number one slot.
Am I going to argue in favor of lock-in? No, but you’re still locked in with open source software, just not to the vendor. With open source, you’re locked in to your app. After you’ve opted for an open source app, it’s up to you to provide ongoing maintenance, upgrades and troubleshooting, as well as any needed end-user support. Congratulations! You’re now a software vendor. The high switching costs of commercial apps are now replaced by the high costs of supporting open source apps.
Bottom line, open source may be “eating the software world,” but not all of it. For ISVs and other software development professionals, open source is a no-brainer. We use it in development and in our commercial products wherever and whenever it makes sense. It is free, after all, and the quality is second to none, as this year’s Future of Open Source survey reinforces.
But software pros have resources in place to support their open source efforts. Your organization may not be so lucky, or it may not be interested in putting them in place. After all, not every company has acquired an appetite for open source.