What we do
Written by Barry Warsaw in technology on Thu 09 September 2010. Tags: canonical, python, ubuntu,
My friends and family often ask me what I do at my job. It's easy to understand when my one brother says he's a tax accountant, but not so easy to explain the complex world of open source software development I live in. Sometimes I say something to the effect: well, you know what Windows is, and you know what the Mac is right? We're building a third alternative called Ubuntu that is free, Linux-based and in most cases, much better. Mention that you won't get viruses and it can easily breathe new life into that old slow PC you shudder to turn on, and people at least nod their heads enthusiastically, even if they don't fully get it.
I've been incredibly fortunate in my professional career, to have been able to share the software I write with the world for almost 30 years. I started working for a very cool research lab with the US Federal government while still in high school. We had a UUCP connection and were on the early Arpanet, and because we were funded by the US taxpayer, our software was not subject to copyright. This meant that we could share our code with other people on Usenet and elsewhere, collaborate with them, accept their suggestions and improvements, and hopefully make their lives a little better, just as others around the world did for us. It was free and open source software before such terms were coined.
I've never had a "real job" in the sense of slaving away in a windowless cube writing solely proprietary software that would never see the light of day. Even the closed source shops I've worked at have been invested somehow in free software, and with varying degrees of persuasion, have both benefited from and contributed to the free and open source ecosystem. Thus, in many ways, my current position at Canonical feels like the perfect fit and ultimate destination for my background, skills, and passion. Canonical is open source to its core. Its central mission, as articulated by our founder Mark Shuttleworth is "to bring free software to the widest possible audience, powered by services rather than licenses, in tune with a world that was moving to services as the core economic model of a digital world."
To me, the free and open source ethos goes much deeper than just the software we write. It's about collaboration, community, sharing, learning, teaching, and having a truly positive impact on the world. It's about empowering individuals to realize their full potential, to give them the opportunity to build a merit based reputation, to carve out their own areas of interest and expertise, and relate that to the larger society, to know that they make a difference, and that their opinions and contributions matter. Open source is about having the courage of your convictions, but embracing humility to admit when you're wrong and someone else has a better idea. To encourage and actively seek out consensus, but also to cultivate a thoughtful and compassionate process for making the hard decisions when consensus can't be reached. It's about spreading enthusiasm and rallying others to your side sometimes, and at other times humbly and joyfully embracing other points of view.
I could go on with all the mushy goodness, but let's look at a few areas where the work I do for Canonical directly contributes to the broader free and open source ecosystem.
Python
I've been a core Python developer since about 1995, and have served several times as release manager for major new versions. As part of my job on the Ubuntu Platform Foundations team, I'm keenly concerned with issues involving Python's deployment on Ubuntu and its upstream ancestor Debian. One of the distinction between Ubuntu/Debian and other Linux distributions is that Ubuntu/Debian often provides more than one Python version in a release. For example, in Natty Narwhal, it's likely that Ubuntu will officially support Python 2.6, 2.7, 3.1, and 3.2. The reason for this is that it does take some porting effort for applications to upgrade their version of Python, and this eases the transition for those applications. But it's complicated by the fact that upstream Python doesn't really support multiple installed versions out of the box. Recent work I've done on PEP 3147 and PEP 3149 improve this situation greatly, by allowing multiple versions of Python to more peacefully coexist. As is typical, I try to push my changes needed for the Ubuntu platform as far upstream as possible, because that benefits the most users of the open source software. In addition, a huge number of users get their Python interpreter from their operating system vendor (this is at least the case on all Linux variants as well as Mac OS X), so work done to improve the Python experience on Ubuntu directly and positively impacts users on Debian and other Linux distributions, as well as the general Python community at large.
GNU Mailman and Launchpad
I've been the lead developer for GNU Mailman since the late 90's, and I've been overwhelmed to see it become the predominant free software mailing list manager. When I was working on the Launchpad team at Canonical, my primary responsibility for the first few years was to integrate mailing lists with Launchpad, and of course Mailman was the obvious choice for underlying technology. At first, Launchpad was closed source software, but the intent was always to release it as open source, and it was with much joy that we saw Launchpad released under a free software license in the summer of 2009. It was not a design goal of the original Mailman software to be easily integrated with external systems, so a good bit of the work I did on Launchpad at the time directly benefited upstream Mailman users by making it easier for ourselves, and others, to do this type of integration. Now that I'm no longer on the Launchpad team, I work on Mailman 3 exclusively in my spare time. My experiences with that integration effort had a direct influence on the architecture of Mailman 3, and I have a goal of swapping the current Mailman 2.1 technology in Launchpad with Mailman 3. All the relevant work to do this is fed back into the upstream project, to the benefit of the larger free software community, since many other people also want a better way to integrate mailing list functionality with their web sites.
My Mailman and Launchpad work also saw many spin-offs of helpful utilities and libraries which can be used by the much wider community of open source developers. The lazr suite of Python libraries has applicability outside Launchpad and I use many of them in my extra-curricular projects, evangelizing them along the way. Many GNU Mailman utilities have also been spun off into their own libraries, and these are now or will soon be available on the Debian and Ubuntu platforms, just as they are now available on the Python Package Index. The work I'm doing, along with my Canonical and Ubuntu colleagues to reduce the barriers to opportunistic participation in projects is key to this ecosystem. We're making it much easier for others to find and participate in the projects that interest them, at whatever level they choose.
UDD
Along those lines, as part of my work on Ubuntu Platform Foundations, I've become quite enthusiastic about technology we're calling Ubuntu Distributed Development. When I moved to the Platform team, I knew next to nothing about the art of packaging, which is how upstream projects are turned into installable and manageable chunks that people can put on their Ubuntu (and Debian) machines. Packaging has a rich tradition, but it's pretty esoteric and to most people who don't package, it's a black art. Even now that I know how to package software, I still think it's way too magical. UDD is a set of tools and procedures that aim to bring packaging to the masses, by reducing the magic and exposing the important parts in much more familiar tools. Every open source developer sooner or later (hopefully much sooner!) learns how to use a revision control system. Such systems allow developers to manage their code in a principled and rigorous way, by keeping detailed records about the changes to their software over time. Revision control systems are an absolutely fundamental and required tool in the open source developer's toolbox.
The Bazaar distributed revision control system was written by Canonical, but is now a community-driven free software project. It's ease of use, superior quality, and high degree of flexibility and extensibility make it a very attractive choice for projects looking to use the next generation in revision control systems. Bazaar also integrates very nicely with Launchpad. UDD are a set of extensions to bring packaging to the Bazaar suite, so that the very tool that upstream software developers use dozens of times a day, are also the tools they will use to create packages for making their software available to the mass of Ubuntu users. I've been using Bazaar for years now, and have written a few plugins and patches. I'll soon be helping to lead an effort to improve the UDD workflows and more widely expose the benefits of UDD to more and more Ubuntu developers.
Platform
I love my work on Platform because it allows me to have a small hand in lots of different upstream free and open source projects. After so many years of hacking on such projects of all different stripes, I'm fairly good at looking at and understanding good open source code, debugging and fixing problems, and interacting with the upstream communities to get those patches pushed higher up the stack. Bug trackers, mailing lists, IRC, and revision control systems are the core technologies needed for this work, and I'm comfortable interacting on all of them. Part of our job as Platform developers is, in my opinion, to engage the upstream projects, so that the fixes and changes we need to make in order to provide the absolute best experience to Ubuntu users, are available even to those folks who don't get their software from Ubuntu. This to me is the the true meaning of being a free and open source developer for a company whose mission is to make free and open source available to the mass of computer users. Our aim is not just to make software that competes on price, or liberty, but also on quality and "sex appeal" - we want our users to flock to Ubuntu not just because it costs nothing, but because it's so compelling that you can't help but love it.