Issues dicht of pull requests dicht?

AI maakt het schrijven van code sneller. Daarmee zou bijdragen aan open source eenvoudiger moeten worden. Toch besluiten twee bekende PHP-projecten vrijwel tegelijk om juist een van de gebruikelijke ingangen voor bijdragen te sluiten.

Taylor Otwell schakelde GitHub Issues uit voor veel Laravel-packages. Wie een bug vindt, kan die volgens hem aan een coding agent uitleggen en een pull request openen. De eerste code hoeft nog niet perfect te zijn: een pull request documenteert het probleem en biedt iets concreets om op voort te bouwen. De keuze leidde onder meer tot een stevige discussie binnen de Laravel-gemeenschap.

Fabien Potencier kiest voor Symfony Language Tools precies de omgekeerde route. Daar staan issues open, maar pull requests niet. De gebruiker levert de waarneming en de context; de maintainer zet die daarna met hulp van agents om in code, tests en documentatie.

Het zijn twee tegenovergestelde experimenten met dezelfde aanleiding: code is goedkoper geworden, maar aandacht niet.

Laravel: kom met een uitvoerbare hypothese

De keuze van Laravel verplaatst meer werk naar de melder. Een bugrapport wordt niet alleen een beschrijving, maar meteen een poging tot oplossing. Dat heeft duidelijke voordelen. Een pull request kan een falende test, een concrete wijziging en informatie over het geraakte deel van de code bevatten. De maintainer hoeft minder vaak vanuit een korte melding zelf te reconstrueren wat er precies misgaat.

Die extra drempel kan ook ruis tegenhouden. Wie een agent een repository laat onderzoeken en een voorstel laat maken, moet het probleem in ieder geval concreter formuleren dan bij een losse melding als „dit werkt niet”. Zelfs een onvolmaakte patch kan nuttiger zijn dan een issue zonder reproduceerbaar voorbeeld.

Maar de drempel selecteert niet alleen op kwaliteit. Zij selecteert ook op toegang tot goede tooling, kennis van Git en tijd om een ontwikkelomgeving op te zetten. Een gebruiker kan een waardevolle bug ontdekken zonder de juiste persoon te zijn om een oplossing te ontwerpen. Dat geldt bijvoorbeeld voor beheerders, beginnende ontwikkelaars en mensen die het probleem alleen in een specifieke productieomgeving kunnen waarnemen.

Een pull request stuurt het gesprek bovendien vroeg naar één implementatie. De vraag of het gedrag echt een bug is, of de oplossing binnen de architectuur past en welke neveneffecten zij heeft, bestaat dan nog steeds. AI kan het voorwerk versnellen, maar maakt de beoordeling niet goedkoper. Een stroom van overtuigend ogende patches kan de reviewlast zelfs vergroten.

Symfony: lever eerst de context

Potencier redeneert vanuit een ander schaars goed. Een coding agent kan vaak snel een implementatie maken, maar kent niet de exacte applicatie waarin iets misging. De gebruiker weet welke editor, configuratie, packageversies en handelingen aan het probleem voorafgingen. Volgens dit model is juist die lokale context de waardevolste bijdrage.

Een issue wordt vervolgens een brief voor de maintainer en diens agent. Dat houdt de keuze over scope en architectuur bij de mensen die ook de geschiedenis, eerdere experimenten en verborgen beperkingen van het project kennen. Het voorkomt dat review vooral bestaat uit het terugvormen van een externe patch naar een ontwerp dat beter bij het project past.

Ook hier verdwijnt de onderhoudslast niet. De maintainer neemt de implementatie op zich en kan daardoor een bottleneck worden. Externe ontwikkelaars die wél een goede oplossing kunnen bouwen, mogen die in dit experiment niet rechtstreeks aanbieden. Daarmee gaat mogelijk technische creativiteit verloren en wordt erkenning voor bijdragen minder vanzelfsprekend.

En een issue is niet automatisch goede context. Agents kunnen net zo gemakkelijk keurige maar speculatieve bugrapporten produceren. Symfony vraagt daarom expliciet om alleen te publiceren wat iemand zelf heeft waargenomen en om de AI-uitvoer eerst te beoordelen.

De echte keuze gaat over eigenaarschap

De tegenstelling is dus niet „voor of tegen AI”. Beide modellen omarmen coding agents en beide houden menselijke review aan het einde. Ze verschillen vooral in de vraag wie de eerste vertaling maakt van probleem naar oplossing.

Laravel zegt in feite: breng een uitvoerbare hypothese mee, dan kunnen we die samen verbeteren. Symfony zegt: breng betrouwbare context mee, dan zorgen wij voor een oplossing die bij het project past.

Daarachter zit ook een verschil in eigenaarschap. Bij een pull-request-first model krijgt de buitenwereld meer ruimte om de technische richting voor te stellen, maar ook meer verantwoordelijkheid voor het voorwerk. Bij een issue-first model blijft de technische regie sterker bij de maintainer, terwijl de gemeenschap vooral als bron van praktijkkennis fungeert.

Geen van beide hoeft de universele toekomst van open source te zijn. Beide experimenten zijn bovendien bewust begrensd: de issues van de hoofdrepository van Laravel blijven open en Symfony probeert dit alleen bij het jonge, nog experimentele Language Tools-project.

Misschien is de grens niet binair

Voor veel projecten lijkt een combinatie mij sterker. Houd een issue als vindbare, gezamenlijke probleembeschrijving. Vraag bij een afgebakende bug waar mogelijk om een minimale reproductie of falende test, eventueel gemaakt met een agent. Laat een pull request volgen wanneer probleem, scope en gewenste richting voldoende duidelijk zijn.

Daarbij kan de bijdrage-eis verschillen per soort verandering. Een kleine regressie leent zich voor een directe patch. Een architectuurwijziging, privacyvraag of nieuw gedrag verdient eerst een gesprek. De vorm volgt dan het risico en de onzekerheid, niet één vaste overtuiging over hoe open source voortaan hoort te werken.

AI neemt het werk namelijk niet weg. Het verplaatst werk tussen melder, bijdrager en maintainer. De beste bijdrageflow is daarom niet degene die de meeste code genereert, maar degene die schaarse menselijke aandacht inzet waar die het meeste verschil maakt.