These are the tags I use on delicious to store and organize all the links about Open Money and Local Currencies:
http://delicious.com/openp2pdesign/open_p2p+money
http://delicious.com/openp2pdesign/open_p2p+open_money
http://delicious.com/openp2pdesign/open_p2p+local_currency

Some Twitter users you should follow:
http://twitter.com/openmoney
http://twitter.com/metacurrency
http://twitter.com/newcurrency
http://twitter.com/thetransitioner
http://twitter.com/fer_ananda
http://twitter.com/jfnoubel
http://twitter.com/flowplace
http://twitter.com/myrfa
http://twitter.com/zippy314

Twibe (Twitter group):
http://twibes.com/openmoney

Hashtags (a community-driven convention for adding additional context and metadata to Twitter tweets.):
http://hashtags.org/tag/openmoney/messages
http://hashtags.org/tag/p2pmoney/messages
http://hashtags.org/tag/metacurrency/messages
http://hashtags.org/tag/metacurrencies/messages

Social Networks:
http://openmoney.ning.com/
http://people.thetransitioner.org/

A comprehensive page on the P2P Foundation wiki:
http://p2pfoundation.net/Open_Money

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

We can say that these days the first mass product completely open source has been distributed. Therefore, this is the first example of a real Open Design, not tied to individual experiments or niche markets (albeit very important): the first example of how open source philosophy can be adopted not only in areas different from programming and production of contents, but also in a production of physical goods, rival goods.
I am talking about the Openmoko organization, a project aimed at the design of a smartphone completely open source, first for its software, and now also for its hardware and design.

We can say that this is the first, true, open source mass product design, as the previous examples have not pursued completely the Open Source philosophy, or because they have had limited results, or, lastly, because the context was not ready for actions of this type.

Thinkcycle, which is the first and most developed example (at least so far), was an experiment aimed at niche markets, and for this reason should deserve even more importance because it was aimed at helping disadvantaged contexts, but still limited in the results and in influence on the world of design as too ahead of the spread of Open Source awareness in society.
The initiative Ronen Kadushin, although worthy, represents only a solitary experiment without broad appeal and development.
Martí Guixé’s proposal takes the Open Source as a metaphor and try to adopt some of its collateral features, in the sense that look for certain effects of the open source that can apply to products too, but in substance it is not open source.

The Openmoko initiative (in its first incarnation, Neo1973, produced by FIC) is so important because the adoption of the Open Source philosophy is not an experiment but a real initiative. We then passed the stage of inspiration and experimentation for Open Design, to a stage where it is put into practice. Of course, experimentation is not over and should be pursued further, but now we are talking about a product that the general public will see in stores and that is in competition with the most expected product of the moment, the Apple iPhone. And this referring to the freedom that this choice of opening may give the user, just like the philosophy of the Free Software:

If you can’t open it, you don’t own it. Our first key unlocked the software, unleashing the community to recraft the code. Now, we free the case and share the keys to Industrial Design. Developers who want to re-craft the case are set free.

It is by no coincidence that an advanced version can be bought, bearing all that is needed to open and edit the phone, enabling his hacking in order to customize and learning from it at the same time.

The distribution of the design files, which took place recently, is therefore a logical consequence; the files (IGES, STEP, ProE), were published under license Creative Commons ShareAlike at this address: http://downloads.openmoko.org/CAD/

The fact that a mobile phone of new generation (a smartphone) is the first true open source product, makes the event even more important. Why? Because mobile phones represent a huge potential for the development of community-based collaborative services. A tool that will enable us in the future to exploit, enhance and more easily spread the collective intelligence, because it has the ability to further break down barriers of the service, as many more people have access to mobile phones and feel more comfortable with them than with computers and the World Wide Web.

Therefore, with an Open P2P design methodology we could design with/for a community, mobiler phones, their software and their services, according to their specific needs. We are then able to co-design with a community their collaborative services and the tools that allow their deployment, even for small contexts.

via | core77

While surfing through my favourtie websites I found on linux.com a very interesting article: Lessons learned from open source Xara’s failure, written by Nathan Willis.
For us, it is intersting twice: as Xara is an open source / proprietary vector drawing software (and therefore could be interesting for designers), and because it explains which errors should be avoided while developing a community-based and open source business, even if it is not a software one.

On October 11, 2005, proprietary software maker Xara announced its plans to open the source code to its flagship vector graphics package Xara Xtreme, and with the help of community developers port it to Linux. Today, two years later, the project is stagnant and on the verge of irrelevance, primarily because the company couldn’t figure out how to work with the open source community.

Xara and the volunteer developer community disagreed from almost the very beginning about a crucial issue: the company’s decision to keep the application’s core rendering library CDraw closed source. The developers said time and time again that a half-open, half-closed application was a dealbreaker.

Xara refused to listen, insisting that the code it had made available should be good enough, and that by not contributing its time, the developer community was not upholding its end of the bargain.

During the fall of 2006, Xara pulled its own developers off the open source project and shifted its energies toward the next major release of its Windows product — the company’s primary money-maker.

Looking back on it, Xara went into this experiment with a set of preconceived notions and expectations about open source — notions and expectations that were wrong.

As Xara saw it, the company’s contribution was the source code, and the open source community’s contribution was developer time. It had made the code available to the community, and therefore the community was obligated to work on it. Unfortunately, as the company learned, the developer community doesn’t operate that way.

That misperception isn’t a fatal flaw; many proprietary software vendors misplace assumptions when delving into open source for the first time, just as they might when tackling any new business model.

What doomed Xara’s experiment was that it continued to hold on to those bad assumptions, even in the face of repeated and candid feedback from the developer community.

Xara was wrong about the surface issue — the importance of keeping CDraw closed. So what if it didn’t release all of the code, it asked in effect. It released 90% of the code; at worst it ought to get 90% of the payoff that it would have from releasing the entire kit and caboodle.

But source code isn’t hay, to be bought and sold by volume. Ninety percent is no better than nothing if the 10% withheld is what keeps the rest of it together — which is exactly how the developer community saw CDraw. It was not some add-on feature, it was central to the app. And it was not the licensed property of some third party that Xara could not release; the company chose to keep it closed in order to own it and control it.

The more fundamental problem, though, was below the surface. Xara felt it had the right to dictate the terms under which the developer community would operate, and that does not work. The individual developers in the community participate by choice; issuing unilateral commands about what they can and can’t do destroys the relationship. Xara chose terms that the community found unacceptable, but more importantly it refused to listen to the community and adapt. Since the developer community was all volunteer, its members had no incentive to stay and work.

Other companies contemplating working with the open source community can learn at least two lessons from Xara’s experience. The first is that you can’t boss around volunteers — at best you will drive them away, and at worst you will drive them toward the competition.

The second is that collaborating with a community means willingness to adapt and change. The community may move in directions that you did not anticipate before you began; if you refuse to listen to it or refuse to make adjustments, you are likely going to kill it.

Considerations for open source product/service systems

• we should be careful while attempting to mix open source and proprietary code: how do they relate? Are they interdependent, and how much?
• we should listen to the community: it’s not possible to command a community but we can enable its growth and activity
• we should remember that a co-creation, a community-based service, should be not only open but also equal: users/community share decisions and power with the company. For this reason I insist on adding peer-to-peer to open: the most promising dynamics happen when these two features are present