Två veckor till två dagar

För sex månader sedan drog vårt mest använda paket, facebook_app_events, runt 20 000 nedladdningar i veckan. Den här månaden toppade det över 50 000 nedladdningar per vecka.

Vi körde ingen kampanj. Vi släppte ingen flaggskeppsfunktion. Vi ändrade hur snabbt vi svarar, och adoptionen följde.

Det började som ett bibliotek vi behövde själva

I oktober 2019 behövde en kund spårning av Meta app events i en Flutter-app. Inget på pub.dev gjorde jobbet ordentligt, så vi skrev vår egen wrapper runt Metas native-SDK:er och publicerade den samma månad. Version 0.0.1 var intern infrastruktur som råkade vara offentlig.

Andra team hittade det. Sedan fler. Det blev det mest använda Meta App Events-pluginet i Dart-ekosystemet: i dag över 180 000 nedladdningar per månad och använt i mer än 400 projekt med öppen källkod på Github.

I sex år underhöll vi det för hand. Varje Meta SDK-release, varje brytande Flutter-ändring, varje issue, läst och reproducerad av en utvecklare i vårt team.

Tacksamheten från communityn var en ära, och den är det fortfarande. Ett meddelande från en utvecklare i en annan tidszon vars analytics äntligen fungerar är ett bättre bevis på kompetens än något vi kunde sätta i en pitchdeck. Många gav tillbaka: bidragsgivare skickade fixar, reproduktioner och plattformsspecifik kunskap som vi inte hade. Pluginet är bättre än vad vi hade byggt på egen hand.

Det var också en verklig arbetsbelastning, och varje timme av den konkurrerade med ett kundprojekt.

Flaskhalsen var aldrig att skriva kod

facebook_app_events sitter mellan en utvecklares Dart-kod och två native-SDK:er som Meta ändrar enligt sitt eget schema.

När någon lägger upp en issue är rapporten oftast en av tre saker: en riktig bugg i vårt plugin, en förändring på Metas sida, eller ett missförstånd om vad SDK:n gör.

Att skilja dem åt tog förr dagar. En utvecklare måste reproducera rapporten, öppna Metas aktuella dokumentation, kontrollera beteendet i native-SDK:n och sedan lista ut vilket lager som var felet. Att lösa en issue kunde dra ut över ett par veckor. Inte för att fixen var svår. För att diagnosen var långsam.

Det är ett strukturellt fel, inte ett personligt. Tidelifts underhållarundersökning 2023 visade att 58 % av underhållarna inom öppen källkod hade slutat eller övervägt att sluta med ett projekt, med utbrändhet som tredje mest angivna skäl på 44 %. Triage är där timmarna går.

Vad vi automatiserade

Issue-triage som validerar påståendet. Varje ny issue tolkas när den kommer in. Vår triage-automation drar in relevant avsnitt av Metas officiella SDK-dokumentation och pluginets nuvarande beteende i tråden. Innan en utvecklare läser rapporten ser de påståendet, det dokumenterade beteendet och var de två inte stämmer överens.

Notisdirigering. Issues når den utvecklare som äger det berörda området, i den kanal de redan arbetar i. Ingen instrumentpanel som någon måste komma ihåg att titta på.

Automatiserad kodgranskning på varje pull request. Varje PR får en maskinell genomgång före en mänsklig: kontraktsändringar över gränsen mellan Dart och native, saknad null-hantering, parametervalidering, beteendeavvikelser mellan iOS och Android.

En fullständig genomsökning av kodbasen vid varje Meta SDK-uppgradering. När Meta släpper en ny SDK-version skannar vi hela pluginet mot den nya ytan och flaggar vad som går sönder. En Graph API-version slutar fungera två år efter att dess efterträdare släppts, och Meta förbehåller sig rätten att ändra vilket API som helst med kort varsel av säkerhets- eller integritetsskäl. Två år låter generöst till du är lagret däremellan. Vår changelog visar hur vanligt det här är: en höjning av minsta Flutter SDK här, en depreciderad setter där, fastnaglade major-versioner av Metas SDK så att en brytande release inte kan accepteras tyst. Var och en är en potentiellt trasig build i någon annans app.

En veckovis genomgång av säkerhet och kodsvagheter. Den körs enligt schema, inte enligt god vilja.

Allt körs som GitHub Actions-workflows i samma repository som koden. Det finns ingen separat plattform att underhålla.

Svarstid är ett verktygsproblem, inte ett talangproblem

Google studerade kodgranskning i hela sin ingenjörsorganisation. Medianlatens för en fullständig granskning, över alla ändringsstorlekar: under fyra timmar, med 70 % av ändringarna committade mindre än 24 timmar efter att de skickats ut för initial granskning. Det är inte en skillnad i utvecklarkvalitet. Det är verktyg och process.

Communityn inom öppen källkod mäter samma sak. CHAOSS behandlar Time to First Response som ett centralt mått på projekthälsa, eftersom "det första svaret är ofta avgörande eftersom det signalerar till bidragsgivare att communityn är aktiv och engagerad".

Och branschens baslinje är långsammare än de flesta team medger. I DORA:s forskning 2025 deployar mer än hälften av respondenterna mindre än en gång i veckan, och när en deploy misslyckas behöver 15 % av teamen mer än en vecka för att återhämta sig.

Vår lösningstid ligger nu inom två dagar. Nedladdningarna följde, för ett plugin som svarar är ett plugin du kan bygga på.

Automationen fattar inte beslutet

DORA:s slutsats för 2025 är värd att upprepa: AI är en förstärkare. Den förstärker styrkorna hos högpresterande organisationer och dysfunktionerna hos kämpande. Rikta den mot en stökig process och du hamnar i en röra snabbare.

Så vi drog en gräns. Automationen samlar kontext, korsrefererar dokumentation och flaggar risk. En senior utvecklare beslutar. Inget mergas för att en maskin godkände det. Vad som ändrats är var våra utvecklare börjar: de öppnar en issue som redan håller dokumentationen, reproduktionen och diffen, istället för att lägga en dag på att sätta ihop dem.

Det andra som ändrats är avvägningen. Automationen tog bort större delen av konflikten mellan pluginet och vårt kundarbete. Vi tjänar communityn bättre nu, och kundprojekten betalar inte för det.

Vi kör våra kunders kod på samma sätt

Vårt arbete med öppen källkod är inte ett sidoprojekt med lösare krav. Det är samma pipeline, samma granskningsgrindar, samma veckovisa skanningar som vi sätter upp för kundkodbaser. Det är publikt, så du kan kontrollera det.

Nästan sju år in är pluginet moget, och vi är fortfarande engagerade i det. Tack till alla som lagt upp en issue, skickat en patch eller berättat att det fungerade.

Pluginet finns på pub.dev och källkoden på GitHub.

Om ditt team tappar dagar på triage istället för att leverera är det ett lösbart problem. Berätta var det gör ont: hello@oddbit.id.

Källor

• Sadowski, Söderberg, Church, Sipko, Bacchelli, Modern Code Review: A Case Study at Google, ICSE-SEIP 2018. PDF, ACM
• CHAOSS, Metric: Time to First Response
• Tidelift, Maintainer burnout is real, 2023 state of the open source maintainer report
• Meta, Graph API versioning
• DORA, 2025 State of AI-assisted Software Development