Even the most fervent sceptic would find it hard to argue against the value of open source technologies such as Git, Ubuntu, Android, LAMP or Mozilla Firefox. Open source software development has enriched the tech landscape, made possible only thanks to the culmination of efforts from within the open source community. And what’s not to love? The DIY, ‘everyone can have a go’ mantra of the open source movement means the barriers to entry are low.
The spirit of being able to upgrade, improve, enhance and expand the functionality of code through a crowdsourced effort is nothing short of magnanimous. Like many others, we too as a company have benefitted greatly from unsponsored open source projects, and long may this continue. But it's not the right approach for everyone.
So what should be considered as part of any evaluation? And what - if any, are the potential risks of using open source?
1. The Quality Conundrum
Open source often equates to limited warranty or no support, which means you’re using it at your own risk. Past security compromises such as Heartbleed, Shellshock, and Poodle have all fuelled the debate over reliability. The quality of the code can also be further compromised by ‘burnout risk’ – the point when the source code owner loses interest towards investing time and energy in improving the code base.
Open source can be challenging for many organizations, just based on the sheer number of engagement options available. Without the required expertise to navigate the open source landscape, where to focus resources and on which code strand can quickly turn in to a minefield.
2. Goodbye Free, Hello Premium
Developers are proud tinkerers. The lure of free, open source code tends to deter away from proprietary, fee-based software options. It's just a false economy. With free open source there's an unknown nature of what you’re inheriting, and with little support in place, your late-night calls for help may fall on deaf ears.
Countless businesses have built a revenue model based on ‘free open source, come and sign-up’ marketing propaganda. But while attempting to run away from commercial lock-in, you may find yourself signing up to a premium pricing plan, just to get the helpdesk support needed.
3. Infringement on IP anyone?
One of the questions you need to ask yourself as an outfit, is whether your usage of an open source tool infringes on the IP of a third party? Very few companies are equipped to dealing with the legal complexities of contributing towards open source.
Typically, when there’s a patent covering the methodology of the code, the patent holder may demand purchase of a license, or block your business from commercial gains as a direct result of using their software.
4. Going ‘Viral’
And we don’t mean viral as in the latest Game of Thrones meme doing the rounds. Not all open source software licenses are subject to being accountable. You may use the software as a core component to building your own product for distribution.
But in the spirit of the open source movement, you may be obligated to make available the source code of the product to other licensees. This could open up all sorts of competitive considerations that you may have not originally accounted for.
It’s worth noting that cloud software is handled differently to more conventional software. Typically, users don't get access to the source code, even if the hosted software is built entirely on open source. Strictly speaking, this may not label the software as proprietary. But it also doesn't give you all the benefits of open source. In that sense, you may find that the benefits of using a "pay as you go" SaaS model – one that’s tested, has ongoing support and investment towards making it battle-proof, is a more salient option.
It would be churlish to end without paying homage to the progress we've made thanks to the open source movement, which has been responsible for the creation of gems like Blender, Hadoop and ofcourse Git to name but a small few. We're still huge fans, and that remains unchanged. Much of what I've written is likely to be well known within the community. Yet the intention of my post is to summarise what some of our own experiences have been working with open source as users and contributors. Comments are welcome.