Why Some Forks Suck

I created a patch for the ERP software package WebERP (http://www.weberp.org). Now - for those of you who are paying attention, the SourceForge page where you download the source for this project is https://sourceforge.net/projects/web-erp/ (notice the dash). What do you get when you accidentally leave out the dash in the SourceForge page? A fork that has the website http://www.web-erp.org/ (notice the dash).

With these interchangeable names, you can see how anyone outside of the project would be confused, and how it will damage both projects over time.

With open source software, the right to forking isn’t something one should take lightly. When you fork, you should clearly point out a few things:

• That you are a fork. As a politeness to the user, mention the project you forked from (and a URL if possible).
• Why and when you forked. Explaining your reasons sets the tone of the fork, and lets other developers know which project to commit certain patches to (eg. some forks are only focused on one aspect of a system, such as focusing on certain hardware).
• Make your name distinct! OpenOffice and LibreOffice, Beryl and Compiz, these are forks with distinct names, and thus eliminate the kind of confusion you get with this WebERP fork mess.

With Git making forking simple (which is good), I must say I’m glad that sites like GitHub more or less do the above by design. Still, it’s up to humans to make sure things are distinct enough so that no confusion will arise.