Blog | Commerce.net

Decentralized Authoring Can Be Self-Healing

BoingBoing in Wikipedia proves its amazing self-healing powers pointed us to The Isuzu Experiment, which goes like this:

Joi Ito points to an ongoing discussion regarding the authority of wikipedia as a source of information and knowledge. The discussion was prompted by an article in the Syracuse Post-Standard that suggests, in part, that wikipedia “take[s] the idea of open source one step too far” by allowing the user to make corrections.

The article has been correctly ridiculed by many, including Mike at Techdirt. In a later posting, he suggests an experiment: why not go to a certain page, insert something provably incorrect, and see how long it lasts.

No matter which side of the debate you find yourself on, this sounds like an interesting experiment. So, I have made not one, but 13 changes to the wikipedia site. I will leave them there for a bit (probably two weeks) to see how quickly they get cleaned up. I’ll report the results here, and repair any damage I’ve done after the period is complete. My hypothesis is that most of the errors will remain intact.

Does that invalidate Wikipedia? Certainly not! If anything, the general correctness and extent of Wikipedia is a tribute to humankind. It suggests the Kropotkin may be right: that the “survival of the fittest” requires that the fittest cooperate. It means that there are very few Vandals like me who are interfering with its mission.

Terrible experiment, but it demonstrates how decentralized authoring can be self-healing. Wrote Phil in the Boing Boing summary,

Remember Al Fasoldt, the journalist who disparaged Wikipedia? He was challenged by a Techdirt writer to change an item and see if his change was found. While Fasoldt dismissed the idea, Alex Halavais thought it was an interesting idea. He made 13 changes to 13 different Wikipedia pages, ranging from obvious to subtle. He figured he’d give them a couple of weeks and then fix the ones that weren’t caught. Every single change was found and changed within hours.

It’s a terrible idea to vandalize Wikipedia like this. But it’s a wonderful thing how quickly self-healing Wikipedia is to such attacks.

September 8, 2004/by ams

Hal Varian on Differential Pricing

Commerce

Amit Patel wrote about a 1996 piece from Hal Varian on differential pricing:

I had thought that charging customers different prices for the same thing was unfair and the result of pure greediness. But Hal Varian explains why “differential pricing” might be better than fixed pricing, especially in industries with high fixed costs. One of the arguments boils down to: if some people are willing to pay more than others and the fixed costs are high, then you can end up in a situation where it is worse for the consumers (as a group) to all have the same price than to have different prices. The producer usually benefits from differential pricing, but in many (most?) situations the consumer does too. One case in particular is when the producer would go out of business without differential pricing; there is no benefit to the consumer of losing the opportunity of purchasing a product or service.

My sense of fairness says you should charge the same amount for the same thing, but the math shows that society is (overall) better off with less fairness.

“Fairness” is in the eye of the beholder.

September 6, 2004/by ams

Decentralizing Akamai

Decentralization

A step in the direction of “decentralizing Akamai” — but still uses the “centralized DNS” to create an interesting distributed web caching network — is the Coral Content Distribution Network.

Mike Dierken talks about the Coral CDN by quoting Gordon Mohr quoting Michael J. Freedman’s post to the p2p-hackers list:

To take advantage of CoralCDN, a content publisher, user, or some third party posting to a high-traffic portal, simply appends .nyud.net:8090 to the hostname in a URL. For example:

http://news.google.com/ –> http://news.google.com.nyud.net:8090/

Through DNS redirection, oblivious clients with unmodified web browsers are transparently redirected to nearby Coral web caches. These caches cooperate to transfer data from nearby peers whenever possible, minimizing the load on the origin web server and possibly reducing client latency.

Mike writes: “DNS/HTTP based P2P — Wicked cool and finally a REST based scalable p2p network. I wonder how I could use that at Amazon…”

Rohit asks if this technique could help Slashdot alleviate “The Slashdot Effect.” According to the Slashdot post on Coral, apparently not.

September 4, 2004/by ams

Markets in Deep Space

Decentralization

We’ve recently written a new position paper titled
Agoric Architectural Styless for Decentralized Space Exploration. It’s been submitted to the
2004 Workshop on Self-Managing Systems (WOSS’04) to be held at FSE-12 in Newport Beach. it was originally based on some notices of intent (NOIs) for a NASA Broad Agency Announcement (BAA) on innovative Human & Robotic Technologies (H&RT) for future space exploration missions.

Abstract: This position paper discusses an architectural approach to managing decentralized space exploration missions. Developing control applications in this domain is complicated by more than just the challenging computing and communication constraints of space-based mission elements; future exploration missions will depend on ad-hoc cooperation between independent space agencies’ elements. Currently, the frontier of interoperability is providing communication relays, as shown in by recent Mars missions, where NASA rovers relayed data via ESA satellites.

Future mission planning envisions more extensive autonomy and integration. Examples include: taking advantage of excess storage capacity at another node, multicasting messages along several paths through deep space, or even scheduling concurrent observations of an object using several instruments at different locations. An architectural style for developing mission control applications that does not depend on positive ground control from Earth could provide (a) increased margins for space-based computing systems, (b) increased reusability by an effective build-it-for-autonomy-first strategy, and (c) avoid the single-point of failure bias in standard distributed system design approaches.

In particular, we propose combining an architectural style for decentralized applications based on the Web (ARRESTED) with agoric computing to apply market discipline for allocating resources dynamically among coalitions of mission elements in space. Similar approaches may have applicability in other domains, such as crisis management or battle management.

September 1, 2004/by ams

How can society build software that lasts decades?

Decentralization

The following are only a few lines of excerpts from an extremely important argument about the “culture of design” surrounding software. It is a critical aspect of any effort to design “software that works the way society works,” to cite the credo of the decentralized software architecture crowd.

It may have an important impact on how CommerceNet Labs refines its own mission, too…

Software That Lasts 200 Years

In many human endeavors, we create infrastructure to support our lives which we then rely upon for a long period of time…

By contrast, software has historically been built assuming that it will be replaced in the near future (remember the Y2K problem). Most developers observe the constant upgrading and replacement of software written before them and follow in those footsteps with their creations…

In accounting, common depreciation terms for software are 3 to 5 years; 10 at most. Contrast this to residential rental property which is depreciated over 27.5 years and water mains and brick walls which are depreciated over 60 years or more… I can go to city hall and find out the details of ownership relating to my house going back to when it was built in the late 1800’s.

[Dan Bricklin] will call this software that forms a basis on which society and individuals build and run their lives “Societal Infrastructure Software”. This is the software that keeps our societal records, controls and monitors our physical infrastructure (from traffic lights to generating plants), and directly provides necessary non-physical aspects of society such as connectivity.

What is needed is some hybrid combination of custom and prepackaged development that better meets the requirements of societal infrastructure software.

How should such development look? What is the “ecosystem” of entities that are needed to support it? Here are some thoughts:

* Funding for initial development should come from the users…

* The projects need to be viewed as for more than one customer… Funding or cost-sharing “cooperatives” need to exist.

* The requirements for the project must be set by the users, not the developers. The long-term aspects of the life of the results must be very explicit…

* … Impediments such as intellectual property restrictions and “digital rights management” chokepoints must be avoided…

* The actual development may be done by business entities which are built around implementing such projects, and not around long-term upgrade revenue…

* The attributes of open source software need to be exploited. This includes the transparency of the source code and the availability for modification and customization… The availability of the source code, as well as the multi-customer targeting and other aspects, enables a market for the various services needed for support, maintenance, and training as well as connected and adjunct products.

* The development may be done in-house if that is appropriate, but in many cases there are legal advantages as well as structural for using independent entities..

* Unlike much of the discussion about open source, serendipitous volunteer labor must not be a major required element. A very purposeful ecosystem of workers, doing their normal scheduled work, needs to be established to ensure quality, compatibility, modifications, testing, security, etc… The health of the applications being performed by the software must not be dependent upon the hope that someone will be interested in it; like garbage collecting, sewer cleaning, and probate court judging, people must be paid.

The ecosystem of software development this envisions is different than that most common today. The details must be worked out. Certain entities that do not now exist need to be bootstrapped and perhaps subsidized. There must be a complete ecosystem, and as many aspects of a market economy as possible must be present.

August 31, 2004/by ams