You can’t just make something “open” and expect magic to happen. Openness is a lot of work. This is true whether you’re making an open-source software project, a website with user-generated content, a political movement, a charity, or any other kind of organization where you expect volunteers to show up and start doing work for you.

I emphasize this because openness has become quite the buzzword over the last decade, and I worry that people are starting to attribute near-magical powers to it. I wonder if books like Here Comes Everybody: the Power of Organizing Without Organizations by Clay Shirky, or The Wisdom of Crowds by James Surowiecki are over-selling the idea. Being in Silicon Valley I hear a lot about startups based on a “crowdsourcing” business model, or new open source projects run by people who assume that just because they open-source their code, they’ll magically get contributors. Lately the phrase “… ANYONE can participate!” seems to be de rigueur in every presentation.

Let’s say I’ve got an idea for a software project and I want to make it open source. So I put up a public code repository on my website, write a page about my patch submission policy, and start an email list for discussion. Great! I’m done now, right? I can declare my project “open” and go back to hacking now?

This project may be “open” by a technical definition, but if you look at the commit log, I’m still the only one working on it or using it. Where’s my windfall of free volunteer effort?

If I want to be open in a practical and not just a technical sense, I need to get people interested in participating. That means proselytizing my project, building a community, selling people on the idea: doing marketing. That’s a lot of work right there, and none of it gets code written.

Next, suppose some interested volunteers contact me and ask how they can get involved. If I say “Go read the issue tracker and find something to do, I’m busy”, I guarantee they will not remain interested for long. I need to invest some time in building a connection with each and every volunteer I want to integrate into my project. I need to explain to them how things work, answer their questions, find easy tasks to give them, and continue to act as their mentor until they understand the project as well as I do. I am making a substantial investment up-front that I hope will pay off in the long term. Until then, it’s an additional burden on top of my existing workload.

This should be common sense. Openness is a policy choice, not a replacement for old-fashioned hard work. I happen to think it’s a good policy choice in many cases: An organization that is open to outside ideas and criticism will learn faster about its own mistakes. It can build more trusting relationships with its users, because it doesn’t have to keep secrets. It attracts self-motivated contributors, and it get more diversity of viewpoints. There’s that old mantra about how “with enough eyeballs, all bugs are shallow”. Open-source code can travel farther and do more because there are fewer restrictions on its use. Codebases with an active community can evolve more quickly and not go obsolete so fast. So there are a lot of benefits; but openness is not a free ride.

So when trying to learn from the success of projects like Linux and Wikipedia (and Mozilla, for that matter), don’t stop at “openness”. The questions to ask are: How does a new person discover the project and make their first contribution? How do they discover what work needs to be done? How does the organization make this discovery path easier or harder for people? How does it integrate and organize contributions? How does it set goals? How does it maintain a coherent vision? Under what circumstances does it reject a contribution? Etc.

Successful open organizations aren’t just unorganized mobs. Wikipedia is a highly ordered society, with its own cultural norms and dispute resolution systems and division of labor and everything. Mozilla has a whole Evangelism department, we have IRC channels and mailing lists, we have a system of code reviews and module owners, we have requirements someone must meet before they are granted commit access, we have rather intricate rules for using Bugzilla, and so on.

Advertisement