In memoriam: free software projects of 2007

Recently I looked in on the project Web site for a small application I use, only to find the wiki completely filled with spam. The project itself was clearly in disrepair, and the code abandoned for six months or more. I wondered: how many other apps that I use have halted development without my realizing it? I decided to look back at the projects I’ve written about over the past year to see which ones are no longer with us.

Before I compiled a list of dead projects, I had to decide what the definition of a dead project was in the context of open source software. Some apps reach stable maturity and go long stretches without ever releasing an update. That’s rarely the case for system libraries, but for the oddball, scratch-one-programmer’s-itch application, there may be no need for any updates unless substantial changes hit the Linux kernel. Take Heyu, for example, which I wrote about in November. It’s an X10 control app; it speaks only to specialty hardware, via a serial port, and there are rarely changes to the X10 protocol that would warrant a new release. Heyu doesn’t get updated too often, but it’s not dead.

To me, the key factor is developer activity — measured not solely by commits, but by public interaction as well. Even if releases are few and far between, if the developer community actively answers questions, helps new users, and discusses the code, the project has life. Just look at Wengophone, which lost its major corporate funding at the end of 2007. Paid developers were pulled off the project, but the volunteer community continued to discuss the details and broad strokes of the application. As soon as a new corporate partner committed developer time, the dormant project sprang back to life.

Judging by that standard, four projects that I covered in 2007 have either formally or informally closed up shop — and there are half a dozen others to be worried about.

The list

In some cases, it is patently obvious when and why a project is dead. The developers behind unrarlib, which I discussed in a February compression tool roundup, publicly declared the project kaput and posted a message on the Web site informing visitors of the decision. Doesn’t get much simpler than that.

In a less extreme move, Ben Spink, developer of the contest-winning free .Mac replacement service notMac, simply decided he had insufficient time to continue work, and announced that fact. My cynical inner voice tells me this should serve as a warning for “bounty” contests — once the money is collected, there is no incentive for the bounty winner to continue working on the code. Spink did add that other interested parties are free to pick up where he left off. But that’s a truism with respect to free software projects, and one that provides little hope.

After all, the same was said of vector editor Xara Xtreme. Last summer, the company that owned the application came to an unfortunate impasse with the volunteer developer community over keeping one of the core libraries proprietary. Although someone could still come along and pick up the work where the previous participants left off, the size and complexity of the project make that unlikely. With no paid developers from the company and the volunteer community departed, the deal is in all likelihood sealed.

While these few examples are cut and dried, in many cases, there is no announcement or event by which to mark the demise of a project on the calendar; it just slowly peters out, leaving users to wonder why.

Such is often the case when the project is a one-person operation; the fewer developers, the fewer there are to spare. That problem afflicts many Firefox extensions and add-ons, like Biet-O-Zilla, an eBay bidding extension I reviewed in May. Judging by the discussion surrounding it at third-party extension Web sites, it was popular enough with users, but the developer stopped updating it, and eventually it vanished completely (site included).

When the primary developer loses interest in the code, a project is in serious trouble, but Firefox (and other Mozilla app) extensions have another disadvantage in Mozilla’s lack of proper project hosting. Throughout the Mozilla product line, the Add-ons site is marketed as the official, one-stop shopping spot for extensions — and yet it provides no resources or services for extension authors themselves: no issue tracking, no source code management, just a single XPI upload and an underpowered “commenting” system. If you want to build a Firefox extension, you’ve got to register the project elsewhere with a project hosting site, then maintain its Add-ons page in your spare time.

Not quite….

Two other projects that I wrote about in 2007 may look dead from outside, but I don’t consider them finito due to special circumstances: they have not attracted mainstream attention yet, and have the potential to spring to life when they do. David Trowbridge’s innovativelibcontrast has yet to make it into usage by other applications, but not for lack of effort on Trowbridge’s part. Aleksey Nelipa’s sketch app Gogh has always been his own hobby project, and although he hasn’t worked on it much recently, it only fails the “interaction” test because he hasn’t started a mailing list or Web forum.

The other potential problem for Gogh is its simplicity; it incorporates good ideas, but most of its potential users are graphics tablet owners who tend to prefer big, powerful alternatives like Inkscape, Krita, and the GIMP. If I were betting, I would put my money down that — like libcontrast — Gogh’s broader legacy will come from its ideas being picked up by other applications. It just hasn’t happened yet, for either project.

Cause for concern

The above projects all met the conditions for mortality I set out at the beginning of my search. There are a few others that didn’t fit the criteria, but are either dangerously close or headed in that direction. That is not a criticism of any of these projects, merely cause for concern.

The first is N.E.R.O., the artificial-intelligence-themed combat game. Look through the official forum and you would be excused for thinking that the project was abandoned. The truth is that the game has always been developed in the context of a computer science course at the University of Texas. During off-semesters, it receives little attention from the otherwise occupied students and faculty.

But the problem is that no one ever has the spare time to devote any attention to the project once they personally are finished with the class. They may fully intend to keep developing N.E.R.O. over the summer, or after graduation, but it doesn’t happen. Outsiders are interested in helping, but even though portions of the game could easily be made free software, a complete release is hindered by the project’s incorporation of the proprietary Torque engine.

I have reviewed N.E.R.O. twice. In bothcases, the project leaders insisted that they were working on cleaning up the code to release it as an open source project — and that it would happen “soon,” but nothing has changed. As much as I hate to say it, here the perfect (a polished, running, Torque-free open source N.E.R.O.) is clearly the enemy of the good (the source in whatever incomplete form in exists today), and I’m pessimistic that N.E.R.O. source code will ever see the light of day. If the related class doesn’t make it into the course catalog some semester, that could spell the end.

The second project on the edge is RAW photo editor LightZone. Last December, parent company Light Crafts stopped providing freeware Linux builds, replacing them with time-limited demos that suggested a forthcoming commercial release. That release hasn’t happened yet. Official support for the Linux betas consists only of a “here, you guys support each other” forum thread. More troubling, Light Crafts COO Scott McGregor recently announced his departure from the company via the forum. He provided no reason, but considering that his departure followed that of developer (and Linux build maintainer) Anton Kast last year, LightZone on Linux has lost two of its biggest promoters within the company.

Finally, I am not sure what to think of the WYSIWYG Web editor KompoZer. It has not made a release since 0.7.10 in September, and although some later posts to the KompoZer forum indicated that the developers were working on a 0.8 release, there hasn’t been much news from them in 2008. If KompoZer does turn out to be OK, it would still leave open the mystery surrounding a related WYSIWYG editor with a shared history. As I described it in my October review, KompoZer is descended from Nvu, which was abandoned by its original author Daniel Glazman. After he stopped Nvu development, Glazman announced that he was working on a XULRunner-based replacement, but no code has appeared.

That’s the circle of life for ya

The principle of “survival of the fittest” tells us that if a project doesn’t accumulate interest and momentum sufficient to survive, then it doesn’t deserve to. That fits in nicely with the way free software works — if users and developer stop caring about RAR support, then of course unrarlib will eventually go the way of the dinosaurs. What could be more natural?

But when I look back on the now-departed projects that I wrote about in 2007, I see other forces at work contributing to the demise of projects, such as companies that couldn’t (or wouldn’t) figure out how to relate to the volunteer army of free software developers, and programmers who coded a project for a paycheck, then dropped it to move on to the next job. These are preventable problems, for the most part. But even abandoned projects may attain an afterlife, since with open source software the work is still out there on the Internet, where someone who really needs even that obscure, long-abandoned code can make it work one way or another.