I started a new job last week, as Technical Architect of Ubuntu. I’m thrilled to be here, I couldn’t have crafted a more perfect job if I’d written the job description myself. I’ve been reflecting this week on how I got here. Many people know me for my involvement in Parrot, Perl, or Python, but my first love in free software was Linux, specifically Debian. I was already actively involved in my local Linux user group over a decade ago, hacking and speaking, even teaching a summer class at the LUG. I became a public figure in the Perl community almost by accident (it’s a funny story involving a cruise ship, I’ll tell you sometime over beer). But, I took to the Parrot codebase so quickly precisely because it was so similar to the Linux kernel: a large, complex body of C code with subsystems for memory management, concurrency scheduling, I/O, and networking, plus a host of add-on modules. I mentored under Parrot’s founding Architect for the first few years of the project, then took on his role after he retired.
I’ve been involved in Ubuntu almost from the beginning, though not in a public way. In the training material for Canonical new hires there’s a photo of the original founding team, it was fun to see that I know most of them personally. My first UDS was in 2006, and even though I’d already been an Ubuntu user for more than a year, it was a life-changing experience. It wasn’t just about the code, though it certainly was exciting to see such enthusiastic action toward making Linux a compelling replacement for the “Big 2″. It was even more about the people, this amazing team of brilliant, wonderful humans joining together to change the world. It was something like being adopted into a new family. I’ve made it to about one UDS a year since then (I missed two in a row once, and was terribly disappointed). I’ve considered applying to Canonical multiple times over the years, but the specific roles I looked at were never quite right for me. And I was too busy getting ready to ship Parrot 1.0 and working to support my free software development habit (gotta pay the bills somehow), to do much more than packaging work and kicking in ideas at UDS and to the people I knew and talked to regularly. I’ve enjoyed watching some of those ideas come to life, even if I couldn’t be involved in the actual construction.
UDS-M this year was another life-changing experience for me, but in a different way. I was already kind of keeping an eye out for a “next thing” to do, not with any urgency, just an open mind. The Parrot project shipped 2.0 in January this year, and has moved into a stage of refinements rather than “pushing to release the first production version”. And since 1.0 last year, we’ve been moving the project more and more to distributed design involving a team of highly experienced contributors, rather than a single driving head, so it no longer consumes my every waking moment.
At the beginning of the week at UDS-M, I commented casually in an email to Mark, “These are my people and it makes me happy to be here.” And then it struck me how very true that statement was. As the week went on, I started looking for ways to get more actively involved. I talked with Kees Cook about helping on one of the security blueprints. I talked with Robert Collins and Martin Pool about helping out with Python 3.x migration for bzr. Towards the end of the week, I bumped into Robbie Williams and Rick Spencer talking about the new Technical Architect role they were planning on posting. Rick suggested I should apply for it. I sounded interesting, I mean I’m a Software Architect, that’s what I do, I even contributed to a book on the subject. But, it wasn’t until I talked to Colin Watson (who is also my Debian mentor) about the job over dinner on Friday at Ubuntu AllStars that I really decided to apply. Add on time for the job to be publicly posted, time for the interview process (where I understand many qualified candidates were discussed and considered), and time for me to wrap up my final year of chairing OSCON, and here I am.
Right at the start, I should make it clear that I am not the SABDFL. I’m here to help turn his vision into reality. That’s what architects do, translate between the potential for a building and carefully measured graphite on paper, then act as a resource for the whole crew as they work together to translate an abstract plan into hard steel, warm brick, and shining glass. I’m here to champion the community’s vision for Ubuntu, to facilitate conversations as we integrate multiple perspectives and balance multiple needs, to ask good questions that help us find better solutions. I’m here to help smooth some of the bumps in the road, because no road worth traveling is ever completely easy. I’m here to sing harmony to the SABDFL’s melody, with the whole choir, to soften the lows and brighten the highs. If you want a name (or just have a fondness for recursive acronyms like I do), you might call me the SABTAFL, that is, “SABDFL Appointed Benevolent Technical Architect For a-Long-time-but-not-necessarily-Life”. But, “allison” is a perfectly good name, I don’t need any other.
To give credit where credit is due, there have been 4 great influences on my career over the years, mentors, friends, people who believed in me, encouraged me to dream big dreams and try big things, who taught me that I’m better, smarter, wiser, more dynamic, and resilient than I ever imagined. In alphabetical order: Damian Conway, Greg Kroah-Hartman, Mark Shuttleworth, and Nathan Torkington. Thanks guys, I wouldn’t be here without you!
(Appropriately, this post was written on the machine that was my very first Ubuntu desktop. Well, I’ve upgraded pretty much the whole guts of the thing a few pieces at a time over the years, and it currently runs Lucid. But at some deep level, if computers have something like a soul, it’s the same machine.)