How to Grow a Community

pieterhpieterh wrote on 07 Jun 2011 14:50

chart3.png

There are a few ways people define open source or free software. One is by the license: "yes, we can see the code". Two, is by process: "yes, anyone can contribute". Three is by community: "yes, it's built by all of us". For me, only the last measure counts, and steps one and two are milestones. But they're not sufficient, as many failed projects show. I'll present fifteen measures that I've extracted from years of trying (and sometimes managing) to build self-steering, sustainable communities. You tell me if I'm on the right track here or not.

  • Quality of mission. You need a goal that's brilliant and insane and simple enough to get people out of bed in the morning. Your community has to attract the very best people and that demands something special. With 0MQ, we said we were going to make "the Fastest. Messaging. Ever.", which qualifies as brilliant and insane and simple. If we'd said, we're going to make "a smart transport layer that'll connect your cloud components cheaply and flexibly", people would have said, "ugh, what? why?"
  • Freedom of access. A strong community has to be physically and intellectually diverse. This is a basic lesson from smart crowd theory: too many people with the same mindset and background will make large, well-argued, and elegantly executed mistakes. You need the challenge that ignorance can bring. So removing barriers to entry lets you bring in more diversity. For 0MQ, when we switched to git, and github.com, that dramatically lowered the barrier to entry, and brought more people into the process.
  • Well-written rules. Conflict is inherent in the psychology of collaboration. To avoid destructive fights and arguments, you need clear rules about how to work together. This lets strangers trust each other, and the community to scale beyond people who already know each other. That brings us to our next point, strong authority. For 0MQ, the LGPL license and the git fork/merge model were our basic tools for turning natural competition into constructive collaboration.
  • Strong neutral authority. Rules are useless without enforcement. A community needs to know that someone will enforce the rules if necessary. And without bias, clearly. Again, this creates a trust model that can scale beyond a handful of friends. For 0MQ, the authority was and is those who invested most in the project, which brings us to the next point, ownership.
  • Proportional ownership. "You own what you make" is a powerful incentive for people to invest in a project. It's about more than owning the copyrights on some source code, it's about owning (morally, at least), the communities that in turn depend on what you make. When you create a project, and people use it, you are the boss of that project. For 0MQ, we made it easy for people to build projects (mainly language bindings in the first place) on top of 0MQ, and own those projects. Which brings us to the next point, infinite spaces.
  • Infinite spaces. A single large project with many owners does not scale as well as a collection of many small projects, each with one or two owners. Communities grow best when people can layer project upon project, without limit. This needs some careful thought about what is "official", what gets packaged with what, how visitors can navigate the chaotic result, and so on. For 0MQ, we started with two natural layers (core plus language bindings) and built more and more layers on that. Github.com (which has its flaws) makes this so easy.
  • Strong identities. At least in certain communities, we want to know who to talk to. That means real names and email addresses, not aliases. This goes along with ownership. Some communities seem to thrive on anonymity, and that's possibly a good way to resolve ego conflicts, and get wider participation, but for 0MQ we enforced the rule that contributors must use their real names, and this has seemed to work well.
  • Volunteers, not employees. From my work in volunteer organizations like the FFII, it's blindingly clear that skilled volunteers can produce more accurate answers, and faster, than equally skilled professionals. You need the right mix of desperation, brutality, frugality, time pressure, and independence to be really creative. Employees just don't sit in that space, and no management style can create it for them. 0MQ only became brilliantly brutal when the core team switched over from employees in an office to volunteers working around the globe.
  • Measurements of success. A large motivation for many contributors are the rewards that success brings. Happily they tend to underestimate the problems that can also bring. The best measure of success is "footfall", i.e. how many people are using a project, visit a web site, download the tarballs, etc. Luckily this is easy to do, and platforms like github make it easier. How many watchers does my repository have? How many issues? How many pull requests? And as I've already said, popularity translates into power. In the 0MQ community, your voice is precisely as loud as the number of people using the projects you "own".
  • Tools and processes. We work, in an online community, by taking information about the world and turning that into knowledge in some form (software source code, in our case). How efficiently we can do that depends on the tools and processes we use. 0MQ used to run on SVN, which is better than CVS. But switching to git really made a difference. Much better tools means a faster, more efficient community.
  • Freedom to organize. This is a no-brainer for anyone who actually works in a free community, but it's weird for businesses. Let the participants of a community identify the problems, allocate the resources, and monitor success. It's literally impossible for management to do this as accurately as participants. 0MQ can move faster and more accurately than any commercial product precisely because there is no top-down management.
  • Transparency. In my experience, secrecy enables incompetence, and transparency promotes competence. The more public the organisation's work, the better. This means a culture of on-list discussions, about everything relevant to the project, especially things like rules. It's kind of obvious for any free community but hard for businesses to do.
  • Unstructures. It's tempting to create structure to back a community. We think of copyrights and trademarks, and who owns them. We think of the infrastructure, who runs and pays for it. A classic answer is to create a dot-org, fund it, and use that to hold the rights and operate the boxes. A much better answer is, "everyone owns what they make" and be prepared to move to a new home as and when needed. For 0MQ, iMatix backs the infrastructure, but mostly it's in the cloud: wikidot.com, github.com, jira.com. We use Digistan's peer-to-peer framework for standards. Everyone owns the copyright on what they make. It works, without any tiresome organization building. Trust me, you don't want legal entities if you can avoid them.
  • Scalable participation. It has to be trivial to make a simple contribution, and really, really hard to make a profound contribution, and there should be a smooth curve between these points. You want no barriers at any point, but it must get harder and harder. This makes the community feel like a massive multiplayer game, where there's always someone better than you, and you just have to try to catch up. For 0MQ we never planned this curve, but it happened naturally. I've done other projects where the curve broke halfway, or was too steep, and that's pretty much fatal.
  • Full remixability. Finally, though this is almost the first thing, every work needs to be fully remixable. I've often argued that the GPL is an ultracapitalist tool because it enforces the strictest ownership model possible on collaborative works. If I invest in a GPL project, I know my competitors can't use that without also playing the same game as me. The LGPL is slightly weaker than the GPL but works almost as well. For 0MQ, we chose the LGPL rather than Apache/BSD/MIT because we knew that otherwise people would improve 0MQ, but not share their changes.

Now, here's the fun thing. These measures were my guidelines when designing and streering the 0MQ community, starting back in 2008 or so. They didn't guarantee success, that came from the hard work of many people, such as Martin Sustrik. But they meant the hard work could produce something of value, not just one more perfectly made, and useless, piece of software.

However, none of these measures apply exclusively to free/open source software. A software business could structure its development like this. Allow engineers to choose what they work on, compete, remix each others' work, fight for footfall, etc. Even the "no employees" rule can work in a company, simply pay a low salary and base the rest on results, in a competition model.

Of course no business will ever do this because it'd make the managers largely redundant. But it's fun to imagine what if, e.g. Microsoft took a thousand of its brilliant, brainwashed developers, and let them loose.

Comments

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License