Differences between Open Source and Open Currencies

From P2P Foundation
Jump to navigation Jump to search


Text

Arthur Brock:

"Basically this means the source code of a software program is available and licensed in a way that would allow people to download it and adapt it for their own use, and possibly republish modifications for others use.

Open Source is a HUGE BREAKTHROUGH in terms of an Information Age gift economy. Software developers have learned that we can actually produce better software which evolves and adapts more quickly by freely sharing the product of our labor and asking others who use it and adapt it to also share their changes back to the community.

This is a huge strategic advantage over closed and proprietary software applications. In the currency space, Cyclos is probably the most feature-rich and mature example of an Open Source application. It continues to evolve and grow because of the Strohalm Foundation and a supportive base of users and geeks. However, it is built in the traditional siloed computing paradigm.

The traditional approach in pretty much all computing and information technologies is to separate applications into very distinct silos. This means, we run our applications in a very controlled environment (whether the original source code is open or closed). We keep our applications secure by limiting access to our server and databases.

If somebody penetrates the "castle walls" which protect our applications, they can wreak all kinds of havoc: change permissions, modify source code, delete files or records, modify data in the database, change accounts or passwords, etc.

This whole approach creates an inherent power imbalance between a very clearly defined "us" and "them." There are those who control the server, applications and settings, and then there is everyone else (such as users of those applications). The people who can go inside the castle walls control everything, the people outside the walls don’t.

Currently all software applications, whether open source (like Cyclos) or proprietary (like Paypal, banking software, the Visa Network, ACH or GETS) operate inside this siloed approach.

What we are undertaking with the Metacurrency project is no small feat, because we are talking about a whole new architecture for software applications and information technologies. And this is why we’re spending so much energy clarifying what we mean by OPEN.

What happens if you want to write a check against your bank account, but there is a discrepancy between what you believe your balance is and what the bank says? Who is the authority? Who decides whether the check clears? Who decides what fees you’ll be charged if it doesn’t? What interest rates you’ll earn or pay? What other random fees and charges may happen? What the rules are and when they change? How much you can withdraw from an ATM in a single day? Etc…

The short answer: THEY do. Your only option is to move to another bank. Another bank where you'll be in the exact same position again. One group of people holds all the cards, makes all the rules, sets all the policies. And you have no authority to represent your own account, your balance, the rules you’ve agreed to, etc.

So, I ask you... If we are making a whole new model for currencies, do we want to repeat that pattern? Are we going to just trust that well-meaning, community-minded folks will never abuse the inherent power imbalance built into that approach to computing?

There's a reason for the saying: "Power corrupts. Absolute power corrupts absolutely." Currencies are extremely powerful tools. If we want to break the pattern of humanity serving currencies and instead have currencies serve us, then we must break the architectural pattern of power imbalance which gives one group ABSOLUTE POWER and withholds it from the bulk of participants. It is an inherently corruptible structure. If we build the new economy on this inherently corruptible foundation, can we expect any outcome other than corruption?" (http://newcurrencyfrontiers.blogspot.com/2009/05/differences-between-open-source-and.html)


Characteristics of Open Currencies

Our Approach to Open Computing:

"We identify three core components for an open, distributed, and decentralized approach to computing and currency architectures:

1. Open Transport: A protocol which can be used for participants to directly interact with each other and for any currency to interact with any other currency.

2. Open Rules: A means of representing the rules so players know what game they’re playing, what plays are valid to make, how those plays are handled and how any game/currency interacts with other games/currencies.

3. Open Data: A tamper-proof way of distributing data so there is no centralized point of failure nor power imbalance between the participants and the management/governance of a currency." (http://newcurrencyfrontiers.blogspot.com/2009/05/differences-between-open-source-and.html)


Open Currency Data

"Instead of managing data integrity and security through exclusion and obfuscation, we need an inclusive architecture THAT BUILDS INTEGRITY AND SECURITY INTO THE STRUCTURE OF THE DATA ITSELF. (Sorry for shouting, but I want to underscore that last point.) That is the only way to transcend the technological power imbalance between admins and users which is inherent in siloed computing architectures. [See previous post about Open Data]

The mechanisms for doing this involve new technologies that have never been assembled in this manner before. It means having a distributed, segmentable data engine which can store chains of linked, digitally-signed transactions. You can sort of think of this as using the digital signature validation that GIT uses for source code repositories, but for a distributed database application. It would also be helpful to the means to run signed instances of distributed applications and embed them in this distributed data engine.

This enables you to validate any play (via its digital signatures and copies from various players, governance bodies or 3rd party notaries/auditors) and to see the state of play for any player. However, this does not necessarily mean complete transparency of all data. You can encrypt secret data into the transactions, or couple private entries in your own private data store to transactions via their transaction id as a foreign key. This is just like how in some games, you receive cards that are face-down, for that player’s eyes only. Other players can see that they’ve received a card (that a transaction was made), but cannot see the content of that card.

If the governance of a currency gets bogged down in bad politics, makes bad decisions about rules, or even gets shut down, the players can pick right up where they left off with their own tamper-proof account statuses by selecting an old rules version (or forking with a new version) and deciding to continue the play. In this kind of true peered architecture, there’s no way to force a game to shut down as long as there are players that want to keep playing it" (http://newcurrencyfrontiers.blogspot.com/2009/05/differences-between-open-source-and.html)


Cyclos as Example of not sufficiently open currency

Alan Rosenblith:

"However, when people set up an instance of Cyclos, they are establishing a place where users have to set up an online identity (or account), and that ID is only relevant to that currency. I can’t use my ID to participate in other currencies or access other currency platforms (like GETS), so it is a closed network. I also can’t use my ID to set up a new currency with access to the same user base. This means that if the governance (no matter how inclusive) screws up, the users become scattered. People wanting to trade become dependent on a structure that may not serve them, because the currency is operating in a informational silo.

In contrast, if I could use my ID (or account) to establish new currencies or participate in any existing ones, the ecosystem of currencies could freely evolve. It wouldn’t be a huge deal if one currency turned out to be flawed because anyone using that currency would be connected to the broader network and could simply play a new game.

Before SMTP, email was similarly challenged. I could email others using the same service provider, but I couldn’t email people outside the service. So, open standards are the key. When SMTP was invented, email took off. When HTTP and HTML were invented, users could suddenly get ANY information resource from ANY server, and the world-wide-web was born. Closed networks (like Prodigy) didn’t provide that kind of dynamism, so they quickly disappeared.

The MetaCurrency Project is doing the same thing for currency as HTTP and HTML did for the web. It is establishing a simple protocol for defining a currency game, and making a play in that game. So anyone using a currency service provider will be able to play in any game they choose or start new games of their own design. That is very different from anything that has come before in the currency world.

What really excites me about this new world is the implicit invitation to developers to make client software that serves different needs. Firefox, Safari, Chrome, and Flock are all browsers that serve different needs, but they all use HTTP and HTML. Java, flash, php, etc. are all things that evolved to work along side html as the needs arose. I imagine an analogous pattern will manifest with currency. Developers will come up with new client features that we can’t even imagine yet. People will find uses for currency in places we never dreamed of. Did Tim Berners-Lee fully anticipate how much was going to come from http and html? Probably not. A tidal wave of innovation was unleashed by the openness of the web. Similar innovation will be unleashed by openness of a currency protocol.

So, Cyclos could become more open by adopting these open protocols, enabling it to communicate with ANY other client using the protocol. It would also be more open if it allowed users to create their own currencies rather than depend on administrators to do so." (http://newcurrencyfrontiers.blogspot.com/2009/05/metacurrency-and-cyclos-clarifications.html)