In the last year I’ve done a lot of thinking about the open source process and spirit, specifically in terms of applying it to domains other than software. But I always get a bit bogged down by the term ‘Open Source’, as my understanding of its essence is likely different than most people’s understanding. Indeed, the term is strongly associated with software, and anyone who doesn’t actually work with the process in software generally just won’t quite understand what is so amazing about it.
So for the purposes of this blog, I’m going to go with a new term to represent what I mean when I talk of the ‘essence’ of open source, the thing that really excites me about it, and the part I feel is quite transferable to other domains, and indeed already has. Many have written about many parts of this, but none fully gets across what I want to express. The best I’ve heard is ‘Architectures of Participation’. Tim O’reilly coined the term for a speech in 2003, his best explanation of it is here. He focuses on identifying it, with examples of open source software and the world wide web. I will adopt the term, but hope further it by trying to articulate the core ideas, and to examine how we might start to apply the lessons to other domains, what factors are crucial for success.
An Architecture of Participation is both social and technical in nature, and the component parts can not be easily extracted: the social is strongly enabled by the technical, but the technical without the social process is nothing. The architecture leverages the skills and energies of a wide body of users as much as possible to cooperate in building something than any single group of ‘producers’ could alone. The line between producer and user is blurred as everyone participating has something to contribute, and the wide distribution of user/producers contributing incrementally can achieve more than even the most massive top down efforts.
The best articulation of Architectures of Participation is found in Benkler’s Commons-based Peer Production model. If his term were easier to use I would just adopt it, but I find it unwieldy when talking about the ‘thing’ that is utilizing commons-based peer production. There is a commonality between the structures that arise in his described production process, and I use the term Architecture of Participation to refer to that structure. It is both social and technical in nature, as he clearly articulates, it is a group of people who cooperate to build something (peer production). The ‘commons-based’ part I see as a pre-requisite for any Architecture of Participation, contributors must be guaranteed to have access to the results of their work. But he elucidates that all of the successful peer production efforts hinge on lowering the barriers to entry for new users, to make some sort of contribution very easy. He goes in to a lot of depth, theorizing about how to divide up the tasks, how bite sized chunks that are easy for any one to do form the root, gearing up towards larger responsibilities and contributions. I will just point to him, but point that technology can play a large role in making contributions easier. Open Source software has built a variety of technical infrastructures that allow its peer production process to scale up. One of the best examples is the source control management systems like cvs and svn, combined with the innovation of the ‘patch’, a small chunk of code that can be automatically combined with the source tree by someone who has earned the appropriate trust of the project. The technical must enable the social, and often in a novel way in order to bootstrap an effective Architecture of Participation.
In future posts I will attempt to justify and find commonalities between the situations that I would term Architectures of Participation, but for now I will just posit for that the chances of creating a successful architecture, in any domain, rely on one pre-requisite and then maximizing three aspects (though am open to there being more). Much of this can be viewed as bite-sized Benkler, there’s not a ton new here, his work is mostly summarized and put through my filter. I’m mostly writing it so I can refer to it in future posts without having to make people get all the way through Coase’s Penguin.
The prerequisite is that the results of the production process must be available to all contributors. If I put something in, I expect to get something out, and people continue to contribute because they tend to get far more out than what they put in. Often people don’t even mind if their contribution is being used by someone else to make money, as long it continues to provide something useful to them, or if they have a similar opportunity to make money. Sometimes, as in the case of the GPL license in open source software, they want to be guaranteed that if anyone else adds value that it is available to all. But in many situations the strength of the Architecture of Participation is such that it makes economic sense for those deriving value from it to contribute at least the important part of their results back to the community.
There are even cases, such as amazon book reviews, where people continue to contribute even though someone else is making money off of their contributions, and where they are not deriving any economic value. But participating in these architectures is not something that can be measured in mere monetary terms by any means. People who write lots of amazon book reviews enjoy sharing their opinions with others, and it doesn’t matter to them if amazon makes money because of their good review. It’s not like their alternative is to publish in the New York Review of Books. But they definitely want to retain credit for a good review, and enjoy the feedback that others appreciate their views (the ‘was this review useful to you?’). The pre-requisite, however, still holds: they must be able to get out what they put in, and to get out reviews that others put in. If Amazon simply sucked in their reviews and just used them for collaborative filtering and generic blurbs then they’d get a lot less contributions. I plan to write a future post on the interactions of money and Architectures of Participation, as there are a variety of models that sustain the commons in different ways, and indeed I’m sure there are even more innovative business models that will evolve in the future.
Past the pre-requisite, I believe there are three aspects that must be maximised for a successful architecture of participation:
- Work is done on something immediately useful, or at the very least has the promise of being useful relatively soon.
- The barriers to contribute are as low as possible.
- Users are viewed as ‘co-developers’, that is as equal partners in the undertaking, instead of just the consumers.
Let’s take each of these on their own.
Work is done on something immediately useful, or at the very least has the promise of being useful relatively soon. Most people are not going to contribute to something that is going to take years before it can be used. That’s not to say that it needs to be ‘done’ relatively soon, it just has to be useful. Indeed many of the best architectures of participation are around things that will never be ‘done’. The wikipedia is a good example, it will never be complete, as there is always new knowledge generated. But even from the first day it was useful to have a place online to look up encyclopedic knowledge. If there are only four articles, those four articles are still useful to someone. Contributing just becomes a process of adding more things that are more useful. The ebay seller trust mechanism is another example. Though it’s not immediately useful for a buyer to rate a seller, as it does little for the seller, the whole system of buyer and seller ratings is useful. And it can easily be seen that by contributing, one is contributing to something that is useful. The term ‘useful’ is also important. The work must be perceived as valuable by a significant group. If only the initial core group thinks it is useful, then an Architecture of Participation will have no chance of forming around their effort.
The barriers to contribute are as low as possible. And as low as possible often means doing exactly nothing more than what users are doing anyways. My favorite name for this is Paul Kedrosky’s term Drive-By Data. Tim O’Reilly’s Architecture of Paricipation term focuses pretty much on this facet of the architecture exclusively, so contribution is a natural side effect of users pursuing their own goals. Examples of this are napster, where sharing your music is a side effect of using the system,or del.icio.us, where just making your bookmarks feeds in to the value of the whole system. I would argue that this fact in and of itself is not the only factor in making what I call an architecture of participation. It’s certainly a factor in Open Source Software, as when someone fixes a bug and makes it available to all. But it’s not sufficient to fully explain everything, especially why a OSS project comes into existence in the first place, how the initial Architecture of Participation is formed. NASA Clickworkers is another. If other factors are right then contributions can take a bit more involvement. But it should still be trivially easy – editing the wikipedia does not require you to know html, and it doesn’t even require you to create a log-in. This is a great example where the technology enables the social, the ‘wiki’ managed to go one better than html for ease of use. Indeed the original vision of the web was to be read and write, but even though html is quite easy, it still involved a bigger learning curve than most people were willing to take. One could not just look at the ‘source code’ and just start writing, in the way one can with wiki markup. The technical infrastructure must be set up to allow small contributions to happen very easily, or the project will have a much harder time turning into a true Architecture of Participation.
Users are viewed as ‘co-developers’, that is as equal partners in the undertaking, instead of just the consumers. This comes straight from open source development, perfected by Linus and made famous by The Cathedral and the Bazaar. But I firmly believe it is widely applicable. If you treat your users as your most valuable resource, they will become it. To some extent this is an intersection of post on You can change the world and parts of Open Source: Beyond Software. If you are to view your users as mere consumers, that you are the producer and are just providing things to them which they pay you for, then they will remain consumers. But if you view them as equal partners in building something of value, some will become exactly that. And some will have amazing ideas and energy that can build it into something bigger than you alone could have imagined. But it is only by seeing others with that potential, and then giving them the responsibility to make it so, that it will come to pass.
It may sound a bit counter-intuitive, but giving people responsibility is one of the greatest rewards that Architectures of Participation have. Enabling low level contributions is important, but projects really take off because a core group of people devote themselves to it. And they are only going to do so if they truly get a say in the direction, if they have responsibility for the success, and also get credit for it. But the key for me is that you can give responsibility to those who have never had it before, and often they will become the most passionate and hard working contributors. It is incredibly empowering to feel like you can change the world, like you make a difference, even in a very small part of it, since so much of world seems devoted to the message that you are powerless. Successful Architectures of Participation that are structured to not only allow but encourage one to go from a lowly user to a leader of the project are more likely to have success than those that don’t.
Ok, this is getting long, and overdue. Apologies for the lack of examples, some of this stuff may seem a bit too abstract, not firmly grounded. I don’t feel I totally hit what I wanted to, but hey, I’m just applying open source principles to more than just software: release early and often. In the future I’ll attempt to run through many more examples, which should start to elucidate what I feel constitutes an Architecture of Participation.