# BOINC: the volunteer computing platform behind SETI@home and hundreds of science projects

> BOINC is a C++ platform for volunteer computing: a client that runs on donor machines, a server stack that schedules work, and an app framework for scientists. It is maintained by UC Berkeley and the last push to the repository was on 2026-09-27.

**BOINC/boinc** — Open-source software for volunteer computing and grid computing.

- Repository: https://github.com/BOINC/boinc
- Website: https://boinc.berkeley.edu
- Stars: 2,476 · Forks: 525
- Language: C++
- License: LGPL-3.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/boinc-boinc

## What BOINC solves, and for whom

The README calls BOINC a software platform for volunteer computing, described as large-scale distributed high-throughput computing using volunteered home computers and other resources. That sentence contains both halves of the product. The first half is a client that a donor installs so their machine can run scientific work in the background. The second half is a server side that a research group runs to hand out work, collect results and credit participants.

The audience is therefore split. Donors go to the BOINC web site rather than the repository. Scientists and infrastructure engineers come here, because the repository holds the client, the manager GUI, the server, the database schema and the application programming interfaces needed to attach a new project. The topics list confirms the scope: distributed computing, grid computing, high-throughput computing, citizen science, with Android, C++, Java, Kotlin and PHP all present in the tree.

The repository is not archived, and the last push was on 2026-09-27, so the codebase is being changed. That is a statement about commit activity, not about how many projects are running or how many volunteers are attached. Those numbers are not documented here.

## How the client, server and application layers fit together

The top-level layout shows the split directly. client/, clientgui/, clientscr/, clienttray/ and clientsetup/ hold the daemon, the manager, the screen saver, the tray icon and the installer. db/ holds the database side. api/ holds interfaces used by both sides. apps/ and samples/ hold application examples and wrappers. html/ and locale/ hold the web and translation material.

On the donor side, the client is the process that talks to projects, downloads workunits, starts application processes and reports results. The manager GUI is a separate program that reads and writes the client's state. The samples directory includes client_state_save.xml, which is the shape of that persisted state, so the client keeps its project list and task list on disk between runs.

On the server side, a project runs a scheduler that matches volunteers to workunits, a database that tracks them, and a set of daemons that validate returned results and grant credit. Scientists do not write to that layer. They write an application and a wrapper, and the samples directory shows the range of ways to do it: wrapper for ordinary executables, vboxwrapper and vm_wrapper for virtual machine jobs, docker_wrapper for containers, wsl_wrapper for Windows Subsystem for Linux, and separate samples for CUDA, OpenCL and multi-threaded applications. The docker_wrapper even has its own release line, 22, dated 2026-05-22, which tells you containerised jobs are treated as a first-class execution mode rather than an experiment.

The design consequence is that a project can accept almost any Linux binary, which is why the platform has survived so long. It is also why the server side carries more operational weight than a typical job runner.

## Installing BOINC on Linux and attaching to a project

For donors, the README does not walk through installation. It points to the BOINC web site and to the wiki, and the repository contains an INSTALL file at the top level. The client release line is at 8.2.15, dated 2026-06-15.

For a server deployment the path is heavier. The repository ships _autosetup and configure.ac, and the INSTALL file is the document to read, together with the server release notes for 1.6.2, dated 2026-06-12. The README does not describe the server install sequence, so treat the wiki as the authoritative source rather than guessing from the directory names.

Once a client is running, the manager is the graphical entry point. On a headless machine the same client is driven through the command-line control program built from the clientctrl/ directory. BOINC does not decide what to run; you point it at a project URL and it fetches that project's configuration, then downloads an application for your platform and a first batch of workunits. You should see tasks appear in the manager's task list with a status that moves from downloaded to running to ready to report. The account key needed to attach is issued by the project when you register, not by BOINC itself.

## Where BOINC is the wrong tool

Volunteer computing trades control for capacity. A project cannot promise that a workunit returns in an hour, because the machine running it belongs to someone who may shut it down, unplug it or lose interest. If your workload has a deadline, a dependency chain, or a result that another job waits on, BOINC is the wrong scheduler. A cluster queue or a cloud batch service gives you the guarantee BOINC deliberately does not.

Redundant computing is the second constraint. Because donated hardware is untrusted and unreliable, projects typically send the same workunit to more than one host and compare results. The samples directory reflects that world: there is a sleeper sample for testing scheduling behaviour and a sporadic sample, which suggests work patterns that arrive irregularly rather than in a steady stream. If your computation cannot be split into independent pieces, or cannot tolerate being run twice, the model does not fit.

There is also a contribution boundary that surprises people. The README states that The University of California holds the copyright on all BOINC source code, and that by submitting contributions you irrevocably assign all right, title and interest, including copyright, to The Regents of the University of California. That is a real condition on contributing to the platform, and it is not the same as the licence under which the code is distributed.

Finally, the README asks AI assistants and people using them to read the BOINC AI Assistants Usage Policy wiki page before contributing. If you generate patches with a coding assistant, that page is part of your workflow, not an optional read.

## Alternatives and how they differ

The closest conceptual alternative is a general-purpose distributed job framework such as a batch scheduler on hardware you own. The difference is who supplies the machines. BOINC assumes the compute is donated and therefore untrusted, heterogeneous and intermittent; a batch scheduler assumes the nodes are yours, known and reachable. That assumption cascades: BOINC needs credit accounting, host records and result validation because donors must be recognised and results must be checked, while an internal scheduler can skip all three.

A second alternative, visible inside the repository itself, is the execution wrapper. If your goal is only to run a containerised or virtualised job on remote machines you control, the docker_wrapper and vboxwrapper samples show that BOINC's own answer is to wrap the workload rather than rewrite it. The wrapper approach is also what makes BOINC attractive to scientists: the samples include example_app, wrapper, wrappture, nvcuda and openclapp, so an existing binary can often be adapted instead of reimplemented.

A third comparison is against the donation side. If you are an individual who wants to give CPU time and nothing more, the client alone is the whole product, and the server, database and scheduler directories are irrelevant to you. Reading them will not improve your experience; the web site and the manager are the right entry points.

## Maintenance, releases and licence

The repository is not archived and the last push was on 2026-09-27, so changes are landing. Release naming is worth understanding before you plan an upgrade, because client and server move on separate tracks. The most recent client release listed is 8.2.15, dated 2026-06-15. The most recent server release is 1.6.2, dated 2026-06-12. The docker_wrapper has its own line at 22, dated 2026-05-22. A project therefore upgrades three things independently, and a client version number tells you nothing about the server version you are running against.

The repository carries a long tail of checkin_notes files running from 2002 through 2012, plus checkin_notes_samples. That history is useful for archaeology but it is not a changelog for current releases. For upgrade planning, the server and client release notes are the relevant documents, and the README does not document rollback, so you should confirm the downgrade path for your database before applying a server release.

On licensing, the README states that BOINC is free software under the GNU Lesser General Public License, version 3 or later, and the tree contains both COPYING and COPYING.LESSER. Two separate documents also sit at the top level: COPYRIGHT, covering the University of California's ownership, and the contribution assignment described in the README. The LGPL governs redistribution of the code. It does not change the copyright assignment required to contribute. If you plan to modify BOINC and ship it inside a product, read COPYING.LESSER and COPYRIGHT together, and take your own advice on the obligations that follow.

## Conclusion

BOINC fits two audiences. Donors who want to contribute idle CPU and GPU time to research, and research groups that need a scheduling server, workunit database and application framework without building one. It does not fit teams that need guaranteed, low-latency capacity, since results arrive only when volunteers run them, and it does not fit anyone unwilling to accept the copyright assignment the README requires for code contributions. Before adopting it on the server side, read the INSTALL file and the server release notes for 1.6.2, confirm which database backend your deployment targets, and check the wiki page for the version you intend to run, because the README itself does not document rollback or upgrade paths.

## FAQ

### Is BOINC still active?

The repository is not archived, and the last push was on 2026-09-27. Recent releases include client 8.2.15 on 2026-06-15 and server 1.6.2 on 2026-06-12.

### What is BOINC used for?

The README describes it as a software platform for volunteer computing, meaning large-scale distributed high-throughput computing using volunteered home computers and other resources. In practice that means donated machines run scientific applications and report results back to a project server.

### Why is BOINC on my computer?

BOINC runs as a client that executes workunits in the background for projects you have attached to, and it keeps its project and task state on disk, as shown by samples/client_state_save.xml. If you did not install it, someone with access to the machine did, since attaching to a project requires an account key issued by that project.

### How do I install BOINC on Linux?

The README does not give install steps; it points to the BOINC web site and the wiki, and the repository carries an INSTALL file. For server deployments, read INSTALL and the server release notes rather than inferring steps from the directory layout.

### Is BOINC legit?

BOINC is developed at the University of California, Berkeley, and the README states it is free software under the GNU Lesser General Public License, version 3 or later. The web site at boinc.berkeley.edu is the official place to donate computing power or find projects.

### Is BOINC down?

The repository shows no sign of being down: it is not archived and the last push was on 2026-09-27, with client 8.2.15 released on 2026-06-15. Availability of individual science projects is a separate matter and is not documented in the repository.

## Sources

- [BOINC/boinc on GitHub](https://github.com/BOINC/boinc)
- [License: LGPL-3.0](https://github.com/BOINC/boinc/blob/master/LICENSE)
- [Project website](https://boinc.berkeley.edu)
- [README](https://github.com/BOINC/boinc/blob/master/README.md)
- [Releases](https://github.com/BOINC/boinc/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/boinc-boinc