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.

dcbeckman

ewninja I don't think it's that black or white. There will be several trusted repos within our community, which can be vetted by us. And being able to spread the server loads between parties is going to be in everyone's best interests. Hosting and downloads all cost money afterall. The main thing I don't want is a system so locked into one system, that a repo takes over the OS, like the one time I just wanted a Kali package and my Ubuntu install ended up Kali, which was not my intention.

Update: And this leads to my next point. The biggest obstacle we have in that regard is Haiku packages themselves. Because in my project, every time Haiku releases new packages, they touch the modules' times even though the underlying code didn't change. When you have system replacements, they will be overwritten by .hpkg updates from Haiku. They would either have to turn Haiku repos off, or we would need a robust system to block list the Haiku system packages that we carry. This reminds me, we need to create a thread on issues with HPKG. Because I have gathered in the forums that lots of people have issues with it. I just don't know what they are, other than what I just mentioned.

dataflowcodes

Re: package management
My not-yet-made CPU will have an astable ISA so a bytecode package will be needed as minimal level of portability so cached binaries made from bytecode could supply all the others. I am not sure if bytecodes will be preferred overall due to compile time though Cranelift generates code more quickly than LLVM with a smaller selection of processors.

Shaka444

Kevin As far as packaging goes, lets never forget the power of single binaries that leverage the built in kits and libraries. This is a very powerful aspect of BeOS/Haiku style coding.

ewninja

dcbeckman I don't think it's that black or white. There will be several trusted repos within our community, which can be vetted by us. And being able to spread the server loads between parties is going to be in everyone's best interests.

Of course we need to design it like Debian - everything is properly cryptographically signed, but you can easily mirror it by just copying the files. Repo centralized, but mirrors stay easy to create and even self-host.

dcbeckman When you have system replacements, they will be overwritten by .hpkg updates from Haiku. They would either have to turn Haiku repos off, or we would need a robust system to block list the Haiku system packages that we carry.

The only real way I see to fix this problem is either some kind of a store that will hold 10 different versions of a particular library (like Nix) or "ship all your dependencies" (like Snap/Flatpak/Docker).

Maybe a Flatpak like approach would be best though? You have a stable system and any third-party program either follows common conventions, or gets repackaged into a private chroot where it can do whatever it damn wants without interfering with the rest of the system?

Shaka444

Atomozero I just want to use my favorite operating system in peace.

I keep thinking of this line. I think this is why many of us are here. Love it.

ewninja

In my quest to burn tokens about a month ago I got Sol to port XFS, ext4, exFAT, Btrfs, NTFS and ZFS from Linux to Haiku. And also LUKS for encryption.

They were not human tested at all, but they were automatically tested using some stress tests and Walter was able to successfully boot from each of them.

There is one pretty important design decision! How dead-set are we on sticking 100% to MIT?
If we allow some GPL code (not 100% - Walter should be able to compile and work with --no-GPL) it would allow us to port best implementations of drivers, filesystems and other subsystems directly from Linux.

I'd rather use an ext4 implementation that was battle-tested for 20 years than one taken from FreeBSD (where ext4 it's barely ever used). And my trust in BeFS is also really low, there just isn't enough daily users to weed out all the bugs. And also BeFS has some sad limitations - 260GB max file size would disqualify it from being my daily driver.

Shaka444

ewninja There is one pretty important design decision! How dead-set are we on sticking 100% to MIT?
If we allow some GPL code (not 100% - Walter should be able to compile and work with --no-GPL) it would allow us to port best implementations of drivers, filesystems and other subsystems directly from Linux.

I'm ok with some GPL code. (Be had it too! :-D )

While you're burning tokens, a real BeFS with read/write support for linux would be nice too!

ewninja

Shaka444 While you're burning tokens, a real BeFS with read/write support for linux would be nice too!

Unfortunately, right now I have a different project to burn tokens on - I'm getting Linux to run on Apple M4.

And it's basically going to take an agent a full month 24/7 since it essentially requires implementing new drivers from scratch. Or at least adapting older or similar drivers wherever they are available.

You can do it yourself though! I really doubt that porting BeFS to FUSE would take more than a few hours for a frontier model, it's not a difficult task.

Kevin

I'm not opposed to GPL if needed (i.e. porting a Linux driver). It seems like the advantage of MIT was to attract commercial companies that might want to use the OS for their products, but that seems unlikely to ever happen.

I believe all Haiku code that is MIT licensed must remain as MIT, but new code could be GPL.

Kevin

ewninja I really doubt that porting BeFS to FUSE would take more than a few hours for a frontier model, it's not a difficult task.

I ported BFS to my port/modernization of Syllable and I think it took less than a day with Claude, including testing.

ewninja

Kevin I believe all Haiku code that is MIT licensed must remain as MIT, but new code could be GPL.

New code can stay MIT, the only GPL would be ports from other GPL projects.

I played with Syllable (dual-booted it) for a short while 20 years ago.

dcbeckman

Even Haiku uses GPL in some areas. In my Media-OS project I keep GPL code in the 3rd Party folder as a license boundary. I personally love the freedom of the MIT and BSD licenses, without the copy left bs, even though this is all open-source work anyways. I would prefer to keep things to MIT as much as possible, but we shouldn't let it limit us either.

dataflowcodes

dcbeckman before easy licenses were used as free training data for AI, I used to agree about copyleft but now it seems more necessary.

dcbeckman

dataflowcodes MIT is the most ethical source material for AI training, so long as attribution is made. Apparently, Meta is the only AI platform trained soley on MIT/BSD type permissive licenses. Not that I would trust their AI for any serious work.

clasqm

ewninja There is one pretty important design decision! How dead-set are we on sticking 100% to MIT?

Don't ask me, I come from a kinder, gentler age before we all became obsessed with licenses.
Which is why all my recent stuff has been licensed under the WTFPL.

Kevin

It sounds like we have enough interest in moving forward with a fork.

We already have a domain and github, what should our next steps be prior to starting?

Just some thoughts:

Decide on a basic leadership structure or council?
Draft basic project goals and guidelines (what are we doing and why, but also what are we not doing)
Create code and documentation requirements
Determine merging/code review policy
Website / forums?
Packages/repos

Atomozero

Kevin Decide on a basic leadership structure or council?

Maybe at this point, this is the first thing we need to do, so that we can then formalize all the subsequent points.

rainygirl

Kevin Decide on a basic leadership structure or council?

A kind leader would be appreciated if about two people would raise their hands.

Kevin Website / forums?

Is it okay to write this forum?

Shall we try creating a channel to meet up together? I think it’s fine even if they’re not on standby 24/7. Because everyone has a different time zone, too. Which channel do you prefer? IRC (is that too old?) or Discord?

clasqm

Kevin Website?

If we have a Github, then the github.io can be used as the website.

Atomozero

rainygirl

rainygirl Shall we try creating a channel to meet up together? I think it’s fine even if they’re not on standby 24/7. Because everyone has a different time zone, too. Which channel do you prefer? IRC (is that too old?) or Discord?

What if it's Telegram? https://t.me/RenkuOS

rainygirl Is it okay to write this forum?

If you'd like, I've created some new forum sections specifically for Renku.

« Previous Page Next Page »