It has been quite a year, has it not? We will remember 2020 for a long time to come, with shelter-at-home orders, restricted travel, not meeting friends, family, and the wider PHP community. It has been quite a lonely year, as we find that although Zoom is great for doing meetings in your pants, it is by no means equivalent to sharing a beer, laughs, and arguing about Attribute Syntax or which PHP versions should be supported by Open Source tools at a user group or conference. I am really missing it, and you.

Now most of us are stuck at home behind our screens, it is easy to forget that when we write down our arguments and gripes in issues, email, and not to forget on Twitter, that there is a person on the other side of the communication channel as well. And that person is going to have to read your rant on whether the bike shed MUST be purple with pink polka dots, and definitely not the more sane green colour.

In the last year, I’ve seen various posts by maintainers of Open Source software stating that their users are ungrateful when they complain and expect their problem to be solved straight away. Sometimes this stays as a single comment, or they call it “crappy software”, but sometimes words get way too strong, essentially about something that is being given to them for free—software written by a maintainer in their free time. I certainly have had a few rants directed at me for Xdebug for it wasting time, which I find amusing as the sole drive behind Xdebug is that it is going to save users a fuck ton of time. I digress.

I think that as a community we need to acknowledge that there is probably more twaddle thrown at maintainers of Open Source code than they deserve. In the end, they spend a lot of their spare time creating useful things for the world at large. There is definitely no requirement for maintainers to spend more time on problems that a user has, or thinks they have. How can you even require people to work on free stuff in their free time?

But does that mean that that absolves maintainers from not caring about the users of the code they have made public? It depends. Some Open Source code gets written to scratch an itch. I wrote VLD, a tool that shows the internal operations of the PHP engine, to assist me with developing and debugging Xdebug‘s code analytics routines. When I started this, no other such tool was available, so I made this Open Source for others to use if they want. I do not provide any support, and will immediately say “Pull Request welcome” if somebody runs into a problem. I can justify this for VLD, as it is a very low-level tool and only useful for people that know the PHP engine fairly well. VLD was primarily written for me.

Much Open Source software starts out that way, but at some point, things can get out of control. When I started with the development of Xdebug 18 odd years ago, it was also very much for my own benefit. Mostly to learn a little about how the PHP engine worked, and how I could prevent infinite-recursion from crashing the engine due to a stack overflow. But as you know, this got a little out of hand and I’m still here supporting, upgrading, and improving it, recently culminating in the Xdebug 3 release.

For a part of the 18 years that Xdebug exists, I did not actually write a lot of PHP code. I continued maintaining Xdebug for the benefit of PHP programmers at large. I would even go as far as to say that I felt that I neglected its users by not having as much time to work on it as the software deserved. Now that there are so many users, there is an implicit bond between my Open Source side project and its users, and I believe I owe the users at least something. If I did not want that, I should not have chosen to publish the tool that I wrote to scratch that itch as Open Source. But because I did, the question becomes rather what sort of expectations users can expect, and what I’m willing to provide.

Acknowledging Pull Requests and issue reports? Yes. Support questions in a public forum? When I have time. Private questions? Probably not. Free 24/7 phone support? Fuck no.

I am open to providing private support for Xdebug’s users, but only for users who have signed up for a paid support package. But still no 24/7 phone support, I’m not stupid.

By publishing your code as Open Source, you do create an implicit moral contract between yourself as maintainer and the users of your code. Users can rightfully expect you to be a good steward of the software that you publish. It also sometimes inconveniently means that they expect you as a maintainer to care for their problems. That is what you sign up for if you publish code as Open Source.

I think we would all be better off if these implicit contracts became less implicit by writing them down. A part of this is PHP’s supported versions page, and Xdebug’s compatibility page. For Xdebug there is an explicit commitment to which PHP versions I support:

In general, at any point when an Xdebug version is released, it will support the currently supported PHP versions.

I also believe that as an active maintainer I should listen to what users have to say, and take their concerns into account. Only mentioning PHP version support is not nearly exhaustive enough. That does not mean you can be expected to give in to their requests (demands?). You are not obliged to do anything, and free to ignore user’s requests or demand payment in exchange for getting things done.

I have to come back to the issue of which versions of PHP should be supported by (Open Source) tools and libraries that PHP community members publish. This is a subject that sees frequent discussions. I started writing this article a few weeks ago, but even as of this weekend, another discussion thread sprung up on Twitter.

I believe very few developers want to be required to support old versions of PHP. It is no fun constantly forgetting that PHP 5.3 does not support the [...] syntax for arrays (FML).

If you write Open Source code as a “job”, it is more justifiable to spend time on older PHP versions. Unfortunately, that means that I sometimes still have to try to get PHP 5.3 to compile on a new Linux distribution. But because there is an explicit contract in place, I knew what the deal was upfront.

End users want the most amount of compatibility with the widest range of versions of dependencies, because they cannot be arsed to upgrade their code all the time, for various reasons, right or wrong. It is annoying for them to have to upgrade all their dependencies if they just want to use a newer version of PHP, especially if that means that they need to rewrite parts of their code because one or more dependency has breaking changes.

On the other hand, maintainers want to have to support the smallest range of dependency versions they can get away with. Supporting older versions of dependencies, including PHP versions, adds more overhead when you just want to use the latest and greatest to write more efficient and more performant code, while reducing cognitive load. There should of course be a balance, and what that balance is, probably depends on what the context is.

A library or tool that is a dependency that other developers rely on, which has a small range of supported PHP versions makes it harder or impossible for these other developers to use that tool to support a wider range of dependency versions for their users. With Open Source there is no requirement to do anything, but does it really hurt to be generous with what you support instead of having a strict dogma on what you will support? I believe not. As a community, I think we need to look at having more empathy for each other. And yes, that will sometimes mean supporting things for longer than you really want.

This turned out a bit more gloomy than I intended, especially after such a cheerful first paragraph. My main point is two-fold: be more explicit about what you support, and why, but at the same time have empathy for your users, and the eventual problems that they run into with your published open source code, and how it is supported.

On a happier note, although 2020 has been an odd year, it also brought lots of new releases in the PHP world: Composer 2, Xdebug 3, and PHP 8. I suppose we all had a bit more time now we are all stuck at home. I am looking forwards to meeting you all in person again at a user group or conference in 2021, where I will be more than happy to argue that the Attribute Syntax that PHP 8 now ships with is absolutely the best one, or that it is now really time to say goodbye to PHP 5.

Take care,
Derick