Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

[Gabor Kiss]

> There are a handful of people with the background and skills to write a
> next-generation keyserver.  I looked into it a dozen years ago and wrote
> up a whitepaper on it.  I know Phil Pennock has put a lot of thought
> into it.  Andrew, likewise.  There are easily five or six people on this
> list who have the time and ability.
> 
> What we don't have is *consensus* -- not only among ourselves, but in
> the larger community.
> 
> Let's say I decide to implement my whitepaper from 2007.  It would take,
> oh, call it 200 hours of work to implement.  So I write it, put it out
> there, and nothing happens because there's no consensus my idea is the
> direction we should go.
> 
> The problem here is not a lack of manpower or skill.
> 
> It's a lack of community consensus on what a redesign should look like.

My 2 cents:
It is no use to wait a great consensus.

The working model of open source development is:

10 publishing a formal protocol description[1]
20 some peoples implement it
30 collecting experiments
40 years later other peoples write a different implemantation that
  is compatible with the original 
50 GOTO 30

[1]: The famous paper describes the _algorithm_. A protocol description
writes bit-by-bit what is transferred on the wire, what to in case
of any errors, what must to do and what is optional etc. See RFCs.

If there would be _competing_ implementations operators could choose
which one they run. This is an evolution.
Remember Sendmail. 30-40 years ago it was virtually the only (non proprietary)
mail transfer agent (MTA). Eric Allman did a great job. But later other guys
had different ideas. Now there is a dozen MTAs on the market and almost
nobody uses Sendmail. But some do.
And all these programs can talk each to other due to RFC 821 (1982).

Gabor