Good evening all. First things first, I'm screenshotting Carl's post, just in case we need to celebrate 25 years from now and this forum happens to be hosted on a Martian server unreachable from Earth 😃
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).
Over the past few weeks or months, several people have been working behind the scenes to tweak Haiku to better fit their interests. Many chose to keep a low profile due to the aggressive stance taken by the Haiku dream team and associates. There are at least 3 to 4 repositories that might pave the way for the new phoenix, but the burning question is: do we truly want this? Are we sure about the massive amount of work ahead of us for the next 25 years? I'm trying to bring up these tough questions because the honeymoon phase is always nice, but eventually, real life hits 🙂
Kevin 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 noticed a romantic thread was created on the forum asking how everyone first discovered Haiku. By my own choice (given the unfounded accusations against me, I decided to leave that forum), I wasn't able to reply, but in my heart I really wanted to because I've been using BeOS, Zeta, and Haiku for a lifetime. This photo is from 2002, when I gathered some of the Italian users at an old event. I'm the one in the black t-shirt. Just think, we still had CRT monitors back then 😃
So I will be extremely grateful to the entire community, and I will always be thankful for the massive work done on HaikuPorts, the long-term maintenance, and the dedication to keeping ports coming even during the community's dark times. I will always be grateful to all the VOLUNTEERS who contributed to the project. Always!
That said, call it a midlife crisis or the fear of a tool that is completely changing the rules of 'the power to code', but the choices made recently have brought us here. We find ourselves discussing whether to embark on a long journey together with new responsibilities and commitments that we might not even need, turning a passion into a burden we didn't necessarily want to take on. I reiterate these thoughts because if we set off, I'm all in, but we all need to be fully aware of the hard work that follows the first 5 days of adrenaline. Given our respect for everyone who worked tirelessly and quietly without ever getting a thank you, we cannot turn around and betray them by abandoning ship at the first sign of trouble.
Kevin Build a fast, fun, and reliable operating system based on Haiku
Yes, I do
Kevin 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
Yes, I do! I think part of the team should definitely focus on the Raspberry Pi. From a marketing standpoint, it would be amazing and a fantastic calling card
Kevin 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)
Yes, I do! I think this is the rational and sensible foundation for any healthy, modern software development team 🙂
Kevin Have rich branding and a good name. We want to attract more users and developers.
Yes, I do! This will probably be the hardest part, building ourselves up against a 'competitor' with 25 years of history behind them. We will be like a startup that has to make a name for itself and fight to break through, in a healthy, elegant, yet disruptive way 🙂
Kevin 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.
Yes, I do! Given how poorly the Haiku core team's decisions were communicated, I think we'll need a blog or a newsletter where we can share every choice made by the steering committee or a specific team. Here, it will be interesting to figure out how to structure the group by focusing on results rather than the number of lines of code written over time 🙂
Kevin 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
Yes, I do! In my opinion, hardware support should also be driven by metrics. For instance, if the number of image downloads or submitted patches for a specific piece of hardware is zero, maybe we need to rethink supporting it. The community itself will tell us what they actually use
Kevin Maintain a high level of code quality through code reviews and testing
Yes, I do! Just like with the previous points, none of us wants poor-quality code because that would mean more bugs for us to fix later 🙂
I need a break 😃
Kevin Would we maintain BeOS application compatibility? (I strongly vote for no)
Here is where the doubts creep in: exactly how many Haiku users are running 32-bit? 1, 10, 100? What is the threshold to justify tying up resources and potentially limiting future implementations in WalterOS? 🐟
Kevin Would we maintain Haiku application compatibility?
Do we have the capacity or the will to create a new HaikuDepot? If so, compatibility wouldn't be an issue since 99% of the software is open source.
Kevin Do we add multi-user support? Even if it breaks BeOS and Haiku compatibility? (I vote yes)
Haiku is already technically multi-user, it's just missing the GUI management part. Personally I don't feel the need for it since I'm the only one using my PCs, but I can see how it might be useful for some. It won't be a quick task to implement, but it could be one of the goals for our R1.
Kevin Are we forking and running away? Or do we want to bring in upstream changes from Haiku?
If the code doesn't conflict with our choices, I think it would be a waste of resources not to use their code, written as it is by unblemished Tibetan monks.
Kevin 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.
I like the rolling release idea, but maybe once a year couldn't we celebrate with non-alcoholic rum and fake cigars? Argh argh 😃 with a release specifically meant for marketing (yeah, yeah, I'm obsessed with this, but if we don't market, we'll never recruit new pirates!)
Kevin What would we need
Kevin Non-profit organization (eventually?) for donations and to fund paid developers (or at least pay for server costs) and handle trademarks
While I'm not worried about the server tech specs or various tools, I am very concerned about the formal side of things: the headquarters and the whole legal/organizational setup of the association.
Life's way too short to pick fights on forums.
If we kick this off, I really hope that if we bump into each other at a tech fair down the road, I'll still be able to share a beer with all of you and just chuckle about the past, telling our kids about our computing days on IRC, BeShare, forums, and Telegram, oh, and X and Facebook too (yeah, skipping mailing lists here, only folks born before 1970 still touch those 😃).
