(2) Thu Sep 16 2010 21:07What 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:

Automation

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 tag to 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.py script 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
lp:launchpadlib/contrib/upload_release_tarball.py.)

Integration

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.