ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

[ga] Rod Beckstrom, Twiki, and Foswiki -- the case for "getting things right" on new TLDs lest the root be forked

  • To: GNSO GA Mailing List <ga@xxxxxxxxxxxxxx>
  • Subject: [ga] Rod Beckstrom, Twiki, and Foswiki -- the case for "getting things right" on new TLDs lest the root be forked
  • From: George Kirikos <gkirikos@xxxxxxxxx>
  • Date: Sun, 16 Jan 2011 14:10:51 -0800 (PST)

Hi folks,

I wonder if the NomCom and ICANN Board knew about Rod Beckstrom's history with 
Twiki.net (and in particular how there was a "fork" of the Twiki project into 
Foswiki, with a lot of developers leaving)?? 

According to Rod Beckstrom's bio at:

http://beckstrom.com/Speaking_Bio

he describes himself as the "co-founder" of Twiki.net. Twiki is an open-source 
wiki software project, and Twiki.net represented the commercialization of that 
project. This attempt to monetize the project led to unexpected and chaotic 
outcomes. In particular, it led to the creation of "Foswiki", see:

http://foswiki.org/About.WhyThisFork
http://blog.wikiring.com/Blog/BlogEntry36

which was a fork of the Twiki project. In other words, as per the statistics in 
the 2nd link, nearly ALL of the developers who were active in Twiki left that 
project, to form Foswiki, because they were unhappy with the direction taken by 
Twiki.net!

This has important parallels within the ICANN world. There are forces 
attempting 

to ignore the public interest, and instead create unlimited new TLDs which 
would 

have commercial benefits to a small group of ICANN insiders at the expense of 
the public. ICANN is supposed to only enact policies where the benefits exceeds 
the costs, but has failed to produce any acceptable economic studies which 
support these commercialization activities.

The danger is (as with the Twiki experience which Rod Beckstrom must certainly 
be aware) that the stability and security of the root itself can be put into 
jeopardy, as it either splits, or no longer becomes universally resolvable. 
ICANN's main mission is to ensure the stability and security of the naming 
system, and thus a split (or "forked") root system would certainly represent a 
disastrous outcome to the internet community. There has been talk about forming 
a P2P DNS:

http://twitter.com/brokep/status/8779363872935936

due to unhappiness with ICANN, and also talk of creating "Response Policy Zones"

http://www.circleid.com/posts/20100728_taking_back_the_dns/

which would be inconsistent with universal resolvability of domains, due to 
blocking lists that would override ICANN's root.

We have seen a huge amount of staff turnover at ICANN (including the recent 
departure of Tina Dam) since Mr. Beckstrom became President and CEO, and this 
appears to have some parallels with the mass exodus of developers which led to 
the creation of Foswiki.

Given the experience with Twiki/Foswiki, we question whether Mr. Beckstrom has 
learned the proper lessons about forming a community consensus. He might simply 
be the wrong man for the job, the wrong type of "leadership skills" that are 
tuned for commercialization of private interests, but NOT for serving the 
public 

interest. We challenge ICANN and its Board to "get things right", and stop 
gambling with the future of the DNS. ICANN needs to stop acting like an 
internet 

startup trying to make commercial gains for itself, and remember that it was 
created to serve the public interest. Gambling and risk-taking are certainly 
acceptable in the venture capital world, however, those are not attributes that 
are highly valued in the world of public service, where the public seeks 
trusted 

custodians who will minimize risk.

If ICANN will not act to "get things right", we urge the DOC/NTIA/DOJ and GAC 
to 

find the right leaders who will not gamble with the security and stability of 
the DNS. Clearly DAGv5 is nowhere close to "getting things right", and must be 
abandoned.

Sincerely,

George Kirikos
http://www.leap.com/




<<< Chronological Index >>>    <<< Thread Index >>>