Gerrit backlog vs. “no roadmap”: where is Haiku actually going?

Development OS
1

Over the last weeks I’ve been trying to line up three things:

  • what Gerrit says about our review backlog,

  • what the activity reports say about recent work (kernel, drivers, apps), and

  • what the forum says about roadmaps and R1/R2.

Put together, the picture looks a bit weird: we’re clearly doing serious work (guarded heap, Beta5, ports, etc.), but the backlog is heavy and old, and there’s no real roadmap that connects all that work into a clear direction.

I’m not writing this to attack anyone; I’m writing it because I’d actually like to see Haiku succeed as more than a perpetual “interesting beta”.

1. Backlog reality in late 2025

If you look at status:open -is:wip on Gerrit (thumbs up for new touchpad support), and cross-check with the recent October 2025 activity report (hrev59050–hrev59110, 61 commits in one month), you can roughly describe the situation like this:

  • Open non-WIP changes: on the order of 150–250 changes sitting in the queue.

  • Ready-to-push changes: around 30–50 of those have Code-Review +2 and passing CI, i.e. they’re effectively “ready to submit” but still open.

  • Average change size: typical changes are small to medium – about 10 files / ~300 lines; a few big ones (kernel rewrites etc.) go up to 1k+ lines, and unsurprisingly those take much longer to review.

  • Age distribution:

    • average age for open non-WIP changes is somewhere around 60–90 days

    • a noticeable chunk (~10–20%) are older than one year

    • some RISC-V / ports / old driver-related changes go back 4+ years and reference APIs that have moved on

So we’re pushing code (October alone had 60+ pushes; Beta5 landed with a ton of work in previous months), but the queue is clogged with outdated entries

A few consequences:

  • Average slowness:

    • urgent kernel work can land in about a week,

    • but “normal” small changes often wait 2–3 months for a full review/merge cycle.

  • Ready-to-push pile:

    • we have a non-trivial list of “green and +2” changes doing nothing, simply because nobody with submit rights had time/energy to push them.

  • Zombie changes:

    • old entries (pre-2024 driver hacks, experimental ports, etc.) become technical-debt magnets: nobody wants to touch or abandon them, but they still consume mental space and discourage related, newer work.

It feels like we’re pouring fresh water into a bucket that’s already full of stale water and sediment. New submissions are drops; 98% of what you see in Gerrit is legacy backlog.

2. Yes, progress is real – but it’s not connected to a visible roadmap

To be clear: Haiku is not stagnant. Recent reports and external coverage show very real progress:

  • Kernel guarded heap rewrite, better diagnostics, less memory waste.

  • ACPI thermal data and CPU feature reporting wired all the way through to ActivityMonitor/sysinfo.

  • R1/beta5 shipped in September 2024 with dark mode, FAT rewrite, UFS2, USB audio, .NET experiments, etc., and has been covered positively by Phoronix, Hackaday, OSNews and others

  • Development has been shifting more towards apps and ports as the base system matures

So from the outside you can’t say “nothing’s happening”. There is a lot happening.

The problem is: if you read the forum “Roadmaps and R1” thread and related discussions, the official answer to “what’s the roadmap?” is basically “there isn’t one, beyond Bugzilla”.

Paraphrasing the dev comments:

  • R1 goal is “replacement for BeOS R5.”

  • No new features are supposed to be part of R1; it’s “just” a stable point.

  • The “roadmap” is essentially “tickets marked R1 in the bugtracker; no time-based planning.”

  • Timeframes are avoided on purpose because there aren’t enough people to promise anything.

That’s honest, and I respect the honesty. But it leaves a huge gap:

  • Nothing explains how we get from “BeOS R5 replacement” to a usable 2025 desktop (GPU, multiuser, sandboxing, modern apps, etc.).

  • There’s no visible narrative from kernel → drivers → app_server → userland about where Haiku wants to be in 3–5 years.

  • People keep asking the same questions (“3D accel when?”, “what’s R2 about?”, “is there a plan beyond ‘fix some bugs’?”) because this isn’t documented anywhere.

So we’ve got:

  • Real work going on (guarded heap, Beta5, kernel/app work, ports),

  • A heavy, aging Gerrit backlog, and

  • No public, cohesive roadmap tying those pieces together.

3. How backlog + “no roadmap” feed into each other

My take is that these two issues aren’t separate:

  • When there’s no clear roadmap,

    • every change competes in one giant bucket,

    • reviewers can’t easily tell which changes are strategically important vs. “nice to have”.

  • When the backlog is large and old,

    • new contributors see zombie changes and lose motivation,

    • core devs burn review time on ancient patches instead of steering towards big goals.

Some concrete frictions this creates:

  1. No priority lane for roadmap-aligned work
    If we had a public roadmap saying “next 12–24 months we focus on: kernel hardening + compositing app_server + GPU path + key driver gaps”, then changes touching those areas could be clearly prioritized in Gerrit. Right now, it all looks the same in status:open -is:wip.

  2. R1 definition doesn’t match user expectations
    On paper, R1 is “BeOS R5 replacement, no new features.” On the ground, people expect something closer to “reasonably modern daily driver”. That mismatch means the bugtracker “roadmap” doesn’t answer obvious questions like:

    • is GPU acceleration considered pre- or post-R1?

    • is multi-user pre- or post-R2?

    • what’s the plan for modern browsers once current ports get too crusty?

  3. Zombie changes reflect zombie themes
    The very old changes in Gerrit often correspond to areas where there’s no agreed destination (RISC-V, specific drivers, experimental ports, etc.). It’s not just “we didn’t get to it”; it’s “we’re not sure where we’re going with this subsystem, so nobody wants to merge or kill the patch.” (UI changes included)

4. What I’d love to see Haiku do differently

I’m not expecting “corporate Jira roadmaps” from a mostly volunteer project. But I think Haiku could do better with lightweight structure that doesn’t betray the project’s culture.

A. Publish a one-page high-level roadmap

Not dates, not promises – just priorities.

Something like:

  • Kernel & core (next 1–2 years):

    • finish guarded heap integration and hardening,

    • define clear path for GPU/driver model (native vs. leveraging Linux/FreeBSD),

    • ensure stability for Beta6 → R1.

  • Drivers & hardware:

    • minimum level of GPU/Wi-Fi/storage support we want to hit,

    • strategy for legacy vs. modern hardware.

  • GUI & app_server:

    • position on compositing / GPU usage,

    • direction for R2-level changes (multiuser, sandboxing, etc.).

This would anchor expectations and let contributors and reviewers know which patches push the OS towards those points.

B. Add Gerrit health metrics to the website

Even a tiny dashboard would help:

  • number of open non-WIP changes,

  • age buckets (<30, 30–90, 90–180, >180 days),

  • count of ready-to-push changes,

  • monthly merges vs. new submissions.

Make it visible. Once the numbers are public, it’s easier to justify:

  • “backlog triage day” once a month,

  • “focus on clearing ready-to-push changes this week”, etc.

C. Monthly backlog triage for old changes

For changes older than 180 days, run a recurring process:

  • ping authors,

  • decide “merge soon, rework, or abandon”, (

  • actually abandon stuff that clearly has no path forward.

This sounds brutal, but keeping zombie patches around is more brutal to everyone long-term.

D. Tie reviews explicitly to the roadmap

When a reviewer looks at a change, it would help if they could think:

  • “Does this support one of the roadmap themes?”

  • “If yes, push it up the priority list.”

  • “If no, it’s still welcome, but shouldn’t block more strategic work.”

Right now, all reviews are effectively “first come, first served / whoever shouts loudest”.

Closing

From the outside, Haiku in late 2025 looks like this:

  • Technically impressive work is happening (guarded heap, Beta5, kernel & apps improvements).

  • Gerrit’s open queue is large, old, and cluttered; ready-to-push changes sit for months.

  • There is no clear, public roadmap from kernel → drivers → userland aside from “fix R1 bugs”, which doesn’t answer obvious “what next?” questions for people who want to bet on Haiku.

I don’t think the solution is “work harder” or “promise R1 in X months”. I think the solution is:

  • be honest about backlog metrics,

  • be equally honest (and explicit) about where we want Haiku to be in 1–3–5 years,

  • and connect those two with small but concrete process changes.

Lastly @PulkoMandy @waddlesplash and many more,

Thanks!

6 Likes
2

Your conclusion seems made up

For the +2 changes, unless some went through the cracks (in which case it would be nice to have a list), they usually are part of a larger “relation chain” where earlier patches in the chain are still being worked on or need being reworked. Otherwise, the person who gives the +2 or the original submitter can push the change.

I don’t see why old changes would discourage related work. On the contrary, you can start from an existing change, do the remaining 1 or 10% of the work, and get it merged. This should be a great way for newcomers to start contributing. Where did you get the conclusion that it is discouraging from?

It’s Trac, not Bugzilla. What is wrong with the list of tickets in Trac as a roadmap?

You just convenienly chose to ignore the one we have.

Prioirized by who? There is only one full-time developer. Everyone is not getting paid for their work and so they are free to work on whatever they want. Otherwise the effect will just be that people are not going to be told what to do and still work for free, and so they will work on their own pet projects.

You have missed the “R1 features poll” from 2010 where users (more than developers) have overwhelmingly voted to include extra features, such as Wifi, system updates, and more.

GPU and multi-user were both voted to be post-R1 in that poll.

The plan for modern browsers is WebKit/WebPositive, which I am actively working on keeping up to date and upstreamed. It is not crusty and will not get crusty (whatever that means).

More discussion is needed on a few changes. Gerrit and a starting point experiment is a good place to have that discussion. Some of these things are low priority.

So you can already use the Trac roadmap. Again, what is wrong with it?

And why do your example roadmap talks so much about GPU support in all components, when GPU support is firmly in post-R1 tasks?

Sure. Let’s put even more pressure on people for “hey, you should lose your motivation by looking at this embarrassing backlong instead of working on something useful”.

Also, who is going to maintain that dashboard? Who is going to work on these tickets without getting paid for it?

Throwing away work is just rude. None of these changes have “no path forward”. They are work in progress, and it can be slow.

In what conditions could a change block strategic work exactly?

6 Likes
3

To be fair to @theokeist , 2001 is an entire generation ago. Perhaps it’s time for a follow-up poll?

4 Likes
4

This is just going to be a nitpick because it changes very little, but the poll was (nerdy nasal voice) actually in 2010. :nerd_face:

Also, I don’t see much point in a new poll, comparing then to now a lot of users are just asking for GPU acceleration and a couple of high-profile ports, in addition to what was in the poll.

There’s already WIP (as in, not 100% done) code for a lot of these things (AMD/Nvidia GPU acceleration, Firefox, Webkit2, Wine) laying around, we just need some talented developers with the time and interest in finishing up what’s been started.
At this rate, we’re probably getting most of these before R1 is my point.

Having the contributors stop what they’re doing to set up the infrastructure for a new poll seems like a waste of time… to me at least.

5

This post is huuuge, vague and has way too many random lists. Is this another AI Slop?

6 Likes
6

It was in 2010, I’ll fix that typo.

1 Like
7

Also, the poll was done just after the first alpha release, activity was quite high, and the goals set were too ambitious. So, if anything, it would be a poll about what to remove from R1. Which would be very weird to do right now, as we have actually completed all features listed in the poll (which is why we then switched from “alpha” to “beta” releases.

And that answers the “why is there no roadmap” question: the roadmap is just fixing a lot of bugs. A quick look at the roadmap page in Trac through webarchives shows that the number of remaining tickets goes down by about 30 every year. At this rate it will take another 18 years to fix them all and release R1 with all bugs fixed.

Is this unreasonable? I don’t know. Until then I will happily continue to use the nightlies and beta releases, and I have no interest in starting work on R2, since I have no major issues with the way R1 works, only a few minor annoyances.

5 Likes
8

That’s a +2 from me! :slight_smile: (oh wait I’m not a developer :rofl: ) but stand with you on that one, one big happy beta5 user still. (with the slight annoyances I take gladly) :slight_smile:

1 Like
9

Some interesting points for some point of view. I don’t think I would fit in that structure. Not that much would be missed, as I’m a lazy procrastinator, easily distracted and incapable of setting priorities, so my throughput is very, very low. And then I don’t really mind about version numbers, I’m using nightlies as a rolling release, well aware of the possible issues and risks.

I also don’t care about Haiku direction or even if there’s one. I don’t look at a list of stuff some committee (or poll or whatever) has decided is important and work on it. Instead, I work on stuff that I want and think I can understand (so simple, small and detailed), or maybe something someone has noticed in a bug report or a post, but in that same category of small and simple. You need big real programmers for the abstract ones that may appear in a roadmap.

Now, it seems you have already done some of the stuff you are asking for going through the backlog. Keep doing it and provide 4.B. Try to get it included in the website or publish it on your own. Once it’s out, people may use it. Because that’s what we probably need more: people that do, not people that say what must be done. And in particular, going through a backlog and reviewing stuff is not a shiny work with crowds waiting for an opportunity to do it.

1 Like
10

“18 years” raises a rhetorical question if a single-user desktop OS will still be actual and needed in 2043?

A non-rhetorical question is: does R1 really need to have each and every of those bugs to be fixed, or it can be released with some known issues that maybe affects just a limited number of users?

Also, how many of those bugs are obsolete by now? There’s quite a few that have their last comment from like 10-15 years ago, probably there are some that can be closed right away. Those questions bring me to the following idea.

One thing that is wrong is a lack of proper prioritization of issues in Trac. For R1 we have only 2 critical issues (btw one of them is “#6847 Hard disks not shuting down cleanly - does not park heads“. Like really? Critical? For a desktop OS in 2025? I bet it’s not so much critical as it was 15 years ago when the bug was submitted). Then we have 6 issues of high priority, 13 issues of low priority, and then there’s an ocean of issues of “normal” priority: 449 items. Are all of them equally important for the users of R1? If you ask me, I’d process that huge list and change the priority to either High or Low, and then discuss if we can have the R1 release with just the Blockers, Critical and High priority issues fixed, while keeping Low priorities for later (maybe we can point newcomers who wants to help with contributing to try one of those first).

1 Like
11

There are also a lot of changes that are “WIPs” but not actually marked with the “WIP” gerrit status (which has some unfortunate side effects, like preventing code review I think; or was that only in older versions and it allows it now?), and sometimes I have patches that aren’t ready to be merged but I want others to look at and have a chance to comment on, so I post them to Gerrit. A number of my older changes are like that, actually. So those need to be counted differently, too.

12

I sure hope I will still be able to run Haiku for the next 18 years and beyond. As I said, the version number doesn’t matter for people who are already using Haiku. And people who don’t use Haiku actually have requests that are not on the roadmap (such as GPU acceleration, but it has been many other “not on the roadmap” things before that) anyway, so it won’t matter to them that the next version is called R1beta6, R1, 2026.6 or whatever.

I have already moved 300 tickets out of the R1 milestone. We also routinely close obsolete ones as we find them, usually when we make changes to related code and ask people to confirm the fix (either they can’t reproduce it and confirm it’s fixed, or they don’t have the hardware anymore, or they confirm it’s still there). Some tickets have no activity for 10 or 15 years because the thing is still broken.

So, I expect a low number of these bugs to be obsolete, and that maybe a few more can be moved out of the milestone. Feel free to go over the list and suggest some that you think are not important and should be moved to R1.1 or later.

Cutting power to a disk without telling it to flush caches and shutdown can lead to data loss. It won’t lead to hardware damage on SSDs, but it is still a problem. Also, spinning disk are still a thing for larger capacities, and if there is a risk of hardware damage, that’s critical, no matter how rare the hardware is.

Yes, I think more triaging can be done, as I have suggested in several threads discussing this on the forum already. It seems no one is interested in actually going over the list and deciding which of the tickets can be moved out of R1. Then nothing happens. Either people don’t actually want to do the boring part, or the list is already quite good.

1 Like
13

Spinning disks are indeed used for larger capacities, I know as I use one myself for backups. But the bug is not happening for the external USB drives, so that leaves us only with laptops/desktops that still uses HDD as an internal SATA drive, which is a really small fraction of users to block the R1 release. I can see your point why it’s critical, but at least it can be moved out of R1. If the bug also affects SSD (e.g. if we don’t flush caches properly before the shutdown) then it should be renamed accordingly.

Yes, I think more triaging can be done, as I have suggested in several threads discussing this on the forum already. It seems no one is interested in actually going over the list and deciding which of the tickets can be moved out of R1.

I’m interested and ready to start doing the boring part of triaging, where do I sign up? :slight_smile: (Atm, I don’t have necessary permissions to change a priority or milestone).

14

I have a 2 TB SATA HDD. These disks are not that old or rare.

2 Likes
15

Dark mode support has dominated the last 3 betas and will continue into the next beta at least. Although dark mode is a new feature in Haiku it has revealed a lot of bugs, accessibility problems and missing features and so I feel that it has been worth it. There is still more work here to be done.

Scaling the UI based on font size is a similar story.

3d acceleration has become necessary to have a good web experience these days so it’s a must. We could release with our current software-based 3d stack but it would be nice to at least have hard cursor support and hardware video decoding support before release. I’m not sure where the line is exactly but we’ve come a good long way already towards meeting the R1 requirements here.

Web browsers (WebPositive) have also revealed many bugs and many missing features in app_server which cause things not to draw correctly. This is an ongoing process and will hopefully be done in time for R1.

WebPositive and WebKit are still undergoing development like switch to WebKit2 that should be done before release.

There are a few show stopping bugs for R1 that need to be ironed out. Right now my focus has been on fixing regressions from beta5 (and a couple from beta4) so that we can release beta6.

Gerrit is a hodgepodge of commits in various states of completion. I’m not sure how much you can gleam from analyzing it.

I would prefer patches to get triaged more quickly and I’ve done what I can to try and foster support to push things along. It’s a slow process and usually requires responding to a bunch of feedback to get a patch in so patches languish waiting for feedback to be addressed. For others there is some unreconcilable differences of opinion keeping the patch from being included. Anything old with +2 is controversial.

There’s a few more features I’d like to see before R1. One is session support, that is saving the state of all open applications and windows on quit and then restoring them when reopened. Without this feature stack & tile is not very useful because stacks don’t survive a reboot.

Focus on BeOS app support has been deprioritized, at least any “quirks mode” patch I try to include is rejected. The current state of BeOS app support is considered to be good enough and we’re not going to hold up R1 release because a BeOS app misbehaves even if it is our fault.

The docs are in pretty good shape. My goal was to complete the API docs before R1 and we’re pretty much there. There are some notable holes in the documentation like the Game Kit but I’m not too concerned about it.

6 Likes
16

Does it mean BeOS compatibility issues can be moved to post R1?

1 Like
17

No any BeOS related issue must be in R1 milestone, but it may or may not get fixed. If not fixed in time for R1 the issue will never be fixed, sorry about that.

1 Like
18

Okay, but that means we can release R1 without fixing all the bugs in R1 milestone, right? That kind of contradicts what PulkoMandy wrote above, but I’m fully in support of it (because I don’t think “R1 is released when we fix all the bugs” is a viable goal).

1 Like
19

Yes, if you spend any time with an LLM you can quite easily recognise this was definitely written by one.

20

We only have to fix the blocker bugs, everything else is a judgement call. We have the concept on an R1.1 branch to theoretically cover anything that should have been fixed in R1 release but wasn’t.

Once R1 drops we’re going to break all BeOS apps and most Haiku apps in a myriad of ways some documented on the wiki, some not as we make all of the private APIs public and change things in ways we know will be binary incompatible but we have been itching to do for a long time now.

R1 will serve as the stable release while everything after will get reworked dramatically. Any BeOS bugs that are fixed will get applied on top of R1, but by that time the allure of R2 will already have taken the developer focus away and you’ll be hard pressed to get your patch accepted.

If there is an outstanding BeOS incompatibility (and I know there are a few off the top of my head) you’ll want to get those fixed before R1 if you can.