I've spent my entire career contributing to the Free software movement, as instigated by the Free Software Foundation.

By this point it's clear that open source practices are the best way to develop programmers' tools. I expect flourishing ghettos to appear in other areas soon — music, or mapmaking, say — buoyed by the same principles.

What I like the most about the Free software movement is that people can freely choose whether to participate. It's a voluntary revolution.

Jason Orendorff, Nora Tindall, and I are the authors of Programming Rust, a book about the Rust programming language, published by O'Reilly. (I would like it to become known as “The Crab Book”.)

Before I learned Rust, I honestly wasn't expecting much progress in systems programming languages, as C and C++ have explored their design space pretty thoroughly. But Rust makes some very surprising compromises, in return for important improvements in safety and concurrency. If you are a C or C++ programmer and you take the time to learn Rust, I think you will be quite surprised at how much trouble undefined behavior causes in C and C++. It's something very hard to appreciate without Rust as a counterexample.

But beyond safety, I simply find Rust pleasant to use. The interaction of traits and generics lets me be precise without overspecifying. Cargo and the crate ecosystem bring modern dependency handling to systems programming. The integrated documentation and testing are great. The Rust Language Server gives me pretty great 'jump-to-definition' functionality in Emacs, just like Visual Studio programmers have had for decades, ahem. Systems programmers can have nice things.

I work for the Mozilla Corporation on SpiderMonkey, Mozilla's JavaScript engine. In particular, I designed the new Debugger API, which makes it easy to write JavaScript code that observes other JavaScript code's execution; and the debugging protocol, which lets a debugger debug a debuggee in a different processor, or possibly on an entirely different machine. The Debugger API and the protocol are now in use in Firefox's developer tools.

At FOSDEM 2007 I gave a presentation on an implementation of GDB tracepoints for the Linux kernel, which allows GDB to debug the kernel it's running under. A tarball and slides are available on the project's Trac wiki.

For many years, I worked on the Project GNU's debugger, binutils, and compiler, for Red Hat and CodeSourcery. I wrote GDB's C preprocessor macro support, and implemented the bytecode compiler for tracepoints.

On the side, I'm working on tracepoint debugging for the Linux kernel. I have a Trac instance set up for this work.

I'm one of the original designers of Subversion, a revision control system meant to replace CVS. I did the initial design of the repository, but many others have refined and improved what I did. It's a simple and effective application of functional data structures to a real-world problem.

I think Subversion can take some credit for inspiring the current blossoming of Free version control systems: Darcs, Arch, Monotone, and others. A lot of people were very excited when the Subversion project first started, but there was also quite a bit of disappointment and criticism when running code was first released. I don't think this is because there is anything wrong with Subversion. Rather, I think people had projected their personal ideas about how version control should work onto Subversion; no single design could have made them all happy. But that disappointment seems to have inspired a lot of those people to go off and Do It Right (from their point of view). I think this is awesome; I'd love to see what people end up settling on.

In particular, I've become a big fan of Mercurial. It's quick, comfortable, and consistent. I've used it to manage work-in-progress for GDB, and we're using it at Mozilla. Occasionally it doesn't work the way I expected it to, but after some thought I usually find that Mercurial's behavior actually makes more sense anyway.

For several years I was the lead maintainer of Guile, Project GNU's extension language library. That was a real privilege, because a lot of amazingly talented people — Mikael Djurfeldt, Marius Vollmer, Greg Badros, and Maciej Stachowiak come to mind, but I know I'm forgetting some — showed up from nowhere and volunteered to work on it. The project was a friendly place, too. I'd feel very lucky to work with such a group again.

I don't think Guile has lived up to its potential, though. Even Emacs is still using its own lisp interpreter. I'm honestly not sure what the issues are. Personally, I don't like the code base much; it's based on Aubrey Jaffer's SCM, and I think Aubrey is definitely one of those lone genius types; his code isn't easy to work with. But is that really limiting Guile? I don't know.

For a few years, I was the maintainer of Project GNU's Emacs text editor. I released version 19 of Emacs.

Together with Karl Fogel, I'm one of the founding members of Red Bean Software, the world's most successful anti-brand. Karl and I started Red Bean with the intention of ensuring that it would never have any monetary value, so that we'd never be motivated to sell it, allowing it to act as a life-long stable personal email address for both of us. There are now many more people involved.

email:

jimb@red-bean.com