Kellan suggested that some books are read better together and asks “Do you have favorite pairings?” Following Rich’s post on the Creative Commons, I’ve been thinking about Lessig’s The Future of Ideas and ever since the Naropa Workshop on Intentional Economics, I have thought it would be great to pair Lessig with Bernard Lietaer, author of The Future of Money.
I talked to Bernard about Lessig’s code/architecture as the fourth category of ways to regulate. When a complementary currency is introduced, does it merely fall in the economic incentive category or is it a lower level change to code and architecture?
What is intentional economics? Bernard explained that instead of assuming the right money system is in place, we ask “What is our objective?” Then, only after we figure that out do we design the system of money.
Complementary currencies address social problems that the dollar ignores. The metric for the success of a complementary currency is not whether people choose to use it but whether it is fixing the problem the community set out to address. Since that is generally undefined for national money systems, we must assume that their purpose is not to change anything. As Lessig might say, they are designed to preserve the old against the new.
there is a benefit to resources held in common…the Internet forms an innovation commons (p. 23)…Innovation is best when ideas flow freely (p. 71)
Similarly, community currencies form an innovation commons. Only the private central bank can create national money, but when adaptation to new circumstances is desired, preserving the old against the new doesn’t help us. When each innovator creates her own currency (through work completed instead of through a debt loan from a bank), a new innovation commons is formed.
The trick is that everyone must trust in the currency system. This requires data integrity. The top node in the hierarchical structure on the left can allocate security resources and the system can remain closed. However, in the configuration on the right, the responsibility for the data integrity security requirement is distributed among the community. This requires the system to be open, both code and policy process.
We’ll continue the cross-pollination of ideas between Lessig and Lietaer in the next post.