I love the PHP community and I love all the people who, each in their own way, help bring people together, help us to connect, to learn from each other, to get better. Whether it is Cal, Emir, Mark, Michelangelo, Michelle, Stefan, Theo or any of the countless other people out there. I love how we all come together to make PHP and the community around it better.

With so many good people out there, I have to admit, it scares me that some of the most used projects in the PHP sphere are largely maintained by one person.

When I say “PHPUnit“, you say Sebastian Bergmann, when I say “Xdebug“, you say Derick Rethans, when I say “PHP_CodeSniffer“, you say Greg Sherwood, PHPDocumentor, Mike van Riel, Composer, Jordi Boggiano etc.

Of course, they do have help, sometimes even co-maintainers, but when I look at the contributors pages of each of these projects, I truly do get scared.

These projects often have hundreds of contributors with maybe one or two commits and then the main maintainer with the bulk of the commits and the bulk of lines of code contributions. Often the distance between the main maintainer and the next co-maintainer or contributor is a factor 10 or even 100.

Of course, looking at the contributors page is arbitrary. At the end of the day, the quality of contributions is/should be more important than the quantity and the contributors page also doesn’t show who has been most active recently, but it still gives quite a good indication of how many, or rather, how few, people actively contribute to a project.

It is easy to speculate why these projects have few active contributors: they “just” work. But for these projects to “just work”, a lot of work has been done and still continues to be done. And is mostly done quietly by these awesome maintainers, without complaint and often without getting nearly enough credits or praise to keep them motivated.

These are semi-“invisible” projects. You set them up once & they do their job, helping you do your job, every single day.

Unless you have an error or the build is breaking, you don’t even notice they are there, other than in the peace of mind it gives you knowing that these tools are running the background.

Each of these projects is a de-facto industry standard. There are alternatives out there, but generally speaking, these projects have hardly any direct competition in their field as they are good, have earned a reputation, and – as mentioned before – “just work”.

And while it’s bad enough that it’s a relatively thankless job for the maintainers, what scares me is this: what will happen if one of them steps down ? Or changes job and won’t get much time from their new employer to continue working on the project ? Or just loses interest ? Or – while we don’t like to think about this -: what will happen if one of them would die ?

We sometimes talk about the “bus factor“, i.e. if a bus crashes with a certain group of people what would the impact be ? Can a project survive even after the bus crash ? Each of these projects has a bus factor of one. If one particular person would die or withdraw from the project, the project would effectively be dead.

Our dependency as an industry on a few key projects with only one primary maintainer is enormous. Can we honestly afford to allow this situation to continue ?

Of course, the old adage “when one door closes, a window opens” holds true. If one of these projects would “die”, other projects would rise up in their wake. And other projects do rise up now and again anyway, completely naturally, like how Composer effectively replaced PEAR. The difference between this happening naturally and happening suddenly and unexpectedly, is the havoc which we’ll see in the interim before the next project has gained enough momentum to be said to be the rightful successor.

We’ve all seen the drama that happened when left-pad, one of the NPM-hosted projects which was a dependency for thousands of projects, got withdrawn.

Essentially, if there is only one person with admin rights on the repository, there is only one person with the keys to the castle.

Yes, someone could fork the project, but the project “move” can not be registered in Packagist, dependent projects can not easily be informed about the new “official” fork and quite soon there will be a hundred unofficial forks, each slightly differently and nobody knows which one to use anymore.

Still, unless someone actively withdraws a project and/or disables the account under which the project repo is hosted, a project should still be around for a while. But it will slowly disintegrate. A new PHP version will come out and suddenly something doesn’t work anymore, a new PHP feature is not supported while it should be, etc.

And just imagine the sheer amount of effort which would be needed to re-code all unit tests to use an alternative to PHPUnit…. yes, take a moment to let that sink in.

We are talking centuries of dev-hours. CENTURIES.

No matter how awesome we may be as a community, we also have a responsibility.

A responsibility to our fellow developers as well as a responsibility to the projects we maintain. And being dependent on so many one-maintainer projects is irresponsible. So let’s show the world how awesome we are and give these maintainers the support they deserve.

We all use these projects, we all use PHP. All these projects – with the exception of Xdebug – are written in PHP.

My challenge to you for the new year is to have a look at the (dev-)dependencies you use in nearly all projects, have a look at their repositories, have a look at their open issues, open PRs and to ask yourself what you can do to mitigate the risks of using these one-maintainer projects.

It may not be “sexy” to contribute to these kind of projects. They are not the latest “hip” thing, nor the newest bleeding edge technology, but that shouldn’t matter.

By contributing to any of these projects – or any of the other typical dependencies I haven’t mentioned -, you end up making the whole of the PHP sphere better as every other project using these projects will also get the benefit of your work.

And risk mitigation can take many forms, whether it is:

  • validating open issues (arbitrage)
  • reviewing & testing open PRs
  • writing, improving or translating documentation
  • claiming an issue and creating a PR to fix it
  • or donating to the project

And, please, consider the same if you are the sole or main maintainer of a package which could be classed as risky from this point of view. Consider what you can do to on-board more contributors.

Consider adding “good-first-bug” or “up-for-grabs” tags and using them actively to signal easy-pick issues for new contributors to get started. Make sure there is a useful Contributing.md file. Be welcoming to new contributors, even if their ideas do not (currently) fit your project and be willing to spend time on reviewing pull requests, even when it would be quicker to fix something yourself.

Now, I realize on-boarding new contributors onto a project is not a small thing. For some maintainers, it may take a while before they are mentally ready to share their baby with co-maintainers. For others, it will be more of a challenge on how to educate new co-maintainers on the philosophy behind the project and to stay true to it.

So let’s be patient and kind towards each other while we each figure out our new roles.

Of course, the projects I have mentioned here are just examples. There are plenty of other projects out there of which the same can be said. Be it certain Symfony components, Flysystem, Guzzle, Twig or Swiftmailer.

I challenge you to look at the contributor stability of your dependencies and think about what you can contribute to improve the long-term sustainability of these projects.

Let’s show them as much love as we show our beloved elephpants.

Let’s all, in our own way, try to show how great a community we are, by behaving like one and supporting the people and projects who need and deserve it.

I salute you and wish you all a happy & productive 2018.

Juliette

 

Links:

Don’t know where to start contributing ?

 

With gracious thanks to Norbert de Langen, Andreas Heigl and Michelangelo van Dam for reviewing the article before publication.