Unusable Open Source

Still unemployed, I have begun working on a new web site that will at least enhance my resume if it doesn’t make me any money. Since I’ve got no boss telling me what to do, I can use the latest and greatest open source tools. This site will be up in no time at all because no wheels will have to be reinvented. If only that where the case. As I really started to get my hands dirty, I began to realize just how many of the great tools out there are in an unusable state.

The first decision I made was to build the site with Django. It has been my web framework of choice for many months now. I used it to build the new frontrowcrew.com, and I’m very satisfied. The thing is, Django wasn’t always usable.

Some months ago Django 1.0 was not released yet. Yet, when you went to the Django web site and community, it seemed as if nobody was using 0.96, the stable version. When you go to the Django documentation online, it defaults to showing you the documentation for the version currently in development, rather than the latest stable version.

If at that point in time you wanted to start a new project with Django, you had a tough decision to make. Do you start with 0.96 and stick with it? Do you start with 0.96 and go through the hassle of porting over to 1.0 later? Do you deal with the hassle of building on the development version and build your way up to the actual release? Do you just not start your project and wait for the release? This is a difficult decision to make, and there’s an easy answer I left out. Maybe you just shouldn’t use Django, and go find something else that isn’t in a state of flux?

Happily, Django 1.0 has been released now, and this is no longer a problem. Well, at least it isn’t a problem for Django itself, but it is a problem for many things built around Django. Take Pinax for example. Pinax is a project that builds on top of Django. They implemented a lot of solutions to things that are common to all web sites, such as registration, password management, blogging, friend, and tagging. My new site idea will need some of those things, and I want to reinvent as few wheels as possible, so Pinax was very appealing to me.

The problem is that Pinax is currently in the state of flux that Django used to be in. There are sites out there which are built using Pinax, so it can be done. However, the current stable version seems to have been largely abandoned by the community. In my limited experience, the development version appears to be far superior, but it’s still in development. Worse, as a newcomer to the Pinax project, their documentation is very unreliable. I find myself asking those same questions all over again. Maybe it’s easier to reinvent those wheels than it is to deal with the hassle of closely tracking someone else’s project?

Let’s say I just want to add tagging to my Django application. Why should I bother with Pinax, I can juse use django-tagging. It has a stable version 0.2 that came out, over a year ago? The site says that version 0.3 is targeting Django 1.0. In other words, it’s completely useless. I’m not going to use Django 0.96 just so that I can use the stable version of django-tagging. I’m also not going to go through the hassle of using an unstable version of django-tagging 0.3 from their SVN trunk. Since their project was dependent on Django, it was their job to follow Django’s SVN trunk and have django-tagging compatible with Django 1.0 the day that Django 1.0 was released, or very soon after. Their failure to do so has made their project useless.

Just for kicks, let me talk about Laconica. Laconica is an open micro-blogging platform. Think of it as a Twitter clone, but with a different, and better, system architecture. I’ve been running an installation of it for our podcast community, and it’s very nice for the users.

The problem with Laconica is that it’s a nightmare on the back-end. The project has noble goals. They want it to be as easy to install, upgrade, and administer as WordPress. And while they have the first verison of a web installer, the underlying architecture is frighteningly bad. You have to run a set of daemons to handle the queueing of in and outbound messages. That kind of design is going in the exact opposite direction of making things easy. What’s worse is that in the latest version they added even more daemons, and two of them decided to eat up all my CPU. Because it’s under constant development, there are frequent updates with awesome and significant improvements. That’s very good, but the upgrading process is nightmarishly difficult. I want to keep the Laconica server running for the users who enjoy it. It’s just that the administration is far more work than it’s worth.

Here’s the one piece of advice I can give to open source project managers out there. Make sure to maintain a degree of separation between your development community and your user community. A very small percentage of the people who want to use your project actually want to get involved in working on the project itself.

My web site is going to use Linux, Ubuntu, Apache, Python, Django, numerous Python modules, CouchDB, Postgres, memcached, and many other open source projects. If I’m working to build the site, I need all those things to “just work.” I don’t have time to get heavily involved in the communities for any of them. Any effort I have to spend tracking development versions, or dealing with bugs in someone elses code, brings me closer to the point where I would have been better of building it myself.

Actually, let me offer one more piece of advice. Lots of small easy upgrades are better than a few big ones. The difference between Pinax’s stable and development versions is enormous. What if instead of having that huge gap, they had instead made many small upgrades to the stable version over time? The gap between stable and development would be much smaller. Using the stable version wouldn’t be such a bad idea after all, and upgrading to newer stable versions wouldn’t be as big  a deal.

I’m a programmer trying to do a project on my own. I’m smart and full of enthusiasm for the latest and greatest open source goodness. I want to do everything the right way. I want to utilize as much open source code as possible, so that I only have to write the code specific to my project. Sadly, I am unable to do that if the open source projects are in a state of flux, or can’t be relied upon. When reusing code requires just as much effort as rewriting code, you know something is wrong.

This entry was posted in Technology and tagged . Bookmark the permalink.