Nico is blogging

My thoughts on software development, clojure, ruby, and trying to deal with complexity in simple ways

On Forking

Today I’m going to talk about starting a new fork in an open source project. I mean a fork not to just send a patch to the original project but to really go by a different pathway.

There are moments in life when it’s better to split pathways, be it from a job, your own company, a relationship, or an open source project.

If you are going to do that, wait a second and listen:


I mean: Try hard not to do it! It’s better to join forces together, the best stuff is built as a team, and the world has too much code floating around already.

That’s my first advise on this regard.

But if you truly think you have compelling reasons to change the direction of the project and you can get it started on that direction, then:


You’ll hopefully find others who like the shape the new project is taking (a fork is a new project) and will try and help to move it forward. And not only that: once the forked project is a reality, it might give a new perspective to the original project maintainers, and chances are that you might be able to join forces together in the future. Be it by joining the two projects, or just collaborating in unexpected ways.

Just be open in what you are doing.

This post was motivated by a project I started last week, ring-logger, which is a fork of ring.middleware.logger. The reasons for why I started the fork can be summarized as:

  • Ring.middleware.logger has some transitive dependencies (onelog, log4j) that I don’t want to (or even can) pull when adding a logger to a project.

  • I think the code of r.m.logger would benefit from some refactoring and the extension/customization mechanisms are far from ideal. Doing that could introduce some breaking changes.

  • r.m.logger maintainers team was very clear in that they are fine with keeping those dependencies because that’s what they use, and even though they would accept adding additional implementations, they would not change the default one from onelog. And the way how I was implementing the change, I couldn’t find a clean way to keep onelog as the default implementation while providing how to skip onelog dependency when that’s needed.

In a future post I’ll talk about how I decided to split my pathway from yellowspot, the company I co-founded and where I loved to work for almost 6 years, from which I decided to leave by the end of last year.

But that’s a very different story.