Forking a project? Are you up for the commitment?

We have all said it multiple times, the reason we use open source software is because we can change it if it’s not working as we like it to. But when was the last time you forked a major project?

So last month I was so upset by a feature pushed to me from Signal that I decided just do that: to download the source and build it myself and fix it. Said and done, it was just a matter of hours until I had downloaded the source from github, set up the build environment and located the few lines of code which offended me.

Done, works like a charm! But at that time I realized it, my patch would not be able to make it upstream, as it would basically just undo one of the features the core team had decided to add a few days earlier - accepting a pull request to remove it - not likely. 

With the complex systems in an integrated world we have today it is both easier and harder to fork and change a program. It is easy to just fork on github and start to build new binaries but it is harder because it is a commitment.

For instance, Signal a client of a communication system which is actively developed, the forked app must still be able to communicate with their systems. You must keep up with changes in API and protocols to be interoperable.

In other words, when you fork a project it is a long time commitment to at least maintain your own version of the software with the added feature.

So I need to have a maintenance plan. If my branch and upstream diverges too much it will be a enormous task to merge the updates, the only real option is merge and track upstream as closely as possible.

How to handle releases?

Ideally every time the upstream branch is updated I should to pull and merge these changes to my customized branch and rebuild.

Once there is a branch Github actions make it easy to set up CI and automatic release builds, in fact this is so easy I even made a release during my lunch one day last week. From the table at the restaurant waiting for my tonkatsu. 

Running termux on the phone a few simple git commands fetch / merge / tag and push, voila done! Easy and fun to do ... for the first week - I guess I would have to automate this soon, and only look at it when a merge fails and the code is broken.

The signal app is written completely in java not a language I use on a daily basis but for the purpose of just making smaller changes and still maintaining compatibility with upstream project this is not a problem, the fewer lines changed the easier it will be to maintain a fork, but now the box of Pandora have been opened. Now when I could change anything, all the small annoyances, could now be addressed, changing background of toolbars during video calls to transparent and making viewfinder smaller adding a poo emoji the sky was the limit and suddenly slowly I'm drifting away with a fork being more and more unmaintainable.

I guess the moral of this story is to be able fork a program is a great power but it is a power to be used wisely or your creativity it will drag you down in the swamp of merges and maintenance.