Taxi Cab Deathmatch
One of the fun aspects of my job has been the opportunity to travel and see the world. In the last few years I have had the chance to visit some stunning places – Brazil, Argentina, Turkey, Australia, Czech Republic, Portugal, USA, Spain, Germany, Belgium, Ireland and various other places. Of course there are many differences between all of these places – the sights, the sounds, the culture, the religion, the people, the food, the booze, the music, the weather etc, but there is one critical cultural variance that always strikes me when I travel – taxi cabs.
They vary on two critical levels – (1) how chatty and worldly cabbys are, and (2) how much they like to gently teeter their passengers on the edge of death.
So, first up it is how chatty a taxi driver is. Am I the only person who has noticed that particularly in London and the US (notably San Francisco and Portland), there are a large collection of frustrated academics driving cabs? The US particularly so – I have had conversations about Chinese politics, historical events in the UK, the industrial revolution, the development of the American constitution, the philosophical changes in the US since Bush came into power and various other topics. In London in particular, cabbys like to serve this kind of discussion with a garnish of comedy and sensationalism. I was once in a cab with Matt Revell heading to Millbank when a cabby expressed his not-particularly-happy views about David Cameron (current leader of the Conservative party) and then underlined them with the fact that “he had heard” that David Cameron takes Cocaine in very, *very* unconventional way. Matt and I were left stunned.
But the real gem is the second element – the variations in how a cabby likes to walk up to death and poke fun at it. Please, please don’t do that, think of the children. There are more than a few occasions when I have got into a cab and felt like my life was about to flash through my eyes. This was most notable in Porto Allegre in Brazil where it seemed the goal was to drive as fast as possible, discouraging the use of seat belts, and then drive as physically close to the car in front of you. I will be honest with you – I very nearly shit myself a number of times while in some of those cabs. I don’t mind hoying along at high speed, but holy mother of all that is good and sweet…that was just a whole new level. Oh, and then there was Istanbul. Aside from when a cabby drove Mirco Muller, Michael Dominik and I 30KM outside of Istanbul as something of a con, there was one particular incident when said cabby decided to overtake traffic by driving onto the wrong side of the freeway, swerving from on-coming traffic, and then driving back onto our side. I think I must have buried eight holes into the sides of that car seat with my fingers. My most recent trip in Argentina was pretty similar – it seems the goal there is to drive the smallest possible car in the world, with un-adjustable seats designed for children, equipped with some kind of jet engine in it to drive as fast as possible, and…and this is the important bit…brake as late as humanly possible. Oh fun. Believe me, after two days of solid travelling and getting to Mar Del Plato at around midnight, that particular experience bloody wakes you up.
Despite this world of academia, decedent exploration of the unusual, and rollercoaster-like fun, it most be difficult being a cabby – how many times do you really want to be asked whether you have been busy on your shift and what time you finish? I got a little concerned about this with the cabbys that drive me to the train station in Wolves when I travel to London or Heathrow, so I try to mix it up and ask more unconventional questions. Then again, maybe this is why I get myself into these odd conversations with cabbys. Hmmm…
Keynoting OhioLinuxFest
I am pleased to announce that I will be keynoting at the [Ohio LinuxFest](https://www.ohiolinux.org/). I have heard great things about the show, and never been there before, so I look forward to seeing everyone there.
The talk will be brand new, and I am just solidifying a bunch of ideas around it right now – I will be announcing the topic of the talk in the coming weeks.
Look forward to seeing those of you who are going in Ohio. 🙂
Overkill. London. Monday.
I am planning to go and see Overkill on Monday night in at Islington Academy in London, but…alas…all on my lonesome. Anyone heading down to the gig?
would be fun to meet any Ubuntu / LugRadio / Free Software or otherwise people there for a night of thrash metal. 🙂
Linking Bugs As Part Of Your 5-A-Day
You know what, [5-A-Day](https://wiki.ubuntu.com/5-A-Day) is doing really, really well. The idea is simple – much in the same way people are encouraged to eat five portions of fruit or vegetables a day, we encourage our incredible community to work on five bugs a day. If everyone does five bugs a day, amazing progress gets made. And, amazing progress *has* been made by the 5-a-day volunteers so far. 🙂
So, when we talk of *working on five bugs a day*, you would imagine this typically involves triage, filling out bug details, fixing bugs etc. It certainly does include each of these elements, but it also includes one really critical way in which you can help with your 5-a-day – *linking bugs* – something we have not talked a lot about and something we feel is a really great contribution that we would love you amazing 5-a-day-ers to do as part of your magic.
Many bugs that are reported in Ubuntu are actually bugs that exist in one of the pieces of software that we package for Ubuntu (known as an *upstream*). A feature that has been built into Launchpad is the ability to say that a bug in Ubuntu actually refers to a bug in an upstream bug tracker. Rather cleverly, Launchpad can in many cases sync some of the information from that bug report back into Launchpad. This means that we can communicate with upstreams more effectively about their bugs. The Launchpad team are continuing to refine this functionality, but right now linking bugs is an excellent way of ensuring that the right people see the right bugs.
And the great thing is that you don’t need to be a packaging expert or a programmer to help with linking bugs – you just need to be able to find the bug on the upstream bug tracker and hook the Ubuntu one and the upstream one together, which is as simple as filling in a form in Launchpad. Simple…but hugely helpful.
So what is involved in linking a bug? Well, in a nutshell:
* Find a reported bug in Ubuntu in Launchpad. Ensure the bug is not a duplicate.
* Ensure that the bug is actually a bug in the upstream application, and if so, find a bug report for the same bug in the upstream bug tracker.
* On the Ubuntu bug, link the bugs – this is as simple as filling in a form.
Instructions for linking bugs can be found [here](https://wiki.ubuntu.com/Bugs/Upstream).
We are really keen to make this process as simple and effective as possible. If anything seems overly complex or unclear, let us know and we will fix it. 🙂
Balancing Respect and Diversity
Just got back home from attending DebConf over in Argentina. I would like to send out a big thankyou to my Debian friends for making me feel incredibly welcome. I was there with a bunch of other Canonical people – Mark Shuttleworth, Jorge Castro, Matthias ‘doko’ Klose, Kees Cook, Steve Langasek and Celso Providelo. It was a really productive few days, and I had some great conversations with a bunch of people, while also sharing more than a few glasses of something hops-ee, or possibly tequila-ee. It was also an excellent opportunity to meet up with some Debian peeps I have been chatting with online for a long time.
Historically, the relationship between Debian and Ubuntu has been strained at times. There are various technical and social reasons behind this discomfort in our relationship, and while there is still work to be done to ensure we are working effectively together, the relationship has most certainly improved in recent years. I think there are many reasons for this, again technical and social, but I think you can boil it down to a critical *evolution* in our relationship – we have learned more about how a large derivative (such as Ubuntu) and Debian insect, mirror, and vary in different ways, and this takes time.
I am a firm believer in listening and learning from evolution in any distributed community. There are many, many examples where the theoretical blueprint of the best way of managing a community, software project or relationship makes perfect sense on paper, but the many variables in collaborative development result in the actual methodology being quite different. There are thousands of these examples everywhere in our fishbowl – *distros should really ship pristine, unpatched upstream code*, *there should be a stable ABI*, *all bugs should be filed in the same place*, *there should be one primary desktop environment*, *there should be a set of standards across all desktops at a widget and user interaction level*, *all teams should report regularly* – these are all examples of viewpoints that make sense on paper to different people, but in practise the reality is very different.
A relationship in general is no different, be it between you and your parents, you and your partner, you and your boss, different political parties or different distributions. The concept of a relationship on paper and the reality of that relationship can often be very different. On paper the core elements of the relationship are typically clear, but it is the execution of ideas, plans and decision-making as well as additional unforeseen variables that help the relationship really find its natural ebb and flow. Of course, this is fine – this is how things work, but the critical foundation needs to be there. When communication is strong, issues are discussed, with a sensitivity to the impact of those issues on both parties, a relationship can be strong and long-lasting. The greatest relationships have one consistent meme, irrespective of the hundreds of variables – a foundation of respect and openness between both parties to always discuss and drive to a conclusion that is a good medium for all involved.
And this is where we focus the microscope on the most critical ingredient in a relationship – an always present consciousness to find solutions to problems, discuss issues in a calm and focused way and to have a sensitivity for the other party at all times. The longest running bands, the greatest political partnerships, the longest marriages and the most incredible collaborations occur when these ingredients are present – they are not optional, they are required. People often talk about give and take in a relationship, and the above quality fundamentally defines the right balance of give and take – it solidifies the rules of engagement that form the foundation for two parties reading from the same page and moving forward together. This is the microcosm…the branch on the tree, at an atomic level…that when combined with other likewise relationships, connects together to form what we consider a community.
I feel this is where the relationship with Debian has evolved and needs to continue to evolve. There needs to be a fundamental requirement in engaging together on the same terms to foster a partnership where both Debian and derivatives in general are happy. We need to not only foster a close connection and commitment to exploring and respecting the goals of both parties, but we critically need to also not tolerate a culture of disrespect and criticism without evidence and rationale. Flaming is unacceptable – sensible, adult, evidence-led debate is glorious. Really…stunningly glorious. Flaming is the antithesis of the foundational attributes I discussed above – it demonstrates disrespect, arrogance and bad attitude. I have seen it in every community, Ubuntu included, and none of us should tolerate it. We are all together with the same ethos, however you label it, quantify and justify it – when we let this kind of flaming prosper, it weakens our crusade.
Debian kicks arse. Ubuntu kicks arse. They just kick arse in slightly different ways with a strong connection. DebConf, my first one, demonstrated such arse kicking, and I look forward to continuing to work with our friends there.
On Potential
Regulars of this ‘ere blog will be familiar with my abundant love of all things *community*. In fact, this has been a long running joke in the LugRadio world where I am accused of saying *community* way too often. Guilty as charged, m’lud. To this end, the always tiny and affable [Gerv Markham](https://www.gerv.net/) sat in one of my recent presentations with a laptop facing me and flashed the word *COMMUNITY* on the screen whenever I said it. Cheeky sod. 🙂
The thing I find so exciting about community is the sheer *potential* it offers. I remember when I first got involved in Free Software and bought Slackware Unleashed, I opened up the book, so thick that I could barely pick the damn thing up, and when I started reading about the ethos and structure of the Open Source community, it got me really fired up. I was specifically excited by the fact that not only did so much potential exist, but the core tools for realisation of that potential (communication mediums, cost-effective hardware/Internet, free tools, intellect/skill) were all there. *Potential* combined with the *tools to realise that potential* is an exciting prospect.
Potential is not just about the combined ethos and realistic ability to achieve it though. I also find potential exciting because it is conventionally unrestrained by context or the seeming limitations of individuals – potential is the combined realistic opportunity of a collection of interesting minds and motivations. If we want political peace in a region and only an individual can bring it, it will never happen, but construct an environment in which a community prospers around the concept of peace, and the potential for actual peace grows, as does hope. Whether we apply this to political peace or to fundamentally shaking up the rules of engagement in the IT industry…potential is what keeps people of like-minds glued together on the same path.
Potential though is not a mystical hand-wavy substance that is only on-tap to the godly few, it is something that needs to be developed, grown and nurtured, and this requires us to build strong communities – whether IT communities, local communities, political communities or otherwise. When we boil a community down to its core raw material, the skill of creating community is in creating *belonging*. When people feel that they belong, that their interactions are of the mutual benefit of everyone, that they are enabled to do good work, and when they are respected, we not only get potential, but we actually get real, tangible, measurable results.
That is what gets me excited by community; it is not a theoretical exploration performed inside the minds of boffins of MIT professors, it is not just an academic exercise, it is a recipe for real change that is unbound by the limitations of the individual. Pretty darn exciting, eh? 🙂
Ubuntu Global Bug Jam and the value of face-to-face time
Well, this weekend the [Global Ubuntu Bugjam](https://wiki.ubuntu.com/GlobalBugJam) kicks off, with Bug Jams happening all around the world including *Chile, Ecuador, Nicaragua, Perú, Puerto Rico, California, Chicago, Michigan, Michigan, Maryland, Massachusetts, Portland, Seattle, Venezuela, India, Thailand, France, Germany* and the *United Kingdom*.
I am hugely proud of everyone involved in organising their local bug jams as part of the wider global bug jam, and I am really proud of my good friend and compadre, Daniel Holbach for pulling many of these threads together to coordinate everything. You folks are gonna have a blast this weekend – getting together, fixing bugs, having a great time and helping free software. Kick arse. 🙂
You may have noticed that we tend to harp on quite a lot about Bug Jams and Packaging Jams. Part of the reason for this is that we really firmly believe in *onsite learning*. Every release cycle I sit down with the team and we assess the entire timeline of contributor interaction – we look at what happens from when someone expresses an interest in contributing to Ubuntu, right up to them being a core contributor. We try to assess and map the different types of interaction that occur between these two points and use this as a basis for building strong community. A key element here is *self education* – helping the community to educate themselves in different ways. This not only involves *skills* education but also *process* education – helping our community get a good idea of how things work. This is why Bug Jams are so good – they help people get used to fixing bugs and watching other people fixing bugs. Packaging jams are more about skills education – showing people how they can package up applications for Ubuntu, and how it works.
The simple fact is that getting people in the same room to do something is *a lot more fun* than not being in the same room. Add to that mix a supply of drinks and snacks, and it is a recipe for a good time and a sure-fire formula for helping free software rock the world that little bit more. It is tempting to assume that because we are all so used to online collaboration that we should just expect it in all forms of collaboration and discount the benefits of face-to-face time. Generating some face-to-face time is important not only because it helps people more visibly interact – hovering over computers, pointing, drawing things on pieces of paper and chatting, but it also gives people a chance to reconnect important bonds. People, lets not forget we are people, and we love to hang out, be it in a pub, a restaurant, a conference or a bug jam. With over 170 [Ubuntu LoCo Teams](https://wiki.ubuntu.com/LoCoTeams), we have a huge amount of *hanging out* potential. 🙂
So, my Ubuntu friends, have a wonderful time this weekend, kick the arse of some of those pesky bugs, and do let me know how you enjoy your bug jams – I look forward to hearing your stories. 🙂
Vacancy. Apply Within.
I am a lucky boy. Well, I am a lucky boy for many, many reasons, but the particularly lucky-ness I am referring to today is that I have a wicked-cool set of peeps on my team at Canonical. Regular readers of this blog will have heard me mention the other horsemen – Daniel Holbach who works in Developer Relations and Jorge Castro who works on Upstream Relations. We have a great team and we love getting up every day to work with our incredible Ubuntu community.
Sounds good, eh? Well, how would you like to join us?
I am pleased to announce a new role that I am looking to fill – [Ubuntu Translations Coordinator](https://webapps.ubuntu.com/employment/canonical_UTC/). Here is the job description:
**Posting Date**: August 2008
**Job Location**: Your home, as long as you have broadband. Some international travel will be required.
**Job Summary**: The role of the Ubuntu Translations Coordinator is to oversee, represent, guide and optimise the processes and workflow of the Ubuntu translations community as well as coordinating the LoCo Teams project. Applicants should have experience of working in a translations community and with computing user groups, be knowledgeable of the Ubuntu translations community, and be motivated and able to work in a fast-paced community team at Canonical.
**Reports To**: Ubuntu Community Manager
**Key responsibilities**:
* Understand, measure and report on the Ubuntu translations community and be a point of reference in the community and at Canonical
* Establish relationships with community translations leaders and upstreams, enabling a means to deliver quality translations to the Ubuntu platform in general and in key areas
* Effectively translate Ubuntu in a distributed manner
* Work closely with Canonical’s management, business and technical teams to advise and represent Ubuntu translations
* Take a significant role in coordinating Ubuntu local user groups (LoCo Teams), working on projects and goals within that community, and acting as a liaison with user group community leaders
**Required skills and experience**:
* Experience translating open source software
* Experience of using the translation facilities in Launchpad
* Strong community building skills and ability to resolve conflict situations
* Ability to work in a highly distributed environment
* Presentation skills a bonus
I am looking for someone with drive, motivation and experience, and someone with a passion for Ubuntu and making it available in everyone’s local language – this has always been a core goal of Ubuntu, and I need someone with the energy and insight to really make this rock. This person will also work with the business team to be a liaison for translation related opportunities and issues in our commercial agreements.
Sound interesting? Well, don’t contact me directly or leave a comments here, please [check out the job ad](https://webapps.ubuntu.com/employment/canonical_UTC/) and apply there. 🙂
Avoiding Burn Out
Well, after all of the theory and contemplation of how to resolve burnout in companies, teams and communities, it seems that one link has [the complete solution](https://www.therightfoot.net/mystuff/whatever/swf/bubblewrap.swf).
*Ahhhh…*
Ubuntu Free Culture Showcase is born!
[DIGG THIS STORY!](https://digg.com/linux_unix/Ubuntu_Free_Culture_Showcase)
I am really excited to announce the very first **Ubuntu Free Culture Showcase**!
For a long time now we have been shipping a package called *example-content* with each release of Ubuntu. This package provides a bunch of different pieces of content including audio, video, PDFs, OpenOffice.org documents and more. The idea is that you can use this content to kickstart your new Ubuntu system and see what it can do. *example-content* has been really useful, but it has been languishing a little recently, and then we had a rather interesting idea…
Why not use example-content as a great way to show off audio and video from free culture artists? It can give artists a platform of *millions* of Ubuntu users to show off their work and it really excites me because we are applying the Ubuntu ethos to free culture.
The idea is simple:
* Your submission must be either audio or video (we are not accepting documents/images) and no larger than 1MB for the audio and 3MB for the video. The submissions must be made available in either Ogg Vorbis (audio) or Ogg Theora (video). The submissions must be licensed as [Creative Commons Attribution ShareAlike](https://creativecommons.org/licenses/by-sa/2.0/).
* Upload your submission somewhere online (there are lots of free hosting solutions available such as archive.org). Do not email any of the organisers or judges with your submissions.
* Add your entry to one of the submission tables at [https://wiki.ubuntu.com/UbuntuFreeCultureShowcase](https://wiki.ubuntu.com/UbuntuFreeCultureShowcase).
* When the deadline for submissions closes, our panel of judges (Cory Kontros, Luis de Bethencourt, Luke Yelavich, Lydia Pintscher and Tony Whitmore) will pick a shortlist, and the Community Council will then pick the final winners from the shortlist.
The deadline is **4th September 2008** and you can read more about it at [https://wiki.ubuntu.com/UbuntuFreeCultureShowcase](https://wiki.ubuntu.com/UbuntuFreeCultureShowcase)
This is a great opportunity for artists to get their work seen or heard. Lets make something cool happen. Good luck! 🙂