Open Source software is software that is provided to the public with the source code intact. It is not necessarily a guarantee that the software is free (as in beer) or even free (as in liberty); all it means is that you get the source code. Most of the time, in my experience, Open Source software is provided with a permissive license; a license that permits the consumer to use the software however they like without requiring any kind of reciprocation.
This permissiveness encourages use and with use comes the possibility of community engagement. Those that benefit from using the software can contribute back and help to make the project better. This fosters growth and innovation without putting all of the burden on a single person. This model is extremely successful as evidenced by the amount of Open Source software present in everything from your car’s entertainment system, to your WiFi router’s operating system, to your smart cupholder1Please tell me this is not a real product.
Open Source has been a major contributor to the growth of technology. Imagine a world without the Linux operating system? All of those products I mentioned in the previous paragraph? They probably run some form of Linux. Modern software development and containerization wouldn’t be possible without Linux. Kubernetes? Nope, not possible2Sure, something else may have come a long instead of Linux but it’s hard to even imagine what that might be
Recently, there have been a number of high-profile Open Source projects which have negatively impacted downstream users. It has been interesting watching it all unfold and has left me with some thoughts that I’d like to share.
Shared Responsibility
One of the biggest vulnerabilities from an Open Source project in modern history, outside of the OpenSSL Heartbleed bug, is the log4j vulnerability. This vulnerability is the result of an Open Source team adding ostensibly benign features to their software without realizing the potential consequences. In this case, by sending specially crafted messages to a server in a way where those messages may get processed by the log4j library could result in execution of untrusted code (one of the more heinous and critical types of vulnerabilities).
Note the emphasis in that last paragraph: execution of untrusted code. Hundreds of thousands, if not millions, of devices use log4j. Did every organization that sought to adopt log4j thoroughly vet the code? Or, did they just trust that “millions of devices are using this, so it must be safe”? If there was a lack of due diligence then aren’t the consumers of log4j responsible for executing untrusted code themselves?
Look, I get that it’s not feasible to 1) catch all possible security threats in software; 2) review every single line of every single Open Source package that you may use. The former is just the cost of doing business in the software industry, but the latter is not a valid excuse that somehow absolves the consumer of any responsibility. The millions of consumers of Open Source projects are taking a calculated risk in using Open Source software. We, collectively, accept the risk that the software may have flaws because we have full access to the source code for review. Plus, the more popular a software package, the more eyeballs on the code. This is not a guarantee by any measure which is why most, if not all, Open Source licenses include a limit of liability clause. Go ahead, check out the Apache 2 license; I’ll wait (it’s section eight).
So, it says it right there on the tin – we’re not responsible if this breaks your software. You’re an adult with agency (presumably) and you are getting something for free with zero strings attached. In return, you can’t complain if something goes wrong. This seems fair to me and is at the very heart of why Open Source thrives3Why? Because independent software developers don’t need to be worried about getting sued by a Fortune 50 company if something goes wrong.
The Motivation
“Why in the world would software engineers do work for free?!” This is the question that a hear a lot from people who aren’t veterans of the software industry. I think it’s important to understand why software developers release their software for free so that we may understand why we should curb unreasonable expectations. While I can’t speak for all Open Source developers, I can share my thoughts on possible motivations.
First, I believe that many software engineers (myself included) like to build things. It sparks joy in many of us to have our software be used by other people. So, if I’m building a piece of software for myself, it may make sense to open it up to the world so that others may benefit. The benefit to the developer is recognition and use of their software. The benefit to the consumer is the intellectual capital that they are gaining for free.
As I alluded to, the other motivator is recognition. If your software package sees a good bit of adoption, you’ve got yourself some bragging rights. These bragging rights are not just self-adulation – they are, in my experience, very effective in advancing engineers’ careers. Herein lies one possible tangible reward for Open Source software.
With enough recognition and popularity, your Open Source project can be gobbled up by a bigger name, like the Apache Foundation. An advancement in this direction unlocks even more opportunities and could even result in getting consistent funding for the project.
Entrepreneurs, which some software engineers also happen to be, may see their Open Source project as a stepping stone to building a business. Countless Open Source projects also have a commercial offering. There are many ways to monetize popular software.
Maybe you’ve built a tremendously popular container4Like software containers; of the Open Container Initiative ilk managment tool and have decided that the amount of effort to maintain the tool is worth more than the zero dollars you are currently charging. You may decide to start charging and literally nobody should be upset. Yet, it’s been my experience that large enterprises don’t like when they suddenly have to pay for something that provides incredible value. Some companies have even entertained the possibility of rewriting said software5as if it’d be trivial or not an enormous waste of energy. I don’t understand not paying for the best tools. In my experience good tools equal better productivity which leads to better software and wider profit margins. Try to convince a graphic artist to use GIMP instead of Adobe Photoshop. Just please capture it on video so we can all have a laugh6I know GIMP has matured significantly since my last usage in the 2000s, but Photoshop is the de facto industry standard nonetheless.
Sparing the reader any further digression, suffice to say there are many reasons why someone may may share their code with the world. What’s important to realize is that none of these motivations include “wanting to work tirelessly for ungrateful people in a one-sided relationship of taking but not giving back”.
Nobody Owes You Anything
Nobody owes you anything. This applies to Open Source developers as well as consumers of Open Source software. From the consumer point of view, it’s not uncommon7But, in my experience, it’s not extremely common either to see demands from consumers of the project. The following is an extreme example.
As unfortunate this is, it ultimately has a limited blast radius. That is, nothing really changes if someone happens to be mad about decisions made by a maintainer. However, if the frustration comes from the maintainer, then things get a little tricky.
Such is the case of a software developer who recently released a tiny package in the Node.js ecosystem that happened to be used in a lot of downstream packages8Which is normal in the Node.js ecosystem, the developer felt as if they were owed something by the multi-million dollar companies using their tiny chunk of code. They felt so strongly that they sabotaged their project in an myopic attempt to make some kind of statement.
To be fair, it is totally the prerogative of the developer to do such a thing; it’s their code after all. Do I agree with the decision by the developer in this case? No, absolutely not. It violates the spirit of Open Source which is one of sharing without expectations of reciprocation9Okay, there are some licenses (e.g., GPL) that do codify an expectation of reciprocation. The developer in this case effectively said, “if you want to use my software; pay me.” Okay, fair enough, but on the other side of that coin is, “if you want to get paid for your software, then don’t give it away for free”.
You see, the software package, in this case, is only popular because it’s open source. So the developer reaped the reputation rewards and free advertising of Open Source, then decided that they’re being treated unfairly. I don’t recall Daniel Stenberg (the author of the ubiquitous curl utility) sabotaging their work from the past three decades because nobody paid them to use their software.
Stepping off of my soapbox for a moment, I want to make something else very clear: the developer of the sabotaged project is not the only one to blame. They made a change to the next version of their software package, not any existing versions. So, how is it that anyone would pull in the latest version of a software package without vetting it at all? In fact, this is an example of a security anti-pattern. One should never assume software from an untrusted third party is benign. It may not even be the original, potentially trusted, software developer, but instead the distribution channel that is insecure.
Trust and Sharing
Open Source is ultimately about sharing; the sharing of ideas through a common language. A socialized form of software development where many, many people potentially benefit.
As we’ve seen, this can lead to a sense of entitlement, albeit one that is not too frequently seen. In general the Open Source community is a healthy marketplace of ideas backed by passionate software developers. It is not, however, a free-for-all where actions have no consequences. It’s important to recognize that the passionate software developers are building things for free because it’s enjoyable. If too many people actively make the process unenjoyable, then it’s a lose-lose situation; the maintainer loses their passion for the project and the consumer loses any further enhancements.
With sharing comes a requirement of trust. We must be able to trust that Open Source maintainers will not cause a build to fail at three a.m. The onus, however, is not only on the maintainers, but also on the consumers. Responsible software development requires a security-first mindset.
Some advice for consumers of Open Source software:
- Do not blindly take updates from upstream providers.
- Properly vet all code and review any changes to licenses.
- Review the source code (at least skim it)
Outside of that, and as a general rule in life: be kind to people; especially people who are performing a service for the greater community. Let’s build a better tomorrow by working together to solve hard problems. If you’re using Open Source Software and you can give back, please do. If you can’t find time to give back, try donating, sponsoring, or promoting the project. If all else fails, consider just thanking the maintainers.
