Zum Inhalt springen

Entwickler gründen Interaktive Demokratie e. V.

27. Juni 2010
von jbebln

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
von darkbln

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. Februar 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. Februar 2010
von jbebln

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.

LiquidFeedback via mercurial – Bessere Unterstützung für Administratoren und Entwickler

30. Januar 2010

Ab sofort ist LiquidFeedback nicht nur als komprimiertes Tar-Archiv, sondern auch mittels eines verteilten Versionsverwaltungssystems (mercurial) verfügbar. Entwicklern wird es dadurch leichter gemacht, über Änderungen am Quellcode den Überblick zu behalten. Administratoren können auf einfachere Art Updates installieren, auch dann, wenn Anpassungen an der Software für die eigenen Bedürfnisse vorgenommen wurden. Zukünftige Updates werden ggf. schon vor einem offiziellen Release im jeweiligen Repository verfügbar sein.

Die Repositories für Backend, Frontend und Web-Framework finden sich unter http://www.public-software-group.org/mercurial/. Nach der Installation von mercurial, lassen sich die Repositories mittels der folgenden Kommandos herunterladen:

hg clone http://www.public-software-group.org/mercurial/liquid_feedback_core
hg clone http://www.public-software-group.org/mercurial/liquid_feedback_frontend
hg clone http://www.public-software-group.org/mercurial/webmcp

Ein späteres Updaten auf den offiziellen Entwicklungsstand ist innerhalb eines Repositories durch Eingabe folgender Befehlssequenz möglich:

hg pull
hg update default

Wenn du selbst Anpassungen an der Software vornehmen und diese durch mercurial aufzeichnen lassen willst, empfehlen wir dir, mittels „hg branch <my_branch_name>“ einen eigenen Entwicklungszweig anzulegen. Anschließend kannst du deine Änderungen mittels „hg commit“ in deine lokale Kopie des Repositories einchecken.

In den offiziellen Entwicklungsstand wechselst du mit „hg update default“, in deinen eigenen Entwicklungsstand gelangst du mit „hg update <my_branch_name>“.

Mittels folgender Befehle lassen sich Neuerungen aus dem offiziellen Codestand in den eigenen Entwicklungszweig überführen:

hg pull
hg update <my_branch_name>
hg merge default
# evtl. auftretende Konflikte lösen
hg commit -m merge

Wenn du deine eigenen Entwicklungen, die auch für andere Nutzer interessant sein könnten, in den offiziellen Codestand aufnehmen lassen willst, setze dich bitte mit uns in Verbindung.

Viel Spaß beim Coden!

Mitmachen

15. Januar 2010

Wir freuen uns über die vielen positiven Reaktionen auf unser LiquidFeedback-Projekt und die Angebote, uns zu unterstützen. Inzwischen haben wir uns hierzu Gedanken gemacht.

Übersetzer

Um das LiquidFeedback-Frontend in weiteren Sprachen verfügbar zu machen, suchen wir Übersetzer, idealerweise Muttersprachler, die die Übersetzungsdatei für ihre Sprache pflegen möchten. Programmierkenntnisse werden nicht gebraucht. Ein gutes Verständnis der Funktionen von LiquidFeedback ist jedoch nötig – hier helfen wir aber auch gerne.

CSS-Entwickler

Für LiquidFeedback soll es Skins geben, damit sich jeder Benutzer aussuchen kann, wie die Oberfläche aussieht. Wenn du in CSS fit bist, kannst du ganz einfach selber ein Stylesheet für LiquidFeedback entwickeln oder das bestehende anpassen. Hierzu kannst du dir vom Admin der von dir verwendeten LiquidFeedback-Instanz den Entwicklermodus freischalten lassen. Dieser erlaubt dir dann eine eigene CSS-URL festzulegen. Diese Funktion steht wegen der Gefahr, die von arglistig erstellten Stylesheets ausgehen kann, nur auf ausdrückliche Anfrage zur Verfügung.

Icon-Designer

Ein einheitliches Icon-Design für LiquidFeedback zu erstellen reizt dich?  Eingängige Darstellungen für Sachverhalte wie „eigene Beteiligung am Thema“, „potentielle Unterstützung“, „Initiator“ oder „Delegation aktiv“ auf  kleinster Fläche finden zu müssen siehst du als Herausforderung und nicht als Problem? Du bist eingestellt!  ;-)

JavaScript-Guru (IE)

Die Drag’n'drop-basierte Abstimmung über die Initiativen funktioniert bisher leider nicht im Internet Explorer. Wenn du das ändern möchtest (und kannst), melde dich bitte! Die Lösung soll nicht auf umfangreichen Bibliotheken basieren, sondern so leichtgewichtig wie möglich sein.

Webentwickler mit tiefgreifenden Kenntnissen zum Thema Barrierefreiheit

Damit LiquidFeedback zukünftig auch von Menschen mit Behinderungen besser (oder überhaupt erst) verwendet werden kann suchen wir Webentwickler (oder auch Betroffene), die uns hierbei unterstützen können. Eine tiefere Einarbeitung in die Entwicklung wird nicht erwartet, eine konkrete Beratung auf was im Detail alles zu achten ist hilft auch!

Datenbankentwickler

Wenn du dich mit PostgreSQL einschließlich stored procedures in PL/pgSQL sehr gut auskennst und dich erst ganz tief in der Datenbank richtig wohl fühlst, könnte eine Mitarbeit in unseren Core-Team in Frage kommen.

Webentwickler

Du kannst dich für Lua begeistern? Wenn du zudem bereits Erfahrung mit Webentwicklung unter Verwendung eines Frameworks (z.B. Rails, Symphony, Django, …) hast und bereit bist dich in das verwendete Framework WebMCP einzuarbeiten, solltest du dich bei uns melden.

Rechtliches

Die Software LiquidFeedback steht der Öffentlichkeit unter der MIT-Lizenz zur Verfügung. Damit wir deinen Beitrag in die Software aufnehmen (und auch veröffentlichen) können, benötigen wir daher dein schriftliches Einverständnis. Hierzu verwenden wir das „Contributor License Agreement“ der Apache Foundation. Weitere Informationen hierzu findest du auch auf unserer Vereinshomepage: http://www.public-software-group.org/contribute.

Zur technischen Umsetzung von LiquidFeedback

6. Januar 2010

Die LiquidFeedback Implementation gliedert sich in zwei Teile: Den LiquidFeedback Kern (Core) und das LiquidFeedback Frontend. Die Speicherstruktur aller Daten sowie die Stimmenauszählung unter Berücksichtigung vorhandener Delegationen und das Überführen der Themen und Initiativen in die verschiedenen Antragsstadien ist Teil des Kerns. Die gesamte Bedienoberfläche einschließlich Benutzerauthentifizierung ist Teil des Frontends.

Da grafische Benutzeroberflächen oftmals von vielen Softwarebibliotheken bzw. einem Framework abhängig sind, und diese Abhängigkeiten potentielle Fehlerquellen darstellen, haben wir uns als Entwickler dafür entschieden die Kernfunktionen möglichst unabhängig und plattformübergreifend zu implementieren. Wir glauben, dass uns dies durch die Wahl von PostgreSQL als technische Plattform für den LiquidFeedback Kern gelungen ist. PostgreSQL ist nicht nur eine äußerst verbreitete OpenSource-Datenbank, sondern bietet darüber hinaus umfangreiche Möglichkeiten prozedurale Abläufe mittels Funktionen und Triggern direkt auf dem Datenbankserver auszuführen. Die hierfür in PostgreSQL enthaltene Programmiersprache PL/pgSQL ist angelehnt an die Sprache PL/SQL der bekannten Datenbank Oracle, und trotz einiger “Pitfalls” bei vorhandenen Erfahrungen mit SQL vergleichsweise leicht zu erlernen. Die derzeitige Version des Kernes umfasst weniger als 3000 Zeilen Programmcode.

Die Implementierung der Kernfunktionen in PostgreSQL bietet einen weiteren Vorteil: Es ist möglich in praktisch jeder Sprache Frontends, Schnittstellen oder andere Dienstprogramme zu entwickeln. Es gibt keine Bindung an eine konkrete Sprache oder ein konkretes Framework, da ein Zugriff auf eine SQL-Datenbank in praktisch jeder Sprache möglich ist.

Das LiquidFeedback-Frontend ist in der Programmiersprache Lua geschrieben, die vor allem im Computerspielebereich eine hohe Verbreitung als Scriptsprache hat (siehe Wikipedia). Im gleichen Team, mit dem ich LiquidFeedback programmiert habe, erarbeiteten wir vor einiger Zeit motiviert durch die Erfahrungen mit Ruby on Rails ein eigenes auf Lua basierendes Web-Applikations-Framework, welches wir WebMCP nannten. Dieses steht genau wie LiquidFeedback der Öffentlichkeit unter einer MIT-Lizenz zur Verfügung. Auf Basis dieses Frameworks entstand innerhalb weniger Wochen die erste LiquidFeedback Bedienoberfläche.

Die Wahl der Programmiersprache für das Frontend ist zugegebenermaßen etwas außergewöhnlich – sie ermöglichte uns aber im Zusammenspiel mit dem Web-Entwicklungs-Framework ein hocheffizientes Arbeiten, so dass wir schon nach wenigen Wochen ein zum Kern passendes Frontend präsentieren konnten. Da, wie oben erläutert, fast aus allen Programmiersprachen heraus ein Zugriff auf PostgreSQL möglich ist, kann jeder, der alternative Bedienoberflächen, APIs oder Auswertungsprogramme schreiben möchte, eine Programmiersprache der eigenen Wahl verwenden.

Zukünftige LiquidFeedback-Erweiterungen anderer Entwickler verlinken wir gerne auf unserer Projektseite. Damit Änderungen in die offizielle Codebasis aufgenommen werden können, benötigen wir allerdings, wie bei größeren OpenSource-Projekten üblich, eine schriftliche Erklärung, dass wir die beigetragenen Programmzeilen der Öffentlichkeit zur Verfügung stellen dürfen. Dies ist nötig, damit zu einem späteren Zeitpunkt kein Urheber den Nutzern der Software das Verwenden untersagen kann.

LiquidFeedback wurde von einem Team entwickelt, dessen Mitglieder sich persönlich kennen und gut miteinander zusammenarbeiten können. Anders wäre eine solche Entwicklung gar nicht in so kurzer Zeit möglich gewesen. Unter allen beteiligten Entwicklern herrschte Konsens darüber, dass eine Software wie LiquidFeedback unbedingt unter einer freien Lizenz wie der MIT-Lizenz veröffentlicht werden muss, damit es prinzipiell jedem freisteht, die Software anzupassen oder weiterzuentwickeln, ohne hierbei einen rechtlichen Graubereich betreten zu müssen. Als Entwickler arbeiten wir grundsätzlich frei und unabhängig, und wir werden selbst entscheiden, welche Anregungen oder konkreten Patches wir in die Software aufnehmen. Nicht nur die Piratenpartei, sondern auch andere Organisationen, sollen von LiquidFeedback profitieren können. Durch die Wahl der Lizenz steht es jeder Partei oder Organisation frei, selbst Anpassungen an der Software vorzunehmen.

LiquidFeedback bei den Piraten Berlin

3. Januar 2010
von sferex

Ein Erfahrungsbericht

Die Piratenpartei beschäftigt sich seit 2007 mit dem Thema „Liquid Democracy“. Mit der Europawahl und Bundestagswahl konnte die Piratenpartei einen großen Mitgliederzuwachs verzeichnen, was zur Folge hatte, dass die parteiinterne inhaltliche Arbeit an Themen nun personell auf neue Beine gestellt werden konnte. In Folge dessen gründete sich in Berlin im Sommer 2009 das Squad Liquid Democracy (Anm.: Squads sind Arbeitsgruppen der Piratenpartei des Landesverbands Berlin) und schon bald war klar, dass zwar die Idee „Liquid Democracy“ charmant ist, aber es zu diesem Zeitpunkt leider noch keine Software gab, die den Anforderungen der Piratenpartei genügte. Engagierte Coder, allesamt Piraten, fanden sich zusammen, um an einer möglichst kurzfristigen Lösung zu arbeiten. Manch einer war überrascht davon, wie schnell die Software programmiert wurde!

Bald wurde innerhalb des Squad klar, dass die Konzeption der Software nicht die politische Umsetzung von Staatstheorien oder gar der Abschaffung der parlamentarischen Demokratie in Deutschland als Ziel haben kann, wie das z. B. von einigen Theoretikern vertreten wird, sondern zunächst ganz konkret die Schaffung eines innerparteilichen Diskurssystems, um bei gegebenen Mitgliederzuwachs dauerhaft auf Deligiertensysteme zur Entscheidungsfindung verzichten zu können.

Immer wieder wurde die Frage gestellt, wie einer „Vergrünung“ der Piratenpartei wirksam entgegengewirkt werden kann und schnell wurde bei der Diskussion klar, dass dies nur mittels technischer Hilfsmittel realisiert werden kann, so dass sich alle Piraten an der Meinungsbildung beteiligen können. Dabei wurde bei der Konzeption von LiquidFeedback beachtet, dass das System möglichst resistent gegen Störer sein muss und zu einer förderlichen Mitarbeit anregt.

Die Entwickler von LiquidFeedback sind der Meinung, dass sämtliche im Squad erarbeiteten Anforderungen erfüllt sind, um die Software in der Piratenpartei Berlin zum Einsatz zu bringen. Seit heute ist die Instanz auf pirateneigenem Server nun freigeschaltet und die ersten Erfahrungen können unter ganz realen Bedingungen gemacht werden. Interessant wird dabei sein, wie sich die Piratenpartei Berlin zu inhaltlichen Fragen aufstellen wird. So ist es mit LiquidFeedback zum ersten Mal in der gesamten Parteigeschichte in Deutschland möglich, dass alle Mitglieder einer Organisation an der Meinungsbildung beteiligt werden und konstruktiv mitarbeiten können. Was vor kurzem noch visionär gedacht war, wird nun ganz real möglich: Innerparteiliche Demokratie auch bei hohen Mitgliederzahlen! Wir sind auf die Ergebnisse sehr gespannt.

Interaktive Demokratie durch „Liquid Democracy”

29. Dezember 2009
von Andreas Nitsche

Interactive Democracy pulls political power away from those who secretly and insidiously buy political power, and gives it back to voters. Instead, the supercapitalists have to persuade us by the merit of their arguments.
Professor Robert Reich, University of California, Berkeley

Die Grundidee einer interaktiven Demokratie ist die Schaffung eines politischen Systems, in dem die meisten Sachfragen durch ein Referendum entschieden werden oder die Ergebnisse eines Referendums die Handlungsempfehlung für Repräsentanten bilden. Einen erfolgversprechenden Ansatz zur Schaffung einer interaktiven Demokratie stellt Liquid Democracy dar. Da niemand über hinreichend Zeit und Wissen verfügen wird, um alle Fragen selbst zu entscheiden, sieht Liquid Democracy eine übertragbare, themenspezifische Delegation des Stimmrechts an eine beliebige andere Personen vor, die jederzeit widerrufen werden kann. Die Möglichkeit der Stimmendelegation ist seit langem als „delegated” oder „proxy voting” bekannt. Wurde die Delegation des Stimmrechts ursprünglich genutzt, um bei Abwesenheit einen Vertreter zu beauftragen, so erhebt Liquid Democracy die Delegation zum Prinzip. Es geht letztlich um die Suche nach Experten ungeachtet der formalen Qualifikation: man delegiert seine Stimme an Menschen, denen man in einer Sachfrage vertraut, denen man also entweder in dieser Frage die Vertretung seiner Interessen oder die Entscheidung darüber, wer dies kann, zutraut. Da Liquid Democracy auf die für repräsentative Demokratien typische Bündelwahl und auf feste Wahlperioden verzichtet sowie jederzeit die aktive Teilnahme ermöglicht, kann sie Nachteile der repräsentativen Demokratie abmildern oder beseitigen, korruptionshemmend wirken, Lobbyarbeit nur noch auf der Basis von Argumenten aussichtsreich erscheinen lassen, zugleich aber einer Überforderung der Menschen durch eine unüberschaubare Flut zu treffender Entscheidungen vermeiden. Jeder Einzelne kann entscheiden, ob er sich so verhält wie in einer repräsentativen Demokratie oder in einer direkten Demokratie. Diese Entscheidung kann er außerdem für jedes einzelne Thema treffen. Es ergibt sich ein fließender Übergang zwischen repräsentativer und direkter Demokratie.

LiquidFeedback

Wir haben uns im Oktober 2009 zur Entwicklung der Software „LiquidFeedback” entschlossen. Von Anfang an stand für uns fest, dass wir uns nicht auf Abstimmungen beschränken wollen, weil der Diskurs eine wesentlich Voraussetzung für fundierte Entscheidungen darstellt. Konzeptionelle Arbeit wird heute in der Regel von kleinen Gruppen, Gremien, Expertenkreisen oder gar visionären Einzelpersonen geleistet. Wir haben dies zunächst als gegebene Realität akzeptiert. Die Herausforderung bestand darin, die konzeptionelle Arbeit der demokratischen Mitwirkung zu erschließen ohne sie gleichzeitig zu verhindern. Erreichen wollten wir dies über ein strukturiertes Feedback, einen formalisierten gesellschaftlichen Diskurs, der viel feingliedriger und unmittelbarer wirkt als der bekannte Prozess aus Verlautbarung, Medienecho, Stammtischdiskussion, Meinungsumfrage und Wahlergebnis. Wir gehen also davon aus, dass viele konkrete Vorschläge auch in Zukunft durch vergleichsweise kleine Teams erarbeitet und weiterentwickelt werden und halten dies nicht für kritikwürdig, solange sichergestellt ist, dass alle

  • Kenntnis erlangen,
  • durch Anregungen Einfluss auf die Weiterentwicklung eines Vorschlags nehmen,
  • bei Bedarf einen Alternativvorschlag einbringen und
  • an der abschließenden Abstimmung teilnehmen können.

Zunächst sei gesagt, dass jeder das gleiche Recht hat, als Initiator einen Vorschlag in das System einzustellen. Dies vorausgeschickt haben wir uns entschieden, die Bearbeitungshoheit für einen Vorschlag beim Initiator, also dem Autor, zu belassen. Der Autor erhält während der Diskussionsphase quantifizierte Rückmeldungen über den Zustimmungsgrad und das Potential für zusätzliche Zustimmung bei Umsetzung verschiedener Anregungen. Er selbst kann entscheiden, was in seinen Entwurf passt und was er einarbeitet. Dabei unterstellen wir das Bestreben des Autors, dass sein Vorschlag sinnvoll und konsistent bleibt und zugleich mehrheitsfähig wird.

Teilnehmer, die einem Entwurf zustimmen könnten, sofern bestimmte Voraussetzungen erfüllt werden, können diese notwendigen Bedingungen formulieren und die Anforderung mit dem eigenen Stimmgewicht versehen. Sofern eine Anforderung bereits existiert, kann das eigene Stimmgewicht hinzugefügt werden. Bereits gestellte Anforderungen sind nach dem Stimmgewicht beginnend mit dem höchsten Gewicht sortiert. Um die Chance der Realisierung der eigenen Anforderung zu erhöhen, ist es sinnvoll, sich (wann immer möglich) einer bereits bestehenden Anforderung anzuschließen. Alle vorhandenen Anregungen können wie folgt bewertet werden:

  • notwendigen Bedingungen für eine Zustimmung
    („bei Realisierung dieser Bedingungen würde ich zustimmen“)
  • Indikation der Präferenzsteigerung
    („dies macht den Vorschlag noch unterstützenswerter“)
  • Indikation der Präferenzsenkung
    („ich würde zwar weiterhin zustimmen, dies aber als Verschlechterung ansehen“)
  • hinreichende Bedingung für das Entziehen der Zustimmung
    („bei Realisierung dieser Änderung ziehe ich meine Unterstützung zurück“).

Alle Initiativen arbeiten nun auf eine Verbesserung des eigenen Vorschlags in Bezug auf seine Mehrheitsfähigkeit hin. Wenn eine Initiative einen neuen Entwurf (neue Version des Antrags) veröffentlicht, werden die Unterstützer über die Änderungen informiert (Versionsvergleich) und können die Bewertung ändern und angeben, ob sie eine Anregung als umgesetzt betrachten. Das Feedback umfasst die folgenden Informationen:

  • Zahl derzeit vorbehaltlosen Unterstützer
  • Zahl der derzeit vorbehaltlosen Unterstützer, die den letzten Entwurf schon gesichtet haben
  • Gesamtzahl der potentiellen Unterstützer
  • Angaben über die Anzahl von Anhängern und Gegnern einzelner Anregungen entsprechend der oben genannten Feedback-Klassifizierung sowie über Korrelationen zwischen Anregungen.

Wer mit seinen Anregungen nicht durchdringt, kann bei Bedarf selbst als Initiator auftreten. Bewusst haben wir während der Diskussionsphase auf die Möglichkeit der Eingabe fundamentaler Ablehnung verzichtet. Die Diskursphase soll den grundsätzlich an einem Vorhaben Interessierten Gelegenheit zur Verbesserung des Vorschlags in konstruktiver Atmosphäre geben. Wer einen Vorschlag grundsätzlich ablehnt, sollte Gegenvorschläge unterstützen oder selbst als Initiator auftreten. Stimmen können global, auf Themenbereichs- oder Themenebene transitiv delegiert werden. Durch Beteiligung oder Ausübung des eigenen Stimmrechts wird die Delegation für die jeweilige Diskussion oder Abstimmung automatisch hinfällig. Eine Moderation findet zu keinem Zeitpunkt statt, da die Einflussmöglichkeiten eines Moderators aus unserer Sicht dem demokratischen Anspruch des Systems widersprechen würden.

Im Anschluss an die Diskussionsphase erfolgt eine Abstimmung aller Anträge zum gleichen Thema. Als Wahlverfahren haben wir die Schulze-Methode gewählt. Eine Eigenschaft dieser Methode, die uns besonders wichtig war, ist die Klonresistenz: das Erstellen verschiedener Antragsvarianten zur gleichen Grundidee führt insgesamt zu keinem Vorteil oder Nachteil. Genau diese Eigenschaft bildet die Voraussetzung für den Verzicht auf Mehrheitsklüngelei” und taktisches Wählen. Ein Stimmberechtigter bringt bei LiquidFeedback alle Anträge, denen er zustimmen möchte, in eine Präferenzreihenfolge.  Dabei  kann er auch mehrere Anträge gleichbehandeln, indem er zum Beispiel zwei Favoriten oder mehrere Ersatzwünsche gleichen Ranges benennt. Auch abgelehnte Vorschläge können auf Wunsch in eine Präferenzreihenfolge gebracht werden, damit keine Motivation zur Zustimmung oder Enthaltung für das „kleinere Übel” entsteht. Im Rahmen der Auszählung wird zunächst die Gesamtzahl der Zustimmungen und Ablehnungen ermittelt und die nicht mehrheitsfähigen Anträge werden gestrichen. Die verbleibenden Anträge werden mit Hilfe der Schulze-Methode in eine Rangreihenfolge gebracht. Der Antrag mit dem höchsten Rang gilt als angenommen. Durch die Wahl einer klonresistenten Präferenzwahl brechen wir mit dem politischen Einigungszwang: niemand soll gezwungen sein, zur Schaffung von Mehrheiten schon im Vorfeld faule Kompromisse einzugehen.

Nach der Abstimmung werden alle Abstimmdaten offengelegt (namentliche Abstimmung). Dies gilt auch für die Informationen darüber, wer mit wessen Vollmacht gestimmt hat. Auf diese Weise kann jeder Teilnehmer selbst die Korrektheit der Ergebnisse überprüfen. Dies ist die einzige Möglichkeit, das System nachhaltig gegen Manipulationen zu schützen. Aus Datenschutzgründen können Pseudonyme zugelassen werden, wodurch die Abstimmung aber nicht zur geheimen Wahl werden kann. Eine geheime Wahl mittels Computer stellt ohnehin eine Illusion dar. Unter Verweis auf das Gibbard-Satterthwaite-Theorem bzw. das General Impossibility Theorem von Arrow plädieren wir jedoch während des Abstimmprozesses für eine organisatorisch sichergestellte Geheimhaltung von Zwischenergebnissen zur Verhinderung von Wahlmanipulationen (z. B. durch Bots). Obwohl die Schulze-Methode aufgrund ihrer Eigenschaften den Abstimmenden kein taktisches Wählen aufdrängt, kann nicht ausgeschlossen werden, dass das Ergebnis verfälscht werden könnte, wenn die Zwischenergebnisse weitläufig bekannt sind.

Entwickelt haben wir LiquidFeedback im Rahmen des Public Software Group e. V. mit Blick auf die Piratenpartei, deren Landesverband Berlin es ab Januar 2010 nutzen wird. LiquidFeedback steht der Öffentichkeit als Open Source Software unter MIT-Lizenz kostenfrei  zur Verfügung und kann daher auch von anderen Parteien, Gebietskörperschaften, NGOs, Vereinen und Stiftungen genutzt werden.

Ausblick

Es steht  zu vermuten,  dass auf  Liquid Democracy beruhende Entscheidungen zunächst  als Handlungsempfehlungen Eingang in bestehende demokratische Entscheidungsstrukturen finden werden. Selbst mit der unverbindlichen Einbettung in das übergeordnete System (etwa eine Partei) wäre schon viel gewonnen, weil erkennbar wird, ob ein Repräsentant sich dem Willen der Basis verpflichtet fühlt. Andererseits könnte dies aber auch  Repräsentanten dabei helfen, die „Einsamkeit” der Führungsposition wenigstens teilweise zu überwinden. Dafür ist es aber erforderlich, dass die Entscheidungen selbst keinesfalls schwammig sind. Die Regeln dürfen eben nicht „liquid” sein, vielmehr muss eine Entscheidung zu einem bestimmten Zeitpunkt zweifelsfrei feststehen und belastbar sein.

Möchte man mit einer Partei, deren Entscheidungen mittels Liquid Democracy in permanenter Interaktion zwischen Basis und Repräsentanten fallen, zusammenarbeiten oder gar eine Koalition eingehen? Zunächst einmal kann eine Entscheidung natürlich für eine vereinbarte Zeit gelten. Da unterscheidet sich Liquid Democracy nicht von anderen Entscheidungswegen, es kommt auf die vereinbarten Regeln an. Die sozialliberale Koalition fand übrigens 1982 ganz ohne Liquid Democracy ihr vorzeitiges Ende. Die grundsätzliche Frage wäre aber, ob Koalitionen nicht eigentlich der Suche nach der besseren Lösung im Weg stehen. Die Ausrichtung an Sachfragen könnte uns so bemerkenswerte Vorgänge ersparen, wie die Ablehnung dessen, was man eigentlich fordert aber leider von den „Falschen” beantragt wurde. Vielleicht werden sich die Parlamente der Zukunft durch wechselnde Mehrheiten und mehr Sachorientierung auszeichnen. „Wir wollen an die Regierung – wir wollen ja etwas bewegen.” kann man gelegentlich auch in der Piratenpartei hören. Wenn es um die Sache geht, könnte man mit wechselnden Mehrheiten – je nach Situation – vielleicht sogar mehr erreichen.

Eine große Herausforderung wird auch darin bestehen, die Bedeutung einer Entscheidung für einzelne Gruppen in das öffentliche Bewußtsein zu bringen.  Eine Entscheidung, die vielen einen kleinen Vorteil bringt, einigen wenigen aber einen großen Nachteil, bedarf der Abwägung. Berücksichtigt werden müssen unter Umständen auch Auswirkungen auf Dritte, die an einer Abstimmung gar nicht beteiligt sind. Es wird nicht mehr darum gehen, der Öffentlichkeit etwas „zu verkaufen”, sondern in einem mühsamen Prozess die für eine sinnvolle Entscheidung erforderlichen Informationen zu vermitteln, und es wird nicht genügen, nur die eigenen Interessen im Blick zu haben. Es wird dabei auch um die Frage gehen, was uns der soziale Friede wert ist, und zwar lokal, national und global. Das Durchsetzen von Partikularinteressen ohne gerechte Abwägung ist Kennzeichen einer zu überwindenden Politik alten Stils, die auch heute noch „unter Einbeziehung anderer Mittel” (Clausewitz) fortgesetzt wird. Wir verbinden mit der interaktiven Demokratie die Hoffnung, dass sich mit der Beteiligung vieler interessierter Menschen auch eine neue Sicht auf die Zusammenhänge der Welt gegen Unvernunft und übermäßigen Eigennutz durchsetzt.

Liquid Democracy – was fließt hier eigentlich und wohin?

16. Dezember 2009

Liquid Democracy vereinigt Elemente der repräsentativen und der direkten Demokratie. Ein Stimmberechtigter kann einen Repräsentanten mit der Wahrnehmung seiner Interessen beauftragen. Anders als bei der Wahl eines Amtsinhabers oder Abgeordneten kann die Delegation aber jederzeit geändert werden und der Stimmberechtigte kann seine Interessen auf Wunsch selbst wahrnehmen. Jeder Einzelne kann entscheiden, ob er sich so verhält wie in einer repräsentativen Demokratie oder in einer direkten Demokratie. Diese Entscheidung kann er außerdem für jedes einzelne Thema treffen. Es ergibt sich ein fließender Übergang zwischen repräsentativer und direkter Demokratie.