Building Open Source Communities

by Sebastian Rahtz on 1 November 2004 , last updated

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.


Objective of this talk

  • To remind you why communities matter
  • To look at what makes a community
  • To look at how well Bodington is coming along …but don’t expect answers or miracles today

What’s the problem?

Projects tend to start small, and often go in one of seven directions:

  • stay small: remains a nerd tool
  • gather users but no new developers: frustrated users
  • fragment when primary leader loses interest: unattractive for new people
  • develop power but with minimal documentation: no way to find the power
  • grow within an expert community: high price for admission
  • go commercial: stops being free
  • simply die

Example: JadeTeX

What we aspire to

  • Apache: technical strategy, formal democratic management, enviable reputation
  • Docbook: described in all the books in Blackwells
  • Moodle: tops the rankings in Google
  • Firefox: smooth as butter install, reference implementation
  • uPortal: shared development between academia and business

Three views on communities

Leadership: * You need a leader, but you also need a structure to allow power to be transferredCommunication: * If you build it, they will come: no, they won’tParticipation: * A project needs a range of participants

Community roles

The visionary
has the Big Idea, makes the long-term decisions
The leader
makes the medium-term decisions
The programmer
implements the functionality and makes the short-term decisions
The tester
finds the bugs
The apprentice
programmer fixes the bugs
The documentor
write the manual
The communicator
tells other people how good it all is
The distributor
packages it up for new users to try

How many of these roles can safely be filled by one person?


  • Are you clear about the kind of community you want to grow and why? Sort yourself out first.
  • When people find you, do they (nearly) instantly have a good grasp of what your project is about and how your community works together? Sort out your communications.
  • Are there multiple entry points into your community and is there a clear path of progression through it? If your community is more valuable than your code, then value it.

Why do people work on open source?

The desire to learn technical skills by joining an open project is strong. Typical reasons for staying in OSS are:

  • seeking recognition: 12%
  • improving skills: 32%
  • improving software: 24%
  • ideology 31% A lot of people work on open source because they are paid to by their company. It isn’t all about ideology.

Communities of practice

from the world of learning theory, COPs are:

  • informal networks that emerge from a desire to work more effectively or to understand work more deeply among members of a particular speciality or work group.
  • small groups of people who’ve worked together over a period of time and through extensive communication have developed a common sense of purpose and a desire to share work-related knowledge and experience.
  • communities of apprentices where newcomers learn by gradually going from peripheral participation to full participation in the community. Sound familiar? Is this about Bodington, or about open source communities?

  • Learning is presented as a process of social participation in a community, not as a process of internalization of knowledge by the learner.
  • Legitimate peripheral participation leads to full participation, and this takes place by sociocultural transformations in the context of the shared community of practice.

How to define communities of practice

joint enterprise:
the collective understanding of the community by its members and the accountability to each other
the norms and relationships of members’ mutual engagement
shared repertoire:
the languages, tools, artifacts, etc, produced by the community.

Lave, J. and Wenger, E. (1991), Situated Learning, Legitimate Peripheral Participation, Cambridge, Cambridge University Press.

Top ten tips to have a nice community

  • Tell people in a simple, summary, way what you are up to:

    • This is what the software is supposed to do
    • This is who it is aimed at
    • There are its main features
    • These are the main software or other dependencies
    • Here are some screen shots
    • This is the developer community
    • Here are licence, download and install instructions on the web and on paper

the other 9

  • Have a web site with a forum in which people can post queries and suggestions. Read the posts!
  • Make your software internationalized. You want those Brazilian and Chinese developers.
  • Have a quick start kit or roadmap. Make it possible to get your software running in an hour or less, using temporary software if necessary (Example: uPortal).
  • Set up a structure in which people of all levels can assist (a Wiki for documentation is a useful tool).
  • Establish the ground rules. State the roadmap for future development, but also make it clear when, and how, changes of direction can take place. Apprentices need both structure and challenges.
  • Delegate. A community with one leader through whom everything flows is offputting.
  • Be a good IT citizen. For example, don’t take over a standard TPC/IP port from someone else. Don’t replicate standard software. People will lose faith in you.
  • Be sexy: a good name, a good logo, good press-cuttings, T-shirts, etc are not optional extras.
  • Make sure someone writes a proper book about your software
  • Always put 10 items in a list