What's Right for Ladybird Is Transparency
If you're already familiar with the announcement and history of Ladybird, skip to the "Transparency" section. The following reflects my personal experience in the Ladybird/SerenityOS projects over many years, and my personal opinions only.
Introduction
On June 5th, 2026, the Ladybird Browser Initiative published a statement that, effective immediately, Ladybird will be developed entirely by employees of the LBI and project maintainers. By this, I mean that, on the day it was published, the ability to create pull requests was turned off, and all open community pull requests were closed with the following copy-pasted message:
Thank you for taking the time to work on this pull request.
As announced in "Changing How We Develop Ladybird", we are closing all currently open public pull requests as part of ending the public code contribution path for Ladybird.
This is not a judgment on the quality of your work; we are very grateful for the effort you put into this pull request. But as of right now, code changes to the Ladybird codebase will only be introduced by project maintainers.
We still welcome clear bug reports, reduced test cases, website testing, standards discussion, design discussion, security reports, and technical feedback.
The statement goes on to explain that this choice wasn't made lightly, and that it was made primarily because, thanks to AI, large pull requests were no longer a proxy for contributor good faith. More generally, they could introduce hidden and intentional security vulnerabilities. In the last paragraph, it asserts that "This is the right change for Ladybird now."
While I believe that the nuclear option was not the best choice to tackle this particular issue, the more pressing problem is the lack of transparency in the LBI.
Some backstory
The Ladybird project first began within SerenityOS, a much more informal and community-oriented operating system project. It started as its HTML parser, then an internal web browser, and with rapid development, an effort was made to get it working on Linux.
The project had no established governance other than the authority of Andreas Kling himself (former project lead of SerenityOS, now Ladybird chair), but this wasn't an issue, as a hobby project didn't need to make many official decisions, aside from occasionally dictating GUI direction and limiting project scope.
One example of the above is the refusal to add the start of an entire JVM implementation, or the much more explosive event where a small patch that added the use of a singular "they" pronoun in one place was rejected as "too political."
The SerenityOS community, alongside Andreas Kling, would add new features and software to the OS depending on each contributor's interests. Many of the most active contributors would eventually become maintainers. The openness of the project, and the non-controversial, focused atmosphere in the SerenityOS Discord, made it inviting to beginner developers, including myself.
As time went on, the Ladybird project took on a more central role in SerenityOS, accounting for most of its commits. On June 3rd, 2024, Kling, in his Substack post, made the decision to fork Ladybird off SerenityOS, formally step down from SerenityOS leadership, and allow both projects to be developed independently. The new project inherited the same community, atmosphere, development model, and even most of the maintainers.
Soon after, on July 1st, 2024, the Ladybird project incorporated as a California-based non-profit, opening the gates to new sponsors, tax-exempt donations, and a clear legal identity: the Ladybird Browser Initiative. Regardless, the community continued to make many additions to Ladybird that, in my opinion, helped push it further forward than expected, such as Windows support, which was originally a non-goal until much later.
June 5th
Unbeknownst to the community, a few days after the second anniversary of the independent Ladybird project, the LBI was preparing to make this change. Nobody from the community was consulted. The project continued to welcome people with the promise that they could get their hands dirty developing an increasingly useful web browser. It was not announced in the monthly newsletter or video update, aside from the notable omission of a section thanking that month's contributors, usually placed at the end of the newsletter and video. "That’s it for May. Thanks for reading, and we’ll see you next month."
I hope that from the previous section, it's clear why the community was so distraught by this change, while it was merely surprising or even positive to others. The community had spent years, every day since 2018, with the expectation that SerenityOS and Ladybird were community-driven, truly open-source projects. They devoted significant effort to build first a hobby operating system, and then a real web browser. Overnight, or rather, within a few hours, that dream was gone. Ladybird is now developed like NVIDIA drivers for Linux: you get the code, we get the bug reports.
I personally didn't write as much code as I wish I could have for Ladybird, but I am responsible for the creation of the "Getting started contributing" guide, meant to help onboard new contributors. I believed in that dream, and on that day I felt that the trust between the leadership and the community had been violated.
Transparency
The Ladybird Browser Initiative is a corporation, with a three-person Board of Directors holding meetings relevant to the operation of the non-profit. It publishes some summaries of board meetings, such as appointments and resignations of members, but I believe that is the minimum required by law—and that is all.
I hope to see at least financial reports published, perhaps on the second anniversary.
Regular meetings between all employees, management, and maintainers are certainly held. Andreas Kling has occasionally shown parts of his calendar, but unlike most open-source non-profits, the community has no insight into these meetings and no way to voice concerns. The maintainer appointment process is entirely opaque, and major decisions are made with no warning and no final "thank you" from the founder.
Presumably, the LBI will want to stay with this development model. It is much simpler than having hundreds of PRs to review, accept, and hope they don't blow up the browser. Moving development in-house shifts liability toward a more concrete group of people—whether the developers or the LBI itself. Everything Kling mentioned in the announcement is true: it makes the source of vulnerable code easier to determine.
...but if the Ladybird browser wants to become truly open source once again, transparency must become much more important to avoid violating community trust again.
Therefore, I suggest the following:
- Allow community contributions. As a proposed solution to the vulnerability problem, implement systems that ensure newcomers start with smaller changes, while more established developers can make larger ones.
- Formalize the maintainer appointment process, make it public, and clarify if and when that position is available to those outside the LBI.
- Make more executive meetings public and open decisions to community scrutiny.
- Publish quarterly financial reports so sponsors, the community, and users have a clearer view of the organization's health.