Open-source is popular among software engineers and has been for decades. But far from a silver bullet that automatically makes everything better, open-source is a double-edged sword. It can make wonderful, sustainable projects or break the teams behind them.

I care about people, the power dynamics in society, and my field of work’s impact on them. But what is open-source in the first place? What does it bring to the table? How can it backfire? And why do I think that software that impacts the general public’s lives should be open-source?

What even is open-source

Open-source is a model for software development and distribution. To produce software, one or several people write instructions that tell a computer how the software will behave. This set of instructions is the source code.

That source code is often transformed by the computer into a binary file: an object that the computer can read to execute instructions. Developers can ask the computer to display a window, display a text field, validate the input, send the content of the field to a server, etc.

When software is distributed (e.g. by installing apps from an app store or clicking the “download” button on the project’s website), it is distributed in binary form.

Humans can’t read binary files. It means that without the source code, humans can’t modify the behaviour of their apps… and they can’t really know what a computer is doing. We will get back to this later.

When individuals or groups create source code, they hold the copyright to it. This means the source code is their property, and unauthorized copying or modification is legally prohibited in many jurisdictions.

Authors can grant others the right to reuse and modify their source code by placing it under an open-source license. This allows the authors to retain the copyright on the original source code while enabling third parties to read, use, and modify it.

Different licences exist and give varying ranges of permissions on this source code. Open-source software can be a misleading name: it’s not only about keeping the software’s source code open; it’s about placing it under a licence that respects the open-source principles as defined by the Open Source Initiative.

Open-source is a chainsaw

Chainsaws are great, I like chainsaws. When you know what you’re doing, a chainsaw can make your work significantly easier. But if you’re holding it by the blade (by the chain?) or if you’re reckless with it, it’s going to bite you in the flesh badly. Chainsaws are powerful tools that can make work much easier, but they also can be dangerous.

Similarly, open-source is neither good nor bad. It is a tool. A tool is used for a purpose, and open-source is often used to enable collaboration. But like all tools it can have unintended consequences.

It’s important to understand what granting a license entails. There are good reasons to do it, but also good reasons not to do it. Let’s cover the basics of open-source dynamics with the example of hypothetical invoicing software.

Upstream & downstream

Alice lives in the US. She wrote the source code of Easy Invoice: software to create invoices for retail. With Easy Invoice, she enters the number of items sold, their individual prices, the shipping address of her customer, and she lets the software calculate the sales tax depending on the shipping address of the customer. Alice is publishing her source code under the Apache-2.0 license, a license approved by Open Source Initiative.

Bob lives in France. He stumbled upon Alice’s source on a public repository. He copies Alice’s code, as the Apache-2.0 licence allows him to. Alice’s software is great, but it’s very US-centric. He modifies Alice’s software to create FranceInvoice™: invoicing software that creates invoices based on the same parameters, but that calculates the VAT instead of the sales tax since he’s based in France. Bob tries to keep his software close to Alice’s, because he wants to be able to keep up with what she is doing.

Alice and Bob’s software are related

Alice’s Easy Invoice software is the original version: that’s the upstream. Bob’s FranceInvoice™ was created by copying Alice’s software and modifying it, but trying to stay close to its upstream: it’s a downstream of Alice’s Easy Invoice. Bob’s copy of the source code with changes is also called a branch.

Copying upstream’s homework has a cost

Alice is really talented, and she has an eye for great UX. She brings new changes to the source code of Easy Invoice making it much more pleasant to use. Bob loves the new changes, and he wants to incorporate them to FranceInvoice™. When merging Alice’s updates into his copy of the source code, he needs to be extra careful about not breaking the changes he had made previously to adapt FranceInvoice™ to the French market.

Alice then adds more features and polishes Easy Invoice’s UI. Those are very nice updates that Bob wants to bring to FranceInvoice™. He needs to carefully examine Alice’s code, making sure he brings his changes for the French market again on top of what Alice just released. Once done, he can release a new version of FranceInvoice™ based on the new version of Easy Invoice.

But all of that is rather tedious: every time Alice updates her source code, Bob needs to almost re-do all the work on his side. In rather technical terms: Bob needs to rebase his branch on top of Alice’s latest changes.

That’s a lot of duplicate work, for little added value. Worse: it prevents Bob from making really significant changes, because the more work he does on his downstream version, the more work he has to port next time Alice releases a new version. What if they collaborated instead? What if Bob contributed his changes to upstream? He’s been developing a new feature for free, Alice will surely be delighted to accept his free work!

Maintaining separate projects is expensive

There is unnecessarily duplicate work. For a project, it is often interesting to make the effort to adapt their functional changes to the codebase of the upstream project. It means less maintenance down the line.

For the sake of completeness: there are other strategies possible to benefit from Alice’s changes, that may or may not require less work. We are not going to cover them in this article. If you want to look further, we have described a rebasing strategy. Other strategies like merging upstream’s branch into downstream’s, or patch-based strategies exist.

Contributions are not (just) free work

Bob opens a Pull Request on Alice’s repository to offer to get his work integrated in Alice’s Easy Invoice. Pull Requests are one of the most common mechanisms for a downstream to offer their changes to their upstream.

The details of how they work are not important here, but a Pull Request can be seen as a space where the upstream can see how the downstream diverged from upstream, and what are the changes they offer to bring upstream. You can find below a screenshot of an example Pull Request that moves a single line of code in a project.

A screenshot of a dummy pull request, where we can see two text boxes: one with the code before the change, and one with the code after. The line that changes is highlighted in both boxes.

Alice gets notified of this Pull Request. Whenever she has the time, she can review it. She’s lucky: Bob wrote a nice description of what his changes do, what problems they fix, and how he implemented them.

This will help her understand what those changes do, and whether she is interested in adding this feature to Easy Invoice. She needs to answer three questions:

  1. What does the new code do, and is she interested in adding this feature to her project? Here, is she interested in supporting the European market with Easy Invoice?
  2. What does it mean in the long run and is it worth it? Here, it means she will have to monitor the regulation in Europe, make sure all countries have the same VAT rate, and that it doesn’t change over time.
  3. Is the code well written and will it be easy to maintain? If the code contains bugs, it will degrade the quality of her project. If the logic is convoluted, it will be difficult to keep adding new features to her project.

In practice, Bob didn’t just offer free work!

He also offloaded his maintenance responsibility to Alice. It is now up to her to check that she doesn’t break the feature when she releases new versions of her software.

She inherited of the responsibility to stay up to date on the European regulation when it comes to VAT. If the VAT rate changes, she needs to notice it, update her code, and release a new version of the software.

While at first sight it might look like Bob has done a favour to Alice by giving his work away, he actually broadened the scope of her work. By accepting his contribution upstream, Alice is doing Bob a favour!

Of course, in reality there are other dynamics at play: Bob might not want to upstream his feature because it makes his downstream version irrelevant, which is a problem if he makes a living by selling support for it. Alice might not be interested in third-party contributions at all, and refuse to review any Pull Requests that come her way.

Monetising, relicensing

Alice is happy that her project became popular. Many people are relying on it, and she would like to start charging a fee for it. Her project is distributed under an open-source licence, so she can’t force people to pay for it, but she can ask for donations.

She might want to change the project’s licence to make it a proprietary project. She can do it if she is the only one who wrote the code. But if she accepted Bob’s changes, he would retain his copyright on the code he offered. Alice needs to ask him to consent to a licence change. This is tedious enough with one contributor, but it becomes nearly impossible when there are dozens or hundreds of them.

It’s just a tool

We have seen that open-source licences allow two main things:

  • Projects can copy each other’s code, modify their copy, and offer those modifications back to the project they initially copied.
  • Knowledgeable people can inspect the code of a project and understand what it does.

What are the consequences for the producers of open-source software? What about the consumers?

Long-term collaboration

By definition, anyone can retrieve open-source software’s source code without having to pay a fee. This makes it trivial for developers to grab, examine, and modify the code. There is no licence nor any contractual deal preventing anyone from learning about the project or modifying it. Modern tooling makes it very easy to contribute changes back. Open-source software makes collaboration easier from a technical perspective.

Everyone can copy the code, modify it on their computer, and then offer their changes back to upstream. As we have seen earlier, not all contributions make sense for upstream. Some are a liability. Open-source makes those conversations happen. In case of divergence, the project whose contributions got declined doesn’t have to start everything from scratch.

Another particularly interesting aspect is that collaboration can be indirect. If a project’s team abandons it, another team can step up, grab a fresh copy of the code and take over the maintenance of the project. Two notable examples of this:

  • LibreOffice was created from OpenOffice after Oracle had acquired its primary contributor Sun Microsystems
  • KaiOS, an operating system for feature phones, was created after Firefox OS was discontinued

Open-source projects are durable

Because the code is always available, new open-source projects can emerge from existing ones if their scope differs.

If a project has no maintainer left, another team can take over and revive it.

Organisation-centric business models

Because the source code can be copied and redistributed without any restriction, open-source projects can be difficult to monetise. Indeed, the first principle of the Open Source Definition is:

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

However, for the project to be sustainable, the teams working on it must earn an income from it. Several strategies can be implemented to monetise an open-source project. Wikipedia has a list of popular business models for open-source. They depend on the software’s audience. The most successful business models apply only if at least a part of the consumers of the project is an organisation.

The maintainers can sell support with response time guarantees. If the company that got the software for free has a problem, it can reach out to the maintainers and get a fast response.

Maintainers can develop a partnership programme with integrators. Organisations pay integrators to deploy or customise the software for their customers, and they pay a fee to get fast support from the project maintainers.

Another common practice is dual licensing. The project is put under a “contagious” license like the AGPL-3.0. To oversimplify greatly, any service that relies on that project must become open-source, too. Then, the maintainers can sell a proprietary license to their project so that services relying on it don’t need to become open-source. This is the strategy Element adopted for its Matrix server implementation Synapse. This model is difficult to implement later in a project and has many critics.

The “open core” model is also quite common. The project’s core is open-source, but all the features that can make an organisation’s life easier are proprietary and sold for a fee.

But monetising open-source software for the general public is extremely difficult. The general public can’t be expected to understand the funding dynamics in their apps and even less to solve them. Very few of us subscribe to support licenses for anything; most try to get things for free whenever we can.

Monetising open-source software is difficult

Organisations depending on open-source software will be interested in getting paid support, which is a good source of income for the projects.

The general public cannot be expected to pay for apps that they can get for free. Other forms of monetisation need to arise to make open-source available to the masses.

Fluctuating maintenance costs

Software, like humans, needs regular hygiene to stay in good operating conditions. This hygiene is called maintenance. It consists of making sure the project is using a recent version of the building blocks (developers call those libraries) it relies on, or that it remains adapted to the ecosystem it runs in. Maintenance doesn’t necessarily bring functional changes.

Regular maintenance makes it easy to bring new features, performance improvement, or adapt the software to a new context. Leaving the software without maintenance exposes it to software rot. If unmaintained for long enough, the software becomes unusable and irrelevant: making it useable again becomes more costly than starting a new project from scratch.

If the consumers of a project are organisations, open-source can make maintenance very cheap. The more organisations contribute financially, the cheaper the maintenance is for each. But there needs to be an entity and processes to allow consumer organisations to contribute in the first place. And those contributions are entirely optional.

The open-source definition says that the source-code must be available for free. Unfortunately, this incentivises freeloading, particularly in a capitalist context where cost-cutting and short-termism are common. If an organisation is already paying for the maintenance or for new features, why should mine do too?

Diluting the maintenance costs is also not exclusive to open-source. When charging customers for a licence, proprietary software vendors make them financially contribute to the maintenance. Proprietary software forces everyone to contribute financially, while open-source is opt-in.

Open-source shines particularly when it comes to welcome non-financial contributions. Organisations depending on an open-source project can either hire the maintainer, or allow its own developers to spend time on the maintenance of the project. Developer time is often valued, but other profiles can be interesting. I will expand on this in a future blog post.

Maintenance costs decreases with the number of parties involved

The more parties are willing to contribute to an open-source project, the less expensive it becomes. Organisations can contribute financially to projects, but they can also contribute other resources.

If many parties have a different agenda, the project needs a governance body to set expectations and steer the project’s direction.

Transparency and security

It is usually impossible for an end user to know what an application or even the device’s operating system is doing on their phone, computer, or server. Applications are delivered in binary format, and only computers can read them.

Knowing what an application is doing is a difficult problem, but it is crucial to user security. An application can have unintentional security flaws or be malicious on purpose. A surprising but striking example is the anti-virus vendor Avast who was found to collect private information and sell it to over 100 companies.

There are two main ways to attempt to figure out what an application is doing: testing the application behaviour, also called black-box testing, and source code analysis.

When testing an application’s behaviour, there is no guarantee that what is happening at the moment of the test corresponds to what the software does all the time. It is rather common for malware to detect it’s running in a test environment (such as a virtual machine, among others) and conceal its actual behaviour. This ability called “sandbox detection” has existed for a while now.

Open-source projects can be audited. Their source code can be read and understood by experts, who can then vet them. When a flaw is found in the code, security researchers usually proceed to coordinated vulnerability disclosure to address the issue. In a study published in 2017, researchers found that the vulnerabilities in the open-source Linux kernel have a lower severity score than those found in Windows Server 2008, although they take longer to address.

Access to the source-code is crucial to security

Open-source software is transparent by design, making it much more obvious if it behaves maliciously. There is also a strong security culture in open-source, incentivising researchers to contribute to the project instead of attacking it.

Open-source projects are not secure by design and still need to be audited. But create the ideal conditions for audits to happen.

Human after all

The open-source model is a powerful tool. Like all tools, it can be used to make work more efficient, but it can also have unintended negative consequences. Whether it is for private organisations, individuals, or society, open-source software is a net positive if used appropriately.

The "always has been" meme. Two astornauts are in space. One in the background is looking at Earth, saying "Wait, it's all about the peopl". The other one points a gun to his back, saying "Always has been".

Open-source software can be a sensible choice for organisations, or not. They can share the costs of maintaining the software compared to an in-house solution. Contributing to its sustainability in the long run and getting involved in the project’s governance ensures that the project goals remain aligned with the organisation’s goals. This requires a mature open-source culture from the organisations side, often in the form of an Open-source Program Office.

Open-source software is not directly interesting for most individuals. The software engineering crowd is often strongly, politically, and emotionally involved in open-source. But at the individual scale, they’re the only individuals directly benefitting from it. Most people will not directly see open-source software as a benefit, apart from being able to get it for free.

Open-source software really makes a difference at the societal level. Open-source is a collaboration enabler. It allows one expert to review the code and give assurance to all the non-expert individuals using it. It reduces costs. It increases reusability. It increases transparency and security. It puts governance (or lack thereof) under the spotlight. Some software automates part of our lives and how we interact with each other. It is irresponsible for a democracy to leave that much control to private entities owned by a few people.

Open-source licences are a necessary but insufficient step to making public interest software. A common misconception is that public interest software must be governed democratically. This leads to design by committee, a battle-tested recipe to terrible results.

Finally, I lied to you. Open-source licences are indeed tools. But when projects opt for the open-source development model, they do so for philosophical, political, or business model reasons, or a combination of these.

The licences are just tools. They can fail to fulfill their intended purpose or even have unintended consequences. This loose coupling between their purpose and actual effects underscores the need for more than licences to make public interest software thrive.

Public interest software needs opinionated governance, a structure for financial sustainability, and accountability. I will cover this topic in more detail in a future blog post. If you want to be notified, you can subscribe to the RSS feed of this blog or follow me on Mastodon or Linkedin.

A warm thank you to the numerous eyes and brains that helped with this post, and particularly to my friend and open-source maintainer Felix Häcker; and Tara Tarakiyee, Technologist at the Sovereign Tech Fund.