Why and how to fork: The case of Watson

This story began about a year ago when I started contributing to the Watson project. It was a good experience and I learnt a lot, especially about collaborating in a FOSS project. Nevertheless, along the way, I noticed some patterns and signals that hinted me that this project was not for me. But let's start from the beginning.

What is a fork?

There are (at least) two types of forks:

  1. A development fork is just a copy of the original project where a contributor makes some changes and submits those back to the main project. This meaning of fork is controversial as it's mostly associated to the GitHub concept of Fork, which is far in intention and meaning from the Bazaar model where contributors just clone the original repository, make some changes and send them back (usually in patch form using e-mail).

  2. A hard fork is when some people (or even just one person) decides to part ways with an existing project (the forked project) and start its own independent project (the fork) based on the former. This can be done for a myriad of reasons, in multiple ways and with infinite purposes.

This post refers to the second meaning and I will use the term "fork" meaning "hard fork" through the rest of the text.

Why forking?

The general advice is to fork a project only as a last resort measure, as it effectively splits the efforts weakening both the fork and the forked projects. Still and all, there are multiple reasons to fork a FOSS project and one or more can apply at the same time. Let's review some of them in no particular order:

You will come up with more if you try, but these seem to me like the most common reasons to fork a project.

The case of Watson

Watson is a small tool to track your time from the command line. It was built by the French company TailorDev. As part of their open core values, they developed a variety of very interesting projects that had quite an impact on the global software development audience. They were an inspiration to many people (among which I include myself).

Nevertheless, their activity started to slow down since 2018 and their opensource projects switched to maintenance mode, not because they were complete, but because it was no longer a priority for the people involved. Despite this, they still care and answer questions from the community, always in a kind and friendly manner.

For me, the problem is that these projects (and Watson specifically) have many traits of what I've called a FOSS zombie project. It sounds worse than the maintainers deserve, but I couldn't find a better metaphor to convey the situation as I see it: a project that is alive, but dead.

I'd also like to say that after speaking privately with the maintainers, there is a disposition to improve the current situation to some extent; though they are OK with the current state of things.

To sum it all up, as I haven't seen a clear path to keep participating in Watson, I've prefered to take the situation as a challenge to learn about FOSS maintenance and simplify and customise the software to fit my needs (and hopefully the ones of others too).