Should we really fork?

Kevin

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.

rainygirl

Nice to see you. About 10 minutes ago, I had forked the haiku project onto my GitHub. I was thinking that I should create the code separately from the haiku community for my small, cute machine. If a new fork happens and a new community is created, I’ll help too.

I think we can set a deadline and discuss the direction of the project code. What matters most, above all, is not the direction of the project, but the community’s rules, in my opinion. Rules are needed for smooth collaboration and quality compliance. Along with him, I hope that everyone can feel safe, be free from blame, and that people of all races, genders, sexual orientations, nationalities, ages, and whatever else be welcomed.

Thank you also to the person who invited me to this thread.

Kevin

Welcome! I am the same person as Nighthawk on the Haiku forum. Nighthawk was my old BeOS handle but I don't use it much anymore.

I agree a deadline and rules are critical.

I also agree that everyone should be safe, welcome, and free from blame. One of the many things I love about BeOS/Haiku is there are users from all over the world!

Atomozero

I'm at the office right now, so I'll give you a proper answer this evening. My initial thought when I got the notification was: 'Oh no, I don't want a fork! We're one big family!' But then I thought about what happened to me on the forum, and the fact that I just want to use my favorite operating system in peace.

Kevin

Atomozero Honestly I think it is very sad to even be talking about forking. In fact a couple months ago, I agreed completely about not forking. But the most recent round of fighting on the Haiku forums has opened my eyes that I think it is inevitable.

memson

I think forking is the only way we will all get what we want.

dcbeckman

Next, to Tabby, and I believe someone was working on a Pirate OS distro, or something like that, I think my Media-OS project has a broad enough scope that it could be its own distro. I have been trying my hardest not to make it a distro and simply be a packageable USB stack, usb_audio, usb_midi, etc replacements. But after some of the packaging difficulties I had this week, due to the usual - incompleteness or incorrectness in Haiku documentation and/or code, I almost wonder if it would be easier to just fork my own distro.

One thing to think about, since having a lot of OS forks doesn't make sense, is that Tabby had to fork because it was a new hardware platform and using AI. They can't rely on the Haiku kernel and boot loader like I can. That doesn't mean that Tabby has to be a PPC only platform. It may be possible to also use it as a platform for AI assisted x86 OS improvements as well.

dcbeckman

Atomozero They literally accused someone the other day as either being a 2nd account of yours, or at least being one of your "lackeys" or something like that (don't remember the exact word). Things have gotten BAD in the last few days.

Atomozero

dcbeckman Yeah, Marco told me, I burst out laughing 😃 but let's stay on topic 😃 actually, I'm finishing up a report and heading straight home so I can reply properly.

ilfelice

Considering this statement from Haiku's lead developer...

https://discuss.haiku-os.org/t/the-great-genai-moderation-debate-vol-1/19717/56

...I think a fork deserves serious consideration.

I will post my observations after I get some sleep.
😉

rainygirl

Let's start by resolving the trademark issue. Naming is a very difficult task. So it would be best to come up with a temporary name for now and hold a contest for the official name. In fact, the name “haiku” has already lost its brand value, partly because Anthropic has been using it as the model name (sorry about that). I will send a gift by mail to the person who offers a good new name.

Oh. I found a post about naming. https://forum.desktoponfire.com/d/56-haiku-just-ran-out-of-excuses/4

dcbeckman

ilfelice I am ok with them not wanting AI generated code, but it is really sad that Haiku's only paid engineer admits that it is a great productivity tool for finding bugs, that they could then fix by hand, but they refuse to use it because it is something a human should do (in much more time). Not a good use of limited resources IMO.

Kevin

rainygirl Yes, naming is very important. In addition to it not conflicting with current trademarks we should check that it doesn't translate to anything offensive in other languages, also has a domain available, etc.

rainygirl

Kevin I can help with the languages I know. Let's get started.

jicese

Both forks and distributions are mentioned here. I hope we could treat the fork as a distribution to be synced at least with every Haiku release with its own additions for hardware, services, translators etc and still be fully compatible with Haiku.

Shaka444

Thank you for making this post @Kevin
Love your ideas! One thing I might add is Debian has a constitution
I think thats a good idea to keep things from getting into flame wars on how things should be done.

As far as a name..

HAIku! :-D

I love the whole Pirate theme, it's fun and playful and rebellious with a grin.

I also love Beryllium because it's symbol is "Be". (look it up)

I think we have the motivation and even the man power (man/woman/machine ;-)

I might suggest a "Soft" fork, like a "distro" and to not alienate all the current haiku devs. Some may be open to helping out. There may be a relief in the Haiku community and devs so they don't have to argue constantly about A.I., they can just point everyone interested to the A.I. friendly distro :-)

Kevin

I am quite bad at coming up with names, so I probably won't lead that effort. I do like Beryllium, and I also think Eastern influence names could be good since BeOS had a following in Japan (and I'm personally a fan of visiting Asia).

I really like the idea of a constitution and formality around voting, electing project leaders, resolution, etc. I think structure is beneficial. I also think transparency is important.

The fork vs distribution question will need a lot of thought and input. It is related to my questions about compatibility in my original post. Is maintaining BeOS and Haiku compatibility going to be a goal? And is bringing in source changes from Haiku a goal?

I see pros and cons for both approaches. There is a lot of benefit from being able to source changes from the Haiku code branch, and also not breaking Haiku 3rd party apps, so in that regards a distribution makes sense. On the other hand, the new OS architecture may change a lot (to support PPC/SPARC/ARM/RISC-V, or add multi-user support, or whatever) which may make it impractical to maintain Haiku compatibility. Or perhaps a compatibility layer?

TmTFx

Hi all! Here's a Pirate. My fork started as a proof of concept for the hardware cursor support and since then it improved with various features like an AI integrated subsystem, an encypted Keystore for paaawords, new video card drivers , a new launcher (thanks tzumi) and something more...

I'm still thinking if I should publish it. Life is just hard as it is and having legal issues is not what I'm looking for.
but if anyone likes what I do I can share my code and my thought about what I did on my private distro.

dcbeckman

Kevin Is maintaining BeOS and Haiku compatibility going to be a goal?

I would say at least for BeOS compatibility, that as long as Haiku supports gcc2, we should as well. But we should also focus more on the non-gcc2 32bit branch, and with our lovely toys, figure out how to bridge the 32-bit/64-bit divide within Haiku OS with a 32-bit subsystem, as well as with other systems, like 32-bit WINE support.

As far as Haiku compatibility, it should work out ok in general. Just need to diff their own changes and see if there is anything that we can gain from it to keep things relatively compatible. My current Media-OS project is meant to map to Haiku's own stable releases. My Media-OS name is also up for consideration if y'all like it. I also think Tabby would a good name, if they were interested in extending support to x86 with community help.

Shaka444

TmTFx The only legal issue is using the name Haiku which you don't so you're good.

@dcbeckman
I like the name MediaOS! It harkens back to what Be intended to Be! An homage to our roots.
The gcc2 thing could be fixed by a compatibility subsystem like WINE that I'm sure "The Crew" can manage to build. Either that or I'd say leave it to Haiku to maintain. The audience for that is small enough now not to warrent spending resources on (IMO). Besides, we still have BeOS! I'm running it on bare metal now on a quad-core pentium x86 box. I would rather "The Crew" rewrite BeOS in 64bits than maintain Haiku_x86 (but thats just me :-D

PS what is Tabby? Did I miss something?