jonobacon@home

Yesterday my buddies over at the excellent Ubuntu UK Podcast did a segment on 5-A-Day where they were debating the merits of the initiative. I just wanted to weigh in with some comments.

The debate spawned into a few areas which I want to address separately.

Firstly, in terms of the success of 5-A-Day, it has been a roaring success so far. I have a graph that measures the workflow of the 5-A-Day team and the curve is constantly growing with over 14000 bugs being touched in 7 months; that is over 2000 bugs on average a month. That is touched bugs, but in terms of actual bona-fide closed bugs, that is over 8000 in 7 months. Daviey mentioned the number of members contributing to 5-A-Day seeming small; interestingly the number of people who are involved in the team fluctuates a lot - this is common with most community teams and groups, and auto-expiration of people from the team also contributes to fluctuating figures. Despite the team adjusting in size, the number of bugs touched with 5-A-Day has remained consistent, which suggests that people are doing more and more bugs each day and not limiting themselves to the suggested five. This quells any worries that five is an unobtainable figure - if it was, our stats would say otherwise.

It is also important to get the purpose of 5-A-Day in perspective. 5-A-Day is not intended for everyone. It does require a certain level of technical know-how. It does require someone to know the bug-tracking facilities in Launchpad. It does require someone to run the development version of Ubuntu. The purpose of 5-A-Day is to put a manageable figure on daily bug contributions. It sounds overly simplistic, but it works. When encouraging any kind of adoption or mass direction, it is essential to set fair expectations - this is what governments have done with the fruit and vegetable 5-A-Day - if you set a base-level of expectation, it provides a simple metric for people to strive for in their daily lives. Just think about all of the places this happens - counting calories in a diet, working out for a certain amount of time, running a certain distance three times a week, carbon offset expectations. Admittedly these are all measurements for a healthier and more balanced life, but that is the point of 5-A-Day in the Ubuntu world; getting our contributor community comfortable with a reasonable daily contribution so we can manage the bug list that we have. Not everyone will be able to do 5 bugs a day, some may only do one a day. Not everyone will be suitable for getting involved, but there are a large number of people who are suitable…between 140 and 200 who can make use of the initiative.

So, in a nutshell, 5-A-Day is not for everyone, but it is a great contribution for a good number of people, and with 5-A-Day we are 14000+ triaged bugs better off.

Another element of the discussion was the suitability of our resources in getting people skilled to contribute to 5-A-Day. Again, I want to set fair expectations here - to do 5-A-Day from no development or triaging experience will require quite a bit of perseverance, but it can be done. I think we have a pretty good set of resources in what we offer to help people get involved:

Without sounding arrogant, I think this is a pretty compelling roster of help and support for budding Ubuntu contributors. Again, this will not convert every potential contributor into a super mad-skilled Ubuntu rockstar developer, but it gives people a good start to get involved.

Finally, Daviey mentioned the sponsorship queue. Admittedly, the sponsorship queue has seen some tough times with items languishing there for a while. To help resolve this, I sat down with Daniel Holbach and we fleshed out some plans to resolve these issues, and part of this is that Canonical is requiring that every paid developer spends at least one hour a week tending to items on the sponsorship queue - this time commitment alone (around 25 hours a week) will be a significant contribution in getting the queue in shape. We still need the community to look after the queue too, and we have plans to help encourage this in the coming months.

Hope this helps clarify the situation a little.

You know what, I love being a community manager. I love the challenges, I love the opportunities, and I love the diversity of application and work. There are of course some frustrating elements, and one of these frustrating elements is the pre-conceived perspectives that some people have about this kind of work, and to make matters worse, the things that some community managers do to compound the situation. One such example, but one in which no specific community manager is at fault, but has been something of an endemic voice is that community is vastly free-form and immeasurable.

Bollocks.

Don’t get me wrong, community is very much a soft science. It is about relationships, it is about connections, and most importantly it is about trust. When there are no relationships, no connections and no trust, community managers tend to start looking for jobs as taxi drivers.

A soft science though does not mean though that there is an excuse to just assume the world is a big analogue blur that we can only measure and assess by licking a finger and lifting it to the breeze. A key trick in being an effective community leader is to discover the mechanics of your community, and understand how to assess and measure them.

When Daniel and Jorge both came onto my team, the thing I said to both of them on day one was that I always wanted them to explore two key areas as part of their work - developing strategy and the mechanics behind that strategy. This is core to everything that we do - we have a strategic plan, goals, deadlines, and a range of graphs measuring our work that would look really freaking awesome in the war room from Wargames. Alas, about as good as we have is Jorge’s second flat-screen. We use these metrics to assess our work and the health of the community.

A typical example is the upstream report in Launchpad which we are readying for beta right now - I will have more details on this soon when it is complete. The upstream report shows a bunch of upstream projects, the number of open bugs, the number of bugs with upstream activities (this means the bug is likely to be an upstream bug), and the number of bugs with upstream watches (a known upstream bug that is linked to the Ubuntu bug). This provides us with useful data for which upstreams need most focus. We are currently getting some additional features into the report for colour coding, sorting the results and removing dupes. Bugs are a metric, they are a mechanic - they are the nuts and bolts of the software development process, and we measure them closely.

A huge amount of community management is the soft science, but I urge everyone out there to think about the mechanics. Think about the things you can assess, the things you can measure, and use them as a means to identify if your community is healthy and growing and being effective in the ways that you want it to be.

I am pleased to announce that I will be keynoting at the Ohio LinuxFest. 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.

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.

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 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?

Well, this weekend the Global Ubuntu Bugjam 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, 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.

Its funny how the same approximate process seems to happen for many communities, and sub-communities in projects. It happens a little like this:

The problem here is a lack of focus on what is important - building a team.

Every community that forms needs resources. It needs facilities and tools that people can use to achieve the goals they set for the project. But when starting a new project, there is so much excitement and anticipation, and this combined with the freedom to create resources easily, means that a lot of unnecessary tools and facilities get set up. In these cases, the focus is taken away from the intended goals of the project, and is instead dialed into debates about these tools and implementations. The problem is that too many tools and resources can actually be detrimental to a project.

Lets look at mailing lists as an example. Pretty much every project needs a mailing list. It is typically the primary medium for communication. But even with just mailing lists there is a strong temptation to not just create a single list such as myproject-devel but to also create myproject-discuss, myproject-announce, myproject-users, myproject-commits etc. Hey, if you set up a mailman server, you may as well make use of it and create a bunch of lists, right?

The same temptation can occur with forums. So many projects go out and set up a phpBB forum on a server somewhere and instead of creating a single forum, they produce 10 different forums - General Discussion, Feature Ideas, Technical Problems, Announcements, Offtopic etc. Hey, if you go to the time and effort of setting up a phpBB server, why not have a large array of forums - other sites do, why not yours?

And herein lies the problem, my trigger-happy friends. Just because you have the ability to create more than one mailing list, more than one forum, more than one VCS, more than one bug tracker or more than one anything else, does not mean it makes sense for your project to do so.

The reason why it is a problem is that it fragments your community.

The hardest element in building a community is gaining critical mass. The first order of business with new communities is to get them up and running, with a regular flow of traffic and development. You want your community to feel busy, thriving and productive. The reason why such tool-fetishism seems to happen is because it is assumed that to achieve the regular flow of development part of your community, you need a strong set of tools available. Wrong. You need the appropriate tools and some strong guidance, focus and direction. This direction can only be achieved when you have all the eyes in your project looking in the same place - and when you have 5 mailing lists, 10 forums and a bunch of other distractions, your project loses focus, and problems set in. As such, I recommend that you have one primary medium of discussion (such as one mailing list), one primary web-page, and only the required resources for getting your project under-way (e.g. bug tracking and a (D)VCS).

Of course, this is not to say that multiple lists and forums are not useful - they are. But every project has a life-cycle, and the time for these additional lists and forums are when the project is mature, running and productive. The primary focus in the critical opening few weeks should be on growing a team, not growing a mailing list archive.

Earlier in this post I referenced another element of tool fetishism - debates over CMSs. I see this time and time again with communities, and in the Ubuntu LoCo team world I recommend all teams to simply create pages on wiki.ubuntu.com and get started there. CMSs are nothing more than a distraction when teams get started. The focus and discussion in the first two weeks should not be about arguing about which CMS to use - it merely distracts away from the core purpose of building a team. Sure, people need to jot things down somewhere online, and people need to be pointed at a page about the team, but a wiki is perfectly suitable for this. A wiki may not be as sexy as a CMS, but an inactive team is the pure definition of “not sexy”.

So, the rule of thumb in this post is - when starting a new Open Source project, keep your eyes on the prize and your efforts focused on building a team, and don’t be tempted by these distractions. I can assure you it will put your team in better stead.

One of the primary functions of a community manager is to put governance in place where it is appropriate to help your community run effectively. Governance is a funny ‘ol word though, and everyone has their interpretation of what exactly it means, to what extent it should be used and how required it is. Like any kind of community work though, there is no hard and fast rulebook about how things work - good judgement is the best method of determining exactly how your community should be governed.

The problem is that that bad governance can really bugger up a community. The concept of governance itself is to put in place processes and rules that are universally understood and accepted by the community in an effort to establish a semblance of control and guidance of the community and its growth. Get it right and your community feels well run, not restricted by bottlenecks and effective to growth. Get it wrong and it feels like a bleedin’ great ship that is impossible to turn around.

The problem is that governance can very quickly turn into bureaucracy if you are not carefull. Bureaucracy is simply governance that refuses to change, despite a better method of governance becoming available. If you put rules in place and refuse to change them because they are the rules, your community gets bound in red tape and will heartily suck for all involved.

Again, it all really comes down to common sense and a measured approach. A few things to bear in mind when considering the formation of constitutions, councils, mandates and other governance hop-scotch:

Also, one final note. One of the most wonderful elements of Open Source is the diversity of people it brings along. However, Open Source also has its fair share of Civil Servants who get a kick out of councils, constitutions, boards, elections and what-not. While these people can be useful, and many have the right intentions and balance, beware those who believe that governance is important just for the sake of having governance - invariably this can result in Civil Servant death-matches where there is a fight for power, and the real people who actually care about doing interesting work in the community just get to sit there and watch a pointless power struggle. The best governance is invisible - it just exists and helps cool people to do cool things.

Just my 0.2c.

Right now I am over in beautiful Prague for FossCamp and the Ubuntu Developer Summit. Running and attending these events is always a real treat - there is always a genuine feeling of free software in action; a real meeting of minds coming together with a common ethos. Part of why I love the FossCamp/UDS trip is that it involves a huge amount of diversity. Here at FossCamp we have people from a tonne of projects, including Ubuntu, Jokosher, Sun, EFL, Terminator, Strigi, Xesam, Ubuntu Brainstorm, Linux User Groups, GNOME, Glom, gtkmm, Campware, KDE, Amarok, KOffice, Edubuntu, Xubuntu, Ubuntu Studio, Tango, Novell, Red Hat, Inkscape, freedesktop.org, OpenSuSE, OpenChange, Samba, Debian, MOTU, swfdec, gvfs, OpenOffice.org, eBox, LKSCTP, Elisa, HAL, dbus…

Its been a busy time recently and I have been out on my travels over in San Francisco, Boston, Cambridge, Detroit and London. Its been a hugely fun time, and I got to meet some incredible people - thanks to everyone who made me feel exceptionally welcome. I also want to give a quick shout out to the folks at ubuntu-ma, PenguiCon, CommunityOne, Creative Commons, Mako, Matt Lee, Barton, and my friends over in Lexington who are making Ubuntu work on things that live in your pocket.

Oh, and as a slight postscript, I have finally fulfilled one of life’s little ambitions - to not only meet, but a share a photo with the venerable tron guy:

Not only did I have a photo taken with tron guy - he came looking for me to deliver a parcel with a fake beard in it. While it was happening I felt like I was in some kind of acid trip. We then had a serious and detailed conversation about MOTU, while he was stood there in full tron regalia. Just when I thought my world crazy, it got a little crazier…

I was going to finish this entry here, but sod it, here are a few other things living in my brain right now:

The Severed Fifth machine continues to roll - the server is up, the mailing lists are on their way, the announcement is written, the logo ideas are flowing in, the photo-shoot is in post-processing, and the content is nearly there in terms of initial work. Thanks to that group of amazing people that are making it happen. You know, gyms never really had an appeal to me, but I have been a few times recently - I had a really good session in there a while back and figured it would be fun to repeat. Wow, it seems this post of mine caused a bit of a stir over what is considered music. Always amazes me when people accuse creativity that does not meet their taste as being unintelligent or just noise. I am not expecting people to like the music I like, but I am expecting people to understand and respect the work that goes into any art-form, irrespective of their taste. Everything is worth listening to, even Cannibal Corpse, lounge style or flute beatboxing. Someone should invent an “anti-mint”, something you put in your mouth to take away the taste of mint. Imagine those situations when you wake up in the morning, brush your teeth and then want to drink orange juice. Personally, I want both clean teeth and orange juice and to not sacrifice one or the other. Someone…the anti-mint…lets make it a reality. I bought GTA4 and it rocks. It also drove me to be involved in a police chase, but that’s a story for another time. While in video game news, I got totally whipped at Guitar Hero III, and while despite fervent denial, I got completely annihilated. Mind you, I spent more time posing and prancing around the living room at my competitors apartment than focusing on the game in hand. Well, that’s my excuse and I am sticking to it. Recently jonobacon.org seems to have been picked up in some of these “top blog” listings. You are as surprised as I am, but for my regular readers, thanks for helping to push my little chunk of randomness up in the blog ranks. It really does go to show how many bored people are populating the Internet. You know, Cancun is an amazing looking place, would love to get over there sometime. Thinking of a new phone - Nokia N95 8GB or a Blackberry? Any thoughts? It should be good for email, have a decent camera, preferably have a GPS and preferably have an alpha-numeric keypad.

I think that’s enough for now.

I just wanted to let those involved in the Debian project know about something. We are always trying to learn more about our relationship with Debian and determine ways of ensuring it is as smooth and as productive as possible. As with every relationship, there are high and low points, and I would like to keep the low points strongly focused on my alleged terrible taste in music (which is of course, a lie), and ensure the things that really matter are smooth running.

To help with this, we have set up a new email forward debian@ubuntu.com that comes directly through to me. If you are involved in either Debian or Ubuntu and have something to discuss about our relationship, then do get in touch - this can apply to letting me know where things are working well, things I should be aware of and areas that need improvement.