Without a doubt, open source software has seen tremendous development in recent years. No longer relegated to the margins, open source now features prominently in many companies' operations, rapidly replacing proprietary solutions. As an increasing number of decision-makers have come to discover, open source offers numerous benefits, from reduced costs to greater flexibility.
Yet for all of the advantages offered by open source solutions, it is important for everyone, including open source proponents, to realize that this approach is not always ideal. However, as Smart Company contributor Andrew Sadauskas recently highlighted, sometimes open source supporters overlook this important detail.
Open source often, not always
Sadauskas illustrated this point by highlighting a review he wrote a few months ago for the open source operating system Kubuntu. His assessment was a mixture of both praise and criticism. However, the writer noted that even though the review was far from negative overall, for months thereafter he received argumentative comments from open source proponents, debating Sadauskas and his opinion that this particular open source offering was not for everyone.
This should not be seen as a particularly extreme view. Open source in general is an incredibly powerful approach to IT with countless potential applications, but it has not reached the point of complete saturation. This is even more the case when it comes to any given open source project or approach. Yet as Sadauskas explained, many open source advocates contested this notion, arguing that open source is always the answer.
This is a misguided and potentially damaging notion, the writer asserted.
"[T]here are many hidden costs in business that stem from using the wrong tech tool for the job, including lost productivity, the cost of IT staff for the initial setup and installation, maintenance costs, IT support costs and lost business opportunities," Sadauskas wrote.
"[T]he harsh truth for advocates is the open source option is not always the best option in the market, or the best choice for every business," he concluded.
When it comes to open source, organizations must realize that it can be just as risky as commercial software when it comes to initial set up and maintenance costs or potential losses of productivity when an issue occurs.
A careful approach
This does not mean that the open source movement as a whole has become overly ambitious or misguided. There is still good reason to believe that open source will eventually be the de facto solution for the vast majority of corporate IT needs and will also become commonplace among consumers. This trend is already well underway and most observers expect it to accelerate in the coming years.
This is true even despite the recent security issues that have gained prominence in the open source community. While Heartbleed, the OpenSSL vulnerability, is the most infamous of these, there have been a number of smaller but still significant flaws discovered in recent weeks. These issues have caused some to doubt the viability of open source's cybersecurity capabilities, and therefore its potential in numerous IT areas.
One of the most widely known concepts and advantages surrounding open source is the idea that with enough eyes on a given project, all bugs are shallow. OpenSSL was a unique case because, despite (or, arguably, due to) its widespread use, no one truly looked closely at the code itself to ensure its reliability. Everyone instead assumed that this must have been done by others, considering its widespread popularity.
To protect organizations from liability, it pays to adopt open source policies and tools that help identify where open source exists and the potential risks involved. Open source scanning is an effective way to discover both the known and unknown code within an organization and a comprehensive governance platform helps track, manage, and update packages so teams know exactly where issues may lie.
Without a doubt, though, Heartbleed further emphasizes the dual notions that open source solutions are not perfectly applicable in every situation and, furthermore, must be handled carefully and with best practices in every instance.