Real World = Real People

I blame Steve Lee for the fact that I'm having to write this.  Previously I wrote an account for my students about what it's like to fix a bug in an open source context.  The occasion of my post was a bug related to the use of a deprecated (and memory leaking) OS X API call in Thunderbird.  I was primarily interested in drawing attention to the way I had done the work, namely, to the way in which it had been a community effort vs. a singular idea that had lept fully born from my head.

Steve wrote a nice analysis of what I had written, and then made an interesting further observation:

I will make one point. Dave also learned  something of the kind of real world messiness and compromises that often have to be made when dealing with existing code and many complex requirements. Messiness such as complex build systems, a mixture of languages, incomplete support for platforms . In the relatively isolated academic world of the classroom you can often get by without having to consider such constraints and dubious architectural decisions such as ‘just copy the code into my file, and later, when we move to 10.5+ support, remove it’. The complexities of the real world can only be learnt by engaging with real developers on a real project. Open source projects provide an ideal place for students to learn important skills whilst contributing their energy.
Well, how right he is.  On Friday my work was approved by my reviewers (with minor corrections) and then checked-into the Thunderbird source tree.  I smiled and started my weekend.  Success.

Failure.  This morning I woke-up to find that my fix had been backed-out because it was causing our 10.4 builders to break.  The NSDockTile type I'd used for the 10.5 code paths was not defined as part of the 10.4 SDK, and without it, we can't build this code.  I made myself some coffee and pondered how to deal with this.

The first thing to note is that I had no idea how to fix it.  I had some guesses, but nothing solid.  So I did what you do when you have a problem like this; I went on irc and idly described my problem, and that I had no idea how to fix it.  Two hours later the answer came.  Ted mentioned that I could consider a dirty trick, and use the Objective-C generic type, id, instead of the specific NSDockTile.  I made the change, and did a simulated 10.4 build (I only have 10.5).  Now I have a dozen new warnings due to using a generic type, but no errors, and once again a working build!

As Steve points out, there are no easy solutions to a lot of these problems.  They are, by definition, real world problems that require real world answers.  The most important thing to note about the real world here is that it is populated with people.  To work on open source is to work in community, and to ask for and accept help at every step of the way.

Show Comments