Taking it over the line

One of the central defining characteristics of software, any software, is that it is unfinished.  This is a point most easily understood in the context of open source software, where being half-dressed is easier to see because the curtains aren't drawn.  It's not a criticism.  It's what software is.

This is what software is, but what does it mean for the developer of that software?  It means angst and worry and fear.  While we speak of products 'shipping,' software remains what was done up to now.  It looks at you through the round version number like a face seen in the mirror, the face just before and just after sleep.

While software remains unfinished, the way is marked out clearly, much as it was for Sisyphus.  You are always working to get over the line--that arbitrary but agreed upon point at which you can start the process again.  Getting something "over the line" is a very difficult thing.  People like to say that most of the work comes in the final 10%-20% of the work.  This past week I've spent time on both sides of the line, and it has been an interesting chance to look at myself in the mirror.

First, I got asked to help finish a long-standing Thunderbird-Mac bug: Bug 290057 - "Thunderbird should integrate with the Spotlight Search."  For whatever reason, I've been drawn lately to Mac-facing Mozilla/Thunderbird bugs.  I've learned a great deal about the Mac from the standpoint of a developer, and it's given me a chance to poke around in different corners of the Mozilla code.  I've got a few spin-off bugs to finish tomorrow or the next day, and then it's pretty much done.

When I first looked at the bug, I was tempted to say 'no thanks.'  There are a mass of attachments and comments, and it's not clear what has and hasn't landed.  There are blog posts of people writing hacks to make it sort of work, and a general feeling out there that it should but doesn't quite.  The first thing I did when I opened it and got overwhelmed was to walk away, but leave it open in a tab.  Over the next couple of days, I read the bug, and started to understand what it was all about.  Then I started to piece together what was and wasn't in the tree, what was and wasn't working.  Before long my research had turned into patches, and eventually a working feature.  This was followed by new discoveries about issues that hadn't been dealt with before, and more patches.  I've learned so much about Spotlight, command line handling on Mac with Mozilla, and the build system, it's been well worth the effort.

In the middle of all this work, I saw an email come in between a dozen bugmails.  It's subject was a familiar one, someone wanting to know about VncSharp, my .NET implementation of the client RFB protocol.  I get at least 3 of these a week from people wanting help writing password delegates or who want to know if you can make it do X.  This mail was very different though: instead of asking for help, here was someone with a patch to finally implement the missing pieces of my library!  I wrote the code 4 years ago, and have been so busy with other projects, that I've never had the time, or to be honest, the interest, to finish it.  I'd always meant to someday go back and implement ZRLE, which would mean VncSharp 1.0 vs. the current 0.9.  Now it's done, and after I review it I'll do that final release.

It's hard to get software over the line.  You almost can't do it alone.  You need help to do it.  You need to help people do it.  Standing with one foot on both sides of the line this week has been very rewarding and educational.  I recommend it if for no other reason than this is where people gather, and it's good to be together.