In our interviews we came across aspects and stories that didn’t make it into the report, but that we still find worth telling. Brace yourselves for a wild ride across all sorts of topics!

The reactive nature of FOSS

FOSS projects try to build alternatives to existing solutions that were created by the big players in the tech industry. But those are way ahead of them in time, developer capacity, and financial resources, which means that the alternatives are perhaps more transparent, decentralized, or privacy-respecting, but also less easy to use, less well designed, and have network effects working against them.

The revolution doesn’t happen from below, it doesn’t happen from above.

Interview partner about the impact of their work of regulatory approaches on big tech.

In our interviews, there were few to no visions how this could change in the future, and how the very nature of FOSS – openness and sharing – can work better for them than for the many tech companies that make use of that code, recruit their staff out of open source projects, and then legally prevent them to contribute to the communities they came from, and to the FOSS infrastructure the companies themselves need.

The broken stack

The internet is, what it is: A network that was never designed to relay everyone’s everyday conversations and transactions, yet this is exactly what it does today. Many underlying technologies do not take basic requirements for privacy, safety or verification into account. This means that projects need to find hot fixes and workarounds to uphold these values, while constantly having the underlying infrastructure working against them. One of our interview partners referred to this daily struggle in their work as “the broken stack” – and meant “broken” it not in a way that lessens productivity or efficacy, but security and privacy.

The code thieves

While our interview partners feel very committed to free and open-source software and the ideals behind it, many of them were quite unfazed by instances in which their own code had been used by others without attribution in a way that clearly constitutes a license infringement.

“I’m rather flattered if someone steals my code. But usually, those people don’t get very far.”

Interview partner about their experience with license infringements

But there is a line that should not be crossed: Developers stepped in if others passed their code as their own and made alterations that rendered the it less secure. They became even more vocal about the infringement when the other party aggressively marketed their insecure products.

However, people mostly resorted to contacting those that appropriated their code directly, and, if their messages were not answered, also publicly. Legal steps appear to be the exception, mostly because it potentially costs time and money and because legal support for these cases is scarce.

There is no glory in maintenance

Not only is it difficult to get funding for maintaining code, it is also difficult to find people to do it. As a project matures, contributors are bound to drop out for various reasons – professional, personal, or simply because other projects take up more of their time.

But technically mature projects offer little opportunity for new contributors to test new things and learn. Radical approaches give way to careful conservation, which is much less interesting and brings little fame.

People want to shine and learn.

An interview partner about motivation, and why people don’t join technically mature projects.

Maintenance work therefore is at a double disadvantage: it doesn’t attract volunteers, and it is difficult to organize payment for it. At the same time, mature projects tend to be more widely used by others who rely on them working, compared to a new project that is more attractive for contributors and funders. If a mature project fails, the consequences will be felt far and wide.

A person swatting bugs
The “bug” analogy goes a long way. GIF by Thoka Maer