Earlier this week, I unsubscribed from the mailing lists of a pair of Open Source projects. About two years ago when I found the projects, they involved fascinating topics in under served niches. One of those niches - the one customer/user-facing - is still there and under served, but that's not relevant in the current discussion.

In reviewing the activity on the mailing list, I noticed some interesting things:

• First, activity was very high. There was obviously interest and passion in the subject. That's a good sign.
• Next, there were some smart people involved in the discussions. That's another good sign.
• Finally, there was a lot of discussion on what should be done, but nothing actually done.

And unfortunately, I think that was the downfall* of the project.

* Normally I wouldn't write about this but since the domain name registration has long-since lapsed, I'm considering the project completely dead.

Recently, I realized that despite talking about Karl Fogel's book - "Producing Open Source Software" - numerous times over the past year[1][2][3], I've never written a review of it. So without further ado, here we go.

I originally picked up my copy in mid-2007. It took me a couple months to get to it, but once I did, it rocked my professional world. To be clear, Karl Fogel is an early (founding?) member of the Subversion Version Control System.

A few months ago, I heard an interesting idea about the 2nd Worst Developer.  It's wrapped up in a simple statement:

... the quality of a software system is proportional to the skills of the second worst programmer

While at first pass, that may seem to be a silly statement, but here's why:

... everyone on the team knows who the worst programmer is, so senior developers are closely monitoring everything that he does and cleaning up problems. The work of the second worst programmer is not monitored with that attention so he has the chance to do some real damage.

On small teams with short projects and even shorter deadlines, this problem is multiplied.  Not only are you dealing with overlooked problems, but you're dealing with less-than-perfect decisions consciously made to "get it launched".  Now you have two problems that compound on each other... Brandon Savage covers this one well in "Paying Down Technical Debt".

In my regular web wanderings this morning, I found something interesting.  A company that I'm familiar with just released v3.0 of their primary product.  At first glance, I was happy for them, then I remembered something odd, they released v1.0 early this year.  By all standards, going from v1.0 to v3.0 in under a year is aggressive... so I started to dig and found something interesting:

V1.0 was released in February...

v2.0 was released in July...

v3.0 was released in December...

with no point releases in between.

Wha?

That's right, they had three major releases in a 10 month span with no minor releases in the interim... which poses an interesting question about using their system:

What is compatible with what?

Yesterday I noted how good and useful forks in Open Source Projects could be.  Well, it turns out I was horribly wrong and I'm using this space to admit it:

Forks are the highest order of evil and a plague on our society.

First, it's a way to divide the attention of the community.  Instead of having a single project/effort to watch, the community has to evaluate both and figure out which one works for them.  If there are feature differences - or module support differences - they'll have to figure out which ones do or don't work... or worse, which ones partially work.

At php|works last month, Jay Pipes had the closing keynote where he talked about forks in reference to Open Source Projects... just to (not!) go out on a limb here and say:  I agree!

There are a variety of reasons that it makes sense to have - and sometimes actively encourage - forks...

First, it's a way to inject new life into a project.  There are many Open Source Projects which are out there with a handful of commits and almost no activity... or worse, there are even more that move quickly for a while and then crumble into nothing.  The couple of people that come together to work on the release don't ever pull it together and actually make that release.