Text only | Skip links
Search 
WebWikiAll

1. 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

2. 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

3. Example: JadeTeX

screen dump of JadeTeX project on Sourceforge showing low activity

4. 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

5. Three views on communities

Leadership:
You need a leader, but you also need a structure to allow power to be transferred
Communication:
‘If you build it, they will come’: no, they won't
Participation:
A project needs a range of participants

6. 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?

7. Communities

  1. Are you clear about the kind of community you want to grow and why? Sort yourself out first.
  2. 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.
  3. 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.

8. 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.

9. 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.

10. 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.

11. Top ten tips to have a nice community

  1. 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

12. the other 9

  1. Have a web site with a forum in which people can post queries and suggestions. Read the posts!
  2. Make your software internationalized. You want those Brazilian and Chinese developers.
  3. 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).
  4. Set up a structure in which people of all levels can assist (a Wiki for documentation is a useful tool).
  5. 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.
  6. Delegate. A community with one leader through whom everything flows is offputting.
  7. 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.
  8. Be sexy: a good name, a good logo, good press-cuttings, T-shirts, etc are not optional extras.
  9. Make sure someone writes a proper book about your software
  10. Always put 10 items in a list
Date: Mon, 22 Mar 2010 (first published November 2004)
Last reviewed: November 2005
Author: Sebastian Rahtz

Unless otherwise indicated, this page is © 2004-2010 University of Oxford.
Creative Commons licence It is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
JISC logo OSS Watch is funded by the Joint Information Systems Committee.
OSS Watch values your input and questions.
If you have feedback on this document, or any OSS Watch activity, please send it to: info@oss-watch.ac.uk
Follow our tweets via the OSS Watch twitter account at http://twitter.com/osswatch