De afgelopen weken zijn binnen de PvdA de systemen Your Priorities en DemocracyOS getest. Deze systemen bleken in de huidige vorm niet echt geschikt voor onze PvdA te zijn. In dit vierde artikel bespreken we enige oplossingsrichtingen.
Oplossingsrichtingen
Nu de geteste systemen niet direct toepasbaar zijn liggen er vier scenario’s voor de hand:
1. Een van de geteste systemen aanpassen;
2. Een of meerdere alternatieve systemen zoeken en testen;
3. Een tijdelijke voorziening (lees meerdere systemen);
4. Zelf een systeem gaan ontwikkelen.
Aanpassen?
Laten we eerst de volgende vraag beantwoorden: “Kunnen de al dan niet geteste systemen aangepast worden?”. Simpel antwoord: Ja, want deze systemen zijn Open Source. Uiteraard roept dat ook vragen op: Kunnen we dat? Wat zijn de risico’s? Wat kost dat qua geld en personele capaciteit? Geld en mensen op korte en vooral op lange termijn.
Nu ga ik u hier niet vermoeien met de diverse Open Source strategieën want dat is een wetenschap op zich. Kort door de bocht: of je gaat een geheel eigen afgeleide versie (fork) maken of je stopt tijd / middelen in de Open Souce “community” van ontwikkelaars en gebruikers om jouw wensen gerealiseerd te krijgen. De laatste heeft uiteraard de voorkeur. Samen sterk geldt vooral ook in OS-land. De uitdaging is dan wel om jouw wensen (tijdig) gerealiseerd te krijgen. Aanpassen en bouwen liggen overigens dicht bij elkaar. Beiden kunnen fikse en herhaalde investeringen betekenen.
Andere systemen?
Zijn er andere systemen? Jazeker! De wereld van democratie, participatie en internet is sterk in beweging. Dat heeft zijn klassieke voor en nadelen. Er zijn veel initiatieven, maar je kan nog niet spreken van een volwassen markt of volwassen systemen. Er komt van alles rijp en groen beschikbaar. Van theoretische traktaten tot al dan niet experimentele systemen. Goed opletten en professioneel selecteren is aldus geboden.
De alternatieven worden momenteel binnen de PvdA geïnventariseerd. Ik zal in dit artikel ter illustratie later op één groep nader ingaan: De liquid democracy groep van systemen.
Een tijdelijke voorziening?
Om de gedachten te bepalen: Bijvoorbeeld DemocracyOS aanpassen zodat het wat beter werkbaar wordt. Maar eerst: Waar komt het scenario van een tijdelijke voorziening überhaupt vandaan? Dat komt daar er enige tijdsdruk op het proces om te komen tot een betere ledendemocratie zit. Er ligt een expliciet besluit dat PvdA-leden nu eindelijk eens via het internet andere PvdA-leden moeten kunnen gaan benaderen (dit kan nu niet) en een reeks besluiten (en verwachtingen) om de nieuwe ledendemocratie in de praktijk te gaan brengen. Vandaar dat er ook nagedacht wordt over een tijdelijke voorziening. Een tijdelijke voorziening voor een deel van de processen. Inderdaad, een klassiek doelenconflict, met alle daaraan verbonden kosten en risico’s. Een lastig dilemma, waarbij ik persoonlijk liefst zorgvuldigheid zou laten prevaleren boven tijdigheid. Een goed systeem een paar maanden later lijkt mij beter te verantwoorden en verdedigen dan een reeks onzekere ontwikkelingen met alle mogelijke ellende daaromheen. Maar goed, ik wil expliciet stellen dat er ook andere overwegingen en afwegingen mogelijk zijn. Kiezen is altijd verliezen en zaken als draagvlak zijn dan uiteindelijk bepalend.
Zelf een systeem gaan ontwikkelen?
Uiteraard kan dat. Maar dat is dan wel iets geheel anders. Nu selecteren we een bestaand systeem met alle daarin vervatte kennis en keuzen. Ga je zelf ontwikkelen dan moet je al die kennis en keuzen expliciet maken en vastleggen zoals in een functioneel ontwerp, bestekken of een programma van eisen. Daar zijn genoeg methoden en technieken voor. De vraag is echter of we als organisatie daar wel goed toe in staat zijn en of we die investering kunnen en willen dragen.
Samenvattend kan gesteld worden dat alle oplossingsrichtingen hun problemen kennen. Het is te hopen dat er een bestaand en passend systeem gevonden kan worden dat, al dan niet met enige aanpassingen, een goede start kan geven aan een betere ledendemocratie met gebruik van het internet.
Een concrete oplossingsrichting
Laat ik u de totstandkoming van één (en expliciet niet dé) oplossingsrichting beschrijven. Ik ga hierbij uit van het scenario om ook naar andere systemen te kijken en deze te testen. U snapt, ik streef naar een optimale resultaat, risico en kosten beheersing. Vrijwel kant en klaar van de plank heeft immers zo zijn voordelen.
Een tweede overweging: Gelet op de testervaringen en de vele commentaren over een goede procesondersteuning lijkt het verstandig de processen zo mogelijk volgens de Liquid Democracy principes te structureren. Beter en/of anders kan ook (het kan altijd beter), maar momenteel ontbreekt nog het zicht daarop. In ieder geval is Liquid Democracy al verder in haar ontwikkeling en is vertaald in meerdere geautomatiseerde systemen. Ook is er veel materiaal dat voor opleidingen gebruikt kan gaan worden.
Maar waarom nu pas?
Een vraag die dan gelijk gesteld dient te worden is: Waarom zijn jullie er dan niet gelijk mee gaan testen? Die vraag heb ik ook gesteld. Reconstruerend kwam het er kennelijk op neer dat het meest bekende Liquid Democracy systeem (Liquid Feedback) enige technische problemen kende. Zaken zoals o.a. de opbouw (goede scheiding front en backend), de API werkt niet goed en de gebruikte programmeertaal was weinig populair. Dit betekend dat aanpassingen van het systeem of het koppelen van systemen lastig kan worden. Het is altijd een lastige situatie als een technisch aspect dreigt te gaan bepalen dat een functionele behoefte niet ingevuld wordt. Aan de andere kant zijn de hieruit volgende risico’s en kosten wel een helder argument.
Verder met een concrete oplossingsrichting
Wel Liquid Democracy is mooi, maar Liquid Feedback kent problemen. Wat nu? Daar komt ervaring met het ontwikkelen van software van pas.
De open-source-wereld-ervaring leert dat, als wij hier tegenaan lopen én het waar is én het belangrijk is, er in de Open Source wereld er meestal vanzelf alternatieven ontstaan. Belangrijk is je te realisten dat Liquid Democracy en Liquid Feedback vaak (heel verwarrend) als synoniemen gebruikt worden, maar dat het twee verschillende zaken zijn en er op basis van de Liquid Democracy gedachte meerdere systemen zijn ontwikkeld. Kost even wat tijd om dat uit te zoeken via het internet, maar al gauw blijkt: Binnen de Liquid Democracy familie blijken meerder alternatieven te zijn en te worden ontwikkeld.
De Liquid Democracy familie van systemen bestaan nu kennelijk uit o.a. Liquid Feedback, Adhocracy, Votorola, Candiwi, Newdemocracy en Liquidizer. Er zijn diverse artikelen te vinden die deze systemen onderling evalueren en waarderen. Ik wil niet nalaten een overzicht, met vele verwijzingen, van de Duitse Piratenpartei te noemen. Kort door de bocht: Adhocracy wordt vaak als een interessant alternatief genoemd.
Adhocracy is al wat langer actief in ontwikkeling. Dit is een belangrijk criterium. Waarom? Wel een oude management wijsheid is dat je liefst nooit de eerste klant van een nieuw product zou moeten willen zijn. Als manager is het verstandig om dingen te doen omdat het moet en niet omdat het kan. Betekend dat dat je nooit een nieuw product of systeem zou moeten gebruiken? Zeker niet, maar weet dan wel heel goed wat je kan, moet en doet.
Adhocracy is een directe concurrent van Liquid Feedback. Adhocracy wordt al vele jaren actief ontwikkeld en is ook gebruikt door de SPD, Die Linke, enz. Adhocracy is geprogrammeerd in een wat toegankelijker programmeertaal dan Liquid Feedback, te weten Python.
Bottomline betekend het dat we mogelijk met Adhocracy een interessant te testen Liquid Democracy alternatief hebben voor Liquid Feedback, Your Priorities en DemocracyOS.
Tot zover de beschrijving hoe we tot één van de alternatieven zijn gekomen. Nogmaals, zo zouden er mogelijk ook ander alternatieven gevonden kunnen worden. Misschien alternatieven met een nog betere workflow of alternatieven die heel flexibel in te richten zijn. We hopen ze te vinden, maar we hebben met Adhocracy in ieder geval al één testkandidaat.
Resumé
In dit artikel hebben we de diverse oplossingsrichtingen aangegeven en een stukje van de totstandkoming van één mogelijke oplossingsrichting uitgewerkt. Daarnaast hebben we het lopende onderzoek naar andere alternatieven aangegeven. Wat hier ook uitkomt en wat er ook gekozen wordt: Goed verder testen, plannen, opleiden en verwachtingen managen zijn vereisten om te komen tot een goede oplossing voor onze PvdA.
Wordt vervolgd.