How to loosely organize a community
(→Practice radical transparency from day zero: "in to" -> "into")
(→Turn over project leaders regularly: Rearranged sentence "There is no job ...")
|Line 184:||Line 184:|
* Back to the top.
* Back to the top.
There is no job in the world that a fresh mind and perspective
There is no job in the world that a fresh mind and perspective.
'''''Most of us are not Linus Torvalds. Don't be afraid to find a leader to replace you.'''''
'''''Most of us are not Linus Torvalds. Don't be afraid to find a leader to replace you.'''''
Revision as of 23:49, 3 July 2010
This chapter explains the basic structure of a community that is succeeding and evolving.
We often call this community growth, with the caveat that healthy growth is not boundless growth.
Control the growth -- you water and feed, but you also prune.
If you look at an open source project with a long history, you see these guiding principles of how to loosely organize a community. Going through the history of the BSD project, you see they discovered and iterated through everything from mailing lists to open access code repositories. Their 30+ year lifespan can be viewed as a stretched out version and variation of the Fedora Project's 15 year lifespan from Red Hat Linux to Fedora Linux.
Community soil - truisms to grow with
You have one of two goals in your community building plans.
- You want to create and be central to the success of a community effort.
- You want to be a catalyst in a community that includes you but is not relying upon your individual or team efforts for survival.
Arguably, the second goal is the preferred goal for any Red Hat community activity that leverages community growth to continuously increase the value of our investment, while not having to increase the actual investment.
When we look at the most successful Red Hat products, they come from projects where Red Hat's relative investment over time remains flat or decreases in comparison to the ongoing value. The Linux kernel forms the core of the Red Hat Enterprise Linux distribution, but Red Hat does not employ the greatest number of kernel contributors, just the ones that do the most work that matters to Red Hat as well as the kernel community.
When we look at Red Hat projects that fail, the early investment was high and stayed high throughout the project's lifespan while the community continued to never appear.
Regardless of which goal you have, the methodology is the same.
Initial soil building or 'Get it going'
Practice radical transparency from day zero
(Short URL: http://bit.ly/TOSWDay0)
- From the earliest project moments all discussions and content (documents) need to be openly available and version controlled.
- All discussions and decisions must be done in the open and be archived.
- Wiki page changes (such as Special:RecentChanges) and code commit logs to the mailing list until it becomes annoying.
Do not fall into the mistake of doing private email discussions to "get things started quickly." You can have all of the needed collaboration tools available within 2 hours and $US15/mon under a custom domain on any number of Linux-based hosting services (at a bare, bare minimum.)
Do not underestimate the importance of the right set of tools available at community start or continuance.
Get things started immediately with the simplest and most open communication methods available plus a meeting time
(Short URL: http://bit.ly/StartingTOSW)
Focus first on enabling communication, then people can self-organize around the work that needs to get done.
Don't try to get everything ready before revealing to the world. Other people want to help get it ready; it won't be any fun if you do all the work before they get there.
- Make sure that meeting happens regularly.
- Use it to discuss tasks, leave tactics and strategy for the mailing list.
- This ensures the widest participation in the important guiding activities (tactics and strategy).
- The meetings become a regular check point/drum beat to ensure progress is made and things are not forgotten.
Start open marketing soonest
You aren't working on a stealth-mode start-up, you are trying to grow an open project. Make appropriate-sized noise at the earliest opportunities.
Remember that it is better to do than to seem. Don't just talk about ideas -- talk about ideas and do stuff about them, too.
- At least the leadership needs to blog on relevant technical planets (GNOME, Fedora, etc.)
- Social media information feeds aggregated on a page for reference.
- If you are like many people, you are the most excited at the beginning of a new venture. That is when you want to set your tone of voice and participation bar, to give yourself the highest open marketing standards to maintain throughout the community life.
This ties back in to Practice radical transparency from day zero.
Quiet projects stay quiet. Noisy projects get noisier.
At this point, you have things moving in some direction, even if it is only three of you discussing things loudly in public.
What is going to draw new people are:
- Interesting parts of the project that match their passions.
- The project itself inspires passion in people.
- Some other passion drives people toward the project.
People find out about this through your rigorously open marketing what you are working on.
What are developers working on and why? Expose every part and reason in a well organized wiki page.
What supportive pieces are not owned or in danger of being orphaned? Make a list and keep it updated.
Tasks, tasks, tasks or 'Project management matters'
(Short URL: http://bit.ly/TOSWTasks)'
The first item on your task list should be, "Write initial task list, prioritize, assign dates and doers."
An updated task list says, "We're getting things done, here's where you can help."
Think of it like putting a few euros and coins in a guitar case when busking (playing for money in public), or seeding a tip (gratuity) jar with a few dollar bills. Entice people to fill in the blanks of a few "Unassigned" items without making it totally scary by being too empty.
One simple project management method is to assign around 50% of the unassigned tasks to the project leader, who then has a lot to delegate when asked.
Too empty is scary. Too full makes it look too late to help. Balance your task list, have at least 60% of your tasks assigned.
If you have more unassigned tasks than 40%, take out some tasks, or mark them as a lower priority. It is a sign that you are reaching too far at this stage. You aren't going to do them anyway, and they can be added back later if still viable.
Make your contribution policy clear and as low as possible
When people want to add some value and do some work in the community, make it as easy and clear and possible to know what is expected of them.
Have one single page that clearly states what the policy is around contributions. It should mention licensing (if any), means and methods, and anything unique to the project.
An example of a unique aspect to a project is where digital art is a product. If a goal is 100% free and open content, then the contribution policy should specify that source components of an image must be 100% freely licensed to be included in the aggregate picture.
The Contribution policy for this wiki is a good (and reusable) example of how to make a clear policy for a wiki.
Ongoing soil support principles or 'Get out of the way'
We presume you are looking to get the most value from your community growth, meaning you understand you want it to scale beyond your ability to be the central person. You are seeking a leaderless organization, or as near as you can make it.
Turn over leadership tasks to natural community leaders
As you lower the barriers to participation, as contributors arise from the participants, natural leaders arise from the contributors.
You can tell a natural community leader:
- They listen when people talk.
- They talk, people listen.
- They get stuff done as much as or more than talking.
- They inspire other people.
- They demonstrate a sense of ownership of part of or the entire project.
- They are eager to own a task or project from the beginning.
- They work and play well with others.
- They show common sense.
- They do not run with scissors.
- They tend not to feed the trolls.
Take that person aside and say, "Hey, you seem to be in charge of/most interested in Foo, can you be the project leader there?" At worst, they say no. At best, you just helped give birth to another community leader. Congratulations!
When Fedora decided to migrate to MediaWiki, the Infrastructure team got an interesting email. Ian Weller wrote, "If you need any help, give me a shout." Turns out he was a minor participant/contributor in Fedora but was passionate about MediaWiki. Within a few weeks, he was debugging migration scripts, writing how-tos, and leading various Fedora teams in best-practices about using MediaWiki. After a highly successful migration and subsequent build-out, Ian was named 'Wiki Czar' in January 2009, nominated by a member of the Community Architecture team.
Turn over project leaders regularly
Often a single person sits in the center of a group of contributors, acting as a go-between, arbiter, soother of feelings, and go-to person. We call such people "project leaders". They are your best friends. They might even be you!
If they are you, you need a six month exit plan.
You may not pull the trigger right away, but you need to be prepared to.
The sign of a true open source leader is they know when to call it quits.
- One week as the head chef -- plan menus, order food, touch each plate before it goes to a diner.
- One week as the sous chef -- right-hand to the head chef, responsible for food before it leaves the kitchen/line.
- One week as a line or prep chef -- fixed work station area, run the process and work hard.
- One week as a dish washer -- nothing like seeing up close what people don't eat.
- Back to the top.
There is no job in the world that cannot gain from a fresh mind and perspective.
Most of us are not Linus Torvalds. Don't be afraid to find a leader to replace you.
Community building tools - just enough to get the job done
Initial tooling or 'Get it going'
Set up a mailing list first
(Short URL: http://bit.ly/TOSWMailList1st)
An open collaboration needs a relatively low barrier to entry communication method that is:
- Open to all to read;
- Open to many to write to;
- Openly archived.
A mailing list fulfills this need.
Bonus for doing it on open infrastructure using open source software.
That is a recursive use of the value of the open source way as experienced through quality software.
Mailman is the de facto standard.
You need a version controlled repository for content - code and documentation and art and etc.
For more information on version control, read Introduction#Version control.
Version control is the insurance that makes you and your contributor community bold.
- This is a code repository (git, Subversion) and a document system that has the lowest barrier to entry (wiki).
- Look at existing best-of-breed hosting, e.g. fedorahosted.org.
- Making giving access to this as easy as possible; do not let the administration fall between the cracks.
Use lightweight, open collaboration tools - wikis, mailing lists, IRC, version control, bug trackers - and give out access
To quickly gain momentum, a series of small and useful tools always trumps a monolithic, inappropriate, hard to use tool.
People are familiar with certain tools already -- give the people what they want.
The tools you start with here are not always going to be be open source. Sometimes you are stuck accepting non-free and open source software solutions in pursuit of a goal you put higher. Be aware that if you choose a non-open solution, you incur additional risk for whatever opportunity you are trying to capture. Make sure that a move to fully open tools is part of your roadmap for the project. These are the parts you cannot compromise or eventually they will be the downfall of your openness and transparency.
Some people will show up to participate no matter what tool you choose. Another group will participate only if the tool is open source, with some preferring popular tools. Why not choose an open, popular solution and capture all groups?
- Default open subscription is the rule.
- Spread admin rights to anyone responsible; try to pair with email@example.com people.
- Encourage people to be bold.
- Don't be afraid to roll back bad decisions, that is what version control is for.
- Be bold yourself.
Ongoing tools or 'Get out of the way'
Improve your infrastructure to improve your project
The community needs to keep finding and building tools, processes, and especially automation.
Automated testing, automated building, automated error checking, lint scanners run on code and content, wiki patrolling, etc.
You do not need to always build all this yourself. For example, projects hosted on fedorahosted.org gain everytime a new project is hosted or Fedora Infrastructure adds features to the web apps or the Fedora community panel.