Open source software and me

Last updated: 10 Apr 2023

Background¶

I grew up using free open source software, especially when learning to develop websites - Linux, PHP, MySQL, Vim, WordPress, various other CMS's, blogs and forums. So when I started making my own software, it seemed only natural that it should be open source too.

Laravel Breadcrumbs¶

Until 2013, I don't think anyone else used anything I created. Then I created Laravel Breadcrumbs, a PHP port of Gretel. Evidently it was something other people wanted too, because it eventually grew to have over 2,300 stars on GitHub, and over 5 million installs according to Packagist. It felt good for a while. But, like many others, I eventually started to feel a certain level of burnout. Not to the extent that more popular software developers do, I'm sure, but I started to feel like I had to answer every issue and pull request straight away - and I got frustrated when people opened issues expecting me to fix their problems.

At first, I tried to be helpful and answer all questions. Some people were grateful, which was rewarding. Others contributed pull requests, which was too, and I got to see the project grow in ways I hadn't thought of. But some people provided too little information for me to help them, so I had to spend time going back-and-forth asking for more information.

Then, for a while, I tried the template approach - I asked a whole bunch of questions up front so I would have enough information to debug problems. But I'm not sure it helped much - when people did provide the information, it meant I had more to read through; but still some people didn't provide it.

Later, I tried making it clear that I wouldn't offer any technical support - even though I felt rather mean saying it. The trouble is that didn't deter some people from asking, and even arguing that I "must" support them. That was even more demoralising them spending time helping them!

I also tried saying I would only accept pull requests, not issues/feature requests - but often I wasn't happy with the code quality, and ended up fixing it myself, asking the submitter to make changes, or just rejecting it.

Twice I ended up dropping the project completely - once between Oct 2016 and Jun 2017, then again in Apr 2020. Ironically (though perhaps unsurprisingly), these were the times when the most people contacted me to say how useful they found the package - which is one of the reasons I resumed development in 2017. The second time, someone else volunteered to take on maintenance - which I am happy about - that's one of the great benefits of open source.

What next?¶

The reason I'm writing this now (Apr 2023) is I've avoided open source development for the last few years, but now I'm thinking of starting again. I have no idea whether any of my new project ideas will become popular, but in case they do, I want to figure out a way to make it sustainable this time.

What is sustainable?¶

Make it worthwhile¶

One way to make open source sustainable is to make it worth dealing with the inevitable requests for your time...

Some people do it to build up their reputation or increase their earning potential. That was one of my motivators 10 years ago - but not any more.

Some people find ways to earn money, such as offering paid support, paid upgrades or paid services. I don't think that would work for me, even if I could think of something to sell - I'm happy with my day job, and not looking to earn any more on the side.

For the same reason, I don't think donations would motivate me - even if I could attract any, which is unlikely for the projects I have in mind.

For me, the things that make software open source worthwhile are - in this order:

1. Knowing my work will be public makes me do better quality work
2. Being able to use my projects for both work and personal use, while retaining ownership
3. To give something back, since I use a lot of open source software myself

Only the last one relates to helping others solve their issues, and only applies to people who contribute something themselves - not people who expect something for nothing.

Do less¶

The alternative is to reduce the number and/or difficulty of the requests...

The extreme version of this is not to publish anything - which has been my solution for the last few years. But making software just for myself is less fun, somehow, and less motivating. (Similarly, I recently started writing articles like this again - I find I do a better job if I know other people may read them.) So I would like to find a middle ground.

I've already tried saying I won't provide technical support, and even disabling GitHub Issues. Looking back, I think the problem with that was I still felt that if someone asked for help, I had to respond. I hated having open issues, thinking it reflected poorly on me that I wasn't dealing with them. But now I think I need to be OK with not responding to every issue. Perhaps I should even turn off email notifications, and only check for new messages periodically, to remove the urgency.

Another option is to self-host my projects (using Gitea), rather than putting them on GitHub. That way I can completely disable issues, pull requests and forks¹¹. People may still contact me by email - but I don't make that too easy to find. The downside of that is users are also less likely to contribute improvements, and there is nowhere for them to share ideas and issues with each other. It also makes it harder for people to discover projects in the first place.

Where am I going with this?¶

I'm currently leaning towards:

• Using GitHub, rather than self-hosting, to improve discoverability and allow for collaboration with others
• Keeping email notifications on - otherwise I need to check for messages manually
• Only responding to sensible questions, requests and ideas, not going back and forth asking for more information - and only when people are nice about it
• Only implementing features I personally want to use, or can see value in adding - perhaps preferring hooks/extension points to implementing them directly
• Leaving the other requests open, so I don't have to explicitly tell people I'm not going to deal with their issue (avoiding arguments) - and so other people can jump in if they want to
• Adding any issue I do want to work on to a separate, private to do list, rather than treating all open issues as actionable
• Not suggesting that other people submit pull requests - since it doesn't actually reduce my workload most of the time
• Not using labels, because that would force me to interact with issues, and require extra effort for little benefit
• Not including a "no technical support" section this time - it comes off as quite negative, and doesn't seem to work anyway.