Safe as Milk

Football clubs and free software projects

A few weeks ago I pointed out some similarities between community software projects and critical mass. After watching Chelsea-Barcelona last night – an entertaining match for many of the wrong reasons and a few of the right ones – I wanted to share another analogy that could perhaps be useful in analysing free software projects. What can we learn from football clubs?

Before you roll your eyes, hear me out for a second. I’m a firm believer that building software is just like building anything else. And free software communities share lots of similarities with other communities. And football clubs are big communities of people with shared passions.

Football clubs share quite a few features with software development. Like with free software, there are different degrees of involvement: the star players and managers on the field, the back-room staff, physiotherapists, trainers and administrators, the business development and marketing people who help grease the wheels and make the club profitable, and then the supporters. If we look at the star players, they are often somewhat mercenary – they help their club to win becauise they get paid for it. Similarly, in many free software projects, many of the core developers are hired to develop – this doesn’t mean they’re not passionate about the project, but Stormy’s presentation about the relationship between money and volunteer efforts, “would you do it again for free?” rings true.

Even within the supporters, you have different levels of involvement – members of supporter clubs and lifetime ticket holders, the people who wouldn’t miss a match unless they were on their death bed, people who are bringing their son to the first match of his life in the big stadium, and the armchair fans, who “follow” their team but never get closer than the television screen.

The importance of the various groups echoes free software projects too – those fanatical supporters may think that the club couldn’t survive without them, and they might be right, but the club needs trainers, back-room staff and players more. In the free software world, we see many passionate users getting “involved” in the community by sending lots of email to mailing lists suggesting improvements, but we need people hacking code, translating the software and in general “doing stuff” more than we need this kind of input. The input is welcome, and without our users the software we produce would be irrelevant, but the contribution of a supporter needs to be weighed against the work done by core developers, the “stars” of our community.

Drogba shares the love

Football clubs breed a club culture, like software projects. For years West Ham was known for having the ‘ardest players in the league, with the ‘ardest supporters – the “West ‘Am Barmy Army”. Other clubs have built a culture of respect for authority – this is particularly true in a sport like rugby. More and more the culture in football is one of disrespect for authority. Clubs like Manchester United have gotten away with en masse intimidation of match officials when decisions didn’t go their way. I was ashamed to see players I have admired from afar – John Terry, Didier Drogba, Michael Ballack, in the heat of the moment show the utmost of disrespect for the referee. That culture goes right through the club – when supporters see their heroes outraged and aggressive, they get that way too. The referee in question has received death threats today.

Another similarity is the need for a sense of identity and leadership. Football fans walk around adorned in their club’s colours, it gives them a sense of identity, a shared passion. And so do free software developers – and the more obscure the t-shirt you’re wearing the better. “I was at the first GUADEC” to a GNOME hacker is like saying “I was in Istanbul” for a Liverpool supporter.

This is belonging

So – given the similarities – spheres of influence and involvement, with lots of different roles needed to make a successful club, a common culture and identity, what can we learn from football clubs?

A few ideas:

• Recruitment: Football clubs work very very hard to ensure a steady stream of talented individuals coming up through the ranks. They have academies where they grow new talent, scouts, reserve teams and feeder clubs where they keep an eye on promising talent, and they will buy a star away from a competing club based on his reputation and track record.
• Teams have natural lifecycles: When old leaders come to the end of the road, managers often have trouble filling the leadership void. Often, it’s not one player leaving, but a group of friends who have played together for years. Teams have natural lifecycles, but good teams manage to see further ahead, and are constantly looking to renew the team, so that they don’t end up in a situation where they lose 5 or 6 key players in one season
• Build belonging: Supporters want to show their sense of belonging, and people who don’t have the skillz to be on the field still want to wear their team colours, and share their passion for the team. Merchandising is one way to do that, but not the only way. We should look at the way clubs cultivate their user groups and create a passionate following
• Leaders decide the culture: We owe it to ourselves to systematically grow a nurturing culture at the heart of our project – core developers, thought leaders, anyone who is a figurehead within the project. If we are polite and respectful to each other, considerate of the feelings of those we deal with and sensitive to how our words will be received, our supporters will follow suit.

Are there any other dodgy analogies that we can make with free software develoment communities? Any other lessons we might be able to draw from this one?

How do you count your community size?

Way back in the Maemo Summit in September 08, Jay Sullivan put up a slide which talked about spheres of participation in Mozilla.  I threw together a rough approximation of what was in that:

Spheres of participation

Communities are like onions or planets, with, at their core, the leaders who set the tone and direction for the community. Around this core,many more people contribute to the project with their time and energy, with code, artwork, translations, or with other skills. And beyond, we have forum members, mailing list participants, people on IRC, the people who gravitate to the community because of its vision and tone, and who make the project immeasurably better with their enthusiasm, but who individually don’t commit as much time, or feel as much ownership of the project, as those I mentioned before. Finally, the there is user community, the people who benefit from the work of the community, and which is orders of magnitude bigger.

The boundaries between these levels of involvement are diffuse and ill-defined. People move closer to the center or further away from it as time goes on. A core maintainer gets married, has a child, changes jobs, and suddenly he doesn’t have the time to contribute to the project and influence its direction. A young student discovers the community, and goes from newbie to core committer in a few months.

But the key characteristic to remember is that at the inside we have people who have gained the trust of a large part of the community, and significantly, of the other members of the community at the core. Contribution breeds trust, and trust is the currency upon which communities are built.

Last week as OSBC, I heard different companies claim that they had very large communities of developers, but when I asked about this, they meant people contributing translations, signed up to user forums, downloading SDKs, or developing plug-ins or extensions. When I bore down a little and asked how many were committers to the core product, the impression I got was always the same: very few – because these companies, built up around a niche product, build their business case around being the developer of the product, they require copyright assignment to the core, and becoming a core committer is difficult, if not impossible, if you don’t work for the company behind the project.

So I ask myself, what is the best way to count the size of your developer community? Do you include the orange ring, including translators, documenters, artists, bug triagers and developers who submit patches, but aren’t yet “core” developers? Just the red ring, including maintainers and committers to core modules? Or would you also include all those volunteers who give of their time to answer questions on forums and on mailing lists, who learn about and evangelise your product?

For a project like GNOME, I think of our community in the largest terms possible. I want someone who is a foundation member, who comes along to show off GNOME at a trade show, but has never developed a GNOME application, to feel like part of the GNOME community. I consider translators and sysadmins, board members and event organisers a vital part of the family. But none of these set the direction for the project – for that, we look to project maintainers, the release team, and the long-time leading lights of the project.

I think that you need to separate out the three distinct groups. Your core developers set the direction of the project. Your developer community might include extension developers, documenters, and other people who improve the project, but who do not set the direction for the core (some companies might call this their “ecosystem”). Finally, we have the contributor community, which includes people signed on to mailing lists and forums.

When considering how viable a community project is, calculate the bus factor for the red bit, your core developers. Is there one core maintainer? One company hiring all of the core developers? Then the risk involved in adopting the project goes up correspondingly. The breadth of your contributor community will not immediately fill the gap left if all the core developers disappear.

Gran Canaria: Registration & call for participation open

For those who missed the next last week, the Gran Canaria Dasktop Summit website got updated last week – and with it, we opened registration for the conference. This is the organiser’s way of knowing who’s coming, and the way for attendees to reserve accommodation and request, if they need it, travel assistance.

We also concurrently opened the call for participation. Since we’re already a little late organising content this year, we’re going to have a pretty short call – please send abstracts for GNOME-related and cross-desktop content to guadec-papers at gnome.org before April 10th (midnight on the date line, I guess).

The procedure is going to be a little unusual this year because of the co-hosting of GUADEC with Akademy – a GNOME papers committee headed up by Behdad will be choosing GNOME-specific content, and a KDE equivalent will be choosing Akademy content, and we are co-ordinating on the invitation of keynote speakers and choice of cross-desktop content.

The thing that got me excited about this conference last yearn and the reason I was so enthusiastic about combining the conferences, is that cross-desktop content. The Gran Canaria Desktop Summit has the potential to be the meeting place for free software desktop application developers and platform developers, as well as embedded and mobile Linux application developers. We will have the people behind the two most popular free software development platforms coming together.

The conference is an opportunity to plan the future together for developers working on the kernel, X.org, alternative desktop environments like XFCE, application platforms like XUL, Eclipse’s SWT, desktop application developers and desktop-oriented distributions. I’m looking forward to seeing proposals for presentations from all over the mobile and desktop Linux (and Solaris) map.

So to your plumes! We’re not expecting abstracts to be works of art, but we are looking for thought to be given to your target audience and what you want them to get from your presentation. Compelling, entertaining and thought-provoking content will be preferred over “state of…” presentations, or other types of presentation better suited to blog posts. Knock yourselves out!

Maemo community council elections: results in!

The Maemo community council election is over, and the results are in.

166 people voted to elect the incoming council, and when the dust settled, the new council will be made up of:

• Andrew Flegg
• Ryan Abel
• Tim Samoff
• Kees Jongenburger
• Alan Bruce (better known as qole)

For those interested in that kind of thing, you can download all of the ballots from the election in .blt format (the format used by OpenSTV) and replay the election with different counting systems and options for transferring votes. You can also browse the votes online, and verify that your vote was recorded correctly.

Congratulations to the elected council members, and thank you to all of the candidates for running!

Libre Graphics Meeting fundraiser update

With little fanfare, this year’s Libre Graphics Meeting fundraiser has been progressing nicely.

In the three weeks since the announcement of the launch of the campaign, we have raised almost $3,000 in community donation – mostly smaller than $50 – from 71 individual donors. Much of the credit for the campaign this year has to go to Jon Phillips of Creative Commons, Inkscape and OpenClipart fame.

The campaign has started earlier this year than last year, when we were really caught unawares by our difficulties in getting sponsors, and has lacked some of the frenzy of the last campaign, but Jon has been doing stellar work keeping the fire burning, and ensuring a regular stream of donations from supporters of projects related to Libre graphics.

It is hard to overstate the importance this conference has to the communities working on projects like Inkscape, GIMP and Scribus, among others, and to overstate the progress we have made because of these conferences in the past few years in the realm of graphics applications on Linux.

It’s useful to point out that in the Linux Foundation desktop linux surveys, the most popular applications which companies and individuals want for Linux are graphics applications – Adobe Photoshop, Illustrator, Premier, Autodesk AutoCAD, Adobe Dreamweaver and Microsoft Visio are the top 6 applications which people are missing on Linux. This conference is all about encouraging the development of applications destined to fulfil those needs. Also worth noting, when asked whether they wanted the applications above ported to Linux, or they wanted to use equivalent Linux applications where possible, a large majority want to use native equivalents, rather than ported commercial applications.

For any of you looking for a good cause which will go directly to supporting high quality applications that you use, I’d encourage you to contribute to the Libre Graphics Meeting. The conference is only as worthwhile as the people attending it, let’s ensure that we get a critical mass once again and provide energy and momentum to all of the participating projects for the coming year.

Maemo Community Council elections: The story so far

More than half way through the Maemo community council Spring 2009 elections, I thought it would be interesting to get a sneak peek at turn-out figures, to let people know how things have been going so far.

The results are slightly disappointing so far – but I know that there are a lot of last-minute voters, so I’m not exactly worried yet.

Out of 717 ballots issued, as of Tuesday at 15h UTC, we have registered 138 votes so far, or about 20% of the electorate. This tallies roughly with the participation rate that we had in the first council election with people who had more than 25 karma (roughly 35%).

The election will end at midnight UTC on Thursday evening, at which time anyone will be able to download the anonymous ballots and calculate the results of the election using OpenSTV or any other program that handles .blt format files. I will calculate the results using the pre-defined settings for the election (random transfer STV, static Droop threshold, with no lower limit for batch elimination) and publish them on Friday morning, European time.

All of you who have been waiting to vote, vote now! And all of you who have trouble voting, or who haven’t received the voting token you should have, contact me.

FFmpeg release – congrats!

Never one to hold a grudge, I’d like to congratulate the FFmpeg developers on their recent release of FFmpeg 0.5.

I’ve been pretty hard on FFmpeg in the past for their lack of releases and their API policy – it’s made packaging their software hard for distributions, and developing using their libraries hard for third party developers. A release is great news, and I hope it is the first of many.

Maemo Community Council referenda: the results are in

The voting is now closed in the Maemo Community Council referenda on election procedures for the upcoming and future Maemo Community Council elections.

The provisional results, which will stand unless successfully challenged within the next 7 days, are as follows:

1. Which of the following criteria do you want applied to the Maemo Community Council elections to be held in March 2009?
   • 25 karma and 3 month old account (status quo) (71 votes)
   • No karma requirement, anyone with an account for more than 3 months
     may vote (64 votes)
   • None of the above (4 votes)

   139 votes were cast of an electorate of 601 (23%)

   We will maintain a 25 karma requirement for the next elections.

2. Which of the following criteria do you want applied to future Maemo Community Council elections?
   • 10 karma and 3 month old account (48 votes)
   • 25 karma and 3 month old account (status quo) (46 votes)
   • 10 karma or 12 month old account (22 votes)
   • No karma or account age requirement – everyone with a maemo.org account may vote (13 votes)
   • None of the above (0 votes)

   129 votes cast of an electorate of 601 (21.5%).

   For future elections, voters must have a karma of 10, and have created their maemo.org account more than 3 months before the closing date of the election.

3. Which of the following voting systems do you want used for Maemo Community Council elections?
   • A single transferable vote preferential system (60 votes)
   • No change – single vote, with top 5 candidates elected (51 votes)
   • A reweighted range voting system (score candidates between 0 and 100) (13 votes)
   • None of the above (3 votes)

   127 votes cast of an electorate of 601 (21%).

   Future elections, including the election to be held in a few weeks, will be by preferential vote, and will be counted using the Single Transferrable Vote system.

I will be modifying the Maemo election system (stolen borrowed from the GNOME Foundation) before the next elections to implement preferential voting, and we will likely be using OpenSTV to count ballots after the next election.

Governance best practices

Jono asked on the AOC blog for successful governance stories, and while I’m happy to comment on the blog, now that I’ve taken the time to write some down, I thought I might as well share them 🙂

Governance comes in many shapes & sizes of course. My favourite governance stories are about federating individuals, who manage to channel community efforts, maintain a meritocracy where code talks, and yet don’t come across as authoritarians.

Outside of Linus (who’s a good example), Ton Roosendaal of Blender has this kind of presence. Talking to Ton, it is easy to see that he cares about Blender and about the Blender Community. The care and attention that he brings to projects like “Elephants Dream” and “Big Buck Bunny”, or to the supporting documentation and conferences he organises for the community, illustrate the esteem in which he holds his users and his developer community. Even the way the Blender Foundation came into being was amazing.

One of my favourite communities is Inkscape. When they broke from Sodipodi, there was this acrimonious flame war, and something of a bitter taste in people’s mouth. So what Bryce Harrington, Nathan Hurst, MenTaLguY and Ted Gould did when they split was decide to throw open the doors, and accept code from all comers. They set a direction and some ambitious goals, but they were very clear from the start – come right in, you’re welcome. And this gave the project some great results, especially early on when it was still establishing itself. Bryce describes one of them in this article.

The success of the Inkscape project’s governance model is borne out by its ability to escape founder’s syndrome – Bryce, Nathan and Ted have now backed away from the project to some extent, they’re still there as wise heads, but they have passed off the direction of the project to other capable people.

I think the way that Drizzle was born bears some resemblance to this, and I really like the way they have consciously broken down the walls which were necessarily up around MySQL. Brian Aker’s been something of an inspiration on this. His mission statement at the announcement of the project was astounding.

Subversion‘s governance model is an exemplar of best practices too. Set a clear project scope (“Subversion is a compelling alternative to CVS”), clear goals, establish transparent and fair community processes, and open up the gates. Anything within the scope of the project is fair game. And once again, code talks. This story, from Karl Fogel’s “Producing OSS” illustrated the robustness of their governance, and the confidence the project’s leaders had in their ability to influence the project.

The Maemo Community Council has the potential to be a very good governance structure, I think.  The idea of a governing body of the community, by the community, for the community, whose goal is to canalise the efforts of a disparate group into something coherent, and to provide a legitimate point of contact for technical decision-makers in Nokia, is a novel one, and hasn’t been tried, as far as I can tell, by other companies.

Counter-examples of good governance are all around, I won’t name any in particular to protect the guilty. But many of them stem from a misguided belief in absolute free speech, to the detriment of the quality of discourse and code in the project (“we are all created equal”) which results in very chatty, but unproductive, individuals taking senior positions in the community, or a sort of shyness of the founder or leader, who doesn’t believe that it’s his place to set a direction and tone.In company-run projects, excessive control or influence is an equally toxic characteristic. Companies who retain a veto on community decisions are companies who do not trust their communities.

Maemo Community Council referenda: voting now open!

Voting is open for the 3 referenda around the election procedure for Maemo community council elections.

A wiki page has been created for each referendum, where arguments for & against each of the options can be listed. For the moment, these pages are skeletons, but feel free to debate in the Talk page, and perhaps add some arguments for & against in the main page (but they will be heavily moderated to avoid flame-wars).

A reminder of the 3 referenda:

1. Election procedure for the next Maemo community council elections: The choices are the status quo in the election procedure document (25 karma + 3 month), or removing all requirements. The council is recommending a vote to remove requirements.
2. Election procedure for future Maemo community council elections: The choices are the status quo, lowering the karma requirement to 10, and maintaining a 3 month requirement for accounts, lowering the requirement to 10 *or* 1 year since account creation, whichever comes first, or removing all requirements of karma and account age. The council is recommending lowering the karma requirement to 10, and maintaining a 3 month account creation limit.
3. Counting method: Three choices are proposed: first past the post, preferential voting using single transferrable vote, or reweighted range voting.

Voting is open now, until midnight UTC next Monday, the 23rd of February. As we used to say in Ireland in the ’80s, vote early, vote often!