Earlier this week I received a notification in my mailbox, the issue #79 I had created on February the 3rd of 2016 was resolved and completed on the Chronos package. You read that right, an issue I created more that 6 years ago was finally resolved and while I was looking at the notification I could not help but thanks the maintainers of the Chronos package.

I remember opening this issue around the time the first version of Chronos was released and from what I could read through the comments on the issue, there was a lot of discussions and back and forth between the CakePHP team and me. In retrospective, my explanations may have come a bit as a criticism but the people who responded to me were understanding and tried hard to find a way to resolve the issue. Suffice to say it took them 6 years. But is 6 years that long ?

While for a regular user it might seem like an eternity, I tend to think it is not. As developers we have fallen into the habit that once a bug is found it should be fixed as soon as possible because that what any good developer is expected to do. Release early, release often, is what we hear everyday. But, as developper we forget that the developer timeline is hardly the same as the package maintainers timeline. What we usually see as a one to one conversation between the author of the issue and the maintainer of the package is in reality a many to many conversations between each and every member of the package ecosystem with the maintainer serving as a gatekeeper. Whatever the gatekeeper will decide, it will affect the package but also potentially all the other users of that package. As such while you are only focus on your issue, the maintainers are focus on

• the maintainability of the package: Will the fix make the package more or less complex to maintain.
• the package roadmap: Does the fix affect or not any new feature in work ? Will we have to re-evaluated the current project.
• the package usability: Does it introduce a BC break. Does the patch makes the developer experience worst or does it, in contrast, improve it.
• Fixing the package: Does the maintenance team has the resource, the knowledge, the know how and the availability to implement/review the fix if one is found/provided.

In my case, all the above points were checked so even though on surface the fix may have seem simple, its consequences were not and as already mentioned it took 6 years to get to the point were a solution to my issue could be safely deliver to the end users.

Could the resolution have happened earlier ? Probably if the maintainers had enough time in their hands. I remember at some point receiving a notification where they asked me if I wanted to provide such patch. It turned out I could not because of time constraints too.

The bottom line is this, whatever large, complex or old your issue is, you should thanks the maintainers of any package for addressing it. You should also not be afraid of reporting your issue. You will never know when it will be tackle but at least it will be seen by the maintainers and sometimes they may contact you to get more informations regarding your issue. Please keep following your issue and don’t leave them stale because either you found the solution or you found something better to do.

Last but not least, if you find your issue to be critical for you or your business you still have two ways to resolve that urgency. You can either support the development of the package by sponsoring the maintainers (when I say you I am referring to the entity for which you are using the package for, it can be you as an independent or your employer) or you can in most cases fork the package and do whatever you had in mind. In the latter case if what you did can be re-used by other people please submit a Pull Request with your addition to improve everyone DX. Because at the heart of it open source is all about communities sharing experiences. And It takes two to tango.

That being said, once again, thanks to the CakePHP team and to all the maintainers out there for your efforts and cares.