Roadmaps and R1

If people are realistic, we know that Haiku R1 is not about “shinies” (endless new features and capabilties). It’s about having BeOS R5 in modern form. But, we have to be realistic and realize you CANNOT have EVERYTHING you want, if you want ANYTHING… in a timely fashion. And 20 years to get a “clone” of BeOS R5… seriously? TWO FREAKING DECADES?!?

Maybe a lack of finances was partly to blame. Maybe a lack of manpower or the right people to work on the necessary components. I mean, if an open-source project with a low level of finances takes 20 years to reach beta… then I guess it couldn’t be helped, but I sure didn’t think we were THAT unmotivated over the years.

2 Likes

Maybe I am too naïve, but I am still expecting a realistic roadmap that covers a timeframe for releasing R1.

You can expect whatever you want. If there’s not enough people doing the actual work to fulfill the roadmap it’s not going to happen. This is exactly why we don’t have a time based roadmap. Only tickets that are defined as blockers for R1. This has been explained by the developers in several threads on this forum and I wonder how many times it needs to be repeated.

EDIT: It’s even explained by several devs in this very thread

2 Likes

Whatever you say would be valid if the project solely went on with volunteers. Now there is a person on the payroll, paid to do exactly this kind of stuff.

Edit: There was a deleted sentence here, which I am not sure if qualified as an insult, but still removed it as per the mod team’s suggestion just to be on the same page and not give birth to misunderstandings. Didn’t expect this to blow up this much though. Sorry everyone!

8 posts were split to a new topic: Forum moderation discussion

Not going to discuss here, just my 2 cents, my R1B4 runs like a charm, for my personal needs it already “feels” like R1, I don’t care how it’s named. :smiley:

6 Likes

One paid developer is most likely not enough to guarantee an exact timeframe for an R1 release. And I think it’s good that the project is quite upfront with this, instead of making promises that can’t be kept. Everybody that’s thinking about donating can decide if they are OK with this or not.

Besides, I don’t think we would benefit from an exact schedule that much. Think about several releases of commercial software (OS and applications) that were not really ready and were rushed out on the market because of release schedules.
BeOS had its time as a commercial OS and it failed. I think we should be happy that Haiku exists as an open source non-commercial project that moves forward maybe a bit slowly, but also can’t die instantly like commercial endeavours.

3 Likes

What do you find unrealistic about the current list of bugs? The fact that it keeps gettting bigger over time instead of reducing?

One part-time developer, even paid, is not going to make that much of a difference here. Or, well, it does make a large difference, but the TODO list is even larger.

I think, on the contrary, that the current plan is realistic, in the sense that it matches with who is working on the project and what we can commit to it. It is disappointing that this means R1 is several years in the future, but it is realistic. We could instead make a more ambitious plan and then fail at it because we don’t have the workforce to do it.

7 Likes

most of users’s words , it is the Mature solutions of R1.
but most of developers’s words, it is the hobby of R1.
they are very different.

Indeed. Anyone can look at the activity & contract reports I’ve written over the last two years, and my commit logs to match them to see that this is the case.

5 Likes