The participation culture

The participation culture


I am lurking on the OpenMokomailing lists. This is an educational experience for me. Although Ihave participated in many heated discussions concerning Free software, I have never watched such a high-profile full-fledgedFree software project start from the ground up.

It's fascinating watching different sorts of geeks interact.

For instance, currently there is a debate concerning the necessityof a hardware-specific emulator for the purposes of development. Asthe hardware itself isn't stabilized, one group assumes a fullhardware emulator will be of little use emulating a movingtarget. Another group argues there is no way to properly developwithout a solid emulator.

Both sides are correct, of course. There is utility in earlyparticipation, with rough edges and downright dangerous areas. Theearly adopters help define the shape of the project. But there areother early adopters who wish to spend their time coding applications,not fiddling around with changes in the development environment.

The tone of the debate can be somewhat rude, occasionally. Not allparticipants are polite at all times. Some people are sometimes sulky,others may become a bit grumpy. Others maintain Real Or SimulatedRespect (ROSR) at all times. The various lists sometimes border onordered chaos, with everyone going in different directions, followingthe path that interests them most.

The curious thing is, this all works. Somehow, everything fits together.

The unpracticed art of self-organization

Consider this: how is it that huge cities like New York, MexicoCity, Bangkok, or Beijing are able to survive? Between distribution offood, water, and energy; and the removal of refuse and waste; how doesa city manage?

Part of the answer is in planning. There is generally not onecentral authority for planning all aspects of a city, but a centralteam usually takes care of power distribution, and another may planfor water, and yet another for sewer or garbage collection. In all,these groups work more-or-less independently toward a common goal: acity that not only survives, but thrives. Mostly, these groups dealwith the management of infrastructure.

More interesting is the distribution of goods and services, such asvegetables and pink plastic shoes and truck tires and gasoline. Thisis handled independently of central planning, in a distributedfashion, in a self-organizing fashion. Every individualparticipates in this self-organization, whether it is in logistics orconsumption or financing. Those few responsible for the maintenance ofa single bakery, for instance, worry only about their flours and theiryeast and their customers. Nobody outside their sphere influences them(ideally, at least). They order supplies based upon the rate theircustomers consume their products. They don't worry about the butchershop across the street, nor do they concern themselves with themega-mart up the road.

Free software as participation culture

I see a parallel between the self-organizing efficiencies of acity, and the execution of a project such as OpenMoko or GNU/Linux, orFree software in general. In the case of GNU/Linux, certain projectsare huge, and more-or-less centrally organized, such as the Linuxkernel. Other projects are smaller, and managed by the one or twoparticipants, such as most of the myriad packages that make up asingle GNU/Linux distribution. There is no single administrator, noone to say, "I am the decider."

The administration of the great wide world of Free software ishandled by the participants, just as a city is truly administered notby a central authority, but by the ones who run the bakeries and thebutchers, the petrol dealers and the car mechanics and the clothingmerchants; or (on a more abstract level), by the citizens who eat anddrink and drive, making those shops necessary and worthwhile.

The maintenance of the road might be centrally managed,more-or-less, but the point of the road generally isn't the driving,it's the arrival at a destination. The point of the road is tofacilitate the shuffling of goods and services, and to make it easy tovisit friends and families, and to get to work. Similarly, the biggestcentrally-managed projects (such as Apache or the Linux kernel) arethere not as an end to themselves, but to make it possible to_do_ stuff with your computer.

Our society is strongly based on participation. As on the OpenMokolists, or in the controlled anarchy of heavy traffic, participationcan sometimes be impolite, and enlightening, andgruff, and obsequious, and fun, and generally full of targetedchaos. The primary point, though, is participation. We are allparticipants, whether we are users and consumers, or if we activelywork in the organization of the process.

Participation takes many forms. I have participated in a fewprojects, sometimes following the desires of a project manager,sometimes as the only coder on the project. There is nothing likereceiving an email from someone with a bugfix, or a featureenhancement, or even just a polite email saying, "Thanks for theprogram."

All of this is participation. Simply using a piece of softwareis a form of participation: programs are worthless unless they areused. The more a program is used, the greater its worth. (It is worthnoting that "worth" and "value" do not necessarily mean "money.")

The engine and the process

Participation is the engine which powers society. It is participationwhich allows cities to self-organize. Likewise, without participation, therewould be no Free software. It is a powerful engine indeed, harnessing the relatively small efforts of thousands of people into a serious force.

Self-organization is the process that provides coherence to the effortsof the participants. It is an amalgam of interest, ability, andnecessity.

Grocery stores are there because they are needed,and because some people have the interest and ability to build andoperate them. The Linux project appeared because people had theinterest and ability, and because it was needed. There is acertain self-selection in the process, as people of similar interestand abiliity form groups around their favored interests. This makesself-organization malleable and responsive. The only requirement isparticipation.

Self-organization does not assure vitality. I will continue towatch the OpenMoko project grow. I will continue my observation of thedeveloper mailing list, enjoying the interaction of all the diverse personalities working, politely and impolitely, for the success of the project. I hope it will survive and thrive.

As for participation: I hope to help fill a terrible void.I currently cannot play Nethack on mycell phone. That is a serious, serious lack.

Category: 
Tagging: 

Comments

Jonathan Roberts's picture

This might be a very geeky thing to suggest, but I'd love to read a detailed study in to the community and organisation structures of Free Software. In fact, I'd love to write one but where you would start!?

Jon

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Karl Fogel's Producing Open Source Software may be a good place to start.

Vance

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Jon,

I don't know if this will suite your needs, but "Producing Open Source Software" is very interesting book covering anatomy and conducting successful FLOSS projects. Its author is a Subversion developer, which wanted to coin the answer to popular question he gets from other people "how does it really work?":

http://producingoss.com/

kocio,
LinuxNews.pl

Author information

Anthony Taylor's picture

Biography

Tony Taylor was born, causing his mother great discomfort, and has lived his life ever since. He expects to die some day. Until that day, he hopes to continue writing, and living out his childhood dream of being a geek.