The Hidden Downsides of Free and Open Source Software

Ever since the government-appointed Commission on New Technological Uses of Copyrighted Works (CONTU) designated software as copyrightable in 1974, a war has raged between two prevailing software ideologies: open and closed source.

To give an overview, closed and open source software differ in how they choose to handle the source code of a program. You can think of a program’s source code as the recipe to a dish. Trying to glean the source code from a closed-source program is about as easy as deciphering a dish’s recipe just by eating the finished product. Open source software leaves its recipe available for anyone to view and modify as they wish. They do this because they believe that the internet should be a place where users are free to view and modify the code that runs on their machines. Closed source creators, on the other hand, keep that source code secret. They do this for a variety of reasons, but mostly to protect their copyright. Their secret sauces wouldn’t be so secret if the recipes were all over the internet.

We’ve read dozens of articles that try to argue closed source’s superiority over open source. These articles often cite half-true or downright dishonest sources to support their claims. Inevitably, these articles are flooded with angry open source supporters who rip apart the article, line by line.

So, this article is not going to assert the superiority of closed over open source. It will, however, try to bring to light a few points that both sides of the argument seem to overlook.

Let’s begin.

Proprietary Software Locks You Into a Vendor; Free Software Locks You Into a Solution

When you commit to open source software, you are committing to one of two things: spending time and resources on maintaining the software to meet your needs, or trusting that the open source community will handle that support for you. Of course, this is a nonissue if your team is big enough that throwing some resources towards maintaining your software is no big deal. However, most small and medium-sized teams just don’t have the manpower.

If you’re using a closed source solution, then switching vendors can be an extremely expensive and time-consuming process. For example, if your company uses Adobe software, because of all the integrations they have with each other and outside software, the cost of migrating to a new solution would be gargantuan. Open-source supporters cite that cost and difficulty as a major disadvantage to closed source software. And while that criticism is fair, it leaves out a key point: open source software locks you in too.

With proprietary software, it’s usually the responsibility of the providing company to ensure that the software meets all of the users’ needs. This is essentially a requirement of distributing closed source software, since users aren’t free to customize its code to suit their needs.

Open source software, on the other hand, leaves it to the end user to customize the software to suit their needs. So most open source software turns into something slightly different in the hands of its users. In effect, because open source allows a company to take a framework and expand it into a highly customized application that suits their purposes, most open source software takes on a life of its own in the hands of its many users. Another important point here is that open-source software developers have no obligation to provide support for the software they created. And most of the time, they don’t.

That means when you use open source software, you’re on the hook for all maintenance, support, upgrades, and troubleshooting. With the amount of resources that go into maintaining an open source solution, the costs of migrating between solutions (at least in terms of man hours) is comparable to that of closed source.

Put another way: open source locks you in too, just in a different way than closed source.

If You Expect Free Support, You (Probably) Won’t Get It

Forums are great and all, but when it comes to software, sometimes you just need personalized support that properly addresses your issue. The beauty of open source is that the bigger the software’s following, the better the community-generated support is. However, no amount of community-generated support compares to the convenience of having a trained professional walk you through the solution to your problem.

Only extremely large open source projects like Firefox or WordPress, have dedicated support teams. Consider this: even though Firefox is the 4th (or 3rd, depending on your source) most popular browser in the world, it still outsources most of its support to a large team of volunteers.

Another challenge to open-source support is that since you typically modify the software, even if you would get support, it’s likely that your version of their software isn’t exactly what they’re familiar with. This hypothetical support wouldn’t be as useful as dedicated proprietary support.

So, when you hope for free support on a free program, you’re hoping that people will come up and help you out of the goodness of the heart. Which they do, sometimes. But to expect that all the time will lead to bad things down the road.

Another Point About Support

While we’re talking about support, there’s another important thing to mention: open source supporters argue that when you buy closed source, you’re mostly just paying for support. Though we disagree, we aren’t going to focus on disproving that.

Let’s say you are just paying for support with closed source. So what? According to a Univa-led survey, a 27% of open source users cite “lack of Enterprise-grade support” as their biggest pain point. What’s more, this pain point was the most prevalent of all pain points, which included things like usability, maintenance, crashes, bugs, and more.

In addition, of 64% of open source users who said they would pay money for better quality software, 22% cited Enterprise-grade support as their most important consideration

So, to some people, paying for support is exactly what they want to do.

Some Observations on Open- and Closed-Source Security

The debate between closed and open source software is the most heated when it comes to security.

One of the most commonly cited arguments against open source software is that since everybody has access to the source code, it’s easier for ne'er-do-wells to implant malicious code or to identify vulnerabilities. On the other hand, proponents of open source software argue that since more people are involved with creating open source software, there is a higher likelihood that bugs and defects are caught early.

It all boils down to how you feel: do many hands make light work, or do too many cooks spoil the broth?

As it turns out, neither side is correct. At least, neither side has been proven to be correct.

In the end, the conclusion is this: open-source software isn’t more secure because more people look at it, and closed-source software isn’t more secure because it costs money.

But you came here for answers, so we’ll go deeper into the issues, muddy though they might be.

The Coverity Scan Report and Heartbleed

In an attempt to provide some insight into the closed vs open source security debate, Synopsys, a San Francisco-based static and dynamic code analysis development company, launched the Coverity Scan Report. In the report, they test hundreds of millions of lines of code to determine the average number of defects per thousand lines of code.

They found that, overall, the average defect density between open and closed source was nearly identical: .69 defects per thousand lines of code for open source software, and .68 defects per thousand lines of code for closed source software. But there were differences in overall code integrity depending on the size of the project. Open source software had fewer defects the smaller the codebase, whereas the opposite was true for closed source software. All in all, the results of the scan can be summed up by the phrase “it depends.”

Where things really get muddy, however, is when you consider that “error” doesn’t necessarily equate to “security vulnerability.”

Consider this: the Heartbleed Bug is a serious vulnerability in the popular OpenSSL software library—which is open source, by the way. It allows hackers to steal otherwise encrypted information, such as passwords and credit card numbers, without leaving a trace. It has been patched since its discovery in 2014, but it shook the world’s faith in the internet’s security. The effects of it can still be felt today.

It was a small, nearly insignificant error that caused the OpenSSL vulnerability. In fact, the error was so insignificant that the 2014 Coverity scan didn’t even catch it.

So, when it comes to security, take claims with a grain of salt. The truth is, most of the time we don’t know a vulnerability exists until it gets exploited.

Open Source Software Rarely Goes Through Usability Testing

Most open source software is made by developers for developers. And while we don’t like to generalize, we feel that it’s fair to say that open source software typically places a much bigger focus on functionality over design and usability. This means that open source software is typically ugly at best, and downright confusing at worst.

Of course, much closed source software is also ugly and difficult to use. The difference is that with a paid product, there is more of an expectation of good design and usability. That usually means that closed source developers pay more attention to those things. Proprietary software distributors are more likely to have usability experts on staff than open source software distributors are.

A Final Note on the Funding and Sustainability of the Open Source Model

The Heartbleed bug was not a result of the severe underfunding of OpenSSL, a technology that powers most of the web. It was caused by a simple, honest mistake that anyone could have made. The New York Times likened it to something as small and simple as misspelling “Mississippi.”

However, when you consider that the OpenSSL was written by a team of four coders, only one of whom works on the project full-time, it’s easy to question whether or not vulnerabilities would happen less often if more open source projects had the funding and manpower to match their widespread use.

It’s not just OpenSSL, either. Many open source projects suffer from the same resource drought.

So when you pay for closed-source software, you’re not just paying for support—you’re paying for the continued life of the product.

Open Source or Closed Source? It Depends on Personal Preference and Experiences

We hope we’ve opened your eyes to some points in the closed vs open source debate that you hadn’t considered in the past. The point of this article, really, was to setup a base for making an informed decision about the differences between closed and open source, and we hope we’ve done that for you.

In the end, whether it’s closed or open source, the best software is the one that helps you do your job as efficiently as possible. For millions of people worldwide, UltraEdit is that best software.

We would love the chance to show you why we’re so confident in our software.