Alex and I have been going back and forth in comments over the areas of our interest that overlap. In his recent post, he asks, “how long can organic communities self-moderate?”
I admit that I haven’t read the Starfish and the Spider, although I did just one-click it into my Kindle, so it’s doomed to suffer my analysis. Nevertheless, I had some comments about how leaderless organizations can thrive, particularly in open source communities, of which I happen to be a part of a couple.
Obviously, one of my passions is working with Habari and the people that have come together around that common goal. When we started, there were just four of us, each with various levels of ability and availability. I think you can pretty well call that “leaderless”, since we all worked in tandem, and any small change any one person made was easily detected and reviewed by the other three. But as the project has grown, I think there is some kind of tragic irony in that the size of the operation inevitably leads toward a need for at least an informal management structure.
Of course, any of the Habari folks reading would rightfully start screaming at my last statement. The cornerstone of our philosophy is that no animal is more equal than any other. Still, without naming myself supreme ruler of the project, I think there remains a practical aspect to several individuals having responsibility for making things work and controlling the direction development takes.
What I’ve always hoped with Habari is that the community would fracture, but in a good way, and that the different aspects of the system would be able to communicate with each other in a way that is productive for the whole. An example of this came up today regarding our published documentation.
We’ve been using TiddlyWiki for our distributed documentation - the manual - which is supplied with the source of the software, separate from the online wiki. Basically, the large online docs have been distilled into a neat little dynamic wiki manual that comes with the software. A few folks who are less technically inclined decided to make documentation their project, and upon reviewing what we had, concluded that the manual was nice but not internally consistent, because it simply pulls parts of the larger wiki. As a result, they have started rewriting the manual as a single cogent file.
Following pointing out this effort on IRC today, I was asked by the person who originally suggested TiddlyWiki for the manual as to why we were dropping TiddlyWiki. My response to him was basically that some folks had decided to own it, and what they were doing was probably better for the project in the long run, and how could I not support that? And I think he agreed with my reasoning. But also, a personal reason - one that might or might not have been implied - was that I didn’t really want to have anything to do with the manual.
I long ago realized that I simply can’t keep the whole project in my mental scope any more. Back when it was just four guys, I could keep track of every change. Now there are 25 PMC members, and many, many more contributors and users that supply insights and patches with a regular flow. I can’t possibly track it all in a way that makes my own contributions worthwhile. So I’ve decided that if people come along that want to manage a part of the project, they present their ideas well, show some vision I can get behind, and lead other people to follow them there – I am behind that effort. And those are the people we’re looking to promote to the PMC as leaders anyway.
To that end, we’ve been working out a way of handling when splinter groups want to take on specific tasks like these. We call them “working groups”. The concept may be familiar. We started out with some formal guidelines that explain how the groups must be formed and to whom they report, and many of these processes are followed and documented, but personally I think that even as informal groups these units work fine.
The key feature is that there is always reporting back to the main group. They make plans and present them, and the main group has the opportunity to provide more insight, to join, or to dissent. Although the working groups may go off on their own to implement the plan, they don’t do everything in secret or behind a gate. Anyone has the ability to shift in or out of a working group as his interest dictates.
This has been working well for documentation as well as code. Some of our larger initiatives have started out as branches created by others who want to work on a specific task together. The larger group provides some oversight, but the working group is mostly autonomous until the code is submitted for merging. Then others review the code as necessary.
I suppose it’s easy to quantify the project in terms of output, but longevity has a lot to do with the social formula too.
Completely separate from the users of WordPress, the community of developers for WordPress used to spend quite a lot of time talking on IRC. At some point, because this relationship was not encouraged, the heart of the system died. Now on the WordPress IRC channel, some developers might idle, but it’s mostly a desolate place where people come to ask questions that echo into the oblivion, unanswered.
I assume that the social structure for WordPress has moved elsewhere. Perhaps it’s within Automattic itself, or in the halls of the many competent WordPress consulting companies that have formed. But it has changed over time.
I’m hoping that we’ve made some decisions early on that will affect how Habari lives and works long-term. We may individually have plans for making commercial moves with Habari in the future - not Habari itself but services around it - but the social network (not Facebook, but a network of real people) we’re trying to build will hopefully stay strong until the project is obsolete.
Being a worldwide community, we rely on leaders even in different timezones. When I sleep someone is leading the community. Even when I’m around, I’m not always “present”, and other people fill in. Part of that is related to how the project gives people more control, more involvement. Part is that the people actually care to do it. When the people who are involved don’t care any more, they should move on. I hope that we can keep adding people who care enough to keep things going as much as I do.
I’m not really sure that answers any specific questions, but it’s how things are, and how we’ve managed to survive this long, and hopefully what will keep us moving.
I’ve just finished a science fiction book by Vernor Vinge called “A Deepness in the Sky”, and one of the themes of the book is technological collapse; how civilizations can only live so long and evolve so technically before they implode. The trading race that travels and trades between these civilizations sees everything and deals with everyone. Along the way, they record this knowledge and the knowledge makes them great and lasting. By adhering to a set of social rules and general beliefs, they are able to outlast their customer civilizations. It reminds me quite a lot of what I think organic communities need to survive, not so much that a strict process is followed, but that the entire race of people shares a belief that powers their way of life.
