Product SiteDocumentation Site

Chapter 3. How to loosely organize a community

3.1. Community soil - true-isms to grow with
3.1.1. Initial building the soil or 'Get it going'
3.1.2. Ongoing soil support principles or 'Get out of the way'
3.2. Community building tools - just enough to get the job done
3.2.1. Initial tooling or 'Get it going'
3.2.2. Ongoing tools or 'Get out of the way'
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.

3.1. Community soil - true-isms to grow with

You have one of two goals in your community building plans.
  1. You want to create and be central to the success of a community effort.
  2. 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.

3.1.1. Initial building the soil or 'Get it going' Practice radical transparency from day zero

  1. From the earliest project moments all discussions and content (documents) need to be openly available and version controlled.
  2. All discussions and decisions must be done in the open and be archived.
  3. Wiki page changes (such as [[Special:RecentChanges]]) and code commit logs to the mailing list until it becomes annoying.
Do not fall in to 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.
Example needed Get things started immediately with the simplest and most open communication methods available plus a meeting time

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.
  1. Make sure that meeting happens regularly.
  2. 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.
Example needed 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.
  1. At least the leadership needs to blog on relevant technical planets (GNOME, Fedora, etc.)
  2. Social media information feeds aggregated on a page for reference
    1. 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.
Example needed 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.
Example needed Tasks, tasks, tasks or 'Project management matters'

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 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.
Example needed

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

The sign of a true open source leader is they know when to call it quits.
At the Moosewood Restaurant, the collective runs the kitchen using a rotational scheme. A kitchen worker rotates roles:
  1. One week as the head chef -- plan menus, order food, touch each plate before it goes to a diner
  2. One week as the sous chef -- right-hand to the head chef, responsible for food before it leaves the kitchen/line
  3. One week as a line or prep chef -- fixed work station area, run the process and work hard
  4. One week as a dish washer -- nothing like seeing up close what people don't eat
  5. Back to the top
There is no job in the world that a fresh mind and perspective cannot gain from.

Most of us are not Linus Torvalds ...

Most of us are not Linus Torvalds. Don't be afraid to find a leader to replace you.