Some years ago, during lockdown times, ThePHP.cc talked me into writing a talk for their online conference. They knew my company tried to support open source in several ways and hoped that I would share the how and why. Since then, I’ve done that talk at several conferences (including the amazing Dutch PHP Conference and PHPDay). I’ve not done this talk since 2024, but the lessons are still important. After a little prod by Stefan Priebsch, I decided to write a blogpost about how I look at this now.

Open source

Open source exists in many forms, but the basic idea behind it is that the source code for software (or libraries) is available to look at, audit, and use. If the license permits, you could even alter and re-use.

But open source doesn’t just exist. It is built by many people around the world, for all kinds of reasons. To me, open source is not just “a thing I can use”. If I decide to use open source, I become part of the community. And a community is not a place where you just take. It is an interactive organism where you give and take.

Given the amount of open source I use, it would be impossible for me to give back to all projects all the time. But we shouldn’t feel the necessity to give back to all open source projects. Being an active part of one or several communities is already a great way. The choices you make in what projects to support can be important, however.

The responsibility for companies

As a personal user of open source, I feel I should be part of the community. But for commercial organizations, I feel there is an added responsibility. Because if you use open source inside your company, either as user of software or as developer building on top of libraries and frameworks, you earn a (hopefully healthy) profit off open source.

I feel that if you earn money off of open source, then it is your responsibility to support open source. There are a lot of ways to do that and I’ll go into that later, but for now I just want to say: You should actively support open source.

What projects to support

Whether you’re an individual developer or a company, the first thing you need to do is make a choice. As I said before, it’s nigh impossible to support all open source projects. So instead, you can make a choice. And you can make that choice over and over again if you want. You don’t have to choose once and then keep supporting that project all the time.

A great way of making that choice is to look at all the open source you use. Software, frameworks, libraries. By actively contributing to the projects you use yourself, you actively get value from your own contributions, because the project you contribute to gets better thanks to your contribution.

It is important to have a critical look though at what projects to support. Every contribution helps, but a contribution to a project that has a small team or even a single person behind it has more impact. Of course it’s great if you contribute to Symfony or Laravel or phpBB or Drupal. But perhaps also have a good look at your composer.json file to see what other libraries you use that are made and maintained by less people. Not just will your impact be bigger because there aren’t a lot of other contributions, but those projects are also at a bigger risk of being abandoned. The bus factor is a lot higher on those projects. So having even just a single contributor added to such a project is huge.

How to support a project

There are many ways to support a project. Some are really easy, others are perhaps a bit harder. You don’t have to pick one, you can do multiple.

The most obvious one that everyone thinks of is to contribute code. Send a pull request with a new feature is the one thing everything thinks is the best contribution to open source. And of course, that is great. But consider this: The maintainers of an open source project need to do everything: bug fixing, new features, keeping an eye on the big picture. So sending a pull request with a bugfix, or even some added documentation, is also extremely valuable, and allows for the maintainers to focus on the big picture and the new features. Having said that, if you think a new feature would be a great addition, by all means, start building it. But communicate with the maintainers, to make sure they agree on the feature and the way you want to approach it. It isn’t for for the maintainers and for you if your contributions gets rejected.

But code is certainly not the only way to contribute. Some things we did as Ingewikkeld to support open source:

• Give our developers work time to work on open source
• Rector rules to migrate mockery to prophecy
• Bug reports to several projects
• Adding PHP8 support to some phpDocumentor components
• Contribute to a PSR
• Help users of open source projects on social media or in chats

Aside from that, we’ve organized several events. WeCamp was a physical event, a 5-day code retreat where developers would be taken out of their comfort zone to learn new things and focus on both code and personal development. Comference, an online conference with a variety of speakers. And the Ingewikkeld Sessions, live streams focussing on a single topic, with a podcast on the same topic.

And aside from that, we’ve also donated money. Because we can’t underestimate the importance of funding projects and developers. There are a lot of examples of maintainers spending way too much of their time on their open source work. Donating money really helps them in the most practical of ways. That can be a one-time donation, but a recurring donation is really useful as well.

For PHP, another really important contribution is donating to The PHP Foundation. This non-profit organization secures the future of the language in many ways by funding development and projects.

Why?

I started this article already with some reasons to support open source. As individual developer, you become part of a community once you start using a project. It is good open source citizenship to support the ecosystem that you are a part of. As a company, I feel you have an actual responsibility that goes beyond simple “good open source citizenship” because the benefit to your company is not just making your life easier, it’s also an economic, clearly monetary benefit to you.

There are more benefits though: People that contribute to open source projects learn about the things they work on. You do work on a project in a different context from what you usually work on, work with different people, perhaps even with a different process. There’s a lot of lessons we can learn by looking outside of our usual context.

As a company, it can also be marketing or a recruitment tool: Your contributions to open source projects can be noticed by potential customers or potential developers. Your contributions will automatically make you an expert. Or make you a really interesting employer. Several people that have worked for Ingewikkeld have explicitly mentioned that part of their choice for our company was because we allow people to contribute to open source during work hours. Better yet, one of the people that worked for Ingewikkeld was introduced to me by Sebastian Bergmann of PHPUnit and thePHP.cc. He introduced us at SymfonyCon, and not long after, he worked for us.

The benefit of open source

As you can see, the benefit of open source is much more than just free code you can use. As such, it’s important to make sure that that ecosystem can keep existing. As an individual developer, but more importantly, as a company.