Safe as Milk

Barriers to community growth

Barriers to entry

I often talk to vendors who are interested in growing their developer communities around their free software projects. When I do, my advice centers around two things, one of which I think I can help with.

The first is your project vision – why would someone look at your stuff instead of anyone else’s? You are competing for the attention of the pool of free software developers out there, as well as trying to grow that pool, and what will draw people to your project is your vision.

The second is the Hippocratic principle of community building: Primum non nocere, first do no harm.

Most communities fail to reach critical mass because someone becomes interested in your project, and just bounces off it, because of some difficulties they meet when engaging you. To build a successful community, it is usually sufficient to build a compelling vision, and remove all non-essential barriers to participation in your project that exist.

I have compiled a check-list of various barriers to entry which are found in vendor-led projects, roughly grouped into technical, social and legal barriers to entry. Sometimes it’s appropriate for a new community member to face a learning curve – you want to maintain a tone in your community, and ensure that core developers understand the social and technical norms of your project – but often the things that they have to learn are incidental, rather than essential, and removing these is a worthwhile thing to do.

Without further ado, here is Community barriers to entry (pdf) – I’m publishing this under CC BY-SA 3.0 and I would be delighted to get feedback on this to help improve it and make it more useful. Comments welcome!

Gran Canaria wrap-up 2: Day 0

Note: I actually wrote something like this already in GNOME Blog, and a combination of the Intel graphics freezes in Jaunty and GNOME Blog not creating a local copy of in-progress entries cost me the lot. Funny that WordPress, a web-app, offers better transparent data retention across unexpected events than a local client. I have resolved to use Tomboy for drafting blog entries off-line now, and to figure out how to patch GNOME Blog to save drafts.

My Gran Canaria adventure started in a funny ha ha way when I got the airport and I was told I wasn’t on the plane which I had a ticket for. I checked my email to ensure I hadn’t received any schedule change emails, and found the last mail I received from Expedia, indicating I was booked on the 15h flight from Lyon to Madrid. But the friendly & helpful people at the Air France desk eventually figured it out, the airline had bumped me to an 8am flight, with a transfer to Gran Canaria arriving in the early afternoon. The travel agent wasn’t aware of it (I checked later when I got some internet access). So the Air France people asked if I minded flying through Bilbao, I said no (imagining they meant that I’d be flying from Lyon to Bilbao), and they checked in my bags, and gave me a boarding pass. For the plane to Madrid.

“I don’t understand”, I said. “We can’t issue you a boarding pass for the Madrid-Bilbao or Bilbao-Las Palmas legs now”, they explained. Ah. When I looked at the transfer times, and realised that (if we were on time) I would have 30 minutes to transfer in Bilbao, I was told that I would probably be able to get a boarding pass for the Bilbao-Las Palmas in Madrid.

When I got to Madrid, I queued behind some Swedes who were on their way to some holiday destination and had just been told that their flights were over-booked, and that they’d be staying in Madrid for the night. Happy happy joy joy. I also surprisingly ran into Alex Larsson, who was looking for a boarding card for his flight to Gran Canaria, which was delayed. I debated asking to get on the flight with him for a second, but figured that my bags wouldn’t make it even if I did, so I decided to play it safe.

The transfer desk in Madrid couldn’t issue me a boarding card for Las Palmas, so with 35 minutes transfer time, I would have to find the transfer desk, get a boarding pass, and hope that both my bags and I made it to the plane on time. I was not optimistic. After checking in, I bought a nice bottle for the SMASHED meeting, a Yamazaki 10yo.

Landed in Bilbao (the approach looks beautiful, I really want to visit the Basque country now), and found that there was no transfer desk. I had to go past security, with my newly purchased bottle of Yamazaki, check in, go back through security, and have my bags and I both make the plane. I have learned over time that the quality of hustle is important in airports. Relax when things are beyond your control, and when you can do something about it, run. So I ran. Headless chicken style.

An airport attendant who took pity on my cause very kindly brought me out through the security check-point, and I left my whiskey with the security guard. Ran to the first check-in counter I found to ask where I could check in for my flight. And by complete coincidence, the girl who was supposed to be manning the check-in desk had stepped away, since the flight was almost closed, to chat with her friend, who was minding the check-in desk I ran to.

Checked in, registered baggage tags to get the bags on the plane, back through security, got my whiskey back, ran to the plane, and (with take-of delayed a few minutes) felt much more confident about making it to the islands that night, with baggage in tow. Be thankful for the kindness of strangers. And it’s better to be born lucky than rich. All in all, a day made much better by the desire of everyone I met to be nice & helpful, in spite of the bureaucracy they work under.

Landed, picked up my bags, got a taxi to the hotel, and dropped them off. Said hello to someone with a laptop in the lobby (Hi mpt!), and ran to the welcome party to see if anyone was left, as it was now almost midnight local time.

I forgot this was Spain.

I met lots of people on the way. Lots of people (but no free beer) were still at the party. Talked briefly with Stormy, Lefty and family, Quim, Oskari, Henri, Sebas, Richard Dale, Rob Taylor and many more over a couple of nice beers. Thanks Canonical for the t-shirt and for the party, a great time was had. Home & to bed by 3. So endeth day 0.

Gran Canaria wrap-up 1

First in a long series that will probably get finished next June, just in time for the next edition

Of course I was aware of the reaction to RMS’s keynote during the conference, and spoke about it with Lefty on a number of occasions.

I have been bothered by the creation of a “meme” which has, apparently, been perpetuated by people who weren’t even at the conference. The meme seems to be speaking more to Richard’s Mono comments (my opinion here) rather than the Emacs virgins segment, but it’s sufficiently ambiguous that I can’t tell.

If people are primarily concerned about the Mono comments, then say so – it’s not useful to conflate two issues. If you’re primarily concerned with the emacs virgin jokes, then for all those who weren’t at the keynote, or who don’t remember exactly what Richard said, go look at it now:

Aside: anyone know how to embed a youtube video on GNOME Blogs?

Richard is sufficiently predictable that he has been giving the same segment, word for word, for many years – last week was my third time to hear it – and to my knowledge this is the first time there has been such outcry.

Personally, I didn’t think it was offensive. As a born & bred (unbelieving) catholic, we’re big into the Virgin Mary ourselves, and while the “relieving them of their emacs virginity” line felt a bit awkward, I didn’t think that the segment was particularly offensive or inappropriate. I could see how others might feel uncomfortable, and so I have no problem with someone who did feel that way taking the point up with Richard directly. Go look at the video, and make up your own mind.

This is to underline a point: Offensiveness is in the eye of the beholder. It is dangerous to jump on a band-wagon about something as significant as whether someone was inappropriate or not if you were not there. I spoke to a number of people who were bothered by the speech, and many more who hadn’t noticed anything in particular, and who laughed along. It’s very easy to jump on a morally outraged bandwagon, without knowing what we’re talking about exactly.

I don’t mind people being morally outraged, I occasionally am myself, but at least make sure you are before you get in a huff. I have a lot more respect for Lefty, Chani and others who were at the conference than the sheep jumping on the issue as an easy way to take a pot-shot at the FSF and Richard Stallman. Oh – and for all the Boycott Novell crowd that are jumping on this as a way to get at people who support Mono, the same thing I said earlier goes for you too – conflating the issues isn’t helpful, in fact it’s inflammatory, stop harming our community with your bad behaviour.

By the way, the “Stop sexism” sign referred to a presentation in a rails conference, where a guy was using scantily clad glamour model shots to illustrate his talk about how “hot” rails was, IIRC. A bunch of rails heavyweights including DHH jumped in to defend him against the “thin-skinned” crowd. Is a parody of the christian church comparing an editor to a god really on the same scale? I dunno, maybe. Like I said, I can see how some people might not like it, but it didn’t bother me.

Can we move on now?

Update: Before moving on, one thing needs clarification. Let me emphasise one thing I said above: while I personally didn’t find RMS’s Emacs virgins segment offensive, I can see how others might. Taking someone to task because they were made uncomfortable by something is never acceptable. Accept that they were made uncomfortable, explain that it wasn’t intentional, apologise, move on. As I said, being offended is in the eye of the beholder. Other people are just as entitled to feel uncomfortable as you are to be unoffended. So to all those posting comments in Chani, Lefty and others’ blogs telling them to grow a thicker skin, get a life, or whatever other bile you’ve been spewing, think about that. And then don’t post the comment.

Maemo Summit – help make it great

This year, I’ve been asked to help with the content selection for the Maemo Summit, which will be held in October, in Amsterdam. We’re aiming for a very cool conference with lots of tips, tricks, hacks and general hardware coolness over 3 days.

Nokia is organising the first day, and the second and third days are entirely organised by the community. After a round of discussion, myself, Valerio Valerio and Jamie Bennett will be choosing content for the summit from among presentations proposed by the community. We’re aiming for presentations which will target three main audiences: tablet users, application developers and platform developers.

You can read more about the call for content or how to submit a presentation on the Maemo wiki. We’ve agreed on a fairly novel way of filling the schedule – we are starting from an empty grid, with three tracks, a couple of plenary sessions, and some lightning talks. As great talks come in, we will add them directly to the grid. If we don’t think that talks are up to scratch, they will be rejected, the submission will move to the Talk page for the Submissions wiki page, and if we are hesitant, the proposals will stay in the Submissions queue.

This has some great benefits over the usual call for papers/deadline/selection/publish the entire schedule scheme of things. Most proposers will know straight away whether their talk has been accepted, rejected, or converted into a lightning talk. Attendees will see the schedule building up and be able to propose sessions to account for topics that are not yet accounted for. And we will be able to keep some small number of slots until quite late in the organisation cycle for “late breaking news” – those great presentations that arrive too late for your deadline, but which you would really love to see get onto the schedule. And it is a kind of auction system – you have a great interest in getting your presentation proposal in early, rather than waiting for the last minute.

Anyway – let’s see how it works. You can follow the progress of the schedule on the wiki as well.

Good luck to all!

Too many platforms?

Fabrizio Capobianco of Funambol wondered recently if there are too many mobile Linux platforms.

The context was the recent announcement of oFono by Intel and Nokia, and some confusion and misunderstanding about what oFono represents. Apparently, several people in the media thought that oFono would be Yet Another Complete Stack, and Fabrizio took the bait too.

As far as I can tell, oFono is a component of a mobile stack, supplying the kind of high-level API for telephony functions which Gstreamer does for multimedia applications. If you look at it like this, it is a natural compliment to Moblin and Maemo and potentially a candidate technology for inclusion in the GNOME Mobile module set.

Which brings me to my main point. Fabrizio mentions five platforms besides oFono in his article: Android, LiMo, Symbian, Maemo and Moblin. First, Symbian is not Linux. Of the other four, LiMo, Maemo and Moblin share a bunch of technology in their platforms. Common components across the three are: The Linux kernel (duh), DBus, Xorg, GTK+, GConf, Gstreamer, BlueZ, SQLite… For the most part, they use the same build tools. The differences are in the middleware and application layers of the platform, but the APIs that developers are mostly building against are the same across all three.

Maemo and Moblin share even more technology, as well as having very solid community roots. Nokia have invested heavily in getting their developers working upstream, as has Intel. They are both leveraging community projects right through the stack, and focusing on differentiation at the top, in the user experience. The same goes for Ubuntu Netbook Edition (the nearest thing that Moblin has to a direct competitor at the moment).

So where is the massive diversity in mobile platforms? Right now, there is Android in smartphones, LiMo targeting smartphones, Maemo in personal internet tablets and Moblin on netbooks. And except for Android, they are all leveraging the work being done by projects like GNOME, rather than re-inventing the wheel. This is not fragmentation, it is adaptability. It is the basic system being tailored to very specific use-cases by groups who decide to use an existing code base rather than starting from scratch. It is, in a word, what rocks about Linux and free software in general.

Community analysis as risk management

Recently I’ve had a number of conversations with potential clients which have reinforced someting which I have felt for some time. Companies don’t know how to evaluate the risk associated with free software projects.

First, a background assumption. Most software built in the world, by a large margin, is in-house software.

IT departments of big corporations have long procurement proceses where they evaluate the cost of adopting a piece of infrastructure or software, including a detailed risk analysis. They ask a long list of questions, including some of these.

• How much will the software cost over 5 years?
• What service package do we need?
• How much will it cost us to migrate to a competing solution?
• Is the company selling us this software going to go out of business?
• If it does, can we get the source code?
• How much will it cost us to maintain the software for the next 5 years, if we do?
• How much time & money will it cost to build an equivalent solution in-house?

There are others, but the nub of the issue is there: you want to know what the chances are that the worst will happen, and how much the scenario will cost you. Companies are very good at evaluating the risk associated with commercial software – I would not be surprised to learn that there are actuarial tables that you can apply, knowing how much a company makes, how old it is and how many employees it has which can tell you its probability of still being alive in 1, 3 and 5 years.

Companies built on free software projects are harder to gauge. Many “fauxpen source” companies have integrated “community” in their sales pitch as an argument for risk mitigation. The implicit message is: “You’re not just buying software from this small ISV, if you choose us you get this whole community too, so you’re covered if the worst happens”. At OSBC, I heard one panellist say “Open Source is the ultimate source escrow” – you don’t have to wait until the worst happens to get the code, you can get it right now, befor buying the product.

This is a nice argument indeed. But for many company-driven projects, it’s simply not the case that the community will fill the void.  The risk involved in the free software solution is only slightly smaller than buying a commercial software solution.

And what of community-driven projects, like GNOME? How do you evaluate the risk there? There isn’t even a company involved.

There are a number of ways to evaluate legal risk of adopting free software – Black Duck and Fossology come to mind. But very little has been written about evaluating the community risks associated with free software adoption. This is closely associated to the community metrics work I have pointed to in the past – Pia Waugh and Randy Metcalfe’s paper is still a reference in this area, as is Siobhan O’Mahony and Joel West’s paper “The Role of Participation Architecture in Growing Sponsored Open Source Communities”.

This is a topic that I have been working on for a while now in fits and starts – but I think the time has come to get the basic ideas I use to evaluate risk associated with free software projects down on paper and out in the ether. In the meantime, what kinds of criteria do my 3 readers think I should be keeping in mind when thinking about this issue? Do you have references to related work that I might not have heard about yet?

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?

Copyright assignment and other barriers to entry

Daniel Chalef and Matthew Aslett responded to my suggestion at OSBC that copyright assignment was unnecessary, and potentially harmful, to building a core community around your project. Daniel wrote that he even got the impression that I thought requesting copyright assignment was “somewhat evil”. This seems like a good opportunity for me to clarify exactly what I think about copyright assignment for free software projects.

First: copyright assignment is usually unnecessary.

Most of the most vibrant and diverse communities around do not have copyright assignment in place. GIMP, GNOME, KDE, Inkscape, Scribus and the Linux kernel all get along just fine without requesting copyright assignment (joint or otherwise) from new contributors.

There are some reasons why copyright assignment might be useful, and Matthew mentions them. Relicencing your software is easier when you own everything, and extremely difficult if you don’t. Defending copyright infringement is potentially easier if there is a single copyright holder. The Linux kernel is pretty much set as GPL v2, because even creating a list of all of the copyright holders would be problematic. Getting their agreement to change licence would be nigh on impossible.

Not quite 100% impossible, though, as Mozilla has shown. The relicencing effort of Mozilla took considerable time and resources, and I’m sure the people involved would be delighted not to have needed to go through it. But it is possible.

There is another reason proponents say that a JCA is useful: client indemnification. I happen to think that this is a straw man. Enterprise has embraced Linux, GNOME, Apache and any number of other projects without the need for indemnification. And those clients who do need indemnification can get it from companies like IBM, Sun, Red Hat and others. Owning all the copyright might give more credibility to your client indemnification, but it’s certainly not necessary.

There is a conflation of issues going on with customer indemnification too. What is more important than the ownership of the code is the origin of the code. I would certainly agree that projects should follow decent due dilligence procedures to ensure that a submission is the submitter’s own work, and that he has the right or permission to submit the code under your project’s licence. But this is independent of copyright assignment.

Daniel mentions Mozilla as an example of a non-vendor-led-project requiring copyright assignment – he is mistaken. The Mozilla Committer’s Agreement (pdf) requires a new committer to do due dilligence on the origin of code he contributes, and not commit code which he is not authorised to do. But they do not require joint copyright assignment. Also note when the agreement gets signed – not on your first patch, but when you are becoming a core committer – when you are getting right to the top of the Mozilla food chain.

Second: Copyright assignment is potentially harmful.

It is right and proper that a new contributor to your project jump through some hoops to learn the ways of the community. Communities are layered according to involvement, and the trust which they earn through their involvement. You don’t give the keys to the office to a new employee on day one. What you do on day one is show someone around, introduce them to everyone, let them know what the values of your community are.

Now, what does someone learn about the values of your community if, once they have gone to the effort to modify the software to add a new feature, had their patch reviewed by your committers and met your coding standards, the very next thing you do is send them a legal form that they need to print, sign, and return (and incidentally, agree with) before you will integrate their code in your project?

The hoops that people should be made to jump through are cultural and technical. Learn the tone, meet the core members, learn how to use the tools, the coding conventions, and familiarise yourself with the vision of the community. The role of community members at this stage is to welcome and teach. The equivalent of showing someone around on the first day.

Every additional difficulty which a new contributor experiences is an additional reason for him to not stick around. If someone doesn’t make the effort to familiarise himself with your community processes and tools, then it’s probably not a big deal if he leaves – he wasn’t a good match for the project. But if someone walks away for another reason, something that you could change, something that you can do away with without changing the nature of the community, then that’s a loss.

Among the most common superfluous barriers to entry that you find in free software projects are complicated build systems or uncommon tools, long delays in having questions answered and patches reviewed, and unnecessary bureaucracy around contributing. A JCA fits squarely into that third category.

In a word, the core principle is: To build a vibrant core developer community independent of your company, have as few barriers to contributing as possible.

There is another issue at play here, one which might not be welcomed by the vendors driving the communities where I think a JCA requirement does the most harm. That issue is trust.

One of the things I said at OSBC during my presentation is that companies aren’t community members – their employees might be. Communities are made up of people, individual personalities, quirks, beliefs. While we often assign human characteristics to companies, companies don’t believe. They don’t have morals. The personality of a company can change with the board of directors.

Luis Villa once wrote “what if the corporate winds change? … At that point, all the community has is the license, and [the company]’s licensing choices … When [the company] actually trusts communities, and signals as such by treating the community as equals […] then the community should (and I think will) trust them back. But not until then.”

Luis touches on an important point. Trust is the currency we live & die by. And companies earn trust by the licencing choices they make. The Apache Foundation, Python Software Foundation and Free Software Foundation are community-run non-profits. As well as their licence choices, we also have their by-laws, their membership rules and their history. They are trusted entities. In a fundamental way, assigning or sharing copyright with a non-profit with a healthy governance structure is different from sharing copyright with a company.

There are many cases of companies taking community code and forking commercial versions off it, keeping some code just for themselves. Trolltech, SugarCRM and Digium notably release a commercial version which is different from their GPL edition (Update: Several people have written in to tell me that this is no longer the case with Trolltech, since they were bought by Nokia and QT was relicenced under the LGPL – it appeared that people felt clarification was necessary, although the original point stands – Trolltech did sell a commercial QT different from their GPL “community” edition).

There are even cases of companies withdrawing from the community completely and forking commercial-only versions of software which had previously released under the GPL. A recent example is Novell‘s sale of Netmail to Messaging Architects, resulting in the creation of the Bongo project, forked off the last GPL release available. In 2001, Sunspire (since defunct) decided to release future versions of Tuxracer as a commercial game, resulting in the creation of Planet Penguin Racer, among others, off the last GPL version. Xara dipped their toes releasing most of their core product under the GPL, but decided after a few years that the experiment had failed. Xara Xtreme continues with a community effort to port the rendering engine to Cairo,  but to my knowledge, no-one from Xara is working on that effort.

Examples like these show that companies can not be trusted to continue developing the software indefinitely as free software. So as an external developer being asked to sign a JCA, you have to ask yourself the question whether you are prepared to allow the company driving the project the ability to build a commercial product with your code in there. At best, that question constitutes another barrier to entry.

At OSBC, I was pointing out some of the down sides of choices that people are making without even questioning them. JCAs are good for some things, but bad at building a big developer community. What I always say is that you first need to know what you want from your community, and set up the rules appropriately. Nothing is inherently evil in this area, and of course the copyright holder has the right to set the rules of the game. What is important is to be aware of the trade-offs which come from those choices.

To summarise where I stand, copyright assignment or sharing agreements are usually unnecessary, potentially harmful if you are trying to build a vibrant core developer community, by making bureaucracy and the trust of your company core issues for new contributors. There are situations where a JCA is merited, but this comes at a cost, in terms of the number of external contributors you will attract.

Updates: Most of the comments tended to concentrate on two things which I had said, but not emphasised enough. I have tried to clarify slightly where appropriate in the text. First, Trolltech used to distribute a commercial and community edition of QT which were different, but as the QT Software Group in Nokia, this is no longer the case (showing that licencing can change after an acquisition (for the better), as it happens. Second, assigning copyright to a non-profit is, I think, a less controversial proposition for most people because of the extra trust afforded to non-profits through their by-laws, governance structure and not-for-profit status. And it is worth pointing out that KDE eV has a voluntary joint copyright assignment for contributors that they encourage people to sign – Aaron Seigo pointed this out. I think it’s a neat way to make future relicencing easier without adding the initial barrier to entry.

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!