There’s a lot going on in the world of opensource these days – but it seems that not the development side of things is discussed most of the time in some projects – it’s the social side, the “I want this, you want that, I don’t like you”-side of things.
Ever so often some opensource project split up and do a “fork“.
These are just two examples for your reading pleasure and studies of human behaviour:
1. Project Pidgin:
Well – the developers and users of project pidgin are not able to reach a consensus on the question how their beloved software should look like and behave. Believe it or not: There’s a project fork and a hefty discussion just on the question wether or not the Chat Input Text field should be resizable or not.
This picture should visualize the problem:
The developers did not want to make it resizable, the users wanted it to be resizable. Problem – Discussion – Fork you!
You can read the whole story here.
2. Project XBMC / OSXBMC
OSXBMC is the team that forked in this example: They develop – aside of the main XBMC team – the Mac OSX port of the Xbox Media Center (which actually runs on Xbox, Linux, Windows, OSX now).
Obviously there were hefty discussions going on with the main XBMC team. Mainly because teh XBMC main team thinks that the OSXBMC guys didn’t check-in their source changes often enough.
You can read one side of the story here and click you through to the other side.
The problem with these forks is not the fork itself but the way the people in these projects seem work with each other. Many very promising projects died because people just could not work together…
As far as I am concerned: For opensource projects I prefere the maintainer-scheme that for example the linux-kernel uses. Have one gracious dictator who has the final word about the release and people that maintain different parts of the project.