Canonical has encouraged us employees to blog about the work we do on open source. I intended to include these comments as part of the previous post, but that one was too long already.
Open source has been a huge part of my life for many years now. A friend once suggested I commission a song cycle about it, but I haven't been inspired in that particular direction yet. Reflecting back on my open source participation is interesting. I'll start with...
Launchpad
I'm one of the team leads on the Launchpad project. Launchpad's mission to connect open-source software developers within and between projects, and with Ubuntu packagers and users, is an amazing goal. Pragmatically, part of the goal is to help make Ubuntu the best Linux distribution available, and even the best general operating system available. That's a business goal. Beyond that, though, the engineers and managers behind Launchpad truly want it to be a part of improving the entire environment of open source. It's a huge, ambitious effort, and I'm proud to be a part of it.
Since I'm a manager at Launchpad, I have people to point to also.
- Leonard Richardson has already spoken for himself on his blog.
- Benji York doesn't have anything up on his blog yet as of this writing, but in addition to Launchpad, he has a long history of contributing to open source software. I think that Manuel and zope.testbrowser are highlights.
- As part of the QA team, Diogo Matsubara works on analysing the "oops" reports (error logs from the Launchpad application), bringing the prominent ones to the engineers' attention. In the analysis work, sometimes Matsubara suggests ways to fix the bug or finds the root cause, saving the LP engineers time. To accomplish that analysis, Matsubara maintains and improves the Oops Tools, a soon-to-be-open-sourced Django application that helps summarize the oops reports. Matsubara has also been working on improving the testability of Launchpad API clients. The first mission was to convert the Apport tests to avoid screen scraping and use launchpadlib. In a related effort, he's working on defining a API SLA, using the Apport work as the initial test case. Finally, Matsubara helps with process changes to make the Launchpad development easier, more fun and faster. He helped design and hack on the changes to make the recent "merge workflow" process plan work and rock for the LP team.
- Ursula Junque is a very valuable QA engineer for the Launchpad project who has initiated and contributed to many different parts of Launchpad. If she gives me a nice summary like Diogo's I will post it here. :-)
- Stuart Bishop, Launchpad's database administrator, is crucial for keeping Launchpad running smoothly. Beyond that, he has produced several open source projects. Perhaps his biggest contribution is his own timezone library, pytz, which to my knowledge is the standard Python library for this task.
- Maris Fogels hasn't posted anything yet either, but I know he has contributed to Windmill and done some great work on Launchpad's open source libraries.
Speaking of Launchpad's open source libraries, I should mention them too. None of them are mine, but I'm not sure anyone else will mention them all. If you head over to the LAZR project, you'll see many. I've heard mention of a few people finding uses for them, and I hope many more will too!
Zope
The Zope project was the biggest thing that brought me into the world of open source, and I learned a huge amount from it. It's been a big part of my life, and I wouldn't be the same engineer, or even the same person, without it. I think the changes that are happening in the Zope community that I talked about in the previous post are important and good, even if they are a bit painful to see sometimes.
I've contributed a lot to the Zope 3 project, and to the ZODB. Some of the projects I've done that are reasonably popular are zope.copy (over 25000 downloads, and actually useful in pure Python with only a dependency on zope.interface), zc.queue (over 19000 downloads), zc.relation (over 4000), zc.blist (890 downloads; heh, maybe I should move it out of "beta"), zc.async (only 355, but I know some use it heavily), and zc.catalog (meh, 267; I thought it was bigger than that). I have other, older and/or smaller ones too.
I've also contributed to the core projects, like ZODB, over the years as well.
Moreover, often while working on Zope projects, I've also made several other Python contributions. I'll mention those next.
Other projects
I just added the ability to use system Python packages with Buildout. That's a big deal for some.
I added the ability to have "latent slaves" to Buildbot. This means that, for instance, buildbot can start a slave on EC2 on demand when it needs to run a test. Hudson can do that now too, but at the time I added it, it was new, I think.
I did a bit of work on mechanize. The biggest job was teaching it to understand form labels, which made zope.testbrowser tests much more readable and usable.
I tweaked some table generation code in ReportLab.
It is fun to believe that I've contributed a decent amount to the world, and even (usually) had jobs while doing it.
Related work
Finally, since I'm here at a conference, I can't help but reminded that conferences--particularly presenting at conferences--can be very hard work too. I've presented several times (OSCON and DZUG most recently), and always about open source. I've also done crazy stuff in the past like writing a Zope 3 newsletter to let people in on all the changes when it was first being designed, and other promotional work for open source efforts.
In conclusion, though I don't share some of the more extreme opinions that some open source advocates espouse, it is a huge part of my life, and has been so for years. I hope I can keep working with and on it throughout the rest of my career. Maybe I'll even have the energy, time, and interest to work on it when I retire. :-)
1 comment:
Hey, good to see you back posting! It's interesting to see links to projects you've worked on all in one place.
Post a Comment