Thoughts About Starting Out as an Open Source Project

I thought I would start off by just noting down some things about being the maintainer of an open source project such as tsMuxer.

My case is a little unusual in that I didn’t write all the code myself. I contacted the original author of a piece of freeware that had not been updated in a long time and worked with them to make it open source. They passed the code over to me and, as we agreed, it went up on GitHub.

One thing I would definitely change is how I announced it to the community. If I could go back in time I wouldn’t announce anything until the GitHub repo was public and I had tried out a few builds of the software with different configurations. What I actually did was announce my intention to make the repo public and asked for anyone that could help out. I was immediately called out for effectively being a dictator who wanted to keep total control over the code. Whether that was fair or not is immaterial — it created a poor impression from the start.

I am very thankful to the early contributors who created the CMake configuration we now use and helped fix up and modernise the code. However for other members of the community who didn’t want to compile it themselves the lack of binaries being produced was clearly frustrating. I went down some rabbit holes that went nowhere but now I have a pretty nice pipeline for creating binaries, and it will only improve. My mistake was thinking I could just take what others had created and repurpose it — I had to make my own pipeline. If I’d realised it earlier and done more towards it we would be much further along. We still have some way to go but in the early stages I would have focused more on creating binaries for each platform.

I am thankful that I used templates for creating the initial readme files, licences and code of conduct notices. I wanted to create an inclusive and encouraging community and the code of conduct and my own demeanour has a huge part in that. I feel like I still have some way to go in that regard but culture is tremendously important so it’s important to hold contributors (and yourself) up to a high standard.

For a little while there didn’t seem to be much activity with contributions to tsMuxer. I felt like maybe the whole enterprise was a bit of a waste of time if nobody was using it or improving it. Then suddenly we received a flurry of contributions. Things were getting fixed and improved and we had a lot of forward trajectory. So I think then it’s important not to get disheartened, either by a lack of activity, a lack of your own time or even making mistakes. I’ll probably go over some of my mistakes in further blog entries but there have been quite a few!

My final piece of advice would be to keep to the GitHub workflow and test things out. One of my mistakes was taking a small change (or so I thought) and pushing straight to the master branch. Ideally all changes are done in a separate branch and then you create a pull request to merge to master. Issues are great for tracking what you have merged and why. But also you have to test stuff out! I recently found all the Linux builds being generated on GitHub didn’t actually work. Oops! I managed to test tsMuxer on MacOS after a long time and now I actually know what needs to be done to get them working. So yeah — test everything!