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.
Avoid private discussions
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 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
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.
Example needed
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.
Example needed
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
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
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.
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.
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.
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.
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 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.
