BOINC 101: Berkeley's Volunteer Computing Projects

From SETI@home to a platform

⏱ 6 min read

In 1995, David Gedye pitched an idea to Berkeley computer scientist David P. Anderson: use the idle time of home computers to analyze radio telescope data. With Dan Werthimer and Woody Sullivan, that became SETI@home, launched in May 1999. It drew about a million volunteers within a year, far beyond anyone's plans.

SETI@home proved that volunteer computing worked. It also exposed a problem: the software was custom-built for one experiment. Every new science team that wanted the same power would have to rebuild the whole system from scratch.

Why volunteer computing works at all

Most personal computers sit idle most of the day. Even in use, they rarely run at full capacity. Volunteer computing harvests that spare capacity. It only works for certain kinds of problems: work that can be cut into many independent pieces, where each piece needs lots of calculation but little data, and where results can arrive hours or days later. Computer scientists call this "embarrassingly parallel" or high-throughput computing. Searching sky data, simulating molecules and running climate model variations all fit. Weather forecasts that must be done in an hour, or simulations where every processor talks to every other one each second, do not.

A detour, then BOINC

In 2000, Anderson became CTO of United Devices, a company building commercial distributed computing. He left in 2001 and started something different: an open-source, general-purpose platform owned by the University of California. He named it the Berkeley Open Infrastructure for Network Computing — BOINC.

Anderson wrote the first client, server and web code over late 2001 and early 2002. In summer 2002 a National Science Foundation grant came through, paying for a small team at Berkeley's Space Sciences Laboratory. BOINC is licensed under the LGPL, so any lab can run its own project for free.

The cost of switching

When SETI@home moved from its original "classic" software to BOINC, its active volunteer base dropped from roughly 600,000 to 300,000. Volunteers had to install new software and learn a new interface. It was a painful lesson in how fragile volunteer communities are — one that recurs throughout this course.

But the payoff was huge. One codebase now served projects in climate, physics, biology and mathematics. A volunteer could split their computer among several projects at once, and science teams got years of engineering for free.

"BOINC: What is Distributed Computing?" — foxtyke. A plain-language introduction to volunteer computing and BOINC projects. Open on YouTube ↗

Who runs BOINC now?

BOINC began as a Berkeley project and Anderson still leads much of the work from the Space Sciences Laboratory. Since about 2014, a Project Management Committee (PMC) of community members has shared governance: organizing workshops, managing releases and coordinating volunteer developers on GitHub. That shift matters, because BOINC now depends on a community, not only a university grant.

How BOINC works

⏱ 6 min read

BOINC splits into two halves: a client that volunteers install, and a server each project runs. They talk over ordinary web requests that the client always starts. That one design choice means BOINC works behind home routers, firewalls and proxies without special setup.

The client

The client has three parts: the core client, which does the scheduling and runs jobs; BOINC Manager, the graphical interface; and an optional screensaver. Volunteers set rules such as "only compute when idle" or "use at most 50% of CPUs." Desktop clients run on Windows, Mac and Linux. On mobile, only Android is supported, and by default phones compute only while charging and on Wi-Fi. iOS isn't supported, because Apple's App Store rules forbid downloading new executable code.

The server

A project server centers on a MySQL or MariaDB database. A scheduler answers client requests, pulling jobs from a memory cache kept full by a "feeder" process. Background programs called daemons do the rest: the transitioner tracks each job's state, validators compare results, assimilators hand finished science back to researchers, and cleanup daemons delete old files.

Apps that fit any machine

A project might ship the same science code in many builds — for Windows on Intel, Mac on Apple Silicon, Linux with an NVIDIA GPU. BOINC's plan classes match each build to the right hardware. Scientists who don't want to rewrite their code can use a wrapper to run an existing program, or package it as a VirtualBox virtual machine or Docker image. CERN's LHC@home relies on that virtual-machine route.

Being a good guest

BOINC runs on computers that belong to someone else, so it's designed to stay out of the way. Science apps run at the lowest operating-system priority, so anything the owner does takes precedence. Apps save checkpoints regularly, so a reboot or crash costs minutes of work, not hours. Downloaded app code is signed with keys kept on a computer that is never connected to the network, so even a hacked project server can't push malware to volunteers. Technically minded volunteers can also use the anonymous platform option, compiling their own optimized app versions for unusual hardware.

Scheduling: the hidden hard part

Volunteers often attach to several projects with different deadlines and hardware needs. The client juggles them with weighted round-robin scheduling — sharing time in proportion to each project's "resource share" — and switches to earliest-deadline-first when it predicts a missed deadline. On the server side, the scheduler estimates each job's runtime from the host's past speed before sending it.

Trusting untrusted computers

⏱ 6 min read

A supercomputer center controls its hardware. BOINC doesn't. Volunteer computers overheat, get overclocked, run buggy drivers or get switched off mid-job. A few volunteers even try to cheat to climb the leaderboards. So how can science trust the results?

Replication and quorum

BOINC's main answer is replication: send the same job to several unrelated computers and compare. Two settings control this. target_nresults is how many copies go out at first. min_quorum is how many successful results must come back before validation runs. A common setup sends 3 copies and needs 2 that agree.

When enough results agree, one becomes the canonical result, and the job is passed to the project's assimilator. If a copy errors out, BOINC automatically sends a replacement.

Fuzzy matching and homogeneous redundancy

Different processors can round floating-point math differently, so "identical" results may differ in the last decimal places. Projects write their own validators that allow for small differences. Where results must match bit-for-bit, homogeneous redundancy sends a job's copies only to computers in the same class — same operating system and CPU vendor, for example.

Adaptive replication

Replication is expensive: doubling every job halves the useful computing. Adaptive replication cuts that cost by tracking each host's record. A computer with a long history of valid results gets more single, unreplicated jobs, with occasional random checks to keep it honest.

Credit: the volunteer's paycheck

Volunteers earn credit for validated work — a measure of floating-point computation normalized against a reference computer. Credit isn't money, but it drives teams, leaderboards and friendly rivalry. Getting it fair across CPUs, GPUs and projects is hard, so BOINC's newer credit system adjusts each claim for how efficient that app version and host usually are. Cross-project IDs let third-party sites total a volunteer's credit across every project.

Deadlines and lost jobs

Every job also has a delay bound: a deadline after which the server assumes the copy is lost and sends a replacement elsewhere. Volunteers uninstall BOINC, laptops go on vacation and hard drives fail, so a share of all jobs never comes back. Short deadlines get answers faster but waste work from slow machines; long deadlines are gentler on volunteers but slow the science down. Each project tunes this trade-off for itself.

A job also has limits on how many errors or results it can rack up. A job that crashes on every computer is probably broken, so BOINC marks it as failed instead of sending it out forever. The assimilator logs that failure so the scientist can investigate.

Astropulse and SETI@home Beta

⏱ 6 min read

Once SETI@home ran on BOINC, Berkeley could add new applications to the same project without asking volunteers to install anything new. Two of the most important were Astropulse and SETI@home Beta.

Astropulse: listening for clicks, not whistles

Classic SETI@home searched for narrowband signals — a steady "whistle" at one frequency. Astropulse searched the same Arecibo data for the opposite: broadband, very short pulses, more like a click. It was an expansion of SETI@home, not a replacement.

Why look for pulses? A civilization might signal with short, powerful bursts rather than a continuous tone. And pulses are scientifically useful even if aliens never show up. The Astropulse team called these possible finds "silver needles": rapidly rotating pulsars, exploding primordial black holes or completely unknown astrophysical phenomena.

The dispersion problem

Space isn't empty. Free electrons between the stars slow down lower radio frequencies slightly more than higher ones, so a sharp pulse arrives smeared across time, high frequencies first. This is called dispersion. Undoing it requires testing thousands of possible amounts of smearing for every chunk of data — exactly the kind of brute-force job that volunteer computers excel at. Astropulse was active by early 2009, and its work units were famously heavy compared with classic SETI@home jobs.

GPUs change the game

Searches like Astropulse do the same arithmetic on huge blocks of data, which is exactly what graphics cards are built for. When BOINC added GPU support in the late 2000s, using NVIDIA's CUDA and later the vendor-neutral OpenCL, a single gaming PC could suddenly do the work of many ordinary computers. That forced changes throughout BOINC. The scheduler had to track GPUs as separate resources. Plan classes had to match apps to specific GPU types and driver versions. The credit system had to stop rewarding one kind of hardware unfairly over another.

SETI@home Beta: volunteers as testers

Shipping broken code to millions of computers would waste huge amounts of donated time and anger volunteers. So from 2006 until SETI@home's hibernation in March 2020, Berkeley ran SETI@home Beta, a separate BOINC project where volunteers knowingly ran new, untested app versions. Beta testers found crashes, wrong results and platform bugs before they reached the main project. GPU versions of SETI@home and Astropulse went through this pipeline.

BOINC itself uses the same idea: an alpha-test group of volunteers tries new client releases before general release. It's a reminder that volunteers contribute judgment and testing, not just CPU cycles.

The Nebula connection

Both SETI@home searches ended in 2020 when Berkeley stopped sending new work, but the results lived on. The Nebula back end, covered in the companion SETI course, processed the billions of detections that volunteers had returned.

Distributed thinking: Stardust@home, Bossa and Bolt

⏱ 6 min read

Some science problems need human eyes, not processors. Anderson called this distributed thinking: breaking a task that needs human perception or judgment into small pieces that thousands of volunteers can do in a browser.

Stardust@home

NASA's Stardust spacecraft launched in 1999, flew through the coma of comet Wild 2 in 2004, and returned its collectors to Earth on January 15, 2006. One collector, a mosaic of ultra-light aerogel tiles, had been exposed to the stream of interstellar dust passing through our solar system. Finding those grains meant searching tiny impact tracks in an enormous volume of aerogel.

Berkeley's Space Sciences Laboratory, led by Andrew Westphal, launched Stardust@home in 2006 in collaboration with Anderson's group. An automated microscope at NASA's Johnson Space Center produced nearly a million "focus movies." Volunteers, nicknamed Dusters, used a web-based virtual microscope to focus up and down through each movie and mark any tracks.

Quality control mirrored BOINC's logic. Volunteers passed training and a test first. Hidden calibration movies with known answers measured each Duster's skill, and every vote was weighted by that score.

The payoff

In August 2014, the team reported in Science that seven grains were likely interstellar dust — the first contemporary interstellar dust ever brought back to Earth for study, pending further tests. Two particles found in aerogel were named by the Dusters who discovered them: Orion and Hylabrook. Discoverers are credited as co-authors on the paper announcing their particle.

What makes a good thinking task

Stardust@home shows what good distributed-thinking design looks like. Each task is small, taking seconds to a minute. The question is narrow: is there a track here or not? Answers are checked against known examples, and several volunteers see each item, so no single mistake decides the outcome. Finally, a small group of experts reviews the top candidates, the same way SETI scientists hand-review the top computer-ranked signals. The volunteers do the bulk filtering and the specialists do the final judgment. Get any of these wrong — tasks too long, instructions too vague, no calibration — and volunteer accuracy and motivation both fall.

Bossa and Bolt

Inspired by projects like Stardust@home, Anderson built two frameworks in the late 2000s:

By Anderson's own later account, Bossa and Bolt saw little use. The idea won anyway: the Zooniverse and Foldit later made distributed thinking mainstream.

Science United: choose science, not projects

⏱ 6 min read

By the 2010s, BOINC had a discovery problem. There were dozens of projects, each with its own sign-up, website and jargon. A new volunteer had to research them all and register separately. Many never got past that step.

Account managers

BOINC's fix was the account manager: a website that registers you with projects and attaches your computers to them automatically. Third-party managers such as GridRepublic and BAM! (BOINC Account Manager) had existed for years. You still picked projects yourself, but you only managed one account.

Science United's twist

Berkeley launched Science United on December 9, 2017, with NSF funding. It's an open-source account manager with a different premise: volunteers choose science areas — such as "biology and medicine" or "astronomy" — and optionally locations, instead of picking projects. Science United then assigns their computers to vetted projects that match.

Anderson calls this the coordinated volunteer computing model. It benefits both sides. Volunteers don't need to evaluate projects. Projects, including new ones, get computing power without running their own publicity campaigns, because Science United can steer resources toward them.

Keywords under the hood

Science United's matching relies on keywords attached to projects and even to individual jobs: science area, and where the research is based. Volunteers can mark keywords "yes," "no" or "maybe." The same keyword system is built into BOINC itself, so a project hosting many research groups can route jobs by topic.

Why routing matters

In the old "pick a project" model, attention followed publicity. Famous projects like SETI@home drew huge followings, while a new project with important but obscure science could struggle to find any volunteers at all. Every project had to become its own marketing department. A coordinated model separates those jobs. Science United builds one public-facing brand, recruits volunteers broadly, and then allocates computing power according to policy and need rather than fame. Anderson's 2020 paper describes the allocation as a "linear-bounded" model that balances each project's share over time.

The trade-off for volunteers is a bit less control and a bit less connection to a single project's community and leaderboards. That's why Science United is optional: experienced volunteers can still attach to projects directly.

"David Anderson talks BOINC, Citizen Science, and Why We Still Need You" — BerkeleySETI. BOINC's creator on why volunteers still matter. Open on YouTube ↗

BOINC Central and science gateways

⏱ 6 min read

Running a BOINC project isn't trivial. A lab needs a server, a sysadmin, app builds for each platform and a volunteer community. Anderson's 2020 paper estimates a typical project costs on the order of $100,000 a year. That's far cheaper than equivalent cloud computing, but too much for a small lab with one big calculation. Berkeley's newer work aims at that gap.

BOINC Central

BOINC Central is a Berkeley-hosted project that provides computing to not-for-profit research at universities and labs, and to independent researchers. Instead of building their own server, scientists apply through an online form and run jobs on volunteers' CPUs and GPUs.

Its first hosted application is AutoDock, a widely used drug-discovery tool that simulates how small molecules dock with proteins, along with its variants. Researchers can also bring their own applications packaged as Docker containers. Volunteers can even contribute without installing BOINC, though installing it is encouraged.

Universal apps and Docker

The key enabler is what Anderson calls universal apps: instead of porting code to every operating system, a scientist packages it once as a virtual machine or Docker image, and BOINC runs it everywhere. That turns BOINC from a framework you develop for into a service you submit to.

Science gateways

Many scientists never touch a command line; they use science gateways, web portals that run simulations for them. In 2016 the NSF funded a Berkeley–Purdue effort to add volunteer computing to nanoHUB, a popular nanoscience gateway built on the HUBzero platform, alongside work with the Texas Advanced Computing Center (TACC). The idea: when a user clicks "run," the jobs could quietly flow to volunteers' computers.

"Webinar: BOINC - Volunteer Computing for Science Gateways" — Science Gateways Community. David Anderson (UC Berkeley) and Steven Clark (Purdue/nanoHUB), 2017. Open on YouTube ↗

Is your calculation BOINC-friendly?

Before applying, a researcher should check four things. The work must split into independent jobs that don't need to talk to each other. Each job should have a high ratio of computation to data: hours of crunching per few megabytes downloaded, because home internet uploads are slow. The data must be non-confidential, because it lands on strangers' machines — so patient records are out unless future secure-hardware features change that. And the deadline must be flexible, measured in days rather than minutes. Docking millions of molecules ticks every box, which is why AutoDock was the first app chosen.

An honest scorecard

Anderson's own retrospective is candid: the TACC portion stalled and nanoHUB integration never reached production. BOINC Central is the latest attempt at the same goal, with a simpler model.

The wider BOINC family

⏱ 6 min read

Most BOINC projects aren't run by Berkeley. They're run by universities and institutes around the world on Berkeley's software. Anderson worked directly with several of the earliest, including spending a month at Oxford in 2005 helping climateprediction.net. Explore the major ones below.

Einstein@Home: the discovery machine

Proposed by Bruce Allen in 2005 and run by the University of Wisconsin–Milwaukee and the Max Planck Institute for Gravitational Physics, Einstein@Home searches data from gravitational-wave detectors, radio telescopes and NASA's Fermi gamma-ray telescope. In August 2010, it announced its first discovery: pulsar PSR J2007+2722, found in Arecibo data on computers belonging to Chris and Helen Colvin of Ames, Iowa, and Daniel Gebhardt in Mainz, Germany. The paper in Science was titled "Pulsar Discovery by Global Volunteer Computing." By 2018 the project had found more than 70 neutron stars.

Big projects, big institutions

World Community Grid launched in 2004 under IBM and hosted humanitarian projects such as FightAIDS@Home and, from 2020, OpenPandemics – COVID-19 with Scripps Research. In September 2021, IBM transferred it to the Krembil Research Institute in Toronto. LHC@home at CERN uses BOINC's virtual-machine support to simulate particle-accelerator physics. Rosetta@home at the University of Washington predicts and designs protein structures.

Umbrella projects versus single-science projects

The BOINC family comes in two shapes. Single-science projects like Einstein@Home or MilkyWay@home belong to one research group with one long-running goal. They build deep volunteer communities and specialized apps, often heavily optimized for GPUs. Umbrella projects like World Community Grid host many research teams under one brand, rotating campaigns as studies finish. Umbrellas give smaller research groups access to a large volunteer base without running infrastructure — the same goal BOINC Central now pursues for independent researchers. Science United sits a level above both, routing volunteers across whole projects.

What the family shares

Whatever their science, these projects inherit the same Berkeley machinery: client-initiated requests, replication and validation, credit, teams and forums. That shared core is why a volunteer can attach one computer to Einstein@Home, Rosetta@home and climateprediction.net at once, and why third-party sites can total a volunteer's credit across all of them. It's also why the BOINC workshops, which began in 2005 and have since met in cities including Geneva, Barcelona, Hanover, Budapest and Paris, matter: projects share lessons on validation, GPUs and volunteer engagement that flow back into the common code.

Projects end

Not every project lasts. SETI@home stopped sending work in 2020; Cosmology@Home, run from the Institut d'Astrophysique de Paris, completed in January 2024. Ending is normal: many projects are funded for a fixed scientific goal.

The state of volunteer computing

⏱ 6 min read

How big is BOINC today? Anderson's 2020 paper in the Journal of Grid Computing gave a snapshot: about 30 projects and roughly 700,000 active devices, with around 4 million CPU cores and 560,000 GPUs. Together they averaged about 93 petaFLOPS — comparable to the world's top supercomputers at the time. The largest projects, such as Einstein@Home and Rosetta@home, each averaged around 2 petaFLOPS.

The volunteer problem

The same paper is blunt: the volunteer population has gradually declined. SETI@home had about a million volunteers around 1999–2001; BOINC as a whole had roughly 200,000 to 300,000 by the late 2010s. Branded campaigns didn't produce lasting growth, and a 2012 deal to pre-install BOINC on HTC phones collapsed weeks before launch. Laptops replacing desktops, energy costs and competition from other causes all play a part.

Cheaper than the cloud

The economic case remains strong. Anderson's 2020 paper estimates a typical BOINC project costs on the order of $100,000 a year, mostly for staff and a server. Renting the same sustained petaFLOPS from a commercial cloud provider would cost many times more. The volunteers absorb the hardware and electricity costs, which is precisely why their goodwill is the system's most valuable and most fragile asset.

Volunteer computing also counts in scientific output. Anderson's own retrospective says BOINC projects have run on millions of computers and contributed to more than 1,000 papers. That record spans astrophysics, biology, climate, mathematics and physics.

Still shipping

BOINC isn't frozen. The 8.x client line has continued through 2024 and 2025 for Windows, Mac, Linux and Android, maintained by volunteer developers on GitHub. Anderson's list of future directions includes running jobs inside secure hardware enclaves to reduce the need for replication, deeper Docker support, using GPUs on phones, and tighter links with university computing systems such as HTCondor.

Getting involved

For anyone who wants to help — or recommend BOINC to a classroom or club — the path is short. Build a starting setup below.

Test yourself (10 questions)

⏱ ~6 min

Glossary

BOINC

Berkeley Open Infrastructure for Network Computing — UC Berkeley's open-source platform for volunteer computing, started in 2002.

Volunteer computing

Using computing power donated by the public, usually idle time on home devices, for research.

Distributed thinking

Splitting tasks that need human perception or judgment into small pieces for many volunteers.

Work unit / job

A chunk of computation sent to a volunteer's computer; each job may have several replicated instances.

Plan class

A rule that matches an app build to the right hardware, such as a specific GPU type.

Wrapper

A BOINC tool that runs an existing program without rewriting it for BOINC's API.

Replication

Sending the same job to multiple computers to check results against each other.

Minimum quorum

The number of successful results needed before validation runs.

Canonical result

The validated result chosen as correct for a job.

Homogeneous redundancy

Sending a job's copies only to computers of the same class so results match exactly.

Adaptive replication

Replicating less often for hosts with a strong record of valid results.

Credit

A normalized measure of validated computation used for leaderboards and teams.

Account manager

A website that attaches a volunteer's computers to projects automatically, such as Science United.

Dispersion

The smearing of a radio pulse in time by interstellar electrons, which Astropulse had to undo.

Sources

• Anderson — "BOINC: A Platform for Volunteer Computing," Journal of Grid Computing 18 (2020)
• Anderson — "BOINC in Retrospect" (personal history of BOINC)
• David P. Anderson — Wikipedia
• BOINC Wiki — Job replication and validation
• Astropulse FAQ — SETI@home, UC Berkeley
• About Stardust@home — UC Berkeley Space Sciences Laboratory
• ScienceDaily — Stardust grains likely visitors from interstellar space (Aug 2014)
• Science United — HandWiki
• Computing with BOINC Central — UC Berkeley
• Phys.org — Einstein@Home citizen scientists discover a new pulsar (Aug 2010)
• World Community Grid — Wikipedia
• List of volunteer computing projects — Wikipedia

All consulted November 2026. Platform statistics come from Anderson (2020) and may have changed; check project sites for current status.