The Pros And Cons Of Open Source Software: Is It Really Safe?

The Steam Deck was a revolution in mobile gaming for PC, but it was also one for a reason most people weren't aware of: bringing Linux to the masses. The Steam Deck runs SteamOS, its own custom distribution of Linux. If you haven't heard of Linux (or don't know what it does) the TL;DR is that it's a free, open source operating system that can be used by anyone on almost any device. Open source software (OSS) is exactly as its name suggests: software which source code is open, available for anyone to examine at their convenience. Closed-source software is restricted to authorized individuals — mostly proprietary stuff in the tech industry. There's a good chance you've seen a particular software you're interested in putting a lot of marketing weight behind the fact that it's open source. If its code is open to the world, does that mean it's safe?

The answer is not a simple yes or no, although the short answer is yes — for the most part. As with everything in life, things are rarely ever simple and straightforward. I've been an enthusiastic member of many open-source communities for years, using and contributing to Linux and OSS programs of all kinds. Here's my two cents on the pros and cons of OSS, and whether you risk anything when you use it.

At first glance, it might seem risky to expose the inner workings of a program to any random Joe. Wouldn't a castle with transparent walls be easier to lay siege to? Perhaps for a castle, but not necessarily in the case of software. To the contrary, being open source is preferable for security compared to obfuscation. As the saying goes, obscurity is not security. Letting anyone vet the code means, sure, hackers could see vulnerabilities plain as day, but so can engineers, and they can push fixes for them ASAP. Especially issues the original devs didn't notice. Proprietary software, conversely, could have vulnerabilities that hackers discover before company engineers. In fact, many companies will make their own OSS to take advantage of that extra community look-over.

Of course, this doesn't mean OSS projects are secure by default. They are often made by small teams or individual developers in their free time. If those developers get busy (as everyone does) OSS security could suffer — and that has happened, many times. OSS software is very frequently abandoned or discontinued when developers go MIA, and so fixes contributed by the community are meaningless. It's not a given that an OSS project will get all the eyeballs it needs. Smaller, lesser-known projects often don't. This all really comes down to an issue of funding (which we will get into later) but the point is, OSS's openness doesn't guarantee security — but it does make it much more likely.

OSS is nothing without community. While it may be the work of a small development team, users suggest important fixes, improvements, and features. It's completely unlike proprietary software because it's a collaborative effort. To give an example, look at Mozilla Firefox — an excellent OSS replacement for Chrome browser, by the way. Random users are able to submit issues, suggest changes, and make requests for features. Otherwise, they can make their voice heard in the forums where devs may respond to them directly.

The synergy between developers and users creates beautiful things. The people using the software on a daily basis aren't just getting the functionality they want, they are contributing to their own digital safety; there's a strong incentive to chip in with bug reports.

Compare this to tech corporations like Microsoft or Apple where there is minimal communication between everyday users and developers. Aside from exclusive beta testing programs, bug report tools are your best chance at communicating with them. Again, the code isn't open to you, so you have to wait for something to go wrong rather than identify vulnerabilities in advance. Plus, companies don't always prioritize security related bug fixes. Just ask the eternally-hacked Sony. OSS is clearly superior in this regard.

It's important to recognize that hackers aren't the only threat to your devices and your data. The company making the software you use could be just as great an enemy. Just ask Google, famous for violating user privacy again and again, most recently with when it was discovered the company was collecting your Chrome browsing data in incognito mode. It wasn't until they were caught in the act and threatened at lawsuit gunpoint that they relented and publicly admitted to doing so. Case in point, it's impossible to know what closed source software is doing because, well, it's closed.

Naturally, OSS does not have that problem. When all the code is open, you know exactly what it's doing at any given point in time. No OSS developer would get away with it for long if they decided to quietly send your data to their own servers in the background. OSS is inherently more trustworthy (or, more accurately, "trustless") so you know exactly what you're getting into when you download — provided experts have looked it over.

I've already mentioned a few weaknesses with OSS, namely that development teams can be small and stretched thin, projects can be abandoned, funding can be limited, and software may not always get enough expert eyes on its innards. Fortunately, there's a way forward when any of these things happens: forking. A "fork" is like a fork in the road, where new software diverges from the original OSS project. Effectively, someone takes the code and puts their own spin on it, adding or removing whatever they like.

Some forks do their own thing while the original continues to flourish; take Waterfox, a popular alternative to Firefox, or Vivaldi, an excellent Chrome replacement. Some forks revive dead OSS projects so users can enjoy the software they love. Take for example LibreOffice, which took the source code from its flagging predecessor OpenOffice and built something much better.

Remember, the code is open to the public. Even if the original developer logs off and never returns (and never hands the reins over to someone else) the code is still there. OSS licensing is often fairly permissive in terms of use and distribution. For security, forks can address vulnerabilities that remain unpatched by reviving an out-of-date project. Proprietary software, on the other hand, has no such benefit if the company stops supporting it for any reason.

Following off the last point, there's a chance the company making your closed-source software doesn't give it the attention it deserves, ends support for it, or heaven forbid, goes out of business. The very nature of closed-source licensing makes it difficult, verging on impossible, for anyone without the rights to modify or distribute the code — even if said company isn't using it or making a profit from it. Just take a look at how litigious Nintendo gets about game emulators that recreate ages-old games that the company doesn't sell.

An excellent example of this was the indie game "Worlds Adrift." Players absolutely loved it, and the community thrived, but ultimately the game failed. Despite an avid contingent of volunteers willing to bring it back from the dead, developer Bossa Games could not humor them; it ultimately came down to a licensing issue. A mere legal hurdle was all it took to lock the game in a reluctant grave.

In terms of security, that's terrible news for any closed-source software you use that no longer receives updates. Such a thing frequently happens with smartphones; even the pricey Galaxy S23 Ultra gets only five years of software updates. OSS saves the day here. LineageOS is a shining example, an operating system that provides long-term security patches to phones that are past their software expiration dates.

Many hacks take advantage of so-called zero day exploits, vulnerabilities that aren't yet known to anyone but bad actors. Major vulnerabilities such as these need to be patched post-haste; there's a reason notifications pester you to keep your phone updated. Software companies can only do so much to identify these vulnerabilities, fix them, and then push patches. If they can't find vulnerabilities themselves, then they rely on bug reports, bug bounty programs, and audits. Even combining all these things together, they have a limited number of employees to oversee the entire process of keeping software secure — and because it's closed-source, only a select few authorized individuals can view the code directly.

OSS, as you probably guessed, has a major advantage here. Hundreds, possibly thousands of software enthusiasts can look over the code of each release and identify problems. Logically, it follows that problems are spotted faster and — hopefully — patched just as quick, since the community can contribute fixes too. There is some evidence to back up this assumption. A 2006 study by Carnegie Mellon University found that open-source vendors patch issues faster than closed-source peers; it would seem that's because the code is open to more than just employees.

Some argue that a project being open source isn't an important as funding it. To beat a dead horse, OSS projects are made by small teams of enthusiasts who put long hours of free time into something they love for pennies worth of donations. 60% of software makers and maintainers are unpaid, 77% would like to be, and — unsurprisingly — 68% have considered quitting their projects due to this state of affairs (via The Linux Foundation). The sad part of the story is that the overwhelming majority of companies use open source, but even big, multi-billion-dollar corporations often don't contribute a cent after building their entire foundations on these unappreciated passion projects. This xkcd comic puts it best: All of our modern digital infrastructure stands on a project some random person in Nebraska has been maintaining thanklessly for two decades.

You can probably see where this is going. When manpower, time, money, and appreciation are in short supply, even the best projects will suffer. As for you, the end user, this means your favorite piece of software could be on some very turbulent footing that risks your security. We highly recommend finding any way you can to support the developers of OSS that you regularly use. Some only ask you to spread the word, some ask for donations, and some ask you to donate to the dependencies they use.

As established, developers and maintainers are volunteers and human beings. They have lives, and just like you, things can get in the way of their hobbies — or in this case, their OSS projects. Regrettably, this sometimes means that an OSS project will simply die off without your knowledge, as if the developer disappeared off the face of the Earth. Without enough funding to work on it full-time, it's hard to blame someone for dropping something that eats up dozens of hours a month.

You can often tell when this is happening if there haven't been any updates in a long time for software that desperately needs them. Or, there are more frequent bugs and glitches. If the dev blog and the changelog has gone cold for a year, that's usually a pretty good sign that something's awry; it may be time to delete the app, just as you might when a sideloaded app on Android seems neglected.

Check up on the update cycle of an OSS app from time to time to stay abreast of any developments, like end of support announcements. Otherwise, we recommend installing a third-party updater. MacUpdater made the list of our 20 best Mac apps in 2024 for being an easy, convenient way to update software from unconventional sources.

Now that we've firmly established the dynamics of an OSS project, it becomes clear that this is a bit of a numbers game. Software used by a large audience is getting a huge number of eyeballs on the code (and more funding). The bigger the audience, the higher the percentage of experts you are going to have in the crowd. Ergo, it's probably more secure. Conversely, a lesser known app with a small user base is getting far fewer eyeballs (and less funding) — so, statistically speaking, there's a higher likelihood that a vulnerability goes unnoticed.

To add to this, many of these small, lesser known apps are made by people taking their first baby steps into coding, or who are using the project to gain experience. It naturally follows that they may not be capable of identifying issues in their code. We don't say this to insult OSS developers, or discourage you from using their software. Rather, to always have a healthy dose of skepticism. Using an app that strips the formatting from copied text is much less of a security threat than, say, a backup app. Do your research and consider how problematic a certain piece of software could be before downloading.

In some cases, the software is rock-solid on the developer side of things, but there could be a deeper issue they have no control over: dependencies. Dependencies are code databases and libraries that other programs can use to do specific things. So for example, a developer might use a dependency FFMPEG that converts video into audio, rather than programming that functionality by hand. It's a huge time saver, especially if the dependency does something that would be outside the developers forte. Only one problem: dependencies can be just as flawed as bad software.

Vulnerable dependencies have been an issue for decades. Either a dependency hasn't been updated in a while — usually because of the funding issues mentioned — or it's been taken advantage of by hackers. One paper by login estimates that most attacks target open-source software dependencies, not the proprietary stuff.

Now to be fair, this is an issue with proprietary software as well, since much of it relies on the same dependencies. However, we've established how little support there is for OSS already. A company's paid boffins may be able to react faster to dependency issues than one lone developer and a smattering of active community members.

OSS may seem like it's immune to bad actors on the inside thanks to that community aspect, but one recent example proves this is not the case. In March 2024, someone discovered that the popular XZ Utils compression utility had a backdoor — a utility, mind, running on practically every Linux system in the world. For the brief time before the backdoor was patched out, the whole Linux ecosystem — likely including the many, many servers that run Linux — was vulnerable.

What's most terrifying about this story is that it happened because of all the issues with funding and support we mentioned earlier. Lasse Collin (an XZ Utils maintainer) was in need of assistance, and a bad actor disguised as user Jia Tan (aided by others) approached him offering to lighten the load. With his foot in the door, Tan created a backdoor and pushed it to Linux distros the world over. The backdoor was discovered shortly after and removed, make no mistake, but it's not yet clear how many were affected by it or who exactly was responsible. There may well be other open source projects that are (or will become) a repeat of XZ Utils.

Again, this was a dependency that could be used in proprietary software as well. But the point stands: open-source software is uniquely vulnerable to this type of attack. It could happen to your favorite OSS, and you wouldn't know it.

Quite a bit of what I've said today may give the impression that you should swear off OSS entirely. Nothing could be further from the truth. Again, OSS practically runs the world, and it's mostly built with love and devotion by experts who won't let it be abused if they can help it. Many phenomenal open-source apps prove to be better alternatives to major software, and in some cases, do things that no major software can. Apps like Firefox, Signal, VLC, Bitwarden, Standard Notes — and many others — are often formidable heavyweights in their respective classes. OSS is so good that, 99% of the time, there is an open source alternative to any software you can imagine — one that's more likely to respect your privacy besides.

That said, keep everything we've mentioned in the back of your mind. Pay attention to the development of any apps you use, download any updates they push out ASAP, and be prepared if the day comes that you have to delete them because they've gone the way of the dodo. Importantly, don't assume that "open source" equals "good;" companies these days love to slap that label on their product even though it's no guarantee of anything other than their code being open.

Conversely, don't assume proprietary software is only made by evil, privacy-abusing companies. Do your research, and if it suits your needs, use a piece of software. Really, this is less about using one type of software, and more about being proactive and having good digital hygiene in general.