An architecture of participation | Opensource.com

An architecture of participation

Posted 13 Jun 2012 by 

Rating: 
(7 votes)
An architecture of participation
Image by : 

opensource.com

submit to reddit

What happens when half of the world's population lives in cities? When over three billion people are online? When there are more than 15 billion connected devices?

Old organizational models hit end-of-life. People behave differently. Organizations behave differently. What worked in the old world doesn't work in the new.

Download Free eBook

Through the ages, people have collaborated around common goals. Joint creation and joint production are not new ideas. It could be argued that the old religious scriptures were crowd-sourced. Most other activity back then was strictly controlled by a ruling leader or harsh environmental conditions. But when people engaged in new and intriguing topics of the time, they worked together. They collaborated.

What is changing now is that participatory models are becoming the rule, not the exception. The world used to be about command and control. Someone told you what to do. There still is a lot of that. But collaborative innovation is taking over. We are coming to a stage in our civilization where regular functions are masterfully automated and industrialized, and our focus as human beings can and will  increasingly be on innovation. In the area of innovation, the most powerful creation happens in teams, groups, and crowds--across organizational boundaries. When we architect for such participation, we can multiply the power of innovation.

Linus Torvalds stumbled over this mechanism over 20 years ago. In an act that was part abandonment and part invitation, he somewhat unknowingly threw out an intriguing challenge to software developers all over the world: Work with me to build a free operating system. And people did--willingly, spontaneously, and brilliantly.

Soon, a number of free and open source software projects were defining the architecture of participation--a model for how to engage people with different ambitions, different mandates, different employers (or no employer at all), and different communication habits in joint projects that unpredictably but inevitably produce superior results.

That's the essence of the architecture of participation. You construct rules of engagement that allow disagreeing people to let their work products agree. This is a system where the designer invites input from contributors. The end result is an ecosystem that evolves faster than any individual initiative, resulting in a work product with fewer deficiencies.

The architecture of participation is more than open, and more than crowd-sourcing. Open, strictly speaking, means that you share your production with others. It doesn't necessarily mean participation. Crowd-sourcing means many people contribute to a production. It doesn't necessarily mean that they would exchange value with each other. It's not enough to be open and it's not enough to crowd-source. We must build an architecture of participation where different participants with different agendas can exchange ideas and models, and everyone has access to the end results. It's not easy to do that, but it also is not impossible.

The beauty of a well-functioning architecture of participation is that there is no significant distinction or conflict between the public good and the private good. It's just good. It's good for each participant, and it is good for all. It does not matter whether there are free riders or freeloaders in the system, because the moment they take any action whatsoever, they become at least marginally useful to the entire system.

Millions of freeloaders providing a marginal benefit amounts to much more than a small number of contributors each providing a big benefit. This is why the size of the ecosystem matters. With three billion people on the Internet, freeloaders are more abundant and more useful than when we had just three million people on the Internet (which was approximately the time when the Linux project started).

This is why the architecture of participation is now overtaking systems of command and control. The volume of participants is so large that any attempt to be fully in control inevitably leads to a group too small to have meaning. The number of people you can control are vastly outnumbered by the people you can only hope to  influence, but not control.

Let us also be clear that the architecture of participation is not anarchy. It is also not a democracy. Every architecture of participation has an architect. There is a steward of the project. The steward can be a single individual (like Linus Torvalds), a team (think about the creators of the Apache web server) or a company (such as MySQL AB). The steward of the project sets the rules of engagement.

If the rules are too strict or egregious, people will not participate. If there are no rules, people will not know how to participate. In the ideal architecture of participation, there is a steward of the project that sets priorities and design goals and then simply ensures that the field is open for participation by anyone and everyone. To scale collaboration, it makes sense to create useful interfaces--APIs that allow individual initiatives to evolve at their own pace while interacting with each other through the agreed interface.

Architectures of participation exist all over the technology sector today. It's not any longer just about open source. Wikipedia brings together those who can express facts and concepts in writing. Facebook brings together those who can express their daily lives. oDesk and the Mechanical Turk bring together those who have work capacity to provide to others. Kiva.org brings together those who have a penny to spare for someone who is working hard. Twitter brings together those who can express useful information very briefly. The Human Genome Project brings together insight about DNA. The Khan Academy brings together the best in educational practices. The Linux Foundation continues to bring together those who can express computer behavior in the form of kernel code.

We are only in the early stages of the architecture of participation. Cloud computing is a participatory endeavor. The mobile application space  is exploding with participation. Large traditional corporations are launching social initiatives and participatory fora. National governments are opening up for citizen participation. The list steadily grows longer.

The ideal architecture of participation combines the best of ownership of design with the best of collaboration by the masses. If you have no architect, you have no participation. But if you have no participation, it matters little what the architect does. When the architect (whether its a person or a team) is a master of the trade and also a welcoming recipient of contributions and participation, the results can be amazing.

submit to reddit

Marten Mickos is the head of the Cloud business unit of Hewlett Packard. In this role Marten leads the work of building out the HP Helion portfolio which is based on OpenStack and other open source technologies. Prior to HP, Marten Mickos was CEO of Eucalyptus Systems, provider of the only AWS-compatible open source cloud computing platform. Before that as CEO of MySQL AB, Marten grew that company from a garage start-up to the second largest open source company in the world, ultimately

Reader favorite