Author – George Stragand, SW Development Executive, OpenSpan
Open Source code gives the ability to use, in some cases, all or parts of a software component in a project and frequently even allows for the encapsulating project to be a commercial – profit making – service. While Open Source code may be free to download, and in most cases redistribute, it does not come without soft costs in activities like linking the component to your custom solution or developer training. With an enormous library of Open Source software available, it’s worth a look for any size operation to investigate Open Source for security, reliability, licensing, reducing vendor lock-in and leveraging the support available for Open Source.
When the source code is open for the world to see, it better be rock solid or its flaws are exposed to be exploited. This may sound counter-intuitive given the disastrous effect in 2014 of the Heartbleed bug or more recent news that a port is open on 40,000 MongoDB deployments worldwide due to a failure to activate access control which was announced in February of 2015. Both MongoDB and OpenSSL – the source of Heartbleed – are open source projects, and yet major security flaws were announced to the world. With these cherry-picked examples, it would seem that Open Source means Open Season on data theft.
But while both were publicly announced and frightening in source and possible cost, fixes appeared nearly as fast. Personal experience with living through the Heartbleed brouhaha was not as difficult or costly as some reports made it seem; patches were applied and life went on. Patches were available in a timely manner in the case of Heartbleed and a work-around announced quickly with MongoDB. This is precisely attributed to the fact that both are Open Source.
Compare these individual disasters with the announcement of Superfish on Lenovo laptops in February of 2015. Superfish is a Closed Source project, which put what can be classified as man-in-the-middle spy-ware on the laptops of many businesses. The famous breech at Target in 2014 had nothing to do with Open Source software. Is there a secret NSA backdoor in Windows? Who knows if the NSA has convinced Microsoft to work something deep into Windows; so you have to ask yourself if you feel lucky with that Closed Source solution? It’s time to face the sometimes ugly truth that security through obscurity doesn’t work.
The “many eyes” theory, applied to software, suggests that having multiple reviews will help the overall software quality. This is exactly what a code review is supposed to accomplish during development of software. For many Open Source projects, the review period isn’t squeezed into an hour long meeting where all the developers are told to “check their egos at the door” and “collaborate on a solution”. Instead, with Open Source the review is done in the wild.
This might sound like a “I don’t always test my code, but when I do, I do it in production”, and in a very real sense, that’s exactly what happens! An Open Source project starts, a developer thinks it might solve their problem and they attempt to apply that new bit of Open Source. If that Open Source code doesn’t work, the developer is going to tell the world out of anger for being duped into believing it was a solution. To avoid that death, an Open Source project is going to do what it was specifically designed to do and nothing more.
“Do one thing and do it well” describes many Open Source projects. A hammer is a great tool, when used to drive nails yet it is a horrible choice to install a new SSD drive into your rack mounted server!
Licensing is a huge issue for software development and the bottom line profit of the products developed using libraries created by a third party. Licenses that make a component free to develop with, deploy and otherwise replicate are very important to the adoption of Open Source projects.
Take one example of a popular Open Source component: PostgreSQL. The PostgreSQL license is a little different but still follows the general parameters of BSD and MIT licenses. PostgreSQL is a very robust RDBMS which can be deployed on multiple operating systems and continues to innovate (Innovate SQL you ask? Yes! But that’s a discussion for another day!). But somehow PostgreSQL is not only a component of an application, but it has driven several product companies (Greenplum, CitusDB) and is the basis of Redshift offered by Amazon within AWS. All of this progress, from columnar RDBMS to massively parallel RDBMS, has been made possible by the very open nature of PostgreSQL. How many closed source projects have driven more than one successful IPO?
With the approach of a license permissible for free downloading, deployment and redistribution, some question to how anyone can make any money. Many Open Source projects are funded by for-profit companies and others make money by offering training. The astute reader just leapt to the mantra: “The hidden cost of Open Source is training!” Before sniffing after that red herring, ask yourself: when was the last time closed source software was purchased without training, either by hiring someone with the skills or sending employees to be trained on the closed source project?
Less Vendor Lock-In
That’s right, not “no vendor lock-in” but less. Less simply because you can copy the source code itself and if you have the chops, compile that source to keep the component alive. Say the original developers get bored of the project, (it’s happened, look at the history of a component like jDom, with nearly two years between updates – but it was solid for a long time!), and move on to something new? Not a huge worry as you can keep compiling the code.
Additionally, the investment can be ported to other offerings. Take the PostgreSQL example from before, if you developed with a stock PostgreSQL install, there isn’t a whole lot of barriers to stop posting that schema to RedShift (OK, a few small changes in the set of functions available, but it’s a handful and not insurmountable). This level of openness has created more “standards” than many standards alone.
Another common misconception is that with an Open Source solution there is nobody to call at 2am when your servers are on fire. The first rebuttal should be why are your servers on fire at 2am? Did you save few bucks in load testing? But on a serious note, how many closed source solutions are not going to require a ticket be created and give you email updates as your question works through the support queue?
Open Source offers alternatives. First, there are paid support options for many Open Source projects. For another route, check out stackoverflow.com and a host of other online forums. My personal experience is receiving responses within minutes, with a suggestion or solution, even at 2am.
Open Source isn’t what the cool kids use; it’s what successful companies, creating market disruptions – and making serious money – use to be successful.