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.
Introduction
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?
Communities
- 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
- mutuality:
- 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