I work as a maintainer for the open source project PrestaShop. When a user submits a bug report, we thank him for the report and ask if he is willing to submit a Pull Request to fix it. To which some people answers "I'm sorry? Why should I fix the bug myself? Why should I do your job? 🤔" and that is actually a very important and relevant question.

If you are a developer, chances are high that you are using everyday open source technologies that you will never contribute to. For example many people will use Linux 🐧 all their life without ever contributing to the Linux project. Never submit a bug report. Never submit a patch. Never test the beta or the release candidates.

I am one of these person 😅 I use Linux and I never did any of these things.

And it seems to be alright. The project continues to live, and I continue to use it for free without any issues. So... why should I (or you) bother? Even if I do nothing, I still get this awesome OS for free, so why should I change?

---

There are already a few answers on dev.to about "why contribute to open source": some will tell you that contributing to open source is a great way to learn. Others will tell you it helps building your developer reputation. Some developers also think of contributing as "giving back", like saying thank you.

But all of these reasons to contribute share one flaw in my opinion: they rely on developers good will or self-interest. This means that someone who has no free time nor motivation will not contribute for these reasons.

So today I would like to provide a completely different answer. And to introduce it I would like to compare it to the opposite of open source software: proprietary software.

Balance for proprietary software

Proprietary software is the opposite of free software. It is software that you need to buy to be able to use it.

In proprietary software, there is a balance between two sides: customers and seller. Or in other words, users and vendor company.

On the first side are users. Users want to use the software so they pay for it. In exchange for their money, they can use the software either on-premise or hosted. The software is probably being used to achieve something else: if it's eCommerce software, the purpose is to sell online. If it's a CRM, it's for marketing purpose. If it's an ERP, it's to perform entreprise management tasks. The software is a product purchased for a purpose, quite simply.

On the other side is the company selling the software. They are given money by customers, and in exchange they grant access to the software, to the product.
Obviously in order for customers to continue buying it, they must maintain it, which means fixing bugs and enhancing its features. They must address the needs of the customers in order for the software to stay relevant.

So each side trades something with the other to obtain something.

This balance is sustainable if both sides benefit from the trade.
The company must earn more money than it spends maintaining the software while the customer must obtain more value from its purchase (meaning cash) than what he spent on the software license.

Balance of responsibilities for open source software

In open source software, money is obviously out of the picture. But there is also a balance. However the currency being traded is effort, not money.

On the first side is the project whose representatives are the maintainer team. The team spends effort maintaining the software but also managing the project (for example handling incoming bug reports: reproduce, classify, sort) and deliver regular releases for free.

On the other side are users, and obviously what they get in the balance is the software, for free. Users get full and free access to the project.

If some people ask themselves "Why should I submit bug reports? Why should I contribute? I can sit here and get it for free while doing nothing" they must understand that this attitude ... will result in the project eventually dying (if a majority of users do so).
The project would die because the relationship would be unbalanced and consequently unsustainable. It cannot be one-sided.

So... the balance need to be restored. In exchange for the free software given to them, open source users must use the currency for open source projects: effort.

Effort by submitting bug reports.
Effort by suggesting feature ideas.
Effort by contributing to the source code and the documentation.
Effort by testing the betas and the release candidates.

Because maintainers will never be able to manage the project all by themselves. In order for the community to continue being delivered the software for free, they must act as testers and owners for it.

So here is the balance of responsibilities for open source software:

While the balance of responsibilities for proprietary software is profit-driven (each side aims to win more than it spends), the balance of responsibilities for open source software is rather a dependency relationship. Both sides must invest in each other because if one decides to cut the effort, the other will collapse. It can be seen as a prisoner's dilemna where maximum benefit is achieved when both sides cooperate.

The power of multiplication

Presented like this, I'm painting a very poor picture of open source projects 😅! Luckily, the sustainability model of open source is way more robust and complex than just this balance, I over-simplified the concept to explain it.

What however stays true in this over-simplified model is how much more an open source project can achieve than a proprietary software.

In a proprietary balance of responsibilities, the user "only" spends money. All of the development effort is to be spent by the company, which means it is limited by the company size, however rich it is.

In an open source balance of responsibilities, the development effort is spent on both sides, and that is a wonderful thing.

Consider the following situation: you are a user of an open source project A.
While using it, you identify a bug. You report it on GitHub (and that is a first valuable contribution) but as it is not critical, you are being told by maintainers that it wont be fixed anytime soon. No worries, you have some time and money so you spend them fixing the bug yourself and you submit the bugfix as a Pull Request after 3 hours.

Once the Pull Request has been merged, at the end of the day, the outcome looks like this:

• you spent 3 hours worth of your time
• maintainers spent some time reviewing/testing/merging your Pull Request
• one bugfix was delivered to the project

So the balance looks quite bad for you, right? 3 hours for one bugfix of a project you don't even own. Meh. 😒

But the very interesting thing is that, while you were exploring your bug today, twenty other users of the same project A have been exploring twenty other bugs and submitted Pull Requests too. At the end of the day all of the Pull Requests have been reviewed, tested, merged ; and a new patch release is delivered with these twenty-one bugfixes.

So from a group point of view:

• each member of the users group spent 3 hours worth of its time
• maintainers spent some time reviewing/testing/merging all Pull Requests
• twenty-one bugfixes were delivered to the project
• a new release was delivered and can now be used by the twenty-one users

So the real balance looks a lot better now: 3 hours of your time for contributing to a greater effort that landed twenty-one bugfixes worth sixty-three hours of work. In other words, you traded 3 hours worth of your time in exchange for sixty. And that is the power of open source.

Just like in the prisoner's dilemna, if one decides to be selfish and not the others, he gets all benefits while spending nothing. But if everybody decides to keep its effort (= to not contribute), everybody lose. Finally, everybody gets the same amount of effort at the end of the day, so it's a very smart strategy for everybody to maximize this amount of effort.

Maintenance burden

As mentioned by @ttoine, another benefit you get by contributing is passing the burden of maintenance.

Let's say for example you need GIMP to support a new image format TZL. You implement a driver for this. It takes you 3 days but you do it.

Great! Now you have it. But you know that software ages. You will need to spend more effort on your driver in the coming years to fix bugs, to keep it working with new releases of GIMP and the evolution of TZL format.

If however you submit your work as a contribution to GIMP, and it is accepted and merged, you pass the burden of maintenance to the maintainer team. And that is very valuable because it saves your time in the long run. The future years of maintenance will be done by the maintainers, not you.

Another thing you will get from submitting your work as a contribution is free feedback: when you submit a Pull Request, your code will be tested, reviewed, explored, analyzed. It is likely you will receive valuable feedbacks to raise the quality of your work so it can be merged in the project. This feedback is very valuable, it is like free consulting! Your code will gain in quality and you will learn a lot from this process.

Conclusion

Open Source is, to the core, driven by community. Its strength lie in the many, its richness in the diversity of its users. When combined and aligned, this can move mountains (think of Linus's law for example). When misunderstood and forgotten, it just gets abandoned.

That is both a lot harder and a lot more interesting than proprietary software where money rules it all. But what is really important is the multiplication effect, without equivalent in a standard proprietary balance.

So, back to the question, this is why you should contribute to Open Source. Because if nobody else does, the project dies. And because if you do, and same for other users, everybody gets so much at the end of the day.

Where do I start?

If you are now willing to contribute after reading this article, this is great! I would suggest you start contributing on projects you know well and you use everyday. What about testing the next beta or release candidate of your favorite programming language? You can also explore the issue tracker of your favorite framework. Remember that by investing effort in a project, you are also (and mainly) benefiting yourself.