Should we really fork?

Kevin · 2026-08-20T13:42:59+00:00

I think it is beneficial to have some structured conversation around the topic of forking since there have been multiple people talking about this, and infact some already have (i.e. Tabby for PPC). Note: I don't want this thread to develop into a flamewar about AI or the current Haiku developers, that's not practical or beneficial. Over 25 years the Haiku devs have built something truly special, and I am very appreciative of that. If it's time to part ways then let's do it in a respectful manner. I want to talk through what it would take to make a serious fork of Haiku, not just a one person maintained repo on GitHub, but an actual fork maintained by a team of people with the goal of distributing a usable operating system. My big question is would there be enough commonality among the community to make it worthwhile to fork? Or is everyone's vision so separate that it would result in more endless debates? Saying "oh just fork it!" is probably a lot easier than it sounds, so what would it really take? Here are my thoughts, I am curious what everyone else thinks. Goals Build a fast, fun, and reliable operating system based on Haiku Have rich cross-platform support. We already have pretty good x86 and x86_64 support from Haiku, maybe bring in PPC from Tabby (if the developer wants to), I am working on a SPARC port, others have made good progress on RISC-V and ARM Accept LLM contributions, but have a reasonable policy (i.e. must adhere to coding guidelines, must only copy license compliant code if sourcing from other OSes, must update documentation on what change and why, must be tested physically if possible, etc) Have rich branding and a good name. We want to attract more users and developers. Have open and transparent communication about the development and goals of the OS - not just comments buried in commits or chat on an IRC channel. Continue to support "obsolete" hardware (i.e. x86 and PPC) as long as practical or as long as their is interest from users and developers Maintain a high level of code quality through code reviews and testing Questions Would we maintain BeOS application compatibility? (I strongly vote for no) Would we maintain Haiku application compatibility? Do we add multi-user support? Even if it breaks BeOS and Haiku compatibility? (I vote yes) Are we forking and running away? Or do we want to bring in upstream changes from Haiku? What is our release structure? I am a fan of moving to a set schedule of 2 or 4 releases per year and abandoning the "one day we might make it to R1" approach. I think more frequent releases builds momentum. Just call the version based on year and month i.e. 26.8 for an 2026 August release, 27.2 for a 2027 Feb release. What would we need GitHub / source control Website hosting Forum hosting Build servers Devops tooling - how can we get automated builds and ISOs? Non-profit organization (eventually?) for donations and to fund paid developers (or at least pay for server costs) and handle trademarks What does everyone else think? What are we missing? This post is meant to start a conversation, I am no way trying to dictate the future.

clasqm

kaban4ik Why should I ditch Windows or Linux and install HaikuOS?

You should not. It is not ready.

And that is exactly why we are discussing the possibility of a fork. We think we can move faster.

dataflowcodes

I think that AI helps with the abilities of people who, like me, have more system-analyst skills than programmers have and vibe code better. If clean code is possible within such a scenario as this, we should go for a fork. I may help with some stuff if the terms are OK but with a few limits:

Don't waste time maintaining yet another POSIX kernel as a hard requirement
package management needs not be the same because bytecodes are more maintainable for closed source projects than fixed ABIs and a future name mangling conflict resolution like GCC2 can happen again if we focus on C++ only as our compiling and linking convention (C naming conventions preferred)
having a desktop environment based on Haiku-style with stack-and-tile for any POSIX kernel would be enough to maintain without needing to maintain a full OS

My Motive

I intend to vibe-code a hardware processor design that is radically different from any other. It will support no interrupt capabilities other than event handling and NMI for fatal errors, for example. POSIX support beyond the WASIX runtime for WebAssembly will be hard-coded into the instruction cracker in hardware, for another. Packages will just be WebAssembly module derivatives with an astable ISA in the core CPU. WebAssembly-to-native as well as SPIR-V-to-native conversion will be supplied by the package manager/browser as an abstraction (maybe BeOS style translators) rather than having a direct OS at all. Safe coded system-level functions (lower-level than user bytecode allows) in Rust with the rest in WebAssembly bytecode.

Obviously keeping legacy code to a minimal level is preferred in radical designs like mine because rebuilding from a stable bytecode should be an option at all times. Plus, it eliminates the need of CPU and GPU dependencies in the design overall.

In Short

Go big or go home. Clean break from the past is best because we can focus on what is important.

Shaka444

Bob And please devs, don't rush to add features over quality, security and stability

I agree 100% but there should also be active beta testing of new features and tools. I'll gladly help there.

Shaka444

One thing to add- We should leverage the current core devs as much as possible.
We stay as compatible as we can and only break compatibility if necissary, so the core devs become part of our greater development team just like QT/KDE/GTK teams are.
Let them handle the GCC2 x86 side of things. We do x86_64 as primary focus. If anyone wants to do other platforms, great! but our group focus should be for the widest audience first.
This way our "team" becomes bigger than the current Haiku team- an Add-On to it and not battling against them with fewer soldiers.

rainygirl

Shaka444 current core devs

Who are the current core devs? 🤔 For now, it might be easier to create separate distributions for each and then combine them. Because building a collaborative team is always a very complex task.

Shaka444

rainygirl Who are the current core devs?

I was referrring to the Haiku devs :-)

Shaka444

Instead of IRC we could use HiShare. There are benefits for doing this-

It's native
We can share files as we work
You can setup an audio prompt in Sound preferences to play a sound when your name is mentioned, when someone uploads a file from you etc..
I also have a little script called Chat2Speech that will convert the chat to audio. It's like listening to a Developer radio show! :-) I keep it on in the background as I work, and if anything comes up that I can help with, I can answer promptly.
It's cross platform with Unizone and Javashare

Kevin

Shaka444

I also have a Linux port of HiShare, called HiTuxShare, in the works!

Shaka444

Kevin I also have a Linux port of HiShare, called HiTuxShare, in the works!

Thats Great! Is there already a TuxShare? That seems like a natural name.. but thats very exciting! When you're ready for beta testers, I'm in.

Kevin

Shaka444 Is there already a TuxShare? That seems like a natural name..

Yeah, TuxShare is already taken 😦

Kevin

Another question is, how would we organize the project team? I think we need a little more structure than just a handful of people merging their side projects into one codebase.

Perhaps have a "project council" that helps with project goals, then several teams in more focused areas (Kernel, Drivers, Build/Release, Outreach, etc).

No one needs to boxed in (i.e. we won't say a kernel developer can't touch a driver) but having focus areas could help keep build and retain knowledge in those areas.

Contributions from non-team members (i.e. random people who want to help) are welcome, but should be reviewed by team members too. If Dev A spends 1000 hours re-working something we don't want to blindly merge in conflicting PRs that would wipe out their work.

I'm sure we'd start too small for all these teams, but it could be a good way to help plan for growth.

Maybe something like this?

Atomozero

Kevin I find this distribution of responsibilities and authority very interesting. If the team grows, I think we'll definitely need it. I'm wondering how we can adapt this for just 5-10 people today 🙂

Kevin

Atomozero I find this distribution of responsibilities and authority very interesting. If the team grows, I think we'll definitely need it. I'm wondering how we can adapt this for just 5-10 people today

Yes, a very good question 🙂 what is the balance between too much structure, and the chaos of not having a plan.

We are starting small, so some teams might not be needed right away. Also I think the majority of the up-front work will be the non-technical teams.

Outreach/Community will be critical: the name/branding, setting up website/forum/telegram, etc. It sounds like there is already traction there.

Release team will most likely be next. Getting the code repository setup, getting builds setup and pushed to the website, how to we handle PRs and code reviews, etc.

Community experience team: also very important - once we have our first release, how do we handle bugs? Like mentioned earlier, do we need someone to triage bugs in the forums and enter them into a bug tracker?

Most of those 3 teams really could be 1 or 2 people to start.

The technical teams I think could start small and grow. Maybe we don't need a platform team or packaging team right away (especially if we stay with HPKG for a while, or forever?). Or maybe we just start with one technical team and split them out as we grow get more developers.

dcbeckman

You have already started on code of conduct, which is great,

The two things any organization needs to start is Articles of Organization and Bylaws. That is it. I have served on non-profit boards before if you need any help. I think it would best if this were incorporated as a non-profit in the EU and not in the US, although board members could be international.

Kevin

dcbeckman I do think we will need help with the non-profit. I agree about the EU, from what I was reading it sounds like the US has been tightening restrictions on what can qualify for a non-profit.

ewninja

Kevin

"This just became a job"

Isn't that too many teams? Because from what I see that's more teams than actual people... 🙂 I'm not saying that team split isn't necessary, but maybe it should grow organically instead of being created ASAP?

A major point of forking was to allow AI, which means that a single person can work on 2 drivers + a filesystem + package porting + QA all at once.

IMO the QA should really be as automated as possible with a metric ton of smoke tests. With tests being developed pretty much alongside new functionality. Adding a new system app? Tests are created immediately, regressions are caught within hours.

And how about going rolling release instead of doing "releases"? With a schedule like Omarchy for example:

Nightly - bleeding edge - only for adventurous users
Stable - rolls a month after nightly (so all major bugs were already caught), but security fixes are applied immediately

clasqm

ewninja Because from what I see that's more teams than actual people...

For a very long time, there will be one-person "teams", and if my German friends will forgive me, even ohne-person "teams". This is a good forward-looking projection. It sets out where we want to be, eventually.

dcbeckman I think it would best if this were incorporated as a non-profit in the EU and not in the US, although board members could be international.

Agreed. We really don't need to tangle with the IRS or get a friendly request from some US agency to release our membership data or build in back doors. EU privacy laws are probably the strongest right now.

By the same reasoning, is there a non-American alternative to github? Codeberg has gone luddite.

ewninja And how about going rolling release instead of doing "releases"?

The exact mechanism can be discussed, for there are different rr models. But deciding this now can save a lot of work later.

I don't think we have quite defined what we want to do. This covers, in Haiku terms, the Haiku repository. Do we want to do our own equivalent of HaikuPorts as well, or are we content to leave user applications to individual authors' own repos and/or websites? I incline towards the latter: an ecosystem rather than one big repo that everyone aspires to have their stuff included in. I think what we will end up with will actually be somewhere in-between Haiku and Haikuports. Something like freetype or ffmpeg is clearly infrastructure, not something of which you want a thousand slightly different copies floating around.

ewninja

clasqm Do we want to do our own equivalent of HaikuPorts as well, or are we content to leave user applications to individual authors' own repos and/or websites?

Yes, we need to "own the universe", just like every major Linux distro. Even MacOS and Windows have their own store.

What if HaikuDepot is seriously out of date on a critical package? Especially one critical to security, like a web browser? If we don't own the store we'll be SoL stuck hoping we have forked it.

Support for installing packages downloaded from websites or third party repos is absolutely required. Let's leave building walled gardens to Google and Apple.

I don't think that removing repos completely is a valid model in 2026, repos are simply too convenient. What does every developer do on MacOS? They install brew.
Also, your web browser needs to be up-to-date and repository is the easiest way to achieve that.

dcbeckman

There is always Gitlab and Sourceforge.

Maybe instead of a HaikuPorts type setup, we could control which repos are approved for which packages. If not specified, it would return all of the other packages for that repo. Of course you would also need some way to override that, in case you want to install an unapproved or experimental build. Perhaps a system .conf file with the official listing, and then a user settings conf override for whatever packages they want to associate with a different repo.

ewninja

dcbeckman

Repository needs to be centralized for two reasons:

Trust - allowing some kind of third party "no review" just YOLO packages will end up like *AUR.
Reliability - a repository needs to be on strong, DDoS resistant servers. You don't want your apt-get update to download from 30 random servers that are bound to go up or down.

* Last month the Arch Linux User Repository "AUR" saw more than 1,500 malicious packages amid a sophisticated malware attack

« Previous Page Next Page »