Open Samenwerken, hoe doe je dat?
open samenwerking code for nl open source
14 juni 2021
Je project open stellen voor open samenwerking met andere organisaties, teams of “de community” is niet altijd eenvoudig. Toch is het de wens van veel overheidsprojecten om meer open te gaan werken. Code for NL organiseerde een meetup waarin vanuit drie projecten ervaringen werden gedeeld.
Drie projecten die momenteel in de Code for NL community leven werden besproken: Vrijwillig machtigen door Anouschka Scholten, CoronaCheck door Eva van Sloten en Algoritmeregister door Ivonne Jansen-Dings. Daarbij kwam een aantal vragen aan bod:
Wat is werken met “de community”?
Er is niet één community: als project heb je mogelijk te maken met verschillende groepen mensen die op de een of andere manier willen meedenken of mee helpen. Code for NL is er daar één van: een community van developers en designers die heel graag hun kennis, ervaring en expertise willen inbrengen om de overheid te helpen bij de digitale transformatie. Afhankelijk van het type community zijn er verschillende manieren om dit te organiseren.
Hoe begin je met “open werken”?
Laagdrempelige manieren van meer openheid zijn zaken als: een openbare website waarop je omschrijft wat je gaat doen en waarom, het organiseren van open meetups, een open chatkanaal voor discussie, open repositories met daarin de code die gemaakt wordt. Ook erg interessant is open posts vanuit het kernteam over hun observaties en ervaringen.
Echte inhoudelijke samenwerking is vaak pas mogelijk als bovenstaande zaken “makkelijk” gaan.
Hoe houd je verschillende meningen bij elkaar?
Zoveel mensen, zoveel wensen. Meningen lopen vaak uiteen, en dat wil ook best wel eens botsen. Hoe zorg je er dan voor dat een project niet ontploft? Twee belangrijke factoren die naar voren kwamen: open discussie en duidelijke gedragsregels. Door continu een open discussie te blijven voeren worden frustraties in een vroeg stadium afgevangen en ontstaat er wederzijds begrip in plaats van polarisatie. Daarbij is het van belang om gedragsregels voor deze discussie daar ook op in te richten (bijv. iedereen komt aan bod, geen agressie) en die te hanteren.
Hoe maak je open mogelijk?
Op de vraag hoe je open beter mogelijk maakt, komen veel suggesties: “open tenzij”, normaliseren door het meer te laten zien. Ook het bouwen aan een betrouwbare community kan bijdragen. Maar ook het niet direct benoemen van open, maar stapsgewijs introduceren, zodat het minder “eng” is. Ook zou het goed zijn om als team expliciet te maken hoe je met elkaar omgaat, en hoe je met anderen (bijv. de community) wil omgaan.
Verder wordt genoemd dat er ook wel echt verschillende mates van open zijn, en dat “open communiceren” misschien vaak makkelijker is dan de broncode open stellen.
Uit ervaringen is het wel zo dan het wachten met het aanhaken/introduceren van een open community wel een shock oplevert, waarbij een blik aan frustraties open gaat.
Tot slot komt een idee voorbij voor een Code for NL OPEN WERKEN AWARD voor een persoon of project dat hier op een zeer goede manier invulling aan weet te geven.
Wat maak je niet open?
Dingen waarvan wordt gezegd dat ze niet of beperkt in de openheid kunnen zijn fraude-detectie, politiek gevoelige proof of concepts voor technische haalbaarheid, en zaken waarvoor de context te veel ontbreekt om ze te kunnen duiden als je er toevallig bij terecht komt.
Dit levert best wat discussie, waarbij wordt gesuggereerd dat ook deze zaken te ondervangen zijn.
Rimpeleffect
Een van de problemen die er is met volledige openheid, is dat dingen nog wel eens uit hun context getrokken worden. Journalistiek en maatschappelijk middenveld, die als tweede schil meekijken, kunnen geneigd zijn snel aan de haal te gaan met opmerkingen of ideeën die nog prematuur zijn. Ook daar is iets van een nieuwe dynamiek nodig: meer open betekent ook meer nuance en een open dialoog.
Eigen observatie
Veel manieren van werken en gebruikte technieken zitten open samenwerken ook best wel in de weg. Het gebruiken van Word documenten, powerpoints en e-mails om je project te beschrijven zorgt niet alleen voor gedoe met laatste versies, maar het is ook meer en meer onmogelijk voor buitenstaanders om op de hoogte te komen van wat er precies gedaan wordt. In lijn met de “open tenzij” gedachte zou ik daarom pleiten voor het gebruiken van publieke “websites” voor het schrijven van projectvoorstellen en presentaties en (zo veel mogelijk open) communicatie daarover. Vanuit Code for NL helpen we daar graag bij.
Andere aantekenignen
Design thinking: maatwerk is helemaal terug
1 maart 2018
“One size fits none. Overheden moeten weer meer zelf gaan ontwikkelen. Ze hebben gekke processen,” stelt Maarten Geraets. Hij zette drie jaar geleden op verzoek van de gemeente Amsterdam het Datalab op. Zijn opdracht was om met een innovatief team datagedreven toepassingen te zoeken voor een aantal zeurende problemen in de stad. Geraets ontwikkelde daarvoor samen met zijn zakenpartner Johan Groenen de Fixxx-methode, ofwel Fast Innovation Amsterdam. Inmiddels zijn al verschillende projecten met succes afgerond.
Een app om de toekomst te voorspellen
24 januari 2021
Een tijd geleden kreeg ik het verzoek om een Tarot app te schrijven. In eerste instantie moest ik even nadenken; ik geloof namelijk niet in dit soort zaken. [discussie: moest ik deze klus daarom afwijzen?] Uiteindelijk heb ik het appje gemaakt, en daarbij kwam er een interessante afweging voorbij.
De vijf F-strategieën voor Digitale Autonomie
7 november 2024
Welke strategieën kan de overheid ontwikkelen om de (digitale) autonomie van zowel overheid als samenleving te waarborgen? In dit artikel een voorzet in de form van vijf F-woorden.