About fifty million years ago, I encountered a minor bug in the OpenOffice word processor. It was an easy fix, a menu layout problem or something like that, so I thought I’d have a go at patching it. Of course, the first step would be to build the latest development version of the code and see if the bug was still present.

Well, I got stopped on that step. I spent an entire day trying to build OpenOffice, and didn’t succeed. I don’t think I even came close, though it was hard to tell. I eventually concluded that to be an OpenOffice developer, you’d need to first get a Ph.D. in building OpenOffice, and gave up in frustration. It brought home to me the importance of making software easy for developers to build — especially in open source software, where you depend on developers who bring their own energy and who will quickly take that energy elsewhere if it is not rewarded.

Years later, the OpenOffice project forked — well, the actual story is a bit more complicated than that, but basically today there is LibreOffice and Apache OpenOffice. Both are active open source projects, and it’s fair to think of LibreOffice as one of two equally legitimate inheritors of the old OpenOffice mantle in the sense of development continuity. (Do search://apache openoffice libreoffice “document foundation”/ for the detailed story.)

I happened to be talking to some of the LibreOffice developers recently, and related my build experience from years ago, and how it had turned me off from ever considering OpenOffice development again, and from even considering LibreOffice development after the fork happened. The whole thing had left me scarred: buildability was such an obvious non-priority then that I didn’t see how a project could possibly ever get from there to something a normal mortal might build in finite time.

Wait, it’s gotten better, they said.

I expressed skepticism, but they swore it was true. Really?, I said. Okay, I’ll start from the top of the LibreOffice.org home page and see if I can find my way to useable build instructions, right now, right here, while we’re on the phone.

And you know what? They were right!

     $ sudo apt-get update
     $ sudo apt-get build-dep libreoffice
     $ git clone git://anongit.freedesktop.org/libreoffice/core libreoffice
     $ cd libreoffice
     $ ./autogen.sh
     $ make

The whole thing built. Without errors. I had working libreoffice debug binaries in six easy, well-documented steps.

That was amazing — it changed my mind about how much a project can improve its build experience if the developers really decide to prioritize it. (Disclaimer: I haven’t tried the same with Apache OpenOffice; it might well be equally easy.)

They asked me if as penance I’d fix another minor bug, since I wasn’t able to fix that menu bug all those years ago, and offered bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1141106 as the victim. This seemed like a completely fair request; I didn’t make any promises but I said I’d take a look. Sadly, I have to admit that I’m not going to fix it any time soon, only due to other commitments. It’s not a hard fix in theory, but verifying that it works everywhere could take some back-and-forth with various bug reporters and testers, since it’s a modification to run-time shell scripts, and right now I need to ruthlessly cut down on small-scale random commitments.

So as an apology for not fixing that bug, I wrote this blog post. Kudos to the LibreOffice team for having given such a complex piece of software such an easy build process. Although by not fixing bug 1141106 I guess I’m contradicting my own claim, still, I think that being so conveniently buildable must be a major ingredient in getting developers in the door, and that this pays off for the project in the long run.