Browser Ladybird accepteert richting alfarelease geen pullrequests meer door AI

De ontwikkelaars van de alternatieve browser Ladybird accepteren geen pullrequests meer. De makers zeggen dat het project bijna richting een alfarelease komt en dat het daarmee serieus is. De makers willen de groep maintainers in de toekomst klein houden. Bovendien ziet Ladybird het aantal AI-verzoeken toenemen.

De makers schrijven over het nieuwe beleid in een blogpost. "Dit is een beslissing die we niet lichtzinnig nemen", aldus de makers. "Nu we richting onze eerste alfarelease gaan, heeft het project een strakker ontwikkelproces, een beter securitymodel en een kleinere groep mensen nodig om de code te schrijven die in de browser zit", schrijft Andreas Kling, de hoofdontwikkelaar.

Wat is Ladybird?

Ladybird is een opensourceproject dat probeert een nieuwe browser te maken. Het project onderscheidt zich doordat het niet alleen een browser maakt, maar ook de engine daarachter. De meeste alternatieve browsers gebruiken Googles Chromium-engine en een handjevol gebruikt Mozilla's Gecko, maar Ladybird wil zelf zo'n engine bouwen.

Tweakers sprak eerder met de oprichter van de browser, en schreef vorig jaar een achtergrondartikel over hoe de browser richting een alfarelease gaat.

In de praktijk betekent dat dat Ladybird geen publieke pullrequests meer accepteert. Dat deed het project tot nu toe wel; iedereen kon via GitHub een aanpassing voorstellen waar de ontwikkelaars dan naar keken. Kling zegt in zijn blogpost dat 'veel waardevolle contributies zijn voortgekomen van buiten de normale maintainersgroep', maar dat het niet meer verstandig is daarmee door te gaan.

AI-geschreven code

Volgens Kling komen er ten eerste veel pullrequests binnen waarvan de code in ieder geval deels met AI is geschreven. Dat vindt hij in principe niet erg, maar 'een pullrequest zegt inmiddels veel minder over de persoon die het instuurt'. "Een substantiële patch stond vroeger voor substantiële moeite die iemand had gedaan en die moeite was een redelijke benadering dat iemand eerlijk zijn werk deed", zegt hij. Dat is door AI niet meer het geval.

Uitgerekend bij een browser is dat geen goede werkwijze, denkt Kling. Een browser moet veiliger behandeld en geschreven worden. "Of code met de hand wordt geschreven, is niet het punt. Wat belangrijk is, is wie er verantwoordelijk is voor de code zodra die in de browser komt."

Ladybird stopt met het accepteren van nieuwe pullrequests en sluit daarnaast alle openstaande requests. Alleen projectmaintainers mogen nog requests doen. Kling zegt ook dat er geen omwegen komen voor pullrequests. "We willen geen schaduwsysteem via issues, comments, e-mails of forks." Forks van Ladybird zijn onder de licentie toegestaan, maar dat moet volgens Kling niets veranderen voor Ladybird zelf.

Reacties (30)

[jasper580]

Fascinerend, gegeven eerdere keuzes om complete subsystemen te herschrijven met AI...

[Ladybird]

Dit kun je lezen in onze blogpost:

AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. [..] We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it. What has changed is how much faster and cheaper it has become to produce work that looks like a serious contribution.

Het gaat dus niet om AI in het algemeen, of zelfs voor code generatie. Het gaat ons om de intenties van de mensen achter de tools.

[poktor]

Goh.. Een compleet nieuwe browser, inclusief een nieuwe engine. Dan moet je als bedrijf het volste vertrouwen hebben in je ontwikkelaars, maar blijkbaar kunnen ze dit. En nu hopen dat de browser aan de HTML-standaarden voldoet, de lat ligt best hoog voor deze nieuwkomer.

[Overheid]

Voldoen aan de HTML standaard is het probleem niet. Het is vooral de meuk die niet standaard is. Chrome is echt de nieuwe IE wat dat betreft.

[MaltheseFalcon]

Je kunt ook een bestaand project forken en die "meuk" er uit slopen.

[Cambionn]

Ja maar dat is juist 1 van de problemen waar Ladybird tegenin gaat. Er is momenteel een duopoly op de browserenginemarkt, waarbij de grootste speler Google is die eenzijdig de open standaarden van het internet aanpast door aanpassingen in hun engine te doen waar door hun groote marktaandeel op gebouwd wordt met als gevolg dat als je Google niet volgt, jouw browser als incompatible en niet werkend wordt gezien door de massa. Mozilla doet de laatste tijd ook wat vage dingen. Daar gaan je 2 engines.

Tuurlijk, je kán het eruit slopen. Maar hoe meer je afwijkt, hoe meer werk het onderhouden van je fork wordt. Want elke aanpassing geeft extra werk wanneer je de laatste patches van upstream wil toepassen (en dat wil je, bijv. voor security patches en ondersteuning van nieuwe in-spec functies. Of je moet alsnog alles zelf schrijven wat je juist ging voorkomen door te forken). En menig fork kan dat niet of heeft daar geen zin in, en minimaliseerd dus de afwijkingen.

Meer engines verkleint de mogelijkheid om op zo'n manier een machtspositie te misbruiken (mits ze allemaal gebruikt worden) en forceerd iedereen om zich aan de standaard te houden. Die mits is dus ook waarom ik hoop dat Ladybird een redelijke userbase weet te krijgen, en dan vooral van nu Chrome-based users (want Gecko-based, aka gebaseerd op FireFox's engine, is al een minderheid). Of dat lukt zullen we nog moeten zien.

Ik ben iig heel blij met zowel Ladybird als Servo (een andere nieuwe browserengine in ontwikkeling). Ladybird lijkt ook snel richting productie-ready te gaan nu. Zeer fijn!

[Reactie gewijzigd door Cambionn op 5 juni 2026 20:05]

[Jerie]

Er zijn er drie. Safari/WebKit is op mobile behoorlijk dominant, dankzij i(Pad)OS. Safari/WebKit heeft nauwelijks aandeel op desktop, en Firefox/Gecko nauwelijks op mobile.

[Cambionn]

Fair. Hoewel dat eigenlijk meerdere duopolicies creëert gezien de mobiele websites toch al anders geoptimaliseerd worden dan desktop sites, en je de effecten eens erger hebt door het verschil in verhouding tussen de grote en kleine speler. "Voordeel" is natuurlijk wel dan dat dat voor slechts een deel van de code geld, waardoor de rest iig geforceerd is om voor alle 3 compatible te zijn. Waarbij je op mobiel nog wel weer het extra probleem hebt van een monopoly per platform, daar men niet een ander OS kiest gebaseerd op browserengine (zeker niet gezien Jan Modaal niet eens nadenkt over browserengines). Uiteindelijk zou je ook complete papers en boeken over dit probleem kunnen schrijven, en is een tweakerscomment enigsinds versimpelt. De core is iig duidelijk hoop ik.

Maar je hebt wel gelijk, er zijn technisch gezien 3 grote en webkit is zeker wel noemenswaardig wat betreft het probleem van eenzijdig open standaarden kunnen aanpassen door monopolitische macht. Dat was idd mooier om wel te noemen en heb domweg ff niet aan gedacht.

[Reactie gewijzigd door Cambionn op 5 juni 2026 23:52]

[jabwd]

Maakt geen bal uit, beide Gecko en WebKit hebben Chrome compatability layers omdat developers huilen dat andere browsers niet juist werken met de code die ze alleen in Chrome getest hebben.

[Overheid]

Zeker kan dat, maar dan stoppen veel websites met werken omdat men niet bouwt op webstandaarden of test op andere browsers dan alles wat op Chrome lijkt. Zie bijvoorbeeld Pale Moon die dankzij dit soort ongein constant achter de praktijk aan moet lopen. Firefox is daar enkel iets sneller mee maar hebben hier ook last van.

[Oon]

In het geval van Chrome kun je gewoon Chromium als basis pakken, dan hoef je er weinig uit te slopen. Ook prima browser om zelf te draaien ipv Chrome

[kozue]

Chromium is de basis van Chrome en zitten alle rendering quirks ook in. De andere browsers die de Google engine gebruiken (zoals Edge), gebruiken ook Chromium als basis en niet Chrome zelf. Chrome zelf is niet te doen, daar moet je teveel Google troep uithalen om het bruikbaar te maken.

[84hannes]

Voldoen aan de HTML standaard is het probleem niet.

Ik denk dat je het formaat van de W3C specificaties ernstig onderschat

The total word count of the W3C specification catalogue is 114 million words at the time of writing. If you added the combined word counts of the C11, C++17, UEFI, USB 3.2, and POSIX specifications, all 8,754 published RFCs, and the combined word counts of everything on Wikipedia’s list of longest novels, you would be 12 million words short of the W3C specifications.

En dat was in 2020!

[Yucon]

En om het in perspectief te plaatsen: de bijbel is een kleine miljoen woorden.

[84hannes]

En om het in perspectief te plaatsen: de bijbel is een kleine miljoen woorden.

Ik denk dat de auteur die ik citeer een document dat zoveel invloed heeft op miljarden mensen, dat toch zoveel tegenstrijdigheden met zichzelf en de werkelijkheid lijkt te hebben en dat door verschillende interpretaties tot zoveel controversie heeft geleidt, niet wilde vergelijken met de bijbel 😉

[Reactie gewijzigd door 84hannes op 7 juni 2026 20:31]

[bzuidgeest]

Dat is niet alles natuurlijk de standaard voor html heeft net als veel standaarden op sommige plekken ruimte voor interpretatie en soms maken mensen dat verschillende keuzes die allemaal binnen de standaard kunnen, maar niet compatible zijn.

[Guru Evi]

Deze browser volgt wel degelijk de standaard, goede HTML5 is relatief gemakkelijk, het grootste aantal bugs zit waar HTML niet volledig is (dus je hoeft tags niet te sluiten, maar er is wel een standaard waar de tag als gesloten beschouwd moet worden) alsook oudere XHTML, HTML4 etc bestaat ook nog. Er zijn genoeg plekken waar de standaard vaag is en natuurlijk HTML5 tags, JS en CSS en andere dingen die de DOM aanpassen, zodat het document-formaat op dit moment 3 volledige programmeertalen is. Daarnaast wordt er dagelijks veel nieuwe zaken toegevoegd die moeten geimplementeerd worden en natuurlijk moet je dit ook allemaal snel genoeg doen, je code moet relatief optimaal blijven, gebruikers zien het verschil snel tussen browsers.

[Reactie gewijzigd door Guru Evi op 5 juni 2026 18:47]

[kuurtjes]

Niet vergeten dat Google ook al die meuk in de officiele spec probeert te krijgen.

[Firestorm666]

IE6 had ook ooit bijna de browsermarkt in handen, tot Google's Chrome de frustraties van IE6 wegnam en hoppa, iedereen was over.

Zodra het uitkomt wil ik het zeker een kans geven, al is het maar om fuck you tegen Google te zeggen . Al moet ik zeggen dat ik wel content ben met Firefox op Linux.. Maar om 1 of andere reden niet op Windows, daar is het een stuk logger.

[CH4OS]

IE6 had ook ooit bijna de browsermarkt in handen, tot Google's Chrome de frustraties van IE6 wegnam en hoppa, iedereen was over.

Chrome was gereleased in 2008. In 2009 kreeg Microsoft de boete voor machtsmisbruik van IE6 en werd het gedwongen om het browserkeuzescherm in Windows toe te voegen. Ik denk niet dat Chrome zo snel groeide in het begin.

[Reactie gewijzigd door CH4OS op 5 juni 2026 20:36]

[desalniettemin]

Ik stapte over naar Firefox 1. IE6 was waardeloos en het had ook geen tabs, had Fx wel.

[Firestorm666]

Ja, dat keuzescherm kan ik me nog herinneren ja en dat heeft nauwelijks een deuk geslagen. Ook perfect normaal, want mensen zijn als't over computers gaat nogal conservatief en het product moet wel al HEEL slecht zijn eer mensen over stappen.

IE6 was stokoud en mensen waren de kuren kotsbeu, zeker naar snelheid toe.

--

Edge based op Chrome bestaat nu al een heel tijdje, toch blijven de meesten massaal Google Chrome gebruiken. Waarom? Het werkt nog goed genoeg en er zijn geen grote voor/nadelen aan zoals dat bij IE6 en alternatieve browsers wel was.

[desalniettemin]

Ik stapte van IE6, de slechste browser ooit, over naar Firefox 1. Wat een verademing was dat. Veel sneller en het had tabs. Had IE6 niet. Volgens mij had het ook al Adblock Plus, maar dat weet ik niet zeker.

[bzuidgeest]

Als bedrijf? Het is een non profit die leeft van donaties.

[merethan]

Browser engines zijn vooral complex om alle in kladblok geschreven drama te kunnen renderen. Men gaf namelijk vroeger de browser de schuld, en niet de schrijver van de website, als de website niet goed renderde.

Netscape op een floppy is verrassend functioneel op het web van 2026, omdat heden dagen alle HTML door WordPress en weet ik wat gegenereerd wordt en daarmee meestal klopt.

Je hebt met Netscape op je floppy geen CSS en JavaScript, maar dat is bijna ook een feature inmiddels. Alle websites die scrollen heruitvinden in JavaScript wil je toch niet gebruiken.

[StefanJanssen]

Hun aanpak is ook best interessant, ze bouwen eerst de nieuwste standaarden waarop ze de oudere Web standaarden op laten leunen.

En de manier waarop ze prioriseren is ook interessant, ze bouwen niet een deel van de standaard om de standaard te maken maar ze kijken naar wat wordt er daadwerkelijk gebruikt. Dus populaire websites als YouTube eerst, en ook websites van grote sponsors worden werkend gemaakt.

Door de populaire websites goed te laten werken heb je misschien 10% van het web volledig werkend maar wel 95% van de dingen die mensen dagelijks gebruiken.

[rickboy333]

Wat is ubberhaupt het nut van vibe coding op een opensource project? De bragging rights? leuk op de CV? Leuker GitHub profiel? Als iemand in open source geloofd (want anders ga je niet contributen) waarom vindt je het dan prima dat elk open source project hetzelfde eruit gaat zien omdat AI een bepaalde handelswijze heeft die overal hetzelfde is?

[Firestorm666]

Je houdt van open source, maar kent eigenlijk bitter weinig van coden en denkt behulpzaam te zijn?
Je houdt van open source, maar overschat jezelf schromelijk als coder en denkt nu heel belangrijk werk te verrichten?
Je houdt van dit open source project, maar wilt je eigen stempel drukken voor feature xyz die jij persé wilt in het eindproduct, maar je bent zoals bovenstaande (arrogant en/of onwetend)
Je hebt een interesse in programeren, maar denkt dat je al een expert bent omdat ChatGPT geloofwaardige onzin uitkraamt?


Er zullen vast nog wel redenen zijn .

[Thijzer]

Dikke duim! E2E testing en validaties moet door mensen gebeuren, alleen maar omdat je als team de release moet dragen, en je moet alle hoekjes/kantjes kennen van de software. En dat is nu eenmaal een grijze zone geworden met tijdens ontwikkel fase met Ai.

[SampleUser]

Krijg er toch een meh gevoel van. Bij sommige issue meldingen (in het algemeen) wil ik nog best eens kommentaar als "hey, $programmeertaal/dit project/build toolchain ben ik niet bekend mee, maar is dit niet het eigenlijke probleem?" maar als inhoudelijke hulp op dat aspect niet welkom is, laat dan ook maar...

Niet dat ik geen issues meer wil/zal indienen, maar waarom zou ik dossierkennis opbouwen als ze toch geen inhoudelijke hulp accepteren? Of ben ik nu te knee-jerkerig?