Barriers to community growth
July 22, 2009 7:01 pm community, freesoftware
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!
July 23rd, 2009 at 12:04 am
Very nice work, even if this seems quite obvious for people who are part of the free software ecosystem since a long time.
About your point about JCA, I think they should not be underestimated. I know some developers that are against it, so they will never send patch if this requires such procedures. And I have also suffered from delay thanks to a copyright assignement for grub 2, that took 3 months to be sent. This can be quite demotivating, but the effect can also be the opposite.
If someone invest time to become part of a community by following a lengthy procedure, he will feel motivated to continue because he invested something in it ( principle of Commitment , afaik ).
July 23rd, 2009 at 12:23 am
One other point worth considering is raising barriers to exit. One of the principles that’s been quite useful to Gentoo is building users’ commitment and dedication to Gentoo simply by installing it, because it’s a lot of work and gives people a sense of accomplishment. But there are many other ways… =)
July 23rd, 2009 at 12:57 am
I just want to commend you on making such an exhaustive and comprehensive list on community building for corporations.
One suggestion I do have, is a direct link in HTML that people can refer and link to for references in e-mails and other blog posts… that is, if you want it to be freely available to the public.
Nonetheless, I appreciate what you’ve done.
July 23rd, 2009 at 1:59 pm
Hello David,
Great work David! I really enjoyed reading the document.
Some additional ideas:
· Is your code well document and structured? It is easy to read and follow?
· There are projects that had code comments in other languages than English. The most famous case is OpenOffice.org (uses German) but they are others. No need to say that targeting a global audience you should use English.
· Do you have public coding guidelines? See for example[1] Mozilla ones. This important to make sure that any code that you develop can be integrated easily.
· On project infrastructure, to have continuous integration is very useful specially if you target multiplaform, like Mono or Mozilla do, or Test Management software (like TestLink)
· I suggest to add a section on Quality Assurance. Including for example if you test cases are public (OpenOffice.org are for example), your unit tests are public (many projects have then public), if you criteria for accepting and prioritizing bugs is properly defined, etc.
· There is many people in the world that does not feel comfortable with English. Do you provide the infrastructure and help for local communities to been easly set up? For example, IRC, forums, blogs and other resources in languages like Spanish, French, etc.
Regards,
Jordi Mas
jmas at softcatala.org
[1] https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide
July 23rd, 2009 at 3:45 pm
Useful document, thanks.
If you’re licensing this using CC BY-SA 3.0 it might be a good idea to change copyright text in the footer to reflect that.
July 23rd, 2009 at 4:36 pm
Nice write up. Might want to check the spelling of “Hippocratic”.
http://en.wikipedia.org/wiki/Hippocratic_Oath
Might not mean that. I think that you mean hypocrite. 🙂
July 23rd, 2009 at 6:19 pm
No, I mean Hippocratic. As in the Hippocratic oath which doctors take, and which contains the principle “first, do no harm”.
July 23rd, 2009 at 7:12 pm
There are some problems with how you’ve written the license for your document. You say in the blog post that it is under CC-BY-SA 3.0, and you include the respective button on the bottom of the title page — but nowhere do you actually include a link to the license text, or even a textual statement that it is under such a license. In fact, starting on page three, you include the phrase: “All rights reserved.” at the bottom of every page, which specifically contradicts any claim of the document being under a CC license. The preferred way to mark PDFs as being CC-licensed is described here: http://wiki.creativecommons.org/XMP
I presume this is an oversight; but it is important, and should be corrected.
Thanks for your attention!
July 23rd, 2009 at 11:23 pm
Useful guidelines. I will just add a few notes on Fedora:
It is Fedora and not Fedora Core. Core and Extra repositories merged back before the release of Fedora 7 and was a important milestone in the Fedora Project.
Also you mention the relationship of packages between Fedora and RHEL, it is useful to note the presence of EPEL
https://fedoraproject.org/wiki/EPEL
July 24th, 2009 at 2:21 am
Some barriers in your PDF:
* Using a sans-serif font.
* Not using black for text.
Don’t make your documentation hard to read.
July 24th, 2009 at 9:57 am
Please note there is no “Fedora Core” since Fedora 7, there is just “Fedora” now.
July 24th, 2009 at 8:15 pm
[…] Barriers to community growth 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. […]
July 28th, 2009 at 12:58 pm
Thank you for this compilation. I find it useful for other types of projects, such as Open Educational Resource projects, crowdsourced books, or community study groups.
One social barrier (or repellent) I’d like to add to your list is too much meta-discussion. The nasty kinds, such as personal attacks, are obviously harmful. But some nice and friendly communities get so boggled down in discussions of building rules, best platforms for communication, rules of conduct, details of copyleft and so on that a fresh person, who came for content, is repelled by all the meta-stuff.