Meta-Tool

[Friedrich Lindenberg]

Hm, I feel a bit like you're trying to make this argument by
repetition, but maybe that's just the sheer number of lists we're both
on ;-)

> Now with a shared registration the different engines can still compete
> for the best solution, but not at the cost of the whole e-dem-movement.

First off, we're nowhere near a common registration protocol. While I
very much like Mike's attempt to define a common vocabulary and a set
of requirements, this actually just shows how much more work needs to
be done here (and, I feel, that we shouldn't over-engineer this in a
first iteration). Judging from yesterday's minutes of the Berlin LD
squad, they seem to have put any OpenID work on ice pending the
evaluation of LF in Berlin. This essentially means that we'll not have
an concrete use case for registration in a little while. Setback.


As for your proposal for creating a Grand Unifying Platform, I think
you should really start to consider the difficulties involved in this.
Let me again state that I do appreciate the idea, but I don't want to
build the framework before knowing what kind of LD does actually work.
At this stage, none of the platforms involved have yet gathered and
maintained any social momentum.

It's like we're developing three very large carrier airplanes, each
built for a slightly different purpose. One of them is made for
carrying freight, another for transporting people and the third is
actually a helicopter in disguise. None of our planes have actually
left the ground yet and we don't have the models to predict whether
any of them will. No-one would suggest that this is a very good moment
to standardize propeller sizes. We don't know which size works.

Of course we'll have to talk about interoperability in the long term,
but right now there is just no basis for a debate based on empirical
experience. Let me take your vote mirroring proposal as an example:
you don't discuss different kinds of voting systems, preference voting
v. binary voting, security, synchronization and timing issues, etc.
etc. Essentially this is a proposal for the replication of Votorola
pollserver state in a controlled environment, but that's it.

You'll probably disagree with all of what I've said because I describe
LD as a tool (actually, an airplane, sorry for that), while you
consider it a platform. But I feel that strategically we're better off
introducing LD into small groups and organizations to gather the
experience we need to refine our implemenations. These groups could be
NGOs, protest movements, open source projects etc.

Asking for the LD tools to synchronize all those internal platforms is
actually asking for LD to synchronize all those organizations (i.e.
civil society). That's a legitimate goal, but it's something that
people with more resources and better strategies than us have failed
at repeatedly. There is a possibility LD might overcome this, but the
main premise of such a scenario is that LD has been running
successfully within some of the involved groups for a while. There is
no way that (a) we're going to develop a functioning protocol
framework for a complex LD from scratch without heavy experimentation
with different implementations beforehand and (b) that any serious
political group would adopt such a software just based on its
theoretical merits.

This is all just meant to explain why I think we should focus on a
shared discussion on individual technical issues, but why I won't
invest any resources into a Grand Unified Platform while I don't see
an actual use case (i.e. a likely adoption by many groups).

Cheers, Friedrich

-- 
Friedrich Lindenberg <friedrich at pudo.org>