1000 words. On a separate sheet, show us and/or tell us about something that you have created. This can be, for example, a design, a device, an object, an idea or concept, a piece of music or art.

Half a year ago, I changed the world for the very slightly better.

On a computer running Windows or Mac OS, when you find a program you want to install, it comes with an easy double-clickable installer. Since the Windows programmer knows his software will run on a Pentium-family processor and can rely on the presence of the standard Windows runtime libraries, he can easily translate his code — once — into a form that will be sure to run on any PC. Due to the zoo of hardware and software variations across Unix systems, however, the Unix programmer typically distributes only the source code and (if you're lucky!) a decent set of instructions. Compiling and installing the software is left to the would-be user. This can be complicated and annoying even for long-time Unix users who've used it before and know they want it; for novices, or for anyone simply curious to try something new, it's often a barrier not worth the effort to overcome.

There's a family of solutions to this class of problem, called “packaging systems.” One patient soul endures this arduous process for a given program, encapsulates its installation instructions in a standard way, and contributes this “package” to a central, public repository so that everyone else can repeat the installation with a single command. In my role as a NetBSD developer, I primarily work on our packaging system, called “pkgsrc”, both in its infrastructure and as a maintainer responsible for individual packages.

One recent packaging experience stands out in my mind as a thoroughly fulfilling multidisciplinary effort. My favorite software for running an email server, called “qmail”, is somewhat unconventional in its installation and operation. It's also a lightning rod for programmer opinion, due to its unconventional attributes and also its iconoclastic and controversial author. We had a package for qmail, and it worked at a basic level, but it was incomplete and unpolished in several ways that irked me. In the open source world, people tend to solve the problems that irk them, and this was no different. I'd creatively addressed several of the package's shortcomings before I realized that due to the nature of the technical problems, even if I solved all of them, I couldn't publish my updates until I had the cooperation of a handful of people, some of them known to be uncooperative. As someone who'd recently become a manager after doing several years of technical work, my face broke out in a wide grin. This was a challenge I was newly ready and willing to meet!

The first problem I fixed was that qmail installed to an odd place on the disk. The qmail documentation insisted that it stay that way, but pkgsrc has stringent conventions. Using symbolic links (similar to Windows shortcuts), I arranged for qmail to install to a more typical place while still being reachable from the default location. The catch: qmail installed some files with the same names as files installed by a few other packages, which was a problem now that qmail installed to the same place as other packages. The usual solution is to mark such packages as conflicting with each other, preventing them from being installed simultaneously. However, it was all e-mail software that worked very nicely together. If at all possible, I wanted to reconcile the differences.

Since qmail's licensing terms prevent distribution of modified versions, I needed to modify the other packages instead. I couldn't just go and do that, though: I needed to persuade those packages' maintainers to accommodate. Two of them were nice and reasonable people who'd be glad to oblige; I happened to know that the third had a short fuse and hated (truly and deeply) qmail. So I asked the other two first, got their approval, made the tiny changes to their packages, and only then told the third fellow how far I'd gotten and what I was looking to accomplish. Initially reluctant, he acquiesced when I came up with a creative technical compromise to minimize the changes to his package.

I breathed a deep sigh of relief. There was no longer anything preventing me from publishing my work or from having it interoperate as well as possible with other email-related packages.

When it was of sufficient quality, I published, then asked the members of the qmail mailing list for feedback. Knowing that many of the old-timers had short fuses too and strongly disliked automated packages, I made sure to indicate my good intentions, my understanding of the reasons for their dislike, and my efforts thus far to address those concerns. One respected list member initially suggested I remove the package altogether because it was a mix of standard practice and my own customizations, impossible for them to support. I found a way to move the customizations to a separate package, clearly mark them as such, and request that users ask me for help before asking the list. This list member then gave what amounted to a public seal of approval, or as close to it as he'd ever give a package. I knew I'd won him over when he privately asked me to be responsible for the pkgsrc packages of his own software! (I accepted, of course, and have maintained them since.)

All told, I spent most of two months' evenings and weekends on this project. Our qmail package now works fully as one would expect. It's tremendously satisfying knowing that all the hard work is done, the hard problems are solved well, the hard people are on my side, and anyone can benefit from the result. Since it's so easy to install, I use qmail on all my Unix machines, even if they're not high-volume mail servers, and recommend it without reservation to anyone who wants to run a mail server.

Having done all this, when I want to make some changes to the qmail package, they're likely to be non-controversial. When the subject is qmail, that's really saying something!