Just finished reading feminist activist Jo Freeman’s article, written in 1970, called The Tyranny of Structurelessness. She argues there is no such thing as a structureless group, and that structurelessness tends to be invoked to cover up or obscure — and cannot eliminate — the role, nature, ownership and use of power within a group.

The article is worth reading, especially for advocates of open (open-source and openspace/unconference). Occasionally I hear advocates of open source — and more frequently hear organizers of unconferences/openspaces — argue that because of the open, unstructured nature of the process, they are more democratic than alternatives. Freeman’s article is worth reading as it serves as a useful critique of the limits of open as well as a reminder that open groups, organizations and processes are neither structureless, nor inherently democratic. Claiming either is at best problematic; at worst it places the sustainability of the organization or effort in jeopardy. Moreover, recognizing this reality doesn’t make being open less powerful or useful, but it does allow us to think critically and have honest conversations about to what structures we do want and how we should manage power.

It’s worth recognizing that Freeman wrote this article because she did want feminist organizations to be more democratic (whereas I do not believe open source or unconferences need to be democratic), but this does not make her observations less salient. For example, Freeman’s article opens with an attack on the very notion of structurelessness:

“…to strive for a ‘structureless’ group is as useful and as deceptive, as to aim at an ‘objective’ news story, ‘value-free’ social science or a ‘free’ economy. A ‘laissez-faire’ group is about as realistic as a ‘laissez-faire’ society; the idea becomes a smokescreen for the strong or the lucky to establish unquestioned hegemony over others. This hegemony can easily be established because the idea of ‘structurelessness’ does not prevent the formation of informal structures, but only formal ones.”

This is an important recognition of fact, one that challenges the perspective held by many “open” advocates. In many respects, unconferences and some open source projects are reactions to the challenges and limitations of structure — a move away from top-heavy governance that limits creativity, stifles action and slows the flow of information. I have personally (and on many occasions) been frustrated by the effect that the structure of government bureaucracies can have on new ideas. I have seen how, despite a clear path for how to move an idea to action, the process nonetheless ends up snuffing the idea out before it can be acted upon — or deforms it to the point of uselessness.

But I have also experienced the inverse. I’ve personally experienced the struggle of trying to engage/penetrate an open source community. Who I should talk to, how to present my ideas, where to present them — all often have rules (of which, within Mozilla, I was usually informed by friends on the inside — while occasionally I discovered the rules awkwardly, after grossly violating them). Most open source communities I know of — such as Mozilla or Canada25 —  never claimed (thankfully) to be democratic, but there is an important lesson here. Recognizing the dangers of too much (or rather the wrong) structure is important. But that should not blind us to the other risk — the danger outlined above by Freeman for feminists in 1970: that in our zeal to avoid bad structure, we open advocates begin to pretend that there is no structure, or no need for structure. This is simply never the case. No matter what, a group structure exists, be it informally or formally. The question is rather how we can design a flexible structure that meets our needs and enables those whom we want to participate, to participate easily.

The danger is real. I’ve been to unconferences where there are those who have felt like insiders and others who have known they were outsiders. The same risk – I imagine – exists for open source projects. This isn’t a problem in and of itself – unless those who become insiders start to be  chosen not solely on account of their competence or contribution, but because of their similarities, shared interests, or affableness to the current set of insiders. Indeed, in this regard Freeman talks very intelligently about “elites”:

“Elites are not conspiracies. Seldom does a small group of people get together and try to take over a larger group for its own ends. Elites are nothing more and nothing less than a group of friends who also happen to participate in the same political activities. They would probably maintain their friendship whether or not they were involved in political activities; they would probably be involved in political activities whether or not they maintained their friendships. It is the coincidence of these two phenomena which creates elites in any groups and makes them so difficult to break.”

This is something I have witnessed both within an open source community and at an unconference. And this is not bad per se. One wants the organizers and contributors in open projects to align themselves with the values of the project. At the same time, however, it becomes easy for us to create proxies for shared values — for example, older people don’t get unconferences so we don’t ask them, or gloss over their offers  to help organize. Those who disagree with us becomes labelled trolls. Those who disagree sharply (and ineffectively) are labelled crazy, evil or stupid (or assumed to be suffering from asperger’s syndrom). The challenge here is twofold. First, we need to recognize that while we all strive to be meritocratic when engaging and involving people we are often predisposed to those who act, talk and think like us. For those interested in participation (or, for example, finding the next million mozillians) this is of real interest. If an open source community or an unconference does want to grow (and I’m not saying this should always be a goal), it will probably have to grow beyond its current contributor base. This likely means letting in people who are like those already participating.

The second challenge isn’t to make open source communities more democratic (as Freeman wished for the feminist movement) but to ensure that we recognize that there is power, we acknowledge which individuals hold it, and we make clear how they are held accountable and how that power is transitioned.  This can even be by dictate — but my sense is that whatever the structure, it needs to be widely understood by those involved so they can choose, at a minimum, to opt out (or fork) if they do not agree. As Freeman notes, acting like there is no power, no elite or no structure does not abolish power. “All it does is abdicate the right to demand that those who do exercise power and influence be responsible for it.”

In this regard a few thoughts about structure come to mind:

1. Clarity around what creates power and influence. Too often participants may not know what allows one to have influence in an open setting. Be clear. If, in an open source community, code is king, state it. And then re-state it. If, in an unconference, having a baseline of knowledge on the conference subject is required, state it. Make it as clear as possible to participants what is valued and never pretend otherwise.
2. Be clear on who holds what authority, why, and how they are accountable. Again, authority does not have to be derived democratically, but it should be as transparent as possible. “The bargain” about how a group is being governed should be as clear to new contributors and participants as possible so that they know what they are signing for. If that structure is not open to change except by an elite, be honest about it.
3. Consider encoding ideas 1 and 2 into a social contract that makes “the bargain” completely clear. Knowing how to behave is itself not unimportant. One problem with the “code is king” slogan is that it says nothing about behaviour. By this metric a complete jerk who contributes great code (but possibly turns dozens if not hundreds of other coders off of the project) could become more valued then a less effective contributor who helps new coders become more effective contributors. Codifying and enforcing a minimum rule-set allows a common space to exist.
4. Facilitate an exit. One of the great things about unconferences and open source is the ability to vote with one’s feet and/or fork. This means those who disagree with the elite (or just the group in general) can create an alternative structure or strike up a new conversation. But ensure that the possibility for this alternative actually exists. I’ve been to unconferences where there was not enough space to create a new conversation – and so dominating conveners tortured the participants with what interested them, not the group. And while many open source projects can be forked, practically doing so is sometimes difficult. But forking – either an open source project or a conference conversation – is an important safety valve on a project. It empowers participants by forcing elites to constantly ensure that community members (and not just the elites) are engaged or risk losing them. I suspect that it is often those who are most committed (a good thing) but feel they do not have another choice (a bad thing) who come to act like resentful trolls, disrupting the community’s work.

Again, to be clear, I’m using Freeman’s piece to highlight that even in “open” systems there are structures and power that needs to be managed. I’m not arguing for unconferences or open source communities to be democratic or given greater structure or governance. I believe in open, transparency and in lightest structures possible for a task. But I also believe that, as advocates of open, we must constantly be testing ourselves and our assumptions, as well as acknowledging and debating practises and ideas that can help us be more effective.