Skip to content

5 Jahre Liquid Democracy in Deutschland

17. August 2011
by

Vorläufer

Bereits im Jahre 1884 beschrieb Lewis Caroll in seinem Werk „The Principles of Parliamentary Representation“ die Idee des Delegated Voting: Das vorher schon bekannte Prinzip der Übertragung der eigenen Stimme bei einer Entscheidung an einen anderen Stimmberechtigten (Proxy Voting) wurde dahingehend erweitert, dass Stimmen auch über mehrere Stufen (transitiv) weitergegeben werden können (Delegated Voting).

Zu einem tatsächlich Einsatz kamen diese Verfahren praktisch nicht, sicherlich insbesondere aufgrund des hohen logistischen Aufwandes angesichts der damals zur Verfügung stehenden Mittel. Erst über 100 Jahre später wurde diese Idee in Zusammenhang mit den Möglichkeiten des Internets neu gedacht und die Idee der Liquid Democracy als ein demokratisches System mit direkten Abstimmungen und der Möglichkeit zur transitiven und jederzeit widerrufbaren Delegation der eigenen Stimme formuliert.

A democratic system in which most issues are decided by direct referendum. However, since no one has time for this, you can delegate your votes. Here’s the cool part; you can delegate your votes on a certain topic to one person, and then delgate your votes on another topic to someone else. And delegations are transitive; you can delegate to someone who delegates to someone else, etc, in which case your votes will flow to whoever is at the end of the line. Of course, you can “un-delegate” at any time.

David Cary am 29.01.2007 auf communitywiki.org

Gründung der Piratenpartei

In Deutschland ist die Idee der Liquid Democracy mit der Piratenpartei seit ihrer Gründung im September 2006 eng verknüpft. Am 16. Februar 2007 erfolgte der erste Eintrag zu Liquid Democracy im Dokumentations-Wiki der Piratenpartei, in dem die angestrebten Ziele formuliert wurden. Auch der erst viel später zu Tage tretenden Konflikt zwischen Überprüfbarkeit elektronischer Abstimmungen einerseits und Datenschutzansprüchen andererseits wird benannt.

Probleme: Geht nur mit zentraler Registratur wer was wann wo gewählt hat. (Datensparsamkeit?)

Martin Häcker im Wiki der Piratenpartei am 16.02.2007

Read more…

Sicherheitskritischer Bug in LiquidFeedback gefunden

17. May 2011
by

Im LiquidFeedback Frontend wurde ein sicherheitskritischer Bug entdeckt, der es ermöglichte, fremde Benutzerkonten mittels unbefugter Passwortänderung zu übernehmen. Die Sicherheitslücke wurde mit Version beta32 behoben.

Wir empfehlen alle LiquidFeedback-Instanzen schnellstmöglich auf die letzte Version zu aktualisieren und alle Teilnehmeraccounts zu überprüfen.

Ergänzung:

Der Download-Link auf oben verlinkter Seite zeigte fälschlicherweise bis um 12:00 MESZ noch auf die alte Version. Wir bitten diesen Fehler zu entschuldigen und ggf. erneut zu aktualisieren. Aufgrund eines weiteren Fehlers gibt die korrekte Version beta32 eine falsche Versionsinformation beta31 aus, so dass nicht schnell ersichtlich ist, ob der Bugfix tatsächlich eingespielt wurde. Dieses Problem wurde in der darauf folgenden Version beta33 behoben. Wir empfehlen daher ein Update auf beta33.

Die nächste Generation: #codename_blue

7. March 2011

Wir freuen uns, eines der umfangreichsten Releases anzukündigen, die es bei LiquidFeedback jemals gegeben hat.

Wir werden den neuesten Prototyp der LiquidFeedback-Software einschließlich eines neuen Frontends bei einer Release-Party im

Kulturverein Kinski e. V., Friedelstraße 28, 12047 Berlin
am Sonntag, dem 13.03.2011 um 18:00 Uhr vorstellen.

Wir bitten um Anmeldung an ajnATpublic-software-group.org

Entwicklerplattform dev.liquidfeedback.org gestartet

7. February 2011
by

Die Fortentwicklung von LiquidFeedback wird zukünftig auf der neuen Entwicklerplatform unter http://dev.liquidfeedback.org/ koordiniert. Die Projektkoordination und die Veröffentlichung von Softwarereleases wird auch zukünftig ebenso wie der Betrieb der neuen Entwicklerplattform durch den Public Software Group e. V. durchgeführt werden.

Der bereits im Sommer letzten Jahres von den Entwicklern der Software gegründete Interaktive Demoratie e. V. beschäftigt sich hingegen mit über die Technik hinausgehenden Fragen. Er wird zukünftig den Betrieb des Blogs liquidfeedback.org übernehmen.

Wir möchten die Gelegenheit nutzen, um auf die zwei neu eingerichteten Mailinglisten Main und Announce aufmerksam zu machen. Erstere dient den aktiven Entwicklern zur Koordination und zum Informationsaustausch, auf letzterer werden Ankündigungen (z.B. Hinweise auf neue Updates) veröffentlicht werden. Zu beiden Mailinglisten gibt es öffentliche Archive. Fehlerberichte und Featurewünsche sollten so wie bisher direkt in den Bugtracker eingetragen werden. Um internationale Zusammenarbeit zu ermöglichen, sind Entwicklerplattform und Mailinglisten englischsprachig.

Wir bedanken uns bei AS250.net für die freundliche Unterstützung beim Hosting der Entwicklerplattform.

Aussetzen von Stimmgewicht bei Inaktivität

6. February 2011

Mit dem Update auf LiquidFeedback-Kern Version 1.3.1 und dem dazugehörigen Frontend beta31 lässt sich das Stimmgewicht von Benutzern, die sich länger nicht mehr eingeloggt haben, automatisch entziehen. Die Zeit, nach der das Stimmgewicht von Teilnehmern ausgesetzt wird, lässt sich vom jeweiligen Betreiber durch Setzen des Wertes member_ttl in der neu eingeführten system_setting Tabelle der Datenbank einstellen. Da es sich hierbei um eine Konfigurationsoption des LiquidFeedback-Kerns handelt, kann diese nicht wie andere Optionen in der Konfigurationsdatei des Frontends eingestellt werden.

Teilnehmer, denen ihr Stimmgewicht auf die beschriebene Weise entzogen wurde, können dieses durch Einloggen wiederherstellen. Das Feature dient keinesfalls der Verhinderung von Sockenpuppen und kann eine ordentlich durchgeführte Akkreditierung weder ersetzen noch ergänzen.

Benutzer, die an einen anderen Teilnehmer delegieren, der länger nicht mehr aktiv gewesen ist, werden gewarnt. Hierzu ist mit der Konfigurationsoption config.delegation_warning_time des Frontends eine vom Aussetzen des Stimmgewichts unabhängige Zeitspanne einzustellen, nach der ein Benutzer als länger nicht mehr aktiv gilt.

Die Konfigurationsoption des Frontends config.last_login_enabled entfällt, so dass der benötigte Zeitpunkt des letzten Logins nunmehr immer bei jedem Loginvorgang gespeichert wird. Angezeigt (und im Datenbankexport exportiert) wird dieser anderen Nutzern gegenüber jedoch nur unter Angabe des Datums, ohne hierbei die genaue Uhrzeit zu offenbaren. Führt ein Login allerdings zur Reaktivierung des Accounts, wird der Reaktivierungszeitpunkt einschließlich Uhrzeit gespeichert und veröffentlicht, da dieser Einfluss auf Abstimmungsergebnisse hat.

Enquête-Kommission berät über LiquidFeedback

16. September 2010

Die “Enquête-Kommission Internet und digitale Gesellschaft” des Deutschen Bundestags berät sich in diesen Tagen über einen Einsatz einer Software zur Einbeziehung von Bürgern in die politischen Arbeitsprozesse. In die nähere Auswahl ist hierbei auch LiquidFeedback gekommen.

Um entscheiden zu können, welches der beiden Systeme, die derzeit in der engeren Auswahl sind, besser für den konkreten Anwendungsfall geeignet ist, hat die Kommission einen Fragebogen erarbeiten lassen, dessen Antworten hier (PDF) zu finden sind.

Alvar Freude bloggte über den aktuellen Stand der Enquête-Kommission. Etwas überrascht waren wir über die Aussage, dass man sich nicht darüber einig sei “welches Abstimmungsverfahren besser geeignet ist und zur Geschäftsordnung des Bundestages passt: Adhocracy setzt auf eine einfache Form der Mehrheitswahl, während Liquid Feedback die Schulze-Methode anwendet”.

Die Probleme der Mehrheitswahl, insbesondere in Hinblick auf taktisches Wählen, können durch moderne Abstimmungsverfahren vermieden werden. Wir möchten im Folgenden unsere Motivation beschreiben, die zur Entwicklung des LiquidFeedback-Antragsprozesses geführt hat, und erläutern, warum wir den Einsatz einer Präferenzwahl für notwendig erachten.

Bei kollaborativer Textarbeit gibt es ein Problem: Eine Menge von Personen kann Änderungswünsche an einem zu beschließenden Konzept einbringen wollen. Beim klassischen Wiki wird einfach jeder Person pauschal erlaubt Änderungen vorzunehmen. Eine Historie sorgt für Transparenz und gibt die Möglichkeit, schlechte Änderungen auch wieder rückgängig zu machen. Doch dieses Konzept birgt eine offensichtliche Schwachstelle: Wer definiert welche Änderungen schlecht und welche Änderungen gut sind? Zwei Parteien können sich über zwei Varianten des Textes streiten und dann immer abwechselnd die jeweils von der anderen Partei gemachten Änderungen zurücknehmen. Ein sogenannter Edit-War entsteht. In Wikis löst man dieses Problem oftmals durch eine Admin-Hierarchie. Wenn sich zwei Bearbeiter streiten entscheidet der Vorgesetzte. Sonderlich demokratisch ist das nicht – muss es im Anwendungsfalle vieler Wikis auch nicht sein. LiquidFeedback setzt sich jedoch das Ziel, höchste demokratische Ansprüche zu erfüllen, damit es für einen Einsatz in demokratischen Strukturen (z.B. Parteien) geeignet ist. Zur Vermeidung von Edit-Wars und der damit einhergehenden Notwendigkeit einer Hierarchie verwendet LiquidFeedback folgenden Mechanismus:

Autoren von Texten behalten ihre Bearbeitungshoheit über diese. Initiatoren entscheiden somit selbst, welche Änderungsvorschläge sie einarbeiten und welche Ideen sie bewusst unberücksichtigt lassen möchten. Hierbei wird jedoch zunächst der Anspruch an einen demokratischen Prozess verletzt, denn Initiatoren haben in Bezug auf ihre Initiative mehr Entscheidungsbefugnisse als andere Teilnehmer. Um dieses Problem zu lösen, wird es jedem Teilnehmer möglich gemacht Alternativvorschläge einzubringen, für den Fall, dass ein Antragssteller einen berechtigten Einwand unberücksichtigt lässt. Doch aufgepasst: Verwendet man ein Abstimmungsverfahren, welches dem Teilnehmer nur durch Enthaltung oder Ablehnung beim ursprünglichen Vorschlag die Möglichkeit gibt, seine Präferenz zur Alternative zum Ausdruck zu bringen, dann läuft man in ein Problem: Das Einbringen von ähnlichen Alternativvorschlägen zu einer Grundidee (oder schon das Abstimmen hierfür) schadet der Grundidee, weil sich ein Aufteilen der Stimmen auf die beiden ähnlichen Vorschläge nicht vermeiden lässt. Eine Rückkopplung auf das Abstimmungsverhalten ist die Folge, was nach demokratischen Gesichtspunkten als höchst problematisch angesehen werden muss.

Aus diesem Grund setzt LiquidFeedback ein Abstimmungssystem ein, welches das sogenannte Independence-Of-Clones-Kriterum erfüllt. Dieses Kriterium zur Beurteilung eines Wahl- oder Abstimmungsverfahrens wurde erstmalig 1987 von Nicolaus Tideman formuliert. Erst ein Abstimmungssystem, welches dieses Kriterium erfüllt, kann gemeinsam mit dem restlichen LiquidFeedback-Antragsprozess Beteiligungsmöglichkeiten schaffen, die a) keiner Moderation bedürfen und b) in höchstem Maße demokratisch sind.

Aus den genannten Gründen würden wir uns sehr über eine Entscheidung der Kommission zugunsten des LiquidFeedback-Antragsprozesses freuen.

LiquidFeedback bietet jedoch mehr als den LiquidFeedback-Antragsprozess: Die sogenannte Liquid Democracy. Hierbei geht es darum, dass Teilnehmer ihre Stimme für bestimmte Themenbereiche oder Themen an einen anderen Teilnehmer delegieren können. Warum dies eine sinnvolle Sache ist, wurde unter anderem in Folge #158 von Chaos Radio Express erläutert.

Die Kommission plant aber offenbar einen Einsatz ohne Delegation. Alvar Freude kommentiert auf dem Blog der Enquete-Kommission wie folgt:

“Allerdings wird wahrscheinlich die Delegations-Funktion ausgeschaltet, so dass es nicht möglich ist, mit Sockenpuppen sich selbst mehr Gewicht zu verschaffen.”

Hierzu möchten wir erneut deutlich machen: Sockenpuppen können nur durch einen ordentlichen “Akkreditierungsprozess” vermieden werden (z. B. durch Vergabe der Zugangsberechtigung per Brief) . Die Annahme, das Abschalten der Delegationsfunktion sorge für eine Reduzierung des Problems, ist äußerst problematisch. Erhöht jemand sein Stimmgewicht mittels Delegationen, dann ist dies zumindest noch nachvollziehbar. Sind keine Delegationen möglich, können die Sockenpuppenaccounts trotzdem im eigenen Sinne abstimmen und damit das Stimmgewicht faktisch erhöhen. Ohne eine ordentliche Akkreditierung wäre dies in der Regel nicht einmal nachweisbar.

Wir beobachten mit Spannung die Entwicklungen in der Kommission und hoffen, dass unsere Erläuterungen zur Verdeutlichung der hinter LiquidFeedback liegenden Konzepte beitragen. Für die Beantwortung von Fragen stehen wir weiterhin gern zur Verfügung.

Entwickler gründen Interaktive Demokratie e. V.

27. June 2010
by

Seit der Veröffentlichung von LiquidFeedback gab es seitens verschiedener Parteien und anderer Vereinigungen immer wieder Nachfragen bezüglich Informationsveranstaltungen zu LiquidFeedback und dem Einsatz elektronischer Medien zu demokratischen Zwecken. Da die Durchführung solcher Veranstaltungen den Rahmen der Public Software Group sprengt, haben sich Entwickler von LiquidFeedback zu einem neuen Verein “Interaktive Demokratie e. V.” zusammengeschlossen.

Die Entwicklung von LiquidFeedback und der anderen OpenSource Projekte wird unverändert im Rahmen des “Public Software Group e. V.” fortgeführt werden.

Core stable, öffentlicher Lesezugriff und Programmierschnittstelle

18. April 2010
by

Nachdem sich der Kern von LiquidFeedback einige Zeit im wesentlichen unverändert im produktiven Einsatz bewähren konnte, haben wir ihn nunmehr offiziell als stabile Version v1.0.0 deklariert (Sektkorken!). Das Frontend wird sicherlich noch einige Zeit “Beta” bleiben, da diverse Funktionen noch nicht fertig gestellt sind. Dennoch halten wir es aufgrund der in den letzten Monaten gesammelten Erfahrungen des realen Betriebs bereits jetzt für einsatzfähig. An dieser Stelle möchten wir uns bei allen Kontributoren, Testern, Unterstützern und Anwendern für die Mitarbeit und das konstruktive Feedback danken – ohne dies wäre LiquidFeedback heute noch nicht soweit wie es ist!

Das Frontend bietet nun einige neue (optionale) Funktionen: Es ist jetzt möglich, einen öffentlichen Nur-Lese-Zugang auf die Antrags- und Anregungstexte, die Unterstützerzahlen sowie die Abstimmungsergebnisse einzurichten. Profilseiten, Delegationen und Kontakte werden dabei nicht veröffentlicht. Die Pseudonyme der Initiatoren und der Autoren der Antrags- und Anregungstexte können wahlweise dargestellt werden. Diese Funktion kann durch Setzen der Konfigurationsoption config.public_access auf “pseudonym” oder “anonymous” aktiviert werden.

Weiterhin steht die erste Version der LiquidFeedback-Programmierschnittstelle (API) zur Verfügung. Bisher können die Daten zu Initiativen abgerufen werden. Hiermit soll die prinzipielle Funktionsweise in der Praxis überprüft werden können. Wenn die entsprechene Konfigurationsoption (config.api_enabled) auf true gesetzt ist, kann sich jeder Benutzer mittels eines unter Einstellungen -> Entwicklerfunktionen generierten API-Schlüssels Zugriff verschaffen; auf der offenen Testinstanz unter http://lqfb.de/testlogin ist die API angeschaltet. Die technische Dokumentation kann unter http://www.public-software-group.org/liquid_feedback_frontend_api abgerufen werden. Es ist geplant weitere Daten per API verfügbar zu machen. Ebenfalls sollen später über API-Anfragen auch schreibenden Zugriffe möglich sein, wie das Erstellen und Unterstützen von Initiativen und Anregungen, Setzen von Delegationen, sowie die Stimmabgabe bei der Endabstimmung. Wir freuen uns schon jetzt auf den ersten Twitter-Bot. :-)

Die Präferenzwahl richtig nutzen

15. February 2010

Oftmals gibt es den Fall, dass mehrere Anträge zur Abstimmung zugelassen werden, die man grundsätzlich unterstützenswert findet und die sich evtl. nur in Detailfragen unterscheiden. Um zu vermeiden, dass diese Anträge trotz einer eigentlich bestehenden Mehrheit aufgrund von gegenseitiger Stimmenwegnahme nicht beschlossen werden können, gibt es in LiquidFeedback die Möglichkeit, mehreren konkurrierenden Anträgen GLEICHZEITIG zuzustimmen. Die verschiedenen Alternativanträge lassen sich außerdem in eine persönliche Präferenzreihenfolge bringen.

Die Bedienung in der LiquidFeedback Endabstimmung funktioniert folgendermaßen (Screenshot, Video):

Zunächst zieht man seinen eigenen Favoriten mit der Maus in die grüne Box “Zustimmung”. Danach wählt man den nächsten Antrag, dem man zustimmen möchte, und zieht ihn

  • in die gleiche grüne Box, falls man diesem Antrag gleichberechtigt zustimmen möchte – oder –
  • ZWISCHEN die Zustimmungs- und Enthaltungsbox, falls man diesem Antrag nur zustimmen würde, für den Fall, dass der Erstwunsch nicht gewinnt.

Auf diese Weise fährt man fort und legt die Präferenzreihenfolge der Anträge, denen man zustimmen möchte, fest. Ablehnungen lassen sich auch in eine Präferenzreihenfolge bringen.

Allen Anträgen, denen man für den Fall zustimen würde, dass sie als einziger Antrag zur Abstimmung stünden, sollte man auch tatsächlich eine Zustimmung erteilen. So kann man unter Umständen vermeiden, dass wenn der eigene Favorit keine Mehrheit findet, am Ende gar kein Antrag oder ein ungewünschter Antrag gewinnt. Diese “Ersatz-Zustimmungen” kann man als Zweit- oder Drittwunsch im System hinterlegen, so dass (vereinfacht dargestellt) diese Stimmen ihre Wirkung nur dann entfalten, wenn der Erstwunsch nicht gewinnt.

Weitere technische Erläuterungen:

Das genaue Auszählungsverfahren, welches für die Endabstimmungen in LiquidFeedback zum Einsatz kommt, ist die sogenannte Schulze-Methode. Diese Auszählungsmethode wurde erst im Jahre 1997 von Markus Schulze entwickelt und gehört zu den wenigen Verfahren, die folgende drei Anforderungen in Kombination erfüllen können:

  • Jedem ist es möglich all seine Präferenzen zum Ausdruck zu bringen
  • Anträge zu denen es ähnliche Alternativanträge gibt, werden nicht prinzipbedingt bevorzugt oder benachteiligt
    (hängt mit der Erfüllung des “Independence of clones criterion” nach Nicolaus Tideman zusammen)
  • Kein Auftreten von negativem Stimmgewicht (im Gegensatz zu Stichwahlen oder Instant-Runnoff-Voting)

Es werden allerdings nur jene Anträge mit der Schulze-Methode ausgewertet, die mehr Zustimmungen als Ablehnungen aufweisen.

Transparenz und Nachvollziehbarkeit bei LiquidFeedback

6. February 2010

Kein System ist unangreifbar. Genau aus diesem Grund wurde beim Design von LiquidFeedback ein besonderes Augenmerk darauf gelegt, die gesamte Stimmenauszählung nachvollziehbar zu gestalten, so dass sich jeder Teilnehmer selbst von der korrekten Zählung seiner Stimme überzeugen kann. Da hierbei auch Delegationen eine Rolle spielen, wird bei jedem Thema zu bestimmten kritischen Zeitpunkten ein sogenannter “Snapshot” erzeugt, der eine Kopie der aktuellen Unterstützersituation incl. der verwendeten Delegationen darstellt. Mittels dieser Snapshots und den Daten der Endabstimmung lässt sich später nachprüfen:

  • Welche Teilnehmer zum Ende der Phasen “Neu”, “Diskussion” und “Eingefroren”
    • zur Grundgesamtheit in Bezug auf die Themendiskussion gezählt haben
    • einen bestimmten Antrag unterstützt haben
    • sich für eine frühere oder spätere Abstimmung des Themas ausgesprochen haben
  • Wie in der Endabstimmung jeder einzelne Teilnehmer abgestimmt hat

Um zu verhindern, dass verschiedenen Teilnehmern unterschiedliche Datenbestände angezeigt werden können, sollten die Datenbestände den Teilnehmern auch als Download zugänglich gemacht werden. Durch eine weitergehende Aufbereitung und Veröffentlichung der Daten innerhalb der einsetzenden Organisation kann allen Teilnehmern die Möglichkeit gegeben werden, die Stimmenauszählung zu überprüfen, ohne dass hierbei den Administratoren des Systems vertraut werden muss.

LiquidFeedback lässt sich so konfigurieren, dass angemeldeten Benutzern regelmäßig erstellte Archivdateien zum Download bereit stehen. Diese Archive enthalten alle abstimmungsrelevanten Daten incl. Namen bzw. Pseudonymen der Abstimmenden. Andere sensible Daten wie Passwörter oder E-Mail-Adressen sind jedoch ausgenommen. Auch das Feld “Realname” und die weiteren Inhalte der Benutzerseiten sowie gespeicherte Kontakte sind aus Datenschutzgründen nicht im Download enthalten.

Follow

Get every new post delivered to your Inbox.

Join 61 other followers