A couple of months back, I release two open source packages for the Laravel community. Laravel Translation and Nova Translation. These were my first major advances into the world of open source and I decided to document my journey on the Laravel News site. My motivation for doing this was the hope that sharing my struggles publicly would help others to overcome their apprehension of getting started in contributing to the community.
Before deciding to build and release these packages, I was hearing a lot of negativity on the line about the treatment maintainers were getting for all the time and hard work they selflessly put into building tools to assist their peers. People complaining when issues are not resolved in a timeframe they perceive to be reasonable or just having too many issues to deal with and not being able to keep up. Frankly, this is one of the reasons it’s taken me so long to take the plunge. I have a young family, full-time job and multiple side projects. I didn’t want to embark on something that would become a huge time sinkhole for which I couldn’t support and ultimately end up letting people down.
The first release of Laravel Translation was back in September 2019 (10 months ago) and the figures currently stand at a steady 11,285 downloads and 168 stars. Although these figures won’t get me trending on GitHub, I’ve been pleasantly surprised by the amount of activity on the repository.
I’d like to highlight a couple of the things I’ve noticed:
The issue containing the fix
There have been a number of issues raised on the repository. What I find interesting is those issues where folks tell you how to resolve it in the body of the issue, but decide not to contribute the fix back to the project in the form of a pull request.
Don’t misunderstand me, this is just an observation and not a complaint. I’m very grateful for any support I receive. It just seems like an easy way to become a contributor to the package.
The never ending issue
Next there are those issues which don’t seem to end. Someone submits an issue. You understand the problem, but it’s an isolated case not likely to affect others. Implementing a fix would mean a breaking change for everyone else. There is a back and forth on the issue, but no real progress is made. Eventually the conversations dries up. Do you close the issue and move on, or would doing so make that user feel like their issue isn’t important?
Spoiler alert… it’s still open!
To me, pull requests are the magic of open source development. You work away on a package, release it to the world and monitor the downloads and issues. You are confident people are using it, but you don’t get much in the way of feedback. It can feel like a lonely place.
Then bam, out of nowhere a pull request hits your inbox. Some lovely human being has contributed a bug fix or even a brand new feature to the code base.
The first time this happened, I was genuinely surprised and incredibly happy that something I had shared had helped someone enough they felt the urge to contribute back.
What really amazed me was when somebody, without my prior knowledge, contributed a feature which I had on my internal roadmap. I’ve recently had a baby and so my free time is limited. It was a fairly in-depth feature touching multiple parts of the codebase with lots of potential to cause bugs. I just couldn’t find the 3-4 hours needed to build it so this gift was a huge weight off my shoulders. What’s more, I couldn’t have written it better myself!
I find it incredible that someone would go to the lengths of learning the codebase, planning and then developing a solution with no guarantee it would even get accepted and merged by the maintainer. That said, I’m incredibly glad they did!
So far, I’m really enjoying the experience of being an open source maintainer. That claim comes with the massive caveat that I don’t have an inordinate number of users.
My issues are manageable and I’m getting great support from contributors.
However, there is still work to do and I can foresee this would exponentially grow as a project grows in popularity.