Andreas Kling splits Ladybird web browser from SerenityOS, steps down as SerenityOS BDFL

Ladybird already uses some external libraries, such as Qt.

Many commentators have said that the operating system is just this vestigial thing to prop up the browser, a solved problem, over which it is not worth experimenting or trying to make better. This is hardly something you would expect the creator of an operating system to believe, but here we are.

Now I’m off to browse Gemini capsules with 9Front…

He is working from Linux. He has not booted Serenity in a while, his only contact with Serenity is in the form of “sigh, this thing doesn’t build on Serenity on the Github continuous integration and I’m not motivated to fix it myself”. Also, he got donations to work specifically on the browser and not the OS.

It seems clear at this point that 1) he found a market and people willing to donate money for the browser, not really for the OS and 2) he lost interest in the OS, which was a nice toy project for a while, but not much more than that.

Why would you demand that he keeps maintaining the Serenity port? I think this would only lead to burn out. If you’re not interested in a project, you’re not interested. Unless someone is going to pay you to continue doing it anyway, there’s no reason to continue.

I’m sure things will settle and maybe someone from the Serenity team will step up to maintain the Ladybird port. Or maybe they will decide they don’t need a web browser, or pick another one.

Also, if I understand correctly, Ladybird is a Qt based browser and never ran on top of Serenity. All they share is a HTML/CSS/JavaScript engine (LibWeb), that is used by both Ladybird and Serenity browser. Why would you maintain a Qt based browser that doesn’t run on Serenity inside the Serenity github repository? It would be like having Qt applications inside the Haiku sourcecode repository.

It seems clearly a point where the projects have diverged so far that they share nothing but a git repository. You say it’s just a build infrastructure problem, but I see quite the opposite: two largely independant projects that end up stuck together by sharing only the build infrastructure. They have separate websites, separate READMEs in the Git repository, and, at this point, separate developers. It’s time to admit they are separate projects and cut the last link, don’t you think?


I get the feeling more and more that I’m misunderstanding something…
I’ve read a few times now that SerenityOS and Ladybird are totally different projects that need to be separated,but from my understanding they mostly share the exactly same codebase.
Developing a browser UI on top of a rendering engine isn’t a big deal,as the dozens of QtWebKit and GTKWebKit ports in the HaikuDepot show.
The difficult task is creating and maintaining a web engine,such as LibWeb,that is capable of rendering modern websites without huge issues.
And that effort with LibWeb was shared between SerenityOS and Ladybird,which was a good thing as it is a lot of work.
Now how is that supposed to continue?
Will LibWeb become a part of Ladybird and SerenityOS won’t have a browser at all?
That’s what I thought when first reading this topic,but I can’t imagine why the SerenityOS devs would want that.
Or will they both have their own variant of LibWeb,forked at one date and then developed independently from each other?
That would duplicate the needed effort,also a bad idea in my view?
Or will they continue to use one LibWeb that they share,and only the Ladybird UI/frontend code it moved into a separate project?
That’s what it looks like when reading the last reply here,but as a browser UI isn’t that much of a big deal,I also don’t get where the benefit would be.
Does anyone actually know what’s going on and can tell me?

1 Like

Based on what some SerenityOS maintainers have been saying so far in the SerenityOS Discord community, it sounds like changes from Ladybird will be backported to SerenityOS where possible.

1 Like

Thanks,that’s good news.
If Ladybird changes in a way that makes cross-platform support more complicated (by requiring more third-party stuff or something like that),we can base our port on SerenityOS code and will still get a good browser.

Some more discussion has occurred and it seems like it’ll go both ways. That is, changes in either will be cherry-picked to the other where appropriate. However, it’s prolly better to focus more on the Ladybird codebase. It’s considerably more preferable to not have an entire OS codebase being pulled into HaikuPorts just for a web browser.

Well,that depends on where development goes.
I’d prefer to avoid Linux-style dependency hell where I can,and currently the SerenityOS code is very portable and independent.
Maybe Ladybird will keep that route,we’ll see.

No, Ladybird has multiple UIs.
I think they are cross-platform Qt, macOS AppKit, and Android UI.

The Serenity OS browser code is entirely specific to Serenity OS. Ladybird instead uses Qt which makes it possible to run it on Haiku (as well as a few other frontends, yes, forgot about these in my previous comments). The libweb part is made to be more portable, but it’s reasonable to think that this is not going away especially in Ladybird, which has plans to support multiple OS (on the Serenity side they may chose to take some shortcuts and simplify it by making it OS specific). From what I understand, other purts (GUI and network backend) of Ladybird are already based on 3rd party libraries.

If anything, reusing existing 3rd party libraries (letws say: curl, openssl, …) is making our job easier for an Haiku port if we already have those. With no details so far about which libraries Andreas plans to use, it’s hard to say anything. Will it be curl, openssl and the like? Will it be a switch to webkit? (Unlikely I think, but the statements I’ve seen so far don’t rule it out). Will it be relying more on Qt? Will it be some weird library that no one knows about and that is extremely tied to Linux? We have to wait a bit and see what happens, but if the project remains as it was before (Qt gui and libweb backend), With the occasional extra dependency (maybe libpcre for regex, boehm for garbage collection, that kind of thing (these are completely random guesses, but it’s the type of thing I could reasonably imagine)), I don’t think we should have much problems for an Haiku port.


Git is git. If you have a public repo he should be able to get the changes. If it is because there is no PR on github, maybe someone can fork it and submit a PR on your behalf?

I have forked so many projects and re-hosted them on Github, locally via something like Gittea or at work where we have a self hosted Gitlab instance. The actual underlying repo will absolutely be in a format he can access - the “getting it to him” part is just about making a PR that he can easily get access to.

1 Like