We are getting to a point where the noise level of the open web community is getting so loud, people can no longer think. When Brad Fitzpatrick wrote about the social graph, I was one of those who thought it was a great thought provoking essay that will help move us closer to a better social web experience. I would like to take that back, and it has nothing to do with Brad his post.
I would go as far as claim that his post triggered the biggest time wasting flurry among open web thinkers. Just look at how many useless projects were launched, how many silly profile aggregators, XFN parsers, social network mapping tools, data export tools, open standards, and on and on. How about we end 2007 with a celebration of shutting down half the groups, projects, and efforts so we can better focus our limited resources on things that matter and will get us move forward. If you think I am talking about you, you are probably right, but this is aimed at many smart, dedicated, and cool individuals I have talked to and met over the past 6 months.
I am not a fan of big statements, predictions, inspiring essays, blog posts about new eras, or anything academic. I like small, well defined, and useful tools I can accomplish. What made OAuth a success, more than any recent community-driven effort, was the focus, militant at times, on a single, well defined problem. OAuth didn’t start with 350 members. If it did it would still be trying to get a second draft out. A tiny group of people came together and worked hard to keep the effort small. When they had something to show, they slowly opened it up to others, but still kept a strong hold over the effort. This has been the experience with most successful open source projects.
To me, one of the best hours spent talking about the social web was at the Data Sharing Summit, talking about ‘the problem’. It wasn’t yet another daydreaming session in which everyone drooled over geeky ideas that most web users could not care less about. It was a simple list of annoying tasks and missing functionality. It also showed that many of the items on the list were not really worth the effort of solving them.
People talk about social networks fatigue, but maybe it is coming from being unable to decide what it is we are trying to solve? Personally, I think the objective is narrow. Just like IM, I don’t need another service and I don’t need an easy way to move my buddy list around. What I want is use the network that works for me, and be able to reach out to friends in other networks. In the context of social networks, this has mostly to do with giving permissions to resources. Allowing friends to contact me, see my pictures, videos, and who my other friends are. Reuse what I have, not copy or move it around.
Let’s face it, how many of your social networks could be consolidated if they would offer a Facebook application or OpenSocial widget instead of yet another site? Learn from the OpenID marketing rhetoric about how companies should focus on their core business, instead of wasting time implementing identity management solutions. Why aren’t we complaining about companies creating new silos, instead of why their silos are not being open enough?
All this talk about breaking down the silos, freeing data, and putting the user in control has got to stop. It sounds as silly as putting your money in a 2 years CD and then starting a community campaign to force your bank to waive the penalty fee when you realize you need the money sooner. The solution to social networking fatigue is not cool technologies to make moving around easier. It is building better products that focus on the need, and that might mean writing widgets for existing networks rather than starting new ones.
Why not learn from the experience of the community from the last social technology evolution – instant messaging. What started as a single vendor product, was quickly adopted by others as separate walled gardens. Each instant messaging platform offered similar features, but used very different protocols, and has consistently refused to open up or share. Even now, there is no federation across most networks. Instead, vendors build gateways allowing some limited functionality that doesn’t really solve the problem. But very few people actually care about this anymore. How come?
How did the community respond to that? By launching two separate efforts, each focused on a very specific objective. One was the effort of hacking the IM networks to figure out their protocols and build third party tools. The second was to create an alternative solution under the Jabber umbrella that is built on open standards and creates a simple yet powerful IM network, using email as a model.
At some point, the two efforts produces gateways from the Jabber world into the proprietary networks. Even today many of these solutions are operating as hacks, not as fully supported technologies. Jeremie Miller started Jabber in 1998, and in 2005 – 7 years later – Google adopted it as their technology for GTalk. Suggest waiting 7 years to anyone working on these open web efforts, and they will roll their eyes and go back to their 76 projects.
Many will claim this is exactly what they are doing now, with regard to social networks. But unlike the IM effort which was extremely focused, the open web community is all over the place. Every single day I read about a new project, a new protocol, a new something that is going to waste people’s time. Many of these are actually good ideas, but in order to get attention, they describe themselves with so much buzz and splendor, that no one can figure out what they are really about. Then of course, the members of these projects can’t commit to few efforts, and join everything, just to make sure they don’t miss out on the project that might make it.
In the protocols space, we are suffering from the committee-of-one syndrome, where specs are proposed and written to address the needs of a single entity. When Microsoft does that they are evil, but when the open web community does exactly the same thing, just without the IP lawyers, they are true visionaries. Go check the OAuth list, OpenID list, and other similar efforts for how many feature requests people made (and argued about) that are specific to nothing but their own product. And then of course we got those calling for new standards to replace one that are barely even released.
But while the objective is simple, the solution isn’t. But then again, it wasn’t easy when the first few people wanted to get into the IM networks. However, they didn’t write long blog posts, created massive Google Groups, announced the need for new protocols, declared the coming of a new era, and spend their days and nights complaining. They created small projects and started hacking those services. Someone wrote a proposal for a new service, wrote a simple implementation, and presented it. Do, present, get feedback, rinse and repeat.
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. I think OAuth has been a great accomplishment of the openness community in 2007 and I’m looking forward to more great work in 2008. Just hoping for a little less noise.