It sounds like all public contribution will simply be impossible. That said, they will continue to develop out in the open on GitHub and you can clone the repo and build whenever you want. You can continue to contribute in other ways.
I hate this change and agree with your PR comment. This change makes me sad as well.
My hope is that public contributions can resume in the future. Part of their justification for this step is that they are trying to stabalize the project to produce a stable public alpha. Fair enough. And many Open Source projects have begun to voice concerns over the burden that the massive increase in contributions is causing, often from AI. Linus Torvalds has certainly been flagging this. The Open Source world in general is going to have to navigate this and come to a solution that works without the entire Open Source ecosystem becoming read only.
Once Ladybird ships a "stable" browser out to the world, I am hoping they can adopt whatever the "best practice" for Open Source has become to be able to accept public participation again.
That's not really right, though the license is still Open Source compliant. Linux was practising an open, patches-welcome developement style before the forges existed, on its mailing list. This did indeed contrast with how eg. the FSF was running its projects, though even in those the door wasn't shut as hard on people wanting to contribute as Ladybird's now is, I think. Then Eric Raymond wrote "The Cathedral and the Bazaar" specifically to talk up Linux's patches-welcome development model, and to move the emphasis away from (just) licensing terms and source accessibility, to openness to patches. Netscape then launched the Mozilla Project specifically on the CatB model. In response to the surge of momentum, the "Open Source" label was created basically as a brand name for the CatB perspective. After all this, "doing it as open source" was established as a clear mental category in people's heads, and the forges popped up as low-friction SaaS solutions for something that people already wanted to do, and by then were often already doing. (In the process helping to make Web-based SaaS a well-established concept and business model in people's heads, something with ironic consequences.) So Ladybird's current development model is much more clearly in line with the Free Software philosophy than the Open Source philosophy. To be clear, that's not the only disagreement or difference of emphasis between "Free Software" and "Open Source": most obvioulsy, Ladybird's BSD license is a failing in the FSF's view of things, just not enough of a failing make Ladybird not Free Software. But it is a real one.
"The Cathedral and Bazaar" is orthogonal to open source. Its argument is that open source is most valuable when paired with the bazaar model, not that the cathedral model cannot be considered open.
The open source definition was created in that mind. It does not state or imply open development or a community are requirements.
CatB and Open Source aren't coaxial, but there wasn't a very clean separation between them either: https://www.free-soft.org/literature/papers/esr/cathedral-ba...https://web.archive.org/web/20021001164015/http://www.openso... . "[T]he same pragmatic, business-case grounds that motivated Netscape" was CatB. Even now OSI doesn't emphasise any separation: https://opensource.org/about . You are correct: the Open Source Definition does not mandate an open development model. However that's probably at least in a small part because, well, how would one craft a legal requirement for open development in a software license that wasn't either unenforceable or very burdensome and abusable? It's also quite definitely because the expectation was that forks and/or the threat of forks would in practice enforce a certain level of open development on OSD-compatibly-licensed software: this was in fact what ended up happening to GCC at least once https://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_f... . If software projects all largely go the way Ladybird is going now, and stay that way, then it's a crushing (though not total) defeat for what the Open Source movement promoted and what it hoped to achieve; but sure, to be clear, Ladybird remains OSD-compliant. (Not total because at least the source remains available, without paying or signing anything, for bug-hunting.)
I think I didn't put the emphasis right in my comment above. The code is still fully open source, but the project that produces the code isn't. It's not dissimilar to other projects producing open source software.
This is the first time I've seen a project with this much history in community contributions close down, though. I suspect AI will cause more projects to follow in Ladybird's footsteps.
What's the plan for monetization? Your license is Apache 2.0, which I'm not sure makes sense from having customers pay.
In contrast, Lago uses AGPL-3.0 and has an open-core model (not sure if the premium features are source available or not), which makes it more clearer on how they're going to make money.
We have a cloud version that we charge a flat fee for, and I think there’s enough people that don’t want to deal with self hosting for it to make sense. When we started out we just used the same licence as some other dev tools (like supabase).
One more data point: at work we use Stripe for most regions [1], but in our largest region (South Africa) we have to use Paystack [2] (a Stripe subsidiary). The API isn't 1:1 compatible and there's no plans to do so in the near future. Having multiple providers is a must for us to consider a solution.
Lago is better in that they have have support for custom payment integrations [3].
Most banking sites log you out very aggressively, and a lot of them require some sort of 2FA during login. It's quite inconvenient to have to do this login dance every time you need to make a transaction -- with an app, you can use a PIN or biometrics to start using it.
Sometimes the discussions on PRs are equally valuable to see how a commit was arrived at, and I'd be sad if that got lost in this change.
reply