(2) Thu Sep 16 2010 21:07 What I Do: When I meet someone and they ask what I "do", I gauge their level of tech knowledge to determine how much detail to go into. Have they heard of Ubuntu? (I work for Canonical.) Have they heard of Linux? (I work for a company that puts out a Linux distribution.) Maybe at they've used a computer? (I write software.) I do this rather than just going straight to "I write software" (from which I've only had to back off once), because when, as sometimes happens, I'm asked this question by an Ubuntu user, the question of "what do you do" turns from a social nicety into a real conversation. And it's really nice to get appreciation from someone just because of where you work.
This week, Canonical employees are writing about how their day jobs interact with the open source community. For some people, like the desktop team, the connection is pretty obvious. For me it's a little more subtle. I give open source developers control over their accumulated software artifacts, and I give them back some time that they'd otherwise spend doing boring things.
The projects I work on are open source, but for the most part that just means I'm doing my work in public. My main project, lazr.restful, is used a fair amount within Canonical, but not much outside of it. So saying "hey, I write open source software" is cheating. What's really going on?
Launchpad is going on. Launchpad is a website for doing software development. When you work on a project, you're generating document-type artifacts (stuff that's part of your completed project) and process-type artifacts (stuff detailing the actions you took to get to the completed project). Document-type artifacts need to be version-controlled, and process-type artifacts need to be shepherded through a workflow.
Such sites are nothing new. For almost my whole showing-up-for-work-every-day career, I've been working on one of these sites: before Canonical, it was CollabNet. What's new about my work on Launchpad is that with the web service I give you (the developers using the site) direct access to your process-type artifacts. This benefits you in two ways:
Not all the code you write goes into your project. Some of it is utility code you use to maintain the project itself.
For instance, I wrote a little shell script to run whenever I do a new release of lazr.restful. Make a tarball, sign it with my GPG key, create a new release series on Launchpad (if appropriate), upload the tarball and GPG key as a release for that series, upload the release to PyPI, use
bzr tagto tag the current revision with the release number. All I have to do is type my GPG passphrase.
Well, you know how to tarball and GPG-sign with shell commands, and
bzr tagis a shell command, but PyPI and launchpad are websites, and to tell them about a new release requires a web service client. The
setup.pyscript is the web service client for PyPI, and the web service client for Launchpad is
launchpadlib, the code I wrote. If Launchpad's web service didn't publish release series and release files as resources, I'd have to do that step by hand.
And just as there's code you write but don't release, there's code you never write at all—you execute it yourself, over and over and over, using a web browser. You're pushing process-type artifacts—bugs, questions, code reviews—through some kind of workflow.
A tool can provide the framework for a workflow, but the work won't flow on its own. Someone has to operate the pump, and that can get boring. Some rules are easy to describe algorithmically but time-consuming to execute. Like "If a commit message mentions that this commit fixes a bug, go ahead and mark the bug fixed." Or "When making a new milestone, move in all the bugs that didn't get addressed in the last milestone."
As the developers of the Launchpad website, we could force everyone into a specific workflow and optimize for that workflow. Or we could try to create a tool that's so general you could use the website to define arbitrary rules like the commit-message rule. Or, we can publish the software development artifacts as HTTP resources and get out of the way.
When I think about the Launchpad web service, I mostly think about allowing developers to scratch their own itches and automate the automatible parts of their jobs.
(BTW, the Launchpad portion of my release script is in
This is the code that gets published—applications where communication with Launchpad is a feature. For instance, if an application crashes while you're using the Ubuntu desktop, Apport pops up and gives you a chance to report a bug against that application. Apport reports those bugs through the Launchpad web service. There are also programs like Ground Control, which let you manage your software development artifacts from your desktop instead of your web browser. These all bring Launchpad to your desktop.
You're just using these applications, you didn't write them yourself, so you don't know that the Launchpad web service is involved at all. But all these products—better bug reports, easier administration—feed data and saved time back into the open source ecosystem.
And for me it is fundamentally about saving people time. There's a story from the development of the Macintosh that has stuck with me for years. Steve Jobs is doing what he does best: berating developers. In this case he's telling them to make the boot time faster.
Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?
I don't have fifty million users, but I'm also not in the business of saving each of my users ten seconds. I want to save you three hours, or a week would be better. That's why I do what I do—you can see this thread running through every job I've had, both my nonfiction books, and my most successful open source projects. Check the intro to Ruby Cookbook: I just realized I wrote the same damn thing in there.
This book is meant to save you time. Time, as they say, is money, but a span of time is also a piece of your life. Our lives are better spent creating new things than fighting our own errors, or trying to solve problems that have already been solved. We present this book in the hope that the time it saves, distributed across all its readers, will greatly outweigh the time we spent creating it.
Beautiful Soup is showing its age, but I don't think it's totally crazy to estimate that it's saved thirty or forty person-years since 2004. Someday I'll die, and I don't want the main thing people say about me to be "The time he saved other people was a greater-than-unity multiple of his own lifespan." But that is an important part of my personal philosophy. It's Tim O'Reilly's "Create more value than you capture" applied to time.