Make the difference when contributing to open-source

Collaboration in open-source it is always a hard thing. It is a delicate balance of freedom, ideas, rules, time, money and motivation and many other factors.

This post focuses on the PHP community, as it is the one I'm in contact with. I’m pretty sure it applies to many other communities.

Make the difference

The PHP community has matured a lot in the last decade, we moved from a “development in the wild” period (2000-2008?) to a more organized community with standards, best practices, frameworks, meetups, conferences, and much more.

Some big projects emerged, with thousands of contributors. If you look more carefully at those projects you will notice that even if there are a lot of contributors, there are always some individuals that emerge from the crowd.

• Symfony has ~2000 contributors, but most of its code it is written by 10-15 people
• Doctrine ORM has ~600 contributors, but most of its code it is written by 6-10 people
• Laravel has ~2000 contributors, but most of its code it is written by 3-5 people
• Guzzle has ~300 contributors, but most of its code it is written by 1-3 people
• Curl (a very popular C library) has ~600 contributors, but most of its code it is written by 1-3 people

What does that mean? Most of the code we use nowadays is the result of tears and sweat of a few individuals.

If we also look at how some PHP projects evolved, hundreds of people have contributed to those projects, but there has always been a limited group of people who decided to take the responsibility and push the project forward by changing architecture, adding groundbreaking features or working hard to deliver new development standards. Each major change has been done again by a few individuals.

• Doctrine 2.0 when released was written mainly by 3 developers
• Doctrine Second Level Cache has brought in 14k likes of code, written by a single developer
• The performance improvements in PHP 7.0 are the result of the work of two developers
• Each new Symfony Component is the result of the initiative of a single developer

Of course all this work gets reviewed by many other contributors, but in the end, somebody has to sit behind a chair and write the code.

When talking about open source, the focus is very often on the “community” and the long tail of contributions, but those contributions are possible only thanks to the huge work by the few individuals who maintain and keep running the projects we use our daily work. It takes a lot of courage to step into the open-source world.

In the last few years, as part of the PHP evolution, we got strict coding standards, static analysis, immutability, and many other things. I have the feeling that those new concepts shifted the attention from important changes, to a bunch of small and tedious cosmetic changes. Formatting, sorting of array keys, static analysis, naming conventions, so-called Yoda-conditions, docblocks and much more became the focus for many contributions. There have been cases as where maintainers started to reject such kind of pull requests. Unfortunately, also many code review sessions tend to focus on code style, immutability, strict adherence to some way of writing code.

Instead of challenging and reviewing the architecture behind some changes or the foundations on which it is built, attention and effort drifted away to those other aspects.

Initiatives such as Hacktoberfest, 24PullRequests and EU-fossa recently have promoted open source contributions. Unfortunately, all those initiatives focus on small contributions, often fixing small mistakes, typos or sometimes on the border of being ridiculous. Some open source maintainers have tried to put attention on those behaviors but with not that much result.

Most of these initiatives don’t manage to motivate people to do bigger contributions. Contributions that span more than a day of work are rare.

Since important changes take time (more than a day), this brings us to the next point: the people behind open source and how open source is built.

What is open source

This picture, in my opinion, explains the reality of open source development very well.

Most of open-source projects are often the result of the hard work of some individuals. Working in their private time (not always from a dark room as in the picture). In some cases, people even get paid to do open source, but in most cases it is through some other project that is not directly related to open source code itself. In very rare cases and for extremely popular projects (as programming languages) it is possible to see people working full time on open-source.

Doing a major refactoring of a library, releasing a new component for a framework, fixing a not trivial bug can take easily more than 100h of work. Yes, I said 100, it is 2-3 weeks of work full time. It is giving away more than half of your monthly salary. This means that the time people invest in open source is extremely valuable.

Each refactoring or bigger change that happens in open source, is when someone decides to not earn those 2-3 weeks of salary. This precious time, gifted us by people who run open-source projects (both maintainers and contributors) should not be taken for granted nor wasted in non-important things.

Yes, some companies have 1-3 days/month where employees are allowed to contribute to open-source during work time. A nontrivial contribution that requires 100h of work will be completed in ~7 months...

I’m not saying here that companies/people should contribute more to open source. This has been already said multiple times. Companies and individuals are already contributing a lot. I’m saying that those contributions should be braver.

Contributors should stop “hacking” into the code the mere bugfix/feature they need. A more broad approach should be taken. Evaluate refactorings, encourage code reuse, offering help in triaging issues, writing documentation. Understanding the library and seeing how it can be improved it is the right thing to do.

Of course, this approach requires way more time, but contributing in this way makes the project better. By reflex makes the community and the ecosystem stronger, and by reflex again goes back to companies who contributed. Those companies can benefit from a healthier community, able to give them better support in their daily issues.

Most of the open-source projects we have nowadays are the result of someone who decided to not “hack” a solution for a problem, but decided to step back, and implement a proper more decoupled solution, one that can be shared with others so they can benefit from it.

Since we have limited time, and good contributions take time… how to do it?

How to contribute

Any contribution is good... almost.

Contributing to an open-source project is not mandatory nor is it a challenge to get a free t-shirt. Each minute invested in open-source by a contributor requires a minute to be invested by a maintainer. So make your contribution valuable.

In most cases, this means talking to the maintainers, checking what their goals, availability, and the direction they want to take the project.

Try. Be brave. Challenge the current status quo. Be ready to be challenged. Be ready to give up. Be ready to be put aside.

Don’t create a 10k lines of code contribution that maintainers want but are not able to take in. At the same time don’t create a one-line contribution that doesn’t add any value to the project.

Balance your time properly. Carefully choose levels of strictness, architecture, project guidelines adherence, best practices. Remember that a delivered contribution that improves the project by 20% is better than a contribution that would improve the project by 80%, but can’t be merged because it’s too complex. Choose whatever approach you feel comfortable and try it!

Sometimes you will get good suggestions from other people that will help you to improve your work. Sometimes you will get good suggestions, but those suggestions might put you on the spot to not be able to deliver your work. It can be because you don’t have yet some expertise or maybe just because you do not have the time to do so. Choose carefully what will help you to deliver and what not.

Measure your time, your motivation, your ability to make an impact, community motivation and community interest in your contribution.

Take a deep breath, and just jump! You will not regret it!