Zur technischen Umsetzung von LiquidFeedback
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.
Erstmal vielen Dank für die sicher sinnvolle Initiative.
Allerdings stellt sich schon die Frage, warum ein Projekt, bei dem es um Partizipation geht ausgerechnet eine technische Grundlage wählt, die die Beteiligung anderer Entwickler höchst unwahrscheinlich macht.
Natürlich ist man mit selbst geschriebenen Tools recht produktiv und ich verstehe auch den Reiz, neue Programmiersprachen zu lernen. Aber bei grob geschätzt 100 weiteren Entwicklern weltweit, die LUA für Webentwicklung einsetzen, steht wohl nicht zu erwarten, dass das ganze zu einer großen Community wird. Auch das Schreiben eines weiteren Web-Frameworks (das zumindest bei grober Durchsicht außer einer exotischen Sprache keine großen Vorteile bietet) riecht doch etwas nach NIH-Syndrom. Wenn sich das ganze schon stark an RoR orientiert, warum nimmt man es dann nicht gleich und schließt damit an eine große Entwickler-Community an?
Wir haben uns zur Entwicklung eines eigenen Frameworks entschieden, NACHDEM wir intensiv mit Rails gearbeitet haben; allein schon der Speicherbedarf war Grund genug für uns. Hätten wir die Programmiersprache nach ihrer Popularität (und damit potentieller Community-Größe) ausgewählt, wären wir für das Webfrontend sicher bei PHP gelandet. Wir wünschen uns allerdings Qualität und nicht Quantität.
Vielerorts wurde über Liquid Democracy geredet. Monatelang wurde über Fragen wie die Wahl der besten Programmiersprache debattiert, aber eine Lösung, die auch für eine Partei geeignet wäre, kam nicht zustande. Dies war für uns der Anstoß mit der Entwicklung von LiquidFeedback zu beginnen.
In Berlin haben wir Zuspruch bekommen, was die Verwendung von Lua für das Frontend angeht. Ganz so neu ist die Idee, Lua für die Webentwicklung einzusetzen, ja auch nicht: So verwendet z.B. das OpenWrt Projekt Lua als Programmiersprache um eine Weboberfläche zur Routerkonfiguration zu realisieren. Das Projekt nennt sich LuCI und wurde vor längerer Zeit in der C-Base hier in Berlin vorgestellt.
Kann ein Programmierer sich in die Umsetzung der Prozessabläufe hineindenken und besitzt er/sie die notwendige Erfahrung, hieran Änderungen unter Berücksichtigung von Problemen wie Race-Conditions u.ä. vorzunehmen, dann sollte die Einarbeitung in eine neue Programmiersprache wie Lua das geringste Problem sein… Lua ist zwar keine Mainstream Sprache wie Java oder PHP, aber überzeugt durch Einfachheit und Stabilität. Siehe auch: http://www.lua.org/about.html
Aber Programmiersprachen sind nunmal Geschmackssache: Wir würden keinem OpenSource-Entwickler vorschreiben, in welcher Sprache irgendeine gute Idee umzusetzen ist. Das Recht selbst zu entscheiden nehmen wir auch für uns in Anspruch.
Im Übrigen sei gesagt, dass man aus praktisch jeder Programmiersprache (nicht nur aus Lua) auf den LiquidFeedback-Kern zugreifen kann, da dieser ausschließlich auf PostgreSQL aufbaut, wodurch es keine weiteren Dependencies gibt. In quasi allen Programmiersprachen gibt es entsprechende Bindings. Daher sehe ich gar kein Problem. Dir steht die Möglichkeit offen, ein alternatives Frontend, ein Reporting-Tool, eine Web-API oder andere Erweiterungen dieser Art in deiner Lieblingsprogrammiersprache zu entwickeln und mit dem LiquidFeedback-Kern zu verbinden.