10 interesting open source software forks and why they happened | Hacker News Reader

10 interesting open source software forks and why they happened

royal.pingdom.com

52 pointsluckystrike13 comments

I'll tell you what's interesting. This blog. It's from a fairly unsexy uptime monitoring company, whose services I've got little interest in. If the blog was just company updates ("we've got a new server" or "20% off all packages this week") it'd get very little traffic. But I've got it in my RSS reader and it hits the social news sites every other day with well-written and often humorous observations on tech.

Lots of people have heard of Pingdom who ordinarily wouldn't; it just goes to show how a little effort making your website something more than just a corporate website can go a long way.

Absolutely. And to ask the next question: how many people signed up (and paid) for their service because they heard about it via the blog?

At least this one. I've been trialing it and am planning to sign up at the end of the trial. The service works well.

One interesting fork was egcs, forked from gcc in the 1990s, by people who wanted to try out the "bazaar" development model (as opposed to the "cathedral" model the FSF used, which meant very little engaging of the community.) The experiment turned out very successful and eventually the egcs version was named the one and true gcc (and the gcc we use today is a derivative of it.)

Best line in the article, re: Carrier forking from Pidgin: "A fork (initially called Funpidgin) was done of Pidgin 2.4.0 because there were disagreements about the size of the text entry field."

Sometimes developers can be very childish and proud. Just make the damn thing resizable or write a plugin or something.

I was listening to (I believe it was) Mark Shuttleworth the other week and he basically stated that: "All forks are generally a result of lack of good communication between developers."

From what I have seen Pidgin developers are morose than normal. This clashed when they refused absolutely to listen to users who wanted at most an option to disable this effect from the options menu.

In the end this isn't about a text entry field its about developers who will listen and act on user input.

Indeed.

I think this is a nice article - but it can be summed up by: why do (open source) project fork? For lots and lots of reasons.

I guess the lesson is, if you're heavily invested in an open source project, you might want to think about how you'd deal with a (perhaps inevitable) fork.

Why not link to the projects being discussed. That's a lame oversight.

This article is interesting, but I think it is too shallow to get any deep understanding of causes of forking as a phenomenon. A case study on /that/ would be kick ass, and quite a treat in terms of both software engineering methodology and oss anthropology.

For example, it doesn't even mention that OpenBSD's priority is security and NetBSD's is portability, and that that is the reason for the fork.

Pretty good choices for the list. A bit of history and details, but only very little analysis of why they forked.

Eh, made for an easy read. I'm ok with it.

Reply on news.ycombinator.com