Block slipper Berd som Apache 2.0, men avviser pull requests utenfra

Block har lagt ut Berd på GitHub under Apache 2.0, beskrevet i repoet som «en skrivebordsapp for å få gjort arbeid med hvilken som helst modell». Appen er bygget med Tauri 2 og React 19, og snakker med Goose-backenden gjennom en ACP-WebSocket som serveres av en goose serve-sidecar. Repoet har rukket sju utgivelser, sist v0.6.2 den 18. august.

Det som skiller Berd fra en vanlig chat-app, er hvordan backenden er festet. just setup installerer pnpm-avhengighetene, bygger den vendorede @aaif/goose-sdk og klargjør Goose-binæret som er pinnet i goose-backend.lock.json. just dev gjenbruker det stemplede binæret og nekter å starte hvis lockfil-commiten ikke lenger matcher det som ligger i plattformcachen. Vil du teste en annen Goose-bygg, må du sette GOOSE_BIN eksplisitt. Resultatet er en definert versjonsgrense mellom skrivebordsappen og agent-backenden i stedet for en backend som driver stille videre.

Block har også bygget inn det de kaller distribusjonssømmer: definerte punkter der en organisasjon kan legge på egne leverandørinnstillinger, private agenter, kjøretidskonfigurasjon, egne oppdateringskanaler og egen signering, uten at noe privat havner i det offentlige kildetreet. Den offentlige byggen er selvstendig og krever verken private pakkeregistre eller bedriftslegitimasjon, så du kan bygge og evaluere den uten tilgang til noe hos Block.

Governance-modellen er strammere enn lisensen antyder. Berd er laget av «et lite team i Block, i det åpne», og repoet tar ikke imot bidrag utenfra: pull requests fra andre enn autoriserte samarbeidspartnere lukkes automatisk. Veien inn er en velformet issue.

«En feilrapport vi kan reprodusere er verdt mer for oss enn en patch, fordi det er den delen vi ikke kan gjøre selv» — Berds README

For deg som bygger, betyr det at Berd er ferdigvare du kan lese, kjøre og forke, ikke et prosjekt du kan påvirke oppstrøms. Forker du, arver du også vedlikeholdet.

Hva bør du gjøre?

1. Kjør just setup og just dev for å få en lokal bygg med den pinnede Goose-backenden, og la lockfilen styre versjonen i stedet for å peke på et eget binær.
2. Skal du oppgradere backenden, bruk scripts/update-goose-backend-lock.sh og just goose-sync i en PR, slik at versjonsgrensen forblir sporbar.
3. Finner du en feil, bruk issue-skjemaene i stedet for å sende patch. Utenforstående PR-er blir lukket uansett hvor god koden er.