---
tags: blog
---

# Samarbete i praktiken

*Om min svenska är svår att läsa finns även en [engelsk version nedan](#Collaboration-in-practice) ([English version below](#Collaboration-in-practice)).*

**Det är lätt att prata om samarbete vid utveckling av mjukvara, men vad betyder det i praktiken, och hur kan du skapa förutsättningar för det?**

Hej, jag heter Jan Ainali. Som Codebase Steward på [Foundation for Public Code](https://publiccode.net) hjälper jag gemenskaper i kodbaser att komma samman och hitta synergier i deras arbete med att förbättra sin kodbas. Du har kanske redan läst [om oss](https://os2.eu/blog/foundation-public-code-how-help-governments-develop-high-quality-sustainable-cost-effective-and) eller [Standard for Public Code](https://os2.eu/blog/ny-release-af-standard-public-code) (en resurs vi har utvecklat för att underlätta samarbete mellan offentliga institutioner) på denna blogg förut. Baserat på några nyliga erfarenheter vill jag dela en aha-upplevelse om vad som gör kodbasgemenskaper effektiva och spännande. Lite överraskande kanske handlar det inte om att göra saker utan att tala om vad du vill ha gjort.

## Varför ens samarbeta?

Man skulle kunna vara byråkratisk och peka på [OS2:s filosofi](https://os2.eu/side/om-os2):

> At skabe og dele relevante digitale løsninger og resultater i det offentlige til gavn for borgerne.

och säga att det är skälet till samarbete, men jag vill gräva lite djupare än så. Filosofin har inte uppstått i ett vakuum, utan är kärnan i rörelsen för öppen källkod på grund av värdet det för med sig.

Fördelarna kommer inte bara från att det är fler personer som jobbar med samma sak, vilket förstås också är bra, utan från den ökade mångfalden av idéer, perspektiv och kunskap. Detta summerar ofta till något större än att arbetet kan delas upp och utföras parallellt. Låt mig demonstrera.

## Praktiska exempel från Signalen

Nyligen i kodbasen [Signalen](https://signalen.org) gjorde utvecklarna i Signalen en tillgänglighetsanalys och identifierade en del saker som kunde förbättras. De andra som utvecklade, från Föreningen för Nederländska Kommuner (VNG), hade precis själva gjort ett sådant arbete och med arbetet färskt i minnet erbjöd de att hjälpa till eftersom att det var lätt för dem att starta.

På ett liknande sätt hade Signalen en väldigt enkel webbplats och när det började talas om att lägga till flerspråkighetsfunktion till den stod det klart att en ny utvecklare nyss lärt sig ett sådant ramverk vilket gjorde att det snabbt kunde anpassas för Signalen. Som en bonus kunde ramverket också återanvändas av kodbasen Openzaak.

En av kommunerna som planerade att implementera Signalen ville ha en manual för sina tjänstemän. Amsterdam förklarade att de redan hade ett sådant internt dokument. Detta formaterades om och publicerades online samtidigt som den första implementerande kommunen (Almere) dokumenterade sina erfarenheter, framförallt om processen av implementeringen. Så genom att de tre parterna kommunicerade kunde material inte bara återanvändas utan också förbättras mycket snabbare än att starta från noll och det blev också mer användbart i framtiden än bara en användarmanual.

## Vad du kan göra för att förbättra dina samarbeten

Som vi ser i dessa tre exempel är nyckeln för samarbete att kommunicera regelbundet med alla andra som jobbar med kodbasen. Och när du gör det, deklarera dina avsikter så tydligt som möjligt. Chansen är stor att du hittar synergier.

Sättet du kommunicerar på kan göras på många sätt. Det viktigaste är att du gör det tidigt och når rätt mottagare. Om du gör det på ett möte eller i ett forum spelar ingen roll, men att du [utstrålar din intention](https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-intent-d36fd22393a3) spelar roll.

Vad som är viktigt när det gäller verktyg och processer är att de har utrymme för att visa sina avsikter, oavsett sättet du samarbetar på.

Om du inte gör detta, utan bara rapporterar utfört arbete eller skickar in färdigutvecklade pull requests, är risken för förlorade synergier stor. Eller ännu värre att samma arbetet utförs av någon annan samtidigt i onödan.

Att vara öppen på det här sättet är egentligen inte svårt och tar inte mycket energi. Men det kan kännas ovant, eller obekvämt till och med, innan du kommer in i rytmen och upplever värdet själv. Detta kan ta en stund, men ge inte upp. Det kommer att hända förr eller senare när det är fler än en som utvecklar samma kodbas och det kommer att kännas fantastiskt.

# Collaboration in practice

**It's easy to talk about collaboration when developing software, but what does it mean in practice, and what can you do to enable it?**

Hi, I am Jan Ainali. As a codebase steward at the [Foundation for Public Code](https://publiccode.net), I help codebase communities come together and find synergies in their work to improve their codebase. You may have read [about us](https://os2.eu/blog/foundation-public-code-how-help-governments-develop-high-quality-sustainable-cost-effective-and) or the [Standard for Public Code](https://os2.eu/blog/ny-release-af-standard-public-code) (a resource we developed to make it easier for public organizations to make sure they enable collaboration) on this blog before. Based on a few recent experiences, I’d like to share an epiphany into what makes the best codebase communities so effective and exciting. Perhaps surprisingly, it’s not about doing things, but talking about what you want to have done.

## Why collaborate in the first place?

You could be bureaucratic and point to the [philosophy of OS2](https://os2.eu/side/om-os2) that is:

> to promote collaboration, sharing and digital development for end-users of public authorities

and say that this is why we should collaborate, but I want to dig one level deeper into the reason. This philosphy didn't spring from a vacuum, but is core to the open source movement because of the value it brings.

The benefits come not only from more people working on the same thing, which is also of course great, but from the added diversity of ideas, perspectives and knowledge that usually adds up to more than that the fact that the work can be shared and done in parallel. Let me demonstrate.

## Practical examples from the Signalen codebase

Recently in the [Signalen](https://signalen.org) codebase, the Amsterdam development team ran an accessibility audit and identified a few things to polish. The other developing party, the Association of Dutch Municipalities (VNG) had just completed some work in that area. With the topic fresh in their minds, they offered to help as it would be easy work for them to pick up.

Similarly, Signalen had a basic website setup. When talking about adding multilingual functionality to it, it became clear that one of the developers knew about another multilingual framework that made it possible to quickly adapt it for Signalen. As a bonus, the same framework was then reused by the OpenZaak codebase (which we also steward).

A municipality considering implementing Signalen wanted a manual for their civil servants. Amsterdam pointed out that they already had an internal document, which we reformatted and put online. At the same time, Almere documented learnings from its implementation process. So by all parties talking together, not only could material be reused, it could also be improved on more quickly than starting from scratch - and the resulting documentation will be more useful in the future than just a user manual.

## What you can do to improve your collaboration

As we can see from these examples, a key for collaboration is to communicate regularly with all other people working on the same codebase. And when doing that, declaring your intent as clearly as possible. Chances are high that you'll find synergies.

The way you actually communicate can be done in a number of ways. The most important thing is to do it early and reach the right audience. Whether you do this in a meeting or in a forum is not the important part, [radiating your intent](https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-intent-d36fd22393a3) is.

So for example, if you have several parties developing at the same time, having a short meeting once a week to discuss what has been done the last week and upcoming priorities is a great way of sharing knowledge between the teams. If your development is less intense, announcing your intentions on a mailing list or in a forum also works. Either way, creating issues in a repository makes it possible for anyone to follow the progress and what work is being planned and ask specific questions about it. But again, this is not about having meetings, forums or mailing lists, but that you talk about your planned future in them.

If you're not doing any of this, but only submit already developed pull requests, the risk of lost synergy effects is big. Or worse, the same work may be done by another party simultanously in vain.

Being open in this way is really not that hard, and does not take a lot of effort. But it may feel unusual, or uncomfortable even, before you get into the rhythm and experience the value first hand. This might take a while, but don't give up. It is bound to happen sooner or later when more than one party develops the codebase, and it will make you all feel great.