Beside Open Design, Open Hardware, Open Manufacturing, there is another path the Open Everything phenomenon is taking: Open Money. Although the Open Money projects are in their early steps, they represent a very important strategic and metadesign move in order to enable the spreading of community-based open and p2p organizational forms.

The open money project aims to create the global infrastructure, tools, governance mechanisms and platforms that will give communities the capacity to create their own currencies with just a few clicks and thereby liberate their wealth potential.¹

We should note that these examples of Open Money can be understood as metacurrencies (and here comes the Metacurrency project), because Open Money projects are the design of the rules and artifacts needed for the design of a community’s own currency. Open Money projects will be for sure an important part of any platform for Open P2P Design projects (that are metadesign projects of open collaborative systems).

Here is a great video (with subtitles available) from the Wall Street Journal that clearly explains the Open Money concept and other similar projects:

Just as there are now millions of media outlets today, currencies will follow this same evolution by shifting from centralized authoritative models to distributed ones that allow better sustainability, distribution, transparency, and regulation mechanisms. Every community (associations, companies, cities, regions, states, professions, interest groups, etc) will be able to create their own currencies for their own marketplace.²

And here is another video (with subtitles) about the Metacurrency project:

Notes:

1. http://p2pfoundation.net/Open_Money [↩]
2. http://p2pfoundation.net/Open_Money [↩]

After the first book about managing Free Software / Open Source projects, here you can find another and older (2002) methodology for managing a free software project: Free Software Project Management HOWTO, by Benjamin “Mako” Hill.

As I said before, this kind of guides are important as inspiration for open p2p projects, especially if we se them up using the web and networked software as the most important part of the collaborative activity’s platform.

This HOWTO is designed for people with experience in programming and some skills in managing a software project but who are new to the world of free software. This document is meant to act as a guide to the non-technical aspects of free software project management and was written to be a crash course in the people skills that aren’t taught to commercial coders but that can make or break a free software project.

.

« Intro.01 « Intro.02 « Intro.03 « Intro.04 « Intro.05 « Intro.06 « Intro.07 « Intro.08 « Intro.09

Unlike a traditional, linear, design process, Open Peer-to-Peer Design is non-linear and characterized by multiple parallell processes because of the large number of agents and their interactions. An Open Peer-to-Peer design process thus provides the basis for developing more parallel projects, an ecosystem of designer agents with a memetic evolution of the projects that are more “suitable” to the community, whose selection will lead to better results.

An Open Peer-to-Peer design process is characterized by openness and sharing of the project (the source code for software) of the platform and of the activities that it allows once provided to the community by the designers. The community will test and modify it several times and in several directions (in the software, compiling the binary code), until a satisfactory version is reached (the stable version of the software) and self-organization is ensured.

The source code of the project (community source code) consists of tools from design services, with the introduction of a description of the reputation levels within the community, the license that governes cooperation and the access to the results, a social network map able to show weaknesses and strengths in the community. The source code is accessible to all participants, who are testing it with increasing level of reality (the platform is gradually built during this phase) reporting to the design community any errors (bugs in software) present. The higher the number of participants, the greater the chance that errors are detected and corrected.
During the design process and at its end, the community will self-organize modifying the project if necessary, as far as possible; it is this ability to self-organize and improve the local conditions that makes the communities alive and interesting.

Participation in this design process is open and equal, but is also governed by two principles: self-selection and reputation, which give place to different levels of participation in the various design phases, according to the possession of knowledge needed in each project phase. The different phases of the design process, therefore, require different levels of participation and therefore commitment and visibility of the participants. These different levels give place to different typical phases (similar to some phases of the community of practice) of the life of the communities: potential, coalescing, stable, self-organization and expansion, decline.

analysis

The project begins with an analysis of the participants, in order to understand the existing and therefore usable resources, limitations, critical points. Through the analysis, the designers begin to know the participants, prefiguring which features the community’s activity could have in the future. The objective of this phase is to define the objectives and the strategy on which the concept of the community’s activity will be build. The analysis, carried out through ethnographic investigation and social networks analysis, will cover the platform, the characteristics of the individual participants if possible, as well as existing activities.

concept

Once the analysis of the participants, of their activities and their social networks is done, a first concept of the community’s activity (and its platform) is developed. The designers then develop an initial version (we might say the 0.0.1 version) of the project of the activity/platform, formalized in the community source code.

parallel co-design / test / setting-up

Once developed, the concept is shown to the participants and collectively discussed. From now begins a phase of co-design of the activity/platform, characterized by steady growth of commitment, energy and visibility by the participants. At this stage, the concept of activity is developed collaboratively to get a functioning project, a “stable” source code (version 1.0).
The participants test the community source code of the community simulating the activity, in order to understand what are the weaknesses, errors (bugs in the community source code). The source code is subjected to a peer-review process, in which both the designers (who observe the simulation) and the participants report errors and the necessary changes. Once a bug is identified the source code is modified and again a testing begins with the new code.

In order to simulate the activity, participants must share the conditions necessary to carry out the activity, represented by the platform. Rules and roles should be developed and adopted, and the artifacts that are not already present will be built or acquired. This means that along with the continuation of the co-design / test process, the platform is implemented and when the project reaches the stable version, the participants can begin the regular activity, strengthening then the sense of community.
Once the co-design / test ends, the project will already be done, there are no phases of production nor execution. As in software, then the source code (the project) gives place to the binary code (the work done by the participants).

self-organization

After the first “stable version” (1.0.0) of the source code is reached, the community will be largely formed: during the simulation / activity new social relationships will have formed. A stable version of the source code means that it can be “compiled” (ie, done) and used by anyone without the possibility of critical errors. At this stage, therefore, the community is able to carry out the activity and self-organize without the contribution of the designer: if his role was that of a facilitator (enabler), now the community is able to act successfully alone.

At this point, ideally, the role of the designer is not needed anymore; however, the community will always need its contribution in the future: the designer has always knowledge and expertise useful to provide support to the community in response to changes in the outside world.
Also, if the community activity is a design one, the desinger’s capabilities make them important in the community, and they will continue to be part of also during the self-organization phase.

These observations represent therefore an initial proposal (1.1) for an Open Peer-to-Peer design guidelines, in a broader process of studying a comprehensive methodology.

Finally, what are the future opportunities and directions for the application and study of these design guidelines?

(to be continued)

« Intro.01 « Intro.02 « Intro.03 « Intro.04 « Intro.05 « Intro.06 « Intro.07

What can we “design” in a community?

We cannot think about designing the relationships and the complexity of a community (which are the features that make it a community). The disciplines that traditionally have been interested in communities (architecture, urban planning, web design) are not oriented to design the relationships but the characteristics that, once realized, enable and support the birth and the development of the relationships. The necessary infrastructure for the relations, their platform.

it is convenient to talk about a platform¹ as the object of the design process. It is possible to design and to supply those fundamental conditions that, shared inside the social networks of the participants, act as an infrastructure to the emergence of the community and its characteristic activity. A platform is present (and necessary) every time a community forms deriving from the interactions between a high number of agents. As it is part of the activty, the platform can therefore be described through the Activity Systems. The platform consists in a system of artifacts (materials, cognitive and communication ones), rules and division of labor, which make possible the development and practice of the collective activity. As it is shared between the participants, it has a reticular and dynamic nature.

If the platform is necessary for processes that demand an interaction between a high number of agents, then also the design methodology will demand a platform for being carried out. The platform exists previously to the design process, that has the goal of improving it in a determined direction, that comes from a design choice. It is therefore necessary, at the beginnig of the design process, to analyze the existing platform for the collective discussion; thanks to it is possible to establish a contact with the participants. The designers, in fact, enter in the wider design community of the plan: a community whose activity is an open and peer-to-peer design..

But how the designer’s role change when he/she enters in a wider design community?

(to be continued)

Notes:

1. (2006) Menichinelli M., Reti collaborative. Il design per una auto-organizzazione Open Peer-to-Peer, Tesi di laurea, rel. Ezio Manzini, Politecnico di Milano, A.A. 2004/05 http://www.openp2pdesign.org [↩]