We need to talk about the Add Project experience in the BOINC Manager.

Currently, if a user on a brand new Apple Silicon Mac opens the project list, they see dozens of projects that will never send them work. They see CPDN, DENIS, and GPUGrid, even though those projects have zero tasks for their platform or are effectively dead.

The 2-Step Fix:

Platform Enforcement: The BOINC Manager should only show projects that have a verified, active application for the host OS and Architecture. No more Project has no work errors for things that havent been updated since 2018. If a user is on an Apple Silicon Mac, the list should filter automatically to only show Asteroids@Home, Einstein@Home, LODA, NFS@Home, NumberFields@Home, PrimeGrid, and WCG.

Resource Filtering: Give us a GPU-Only or CPU-Only checkbox before we attach to a project. A user shouldnt have to install version 7.24.4 just to get PrimeGrid iGPU tasks; the client should handle that communication and only show Compatible projects.

If we want to move the needle on GFN-16 or other major science goals in 2026, we have to make the software as easy to use as a console game. If it doesnt work, dont show it.

GPUGrid has work this week. Some projects just have work in bursts.

Some projects do not have the capacity to be included and do not want to on the list: TN Grid
Some projects are repeat derivatives the same thing: ODLK2025

While I wish it was so, I doubt BOINC admins have the capacity or desire to keep the processor/OS list up to date every time a project changes the apps or work availability listed here: If anything that page could have a lookup to project server_status and apps pages, then the client would get updates from it. But probably more micro managing that what people want to do.
https://boinc.berkeley.edu/projects.php

BOINC client keeps its list up to date.
If the project has some particular application supported - we show it in the list.
We have no possibility to verify always if the Project has job for every application they show in their list.
If you want to complain - it's better ho to the project and complain to them asling to remove from the list applications that have no work for a long period of time.

Regarding resource filtering: on the 'Add Project' dialog you can directly see what OSs and GPUs are supported:

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.

Thank you for the detailed explanation and the screenshot, Vitalii.

It is great to see the OS and GPU icons in the dialog, but the core issue for a new volunteer isn't just hardware "compatibility"—it's active work availability.

While the client shows the project is capable of running on my hardware, it doesn't tell me if I'll actually get a task today.

Asking new users to manually check project status pages or complain to individual project owners is a high barrier to entry that often leads to "volunteer fatigue."

Could we explore a simple server-side "liveness" check or a status indicator (like a Green/Yellow/Red light) in that list so users don't have to guess which projects are currently "Zombie" projects?

I appreciate the insight into bursty projects like GPUGrid.

You're right that these are valuable, but for a first-time user, a "burst" project that happens to be empty on their first day feels like a broken experience.

What if we added an optional "Active Projects Only" toggle in that wizard?

It would allow veterans to still find those "bursty" niche projects while giving newcomers a guaranteed path to active science.

In 2026, making the "out of the box" experience as smooth as possible is how we'll successfully attract the next generation of iGPU and ARM users.

In reply to kasdashdfjsah's message of 17 Jan 2026:

What if we added an optional "Active Projects Only" toggle in that wizard?

What would be your criteria of 'active' project?
Also, there might be no work 'now' because scentists upload WUs manually, and it's just not a working hours now, and the work might appear in a few hours?

In 2026, making the "out of the box" experience as smooth as possible is how we'll successfully attract the next generation of iGPU and ARM users.

We have a solution for this called 'Science United': you just attach to the science areas you are interested in (or just to everything) and the client does all the work for you. You don't need to look for an active project, BOINC client will do that instead.

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.

Is there real evidence of many users being put off by this issue? Expecting BOINC to handhold the user through choosing projects feels to me like treating users like young children. If anyone is really interested in making a contribution to science using their computer they will not be put off by one or two projects being out of work or having their feeder not running like WCG at the moment.

In reply to Dave's message of 17 Jan 2026:

Is there real evidence of many users being put off by this issue?

Actual evidence isn't relevant.
"Scaring away volunteers" is what they claim to support whatever it is they're posting about in all of the threads they start.

---

Grant
Darwin NT.

Thank you all for the feedback. It is helpful to understand the technical constraints, like manual workunit uploads and the difficulty of verifying real-time job availability.

My goal is to find a middle ground that keeps BOINC’s flexibility while lowering the barrier for the 99% of non-technical volunteers. While Science United exists, many new users prefer the direct experience of the BOINC Manager.

I suggest two main improvements for the UI:

A Liveness Indicator: Even a simple color status in the Add Project list based on whether a project sent work in the last 30 days would prevent volunteer fatigue.

Optional Active Filtering: A toggle to show active projects only would give newcomers a guaranteed path to science while letting veterans seek out niche or bursty work.

I appreciate your dedication. I hope we can make the out of the box experience smoother to maximize the impact of the next generation of hardware.

We don't want BOINC to turn into the distributed computing equivalent of MS Word, or Windows; where all sorts of options and additions have been made in response to requests, which are at their very best only edge cases.

The end result, you get people requesting useful functions that already exist, because they can't find them amongst the almost endless other functions that have been added, 50% of which are only used by 1% of the user base (yes, those stats are made up. But hopefully you get the idea). Along with other functions that were once useful, but are no longer really necessary (eg screen savers).

---

Grant
Darwin NT.

In reply to kasdashdfjsah's message of 17 Jan 2026:

A Liveness Indicator: Even a simple color status in the Add Project list based on whether a project sent work in the last 30 days would prevent volunteer fatigue.

Project sent work to.... where?
We support 4 OSs: Android, Linux, macOS, and Windows
We support 4 GPUs: AMD, Apple Metal, Intel, nVIDIA (OpenCL and CUDA)
Any of this combinations might have their own work availability (and might have not).
Imaging we have this option, and the user has Windows and AMD GPU, they enable this option, see that the project has jobs, attach to it just to find later that this particular project has jobs for Windows CPUs only, and for AMD GPUs but only on Linux? Or even worse: user's GPU is older that Project supports.

Also, what is probably more important: we don't have any of this data, we just simply don't collect this.
Yes, you can find 3rd-party services like this that will show you the work availability for every particular project, but since it is not the service we support, we can't hardcode its usage in our software because one day it might disappear for whatever reason, and we will end up with the broken functionality people will be complailing about.

Also, you really try to find the solution for the problem that might not even exist.
Are you really sure this is the issue (if it frustrates you - that doesn't mean that it frustrates the majority of the current and potential new users)?

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.

I appreciate the transparency, Vitalii.

I didn't realize the client lacked a centralized data feed for work availability.

Grant, I definitely agree that we want to keep the UI clean for new users.

My concern is specifically for the 2026 hardware wave.

With high-TDP iGPUs becoming standard, the 'Empty Project' problem will only get worse as thousands of new users attach to dead projects, get zero tasks, and then uninstall BOINC in frustration.

Instead of a live status, could we simply have the Manager hide projects that have not published a verified application for the user's specific OS/Architecture in over 24 months?

That would solve 80% of the 'ghost project' issue without needing a live data feed.

Instead of a live status, could we simply have the Manager hide projects that have not published a verified application for the user's specific OS/Architecture in over 24 months?

The trouble is there are always new applications, new processors, new data types and all of these would need to be tracked - a grade one pain to keep track of. This may be the only advantage of Science United in that one signs up for an area of science rather than a specific project, and having a number of projects to get work from is far better than just relying one one.

In reply to kasdashdfjsah's message of 18 Jan 2026:

With high-TDP iGPUs becoming standard, the 'Empty Project' problem will only get worse as thousands of new users attach to dead projects, get zero tasks, and then uninstall BOINC in frustration.

It looks like you are very new to BOINC, otherwise you would know that there is no 'thousands of new users'.

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.

In reply to Vitalii Koshura's message of 19 Jan 2026:

It looks like you are very new to BOINC, otherwise you would know that there is no 'thousands of new users'.

Ha hah hah ha. LOL Good one Vitalii. Only those of us that have been around since Seti@home days remember when the daily influx of "new users" ever numbered in the thousands.

Sorting through BoincStats, it looks like only around 11400 users had given credit yesterday. (Of 4 million registered total).

Sorting through BoincStats, it looks like only around 11400 users had given credit yesterday. (Of 4 million registered total).

Here's a Link to the graphs that visualize what was mentioned.

I appreciate the reality check on the current user numbers.

Seeing only ~11,400 active users out of 4 million registered is actually the most compelling evidence for my point: we have a massive retention problem.

If we only have a few thousand active users left from the SETI days, it's because the "out of the box" experience hasn't evolved with the hardware.

Vitalii, I hear you on the technical difficulty of tracking every OS/GPU combination, but that is exactly why the 24-month "Verified App" filter is a low-maintenance middle ground.

It doesn't require a live work-check; it just checks the project’s own application list.

If a project hasn't released a macOS ARM or a Windows Intel GPU app in two years, it shouldn't be the first thing a new user sees.

To Dave and Grant’s points about "handholding"—it isn't about treating users like children; it's about respecting their time.

In the era of the M4 and Panther Lake, people expect hardware to "just work."

If a new volunteer with a high-TDP iGPU attaches to a "Zombie" project and gets nothing, they don't go to the forums to troubleshoot; they just leave.

Science United is a great backend solution, but the "Add Project" list is still the front door for most.

We shouldn't be proud that our user base isn't growing in the thousands—we should be asking what we can change to make those thousands of new hardware owners want to stay.

I’m not asking for MS Word-level bloat; I’m asking for a basic "freshness filter" so the first experience a volunteer has isn't a "Project has no work" error.

However, I would suggest that the overwhelming majority of BOINC users come to the platform not via the BOINC pages but via one of the projects. I first heard of climateprediction.net and installed BOINC to crunch for them. I only later started to crunch for other projects when no CPDN work was available. Those who come via the project route are not going to be affected by what you suggest is a problem.

End users expect things like email, web browsing and word processing along with media management to just work. Those installing BOINC on their machines are by and large a bit more savvy. Thousands signing up is only going to happen if there are projects that catch the imagination of the public to a far greater extent.

In reply to kasdashdfjsah's message of 20 Jan 2026:

If a project hasn't released a macOS ARM or a Windows Intel GPU app in two years, it shouldn't be the first thing a new user sees.

You don't understand.
Every project has a list of supported platforms (e.g. Einstein@Home.
This is the list that is maintained by the project.
The list of platforms you see here and in your BOINC Manager is taken directly from the Projects' configurations.
We do not control (and have no right to do that) what is pubslished there.
If you see that any Project has a supported application that has no jobs for months - go to the Project and complain to them.
We do not monitor this statistics.

Seeing only ~11,400 active users out of 4 million registered is actually the most compelling evidence for my point: we have a massive retention problem.

This is your experience.
You might be right, but I assume you have no proofs.
I see this differently.
Before the main driver of BOINC was SETI@home, also there were more enthusiasts that supported BOINC.
Nowadays this changed from both sides.
There are no new big Projects that appeared recently.
The main reason for that is because the computation power became cheaper and more easy-to-get.
With the big projects that stopped working wee see the userbase declining as well.
The main driver of BOINC (and I already wrote this several times during the last few years) are the Projects.
People join BOINC because they want contribute to some particular Project (so, technically they don't join BOINC in general, they join a particular Project), and later might join some other Projects as well.
Personally I joined BOINC because of SETI@home, and I believe the same as the majority of the current BOINC userbase.
It's not the icons in the BOINC Manager dialog window that scare the people, it's the lack of interesting Projects to contribute to.
We try to change the situation (see the example of BOINC Central where we have made an application that we thought would be attractive for scientists, 4 years since then - and we don't have a singl user of that application).
I could add another science application to BOINC Central but I don't know which one would be a good fit that will be attractive for scientists.
Unfortunately we (BOINC maintainers) don't have resources to do additionally the research and marketing.
If you really want to help here - do the research, ask scientists who need cmputational power about the applications they would be interested in running on BOINC.
This will be the first (but very huge step) to gain BOINC popularity again.
Of course, you might think I'm completely wrong here, and this is not the reason.
I do respect your point of view even if I don't agree with it.

---

BOINC maintainer.
For any insight, check my BOINC Development Blog.