Forking Watson: Motivations

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:

• The project leadership does not align with your personal values

  As a contributor, you should evaluate the value system of the leadership and make a personal determination as to whether or not it aligns with your own. If it does, participate. If it does not, find an alternative or fork the project. Drew DeVault - Effective project governance

• You have a different vision of the direction the project should follow

  Some forks are due to amicable but irreconcilable disagreements about the direction of the project; perhaps more are due to both technical disagreements and interpersonal conflicts. Of course, it's not always possible to tell the difference between the two, as technical arguments may involve personal elements as well. What all forks have in common is that one group of developers (or sometimes even just one developer) has decided that the costs of working with some or all of the others now outweigh the benefits. Producing OSS - Forks

• The project leadership has left or lost the original motivation, ie. the project is abandoned/unmaintained

  In my opinion, there are two good ways to abandon a project: the fork it option and the hand-off option. The former is faster and easier, and you can pick this if you want to wash your hands of the project ASAP, but has a larger effect on the community. The latter is not always possible, requires more work on your part, and takes longer, but it has a minimal impact on the community. Drew DeVault - How to abandon a FLOSS project

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).