There's been quite a lot of talk recently about how the various protest movements against the government that are springing up (well, it's doing lots to protest about) are "open source". Here's a Left Foot Forward post, for example.
As someone who's both organised protests and developed open source software, my reaction to the analogy is extreme bafflement.
The idea behind the analogy is that the "new protest movement" is open, transparent, decentralised and largely non-hierarchical, with everyone able to contribute in the ways that they are most suited to.
Which is fair enough. Legitimate ideals, and they seem to be reasonably effective in practice too, but the areas in which it's actually similar to open source software development projects are areas in which it's also similar to just about every other protest movement ever, so the analogy just doesn't work.
Open source software development is considerably more hierarchical than the stereotypes suggest. It has to be, if it's to actually develop useful software. For any complex piece of open source software - any of the big ones with widespread name recognition like Linux or Firefox, but much smaller ones too - there are a core set of leaders, who make most of the decisions about what the long-term aims of the project are, and all the decisions about which individual contributions go in to the project.
The advantage of open-source over closed-source is not that it doesn't have leaders and hierarchies, but that a popular rebellion against those leaders and hierarchies doesn't have to start from scratch when providing a replacement. Nevertheless, someone disagreeing with the current leadership will have a difficult and time-consuming task on a large project in getting enough supporters, hardware and hosting budgets, and so on, to make a "fork" of the project viable. Successful forks are extremely rare, though hypothetical ones are pretty commonplace.
But there are definitely leaders and a hierarchy, because once a software project gets complex, there is an intense need for quality control. Contributions that aren't up to the necessary standard, or which just aren't considered useful, don't get in.1 That sounds much more like a "traditional" centralised protest movement to me.
Similarly while the outputs of an open source software project may be transparent, the process is not necessarily so. There can be a lot of "back room" discussion about controversial decisions.
As far as the actual similarities between open source software development and "open source" protests go, you'd be hard-pressed to run a protest without them.
- Everyone can contribute? Most protests work on that basis, since they want the numbers. The more common problem is that protests aren't selective enough and let in unrelated people who try to make the protest about something else.
- If you don't like the direction, "fork" it? No protest movement has yet, as far as I know, tried to patent the concept of protesting against a particular thing. This is automatic. Unlike with software, there's not months of dull and boring work to be done before you get back to something vaguely resembling the original if you start from scratch.
- Sharing of ideas/materials? Again, most protests don't try to trademark their slogans, or to threaten with copyright infringement people who modify their sample letters to MPs before sending them.
- Transparent output? By definition, yes. Once you've seen a protest you're at liberty to copy its methods or slogans for your own. As with open source software, though, you might not be aware of the tangled route it took to get to that finished state.
"Many eyes make all bugs shallow"? A protest has no underlying "source code"2 that one can inspect for bugs. The output of the protest is the original form. As with closed source books, where you don't need access to the original typesetting to spot the typos and layout errors, "bugs" in a protest are open to anyone to find regardless of the protest organisation.
Transparent organisation can make the "bugs" obvious before "release", just as many bugs are found and fixed in development versions of software before they ever make it into a formal release, but that doesn't mean they'll necessarily be fixed.
Meanwhile, just as allowing the public to help test planned releases is not limited to open-source software, being transparent about future protests and listening to suggestions and criticism is not something that non-hierarchical movements have a monopoly on.
Call it "decentralised", or "non-hierarchical", or "chaotic", or "anarchic", call it "crowd-sourced" if you must, but don't call it "open source" because it's not in any meaningful way similar to that (indeed, the social network tools used to organise most of the actions are largely corporate-owned and closed-source).
Footnotes
1 The idea is that the hierarchy and the leaders are a meritocracy of sorts: if you do enough good work for the project you'll be invited to join them. The Geek Feminism blog has some good articles pointing out that - as with everything else - the definition of what counts as "good" and "work" is default-biased
"Democracy", however, is generally not something that open-source software projects use or need.
2 The actual openness of the source is not a major factor for finding bugs in most projects. Just about all of the bugs reported for projects I've been involved in have come from users using the software who'd never read the source, not from people who happened to read the source and thought "hey, that'll never work". For any successful project, the proportion of its users who have the time, skill and energy to read the source for bugs is approximately zero.
Likewise, I've never found a bug by reading open source code. I've found bugs by using software and then been able to report them to the developers complete with a cause and a fix, in a few cases, and this is a useful advantage of open source software - especially those pieces of software such as system tools likely to be used by people who can program. More usually, despite in theory being able to read the source and provide a fix, I've just told them about the bug and let them get on with it.
But anyway, on this metric our Parliament is "open source": read the draft Bill, write in with a "bug fix", and the "developers" might well accept it before "release".
