No one talked about “getting back” to exactly a clone of BeOS R5. If you want BeOS R5, just use BeOS R5, it works, it won’t change in the future.
Haiku of course needs to make compromises. Let’s look a little at our history and how we got where we are (as they say, "when you don’t know where you’re going, first check where you’re coming from).
The initial project vision was “to create a free software replacement for BeOS R5”. Yes, in terms of features, this goal has been reached, and this is why we are ready to enter beta stage (as defined in Haiku, a beta is a feature complete system, which may still have bugs).
After the alpha1 release (remember, the alpha1 also had a precise goal: it was shipped once the OS was able to compile itself), there has been a large discussion with devs and users (it happened at BeGeistert) and then an online poll to decide what should and shouldn’t be included in R1. This was in 2009-2010. Already back then, people understood that just replicating BeOS R5 wouldn’t quite work. Because the world had moved on in the 8 years it took to get Haiku to alpha1, and some things that were ok in 2001 were not acceptable anymore. Examples are support for USB and Wifi. Would Haiku still exist if we had decided these were not important? In my case, the answer is clearly no: I would have given up on using such an OS and moved on to something else.
Now, the decisions were made at a time where Haiku had an highly active team of developers working on it. They had just reached their first major milestone after 9 years of hard work, and everyone was quite enthusiastic about the future. Maybe a little too much. In particular, one item slept in: “it should be possible to update the system without reinstalling everything”. This looked simple enough at the time. However, once the Haiku team started thinking about it, they tried, as usual, to do things right once and for all. As a result, it ended up with something that goes further than the goal: a package manager that handles updates not only to the system, but also to all applications.
Anyways, eventually the work on this was completed on the software development side. However, it turned out that the designed system also needed a lot of infrastructure work. This is setting up a server to host all these packages, having buildbots creating the packages automatically, etc. This is a large work and something the Haiku team is not really knowledgeable about. We are all learning there.
Notice that it took 9 years to get from the project start to alpha1, and 9 more to get from alpha1 to beta1. What we are discussing now is the plan for the next 9 years, which should lead us to R1.
I tried to share my vision but it seems some people misunderstood me. So let me repeat it again (note: this is only my vision, I don’t consider it ready. We should discuss this with other devs and users - probably starting at BeGeistert with a brainstorming session as we did after alpha1).
I think Haiku should aim to provide a stable, supported platform. For me, this is what R1 should be. Something you can count on, that will never have regressions, with very careful testing. Something TuneTracker systems could ship to their customer and base their work on. Something users could trust their data to. This is one long term goal, however: there are still hundreds of bugs to solve before we get there.
However, we cannot focus just on this: if we put all our resources on just fixing this almost endless list of bugs, it means we make no progress on anything else. This means no USB3 support, no support for modern video formats, and no changes to the API. We can’t stay in the 1990s forever. So there need to be work on modernizing some aspects of Haiku in what will eventually lead to R2.
When we get to shipping a stable version of R2, it means we can retire the old R1 and customers/users can update to R2 (hopefully with a migration path so they can continue using their apps - the problem in defining R1 and R2 more precisely is around defining that migration path).
This is all great, but it assumes people are willing to invest effort in both maintaining a working R1, and adding new features to R2. This may not be the case forever. As far as I know, many of the developers are - and rightfully so - willing to work on new stuff for R2. Doing maintenance on R1 is not that fun of a job. I’m ok with taking care of R1 for some time after the beta1 release. There will be more betas after the first one. We’ll see how we organize this, maybe a release every 6 months or every 6 years with whatever bugfixes got in. It is likely that the bugfixes will be imported from R2. However, as time passes, it will become more and more difficult to do that, and at some point, R2 will be ready for its first alpha version.
What will happen then? Well, if R2 alpha works well enough, I may start using it. And in that case, my interest for keeping the R1 branch moving forward would stop. So, I would need a reason to keep spending my time on that old code. Maybe if someone really needs it and pays me for doing the maintenance, I will. But otherwise I will just tell people to migrate directly to R2. This is what I mean when I say “R1 may never be reached”. No software is ever perfectly finished and done. It just works well enough for what people do with it. We could at this point make one last release from the R1 branch, and name it “R1” (no beta or anything). It would be some gcc2 based thing in the 2020s. Who would care about it?
Now, I’m ready to change my mind on this. But as you can see, this post is rather long and detailed and tries to cover a lot of things. And I didn’t even start discussing the various options for the R1->R2 migration path. As a result, I find 2-line plans like “R1 is the gcc2 branch, R2 is the 64 bit branch” not any serious. There may be some sense in doing that, but you have to define the global vision, who is doing what, what is the goal for each branch, etc. Not just jump straight into “it’s all about the compiler version we use” or some other technical detail.
I do appreciate discussing these matters with users and outsiders, but the input I need is not technical solutions - not at this point. The input I need is your visions for the future Haiku, does it matter to have a supported R1 branch like that or would people just jump straight into R2, etc. Once we have agreed on a common vision for this, we can start refining it and seeing how we can implement it (things such as “when/how can we stop using gcc2”, “when/how can we drop ABI compatibility”, etc). And we should finally reach a technical plan for 2018-2027, which results in releases that satisfies as much as possible of the users needs.