Eran of Hueniverse has extrapolated 10 helpful rules from his obviously extensive experience of web communities and projects. They seem excellent to me and so I’ll reproduce them here in full for future reference:
Community efforts must adhere to the same rules startups use when trying to build something new. They must be focused, have a clear plan on how they are going to accomplish their goals, and what it is going to take to get there. With that in mind, here are my 10 rules for community driven open-web projects:
- Know what you are trying to solve. Start with a single sentence description of the problem you are going to solve. Stop wasting people’s time by writing long essays about the philosophy of your project and ideas. The more narrow your problem the better. Define the outcome and the most important characteristics.
- Find the right people. Before you open a project to the public, hand pick those you want to be involved. Like any successful business, community efforts must have a strong foundation which is created by getting the right team together. In a way, you are going to need to put a team in place as if you are not building a community at all. It is rare for community members to do more than provide feedback, so you will still need a core group to get stuff done.
- Make it easy for people to join. Don’t start with a wiki, a blog, a group, a website, and a meetup. Pick the one format that works best for your idea. Writing code? Pick a developer oriented solution. Writing specs? A group is all you need. At some point when your project matures, you will need all those other tools, but starting with it just because it makes your project look more real, actually makes it look stupid. If people need to check out 5 different sites to catch up, they will either leave, or contribute the wrong resources.
- Don’t be too nice or too democratic. I’m a big believer in enlightened dictatorship, and it is something every community needs. Give a tiny group of people, 3-5, the power to manage the project, make final decisions, and keep the community on track. It will piss off some people, and they are sure to – you guessed it – start their own new projects that are even bigger and cooler. But your project will stay on track. There is a limit to making decisions by taking votes.
- Set deadlines. Open-ended projects have no motivation to get anything done. Set timelines and do your best to make them. Don’t go too far into the future, and try to limit your effort to few deliverables. People need to see progress to continue putting time into the project.
- Don’t branch out too soon. Almost every single project I read about already has sub-projects going before anything was accomplished. If a member of the community has an idea that doesn’t fit right now, or at all, a better idea is to put it off, rather than split the community resources. This is where #3 comes in – don’t let people hijack your community for their own agenda.
- Let your project grow organically. It is funny how everyone talks about viral marketing but rarely apply that to their own efforts. Letting people find out about your project through members and by experiencing the results of your project is always better than posting about it in every blog comment and other community. If people join a group that has accomplished nothing, they are more likely to try and take over, shift the conversation, and generally have little respect towards the leaders. #3 is easier when people respect you.
- Start with an accomplishment. Starting with an idea or goal is nice, but rarely gets things done. Write some code, a spec draft, a site prototype – anything – just something others can relate to. Point of reference is the single most powerful tool for getting productivity out of a community.
- Don’t be afraid to end a project. If for some reason an effort has not worked out, or did but reached its objectives, don’t recycle the community or force more deliverables just because you have everyone in one place. Most ideas will fail simply because that is the nature of human invention. Recognize that and know when to shutdown a project. The beauty of the internet is that you get to leave behind whatever outputs were created, and that by itself can be a useful lesson. Stale projects are like stale milk. You never buy a one because when you open the fridge it looks like you have milk, and meanwhile that milk is starting to smell.
- Know what you are trying to solve. The first rule is so important, it needs to be repeated. The people you want and need to make your project successful are usually the ones with very little free time. Just like getting funding for a startup, you need to sell them the idea and it needs to be very specific. Remember, you can always get one problem solved and pick another.
Change is driven by need, and so far, the needs of the open social web has not been fully figured out. We don’t need projects to talk and discuss ideas, and we don’t need to give them big names.
Note: There are a couple of issues I have with Eran’s approach to the proliferation of often mismanagement and sometimes pointless web projects – the answer is not to sit it out or wait. Change and improvement happens because someone got pissed off and did it right.