When talking about "open collaborations in appropriate technology", it's worth asking:

• What we mean by open collaborations
• What factors help or hinder an attempt at open collaboration

What makes it open?

Key aspects of openness include:

• Freedom to access the results of an effort (as in open access),
• Freedom to participate (as with open editing)
• Freedom to take the output of a project, modify it and even do something different from what was originally envisaged (libre, also including the freedom to fork)

What makes it effective?

As discussed below, an effective open collaboration with a community of active contributors requires:

• intention
• incentives

• personal satisfaction
• personal enjoyment
• community
• helping to create something that the participant also hopes to use
• ethical imperative - a desire to help.

• low barriers to entry:

• low membership barriers: joining and starting is easy and quick.
• low technical barriers: contributing doesn't scare people off.

• tools to enable collaboration

• easily accessible history of all changes to a unit of knowledge (this exists for wiki pages and source code, but there is some debate over what is needed for a design of a physical product)
• ways of tying communities together when working on the same thing:

• the dominant process, to date is the fairly blunt instrument of merging - several wikis have merged to form Appropedia; however several others have been hesitant to do so, wanting to maintain a separate identity. Merging may be a very good, synergistic option when the ideas are similar enough and branding and identity are not major stumbling blocks.^[1]

The intention is not lacking; the time commitment is a major issue, and this is directly connected to ease of use, and how well the key concepts are understood (which in turn is a product of diffusion of the ideas, and how clearly the ideas are communicated).

Technical options

• A central database may be recognized as the standard repository for all general appropriate technology information (though this may not be the same as the repository for designs) - the data is managed from a single server, and served to different websites. This appears to be getting closer, with the development of an API for Mediawiki (currently considered stable for reading, but not yet ready for editing.)
• Distributed editing, through the OLPC:MikMik model (distributed revision control system, built on top of Bazaar) of collaboration between branched articles, being developed by (or at least begun by) Benjamin Mako Hill. This model require some human intervention to approve changes made in different branches. A distributed wiki^[2] appears to be a brilliant solution to two situations:

• Where contributions are submitted asynchronously. (This is a much more critical version of "edit conflicts" in a wiki.) This was envisaged as an issue in OLPC's XO-1, where users are not always connected to the same network, let alone the global internet. MikMik is/was developed particularl with the XO in mind.
• Where there is a wish to keep the articles substantially different. So additions to a Wikipedia article could be easily compared to additions to an Appropedia article, and changes shared (or even transwikied in either direction when they fit within the scope of the project. This also improves on the current wiki model of attribution when copying or moving between projects, in that the software could presumably attribute the specific user from the other project who made the contributions, within the history page.

Notes