Tag Archives: unconference

Structurelessness, feminism and open: what open advocates can learn from second wave feminists

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.

From here to open – How the City of Toronto began Opening up

Toronto the open

For myself, the biggest buzz at ChangeCamp Toronto was that the city showed up with lots of IT staff (much of it quite senior) who were trying to better understand how they could enable others to use their data and help citizens identify and solve problems. In fact the City of Toronto ran what I believe will be seen later as the most enduring sessions in which they asked what data should they start making available immediately (as APIs).

For those not in the know, think of an API as a plug that rather than delivering electricity instead delivers access to a database.

The exciting outcome is that web designers, coders and companies can then use this data to better deliver services, coordinate activities in neighborhoods, make government more transparent, or analyze problems. For example, imagine if all the information regarding restaurants health violations were not hidden deep within a government website (in a PDF format that is not easily searchable by google) but were available on every restaurant review website? Or if road closures were available in a data stream so a google maps application could show which road were closed on any given day – and email you if they were in your neighborhood.

This is the future that cities like Toronto are moving towards. But why Toronto? How did it arrive at this place? How is it that the City of Toronto sent staff to ChangeCamp Toronto?

The emergence of open in Toronto

I’ve tried to map this evolution. I may have missed steps and encourage people to email me or post comments if I have.

evolution of open data TO

The first step was taken when people like David Crow created a forum – Barcamp – around which some of Toronto’s vibrant tech and social tech community began to organize itself. This not only brought the community together but it also enabled unconferences to gain traction as a fun and effective approach to addressing an issue.

Then, in late 2006 the Toronto Transit Commission (TTC) issued an Request For Proposals (RFP) for a redesign of its website. Many in the tech community – who had no interest in doing the redesign – were horrified at the RFP. It was obvious that given the specifications the new website would not achieve its potential. A community self-organized around redesigning the RFP. Others took note and, because they cared about the TTC, wanted to also talk about simple non-website changes the TTC could make to improve services. TransitCamp was this born and – with enormous trepidation, some TTC officials showed up (all of whom should be loudly applauded). The result? The tech and social tech community in Toronto was engaged in civic matters and their activities were beginning to make it onto the city government’s radar.

Other Camps carried on through 2007 and 2008 (think OpenCities), building momentum in the city. Then, in November of 2008 – a breakthrough. The City of Toronto hosted an internal Web 2.0 conference and invited Mark Surman – executive director of the Mozilla Foundation and long time participant in the Toronto social tech space – to deliver the keynote entitled “A City that Thinks like the Web“. After the talk, the Mayor of Toronto stood up and said:

” … I’ve been emailing people about your challenges. Open data for Google Transit is coming by next June, and I don’t see what we shouldn’t open source the software Toronto creates.” He also said “I promise the City will listen” if Torontonians set up a site like FixMyStreet.com

You can hear the Mayor Miller’s full response here:

In short, the Mayor promised to begin talking about opening up (and open sourcing) the city. Freeing up Ryan Merkley and the City of Toronto IT team to attend ChangeCamp

Lessons for ChangeCamp Vancouver

It remains unclear to me whether ChangeCamp is the right venue for tackling this opportunity in Vancouver.

We in Vancouver are not as far along the arc as Toronto is. We do, however, have some advantages. The map is more obvious to us and some of us have good relationships with key staff in the city. However, this process takes time. To replicate the success in Toronto, governments here on the west coast need not only be at ChangeCamp, they need to be running sessions and deeply engaged. For this to occur cultures need to be shifted, new ideas need to percolate within government institutions and agencies and relationships need to be built. All this will take time.


Want to say congratulations to Jay Goldman, Eli Singer and Mark Kuznicki. Their article on TransitCamp has been published in the February 2008 issue of the Harvard Business Review.

For those unfamiliar with the concept of an unconference – like TransitCamp or the opencities unconference we put on last year – the article is a great starting point.

It’s a wonderful example about how citizens can be engaged in a truly meaningful way. As the website states: TransitCamp was – and will continue to be – a solution playground, not a complaints department. It is as much a celebration of transit as it is a place where people gather to figure out how to make it better.

Much like a NFL game is as much about the tailgating, social/community oriented party in the stadium parking lot as it is about the serious game going on inside the stadium, TransitCamp is as much about celebrating and uniting the transit community as it is about the serious work of figuring out how to make the TTC better.

And, to top it all off, it was a place where ideas get to flourish and are not subjected to consensus and other lowest common denominator approaches.

This, and all sorts of other good reasons, is why HBR made it a breakthrough idea for 2008.

(BTW: Go Pats Go)

Open Cities – A Success…

Finally beginning to relax after a hectic week of speeches, work and helping out with the Open Cities unconference.

Open Cities was dynamite – it attracted an interesting cross section of people from the arts, publishing, IT, non-profit and policy sectors (to name a few). This was my first unconference and so the most interesting take away was seeing how an openly conducted (un)conference – one with virtually no agenda or predetermined speakers – can work so well. Indeed, it worked better than most conferences I’ve been to. (Of course, it helps when it is being expertly facilitated by someone like Misha G.)

Here’s a picture chart of the agenda coming together mid-morning (thank you to enigmatix1 for the photos)

There was no shortage of panels convened by the participants. I know Mark K. is working on getting details from each of them up on the Open Cities wiki as quickly as possible. Hopefully these can be organized more succinctly in the near future (did I just volunteer myself?).

There were several conversation I enjoyed – hope to share more on them over the coming days – but wanted to start with the idea of helping grow the Torontopedia. The conversation was prompted by several people asking why Toronto does not have its own wiki (it does). Fortunately, Himy S. – who is creating the aforementioned Torontopedia – was on hand to share in the conversation.

A Toronto wiki – particularly one that leverages Google Maps’ functionality could provide an endless array of interesting content. Indeed the conversation about what information could be on such a wiki forked many times over. Two ideas seemed particularly interesting:

The first idea revolved around getting the city’s history up on a wiki. This seemed like an interesting starting point. Such information, geographically plotted using Google Maps, would be a treasure trove for tourists, students and interested citizens. More importantly, there is a huge base of public domain content, hidden away in the city’s archives, that could kick start such a wiki. The ramp up costs could be kept remarkably low. The software is open sourced and the servers would not be that expensive. I’m sure an army of volunteer citizens would emerge to help transfer the images, stories and other media online. Indeed I’d wage a $100,000 grant from the Trillium Foundation, in connection with the City Archives, Historica and/or the Dominion Institute, as well as some local historical societies could bring the necessary pieces together. What a small price to pay to give citizens unrestricted access to, and the opportunity to add to, they stories and history of their city.

The interesting part about such a wiki is that it wouldn’t have to be limited to historical data. Using tags, any information about the city could be submitted. As a result, the second idea for the wiki was to get development applications and proposals online so citizens can learn about how or if their neighborhoods will be changing and how they have evolved.

Over the the course of this discussion I was stunned to learn that a great deal of this information is kept hidden by what – in comparison to Vancouver at least – is a shockingly secretive City Hall. In Vancouver, development applications are searchable online and printed out on giant billboards (see photo) and posted on the relevant buildings.Development application According to one participant, Toronto has no such requirements! To learn anything about a development proposal you must first learn about it (unclear how this happens) and then go down to City Hall to look at a physical copy of the proposal (it isn’t online?). Oh, and you are forbidden to photocopy or photograph any documents. Heaven forbid people learn about how their neighbourhood might change…

Clearly a wiki won’t solve this problem in its entirety – as long as Toronto City Hall refuses to open up access to its development applications. However, collecting the combined knowledge of citizens on a given development will help get more informed and hopefully enable citizens to better participate in decisions about how their neighbourhood will evolve. It may also create pressure on Toronto City Hall to start sharing this information more freely.

To see more photo’s go to flickr and search the tags for “open cities.”