OpenCompute: a documentation stub for Nebulai's distributed compute network

The repository you clone is two files

This is the first thing to establish, because the repository name suggests otherwise. The OpenCompute repository contains a `README.md` and an `img/` directory holding the logo. That is the entire tree. There is no source directory, no package manifest, no build file, and no license file.

The repository has 2,364 stars and 78 forks, which is a substantial following for a repository with no code. The stars are best read as interest in the idea rather than adoption of a library, because there is nothing here to depend on. GitHub reports seven open issues and a last push on 2026-08-12, so the repository is not abandoned; the README simply is not the place where the implementation lives.

The metadata is also unusually sparse in ways that matter. No programming language is reported and no license is declared. For a project inviting outside parties to contribute compute to a network, the absence of a license file is the kind of detail you would want resolved before running anything on your own hardware, since without a license the default is exclusive copyright.

Workers in a browser, users through a Python SDK

The architecture the README describes has two halves. On the supply side, workers contribute computing power, and the README's claim is that this happens simply by opening a browser with no installation required. On the demand side, users reach global compute resources through a lightweight Python SDK, without managing any backend.

The browser claim is the ambitious part, and it implies the work is executed somewhere other than the contributor's machine, most likely in a sandboxed environment on the network's own infrastructure. That is a meaningfully different arrangement from the typical distributed compute project where volunteers install a client on their own machine and donate idle CPU. It removes the install barrier, which is the main reason people never join those networks, and it moves the trust question somewhere else: whoever runs the execution environment sees the workload.

The user side being a Python SDK with no backend to manage means the task submission path is code, not a dashboard. That fits a workload oriented developer audience rather than a consumer one. The repository description itself calls these depin computing services, which places the project in the decentralized infrastructure category alongside the compute and storage networks that trade central ownership for open participation.

Where the code actually lives

The README answers this directly in a section announcing that the current release is now open source, and that two components have been released: an OpenCompute User Module, described as the client interface for submitting and managing compute tasks, and an OpenCompute Worker Module, described as the execution node responsible for running compute workloads.

Both are separate repositories under the same organization, linked from this README: `NebulaiNetwork/OpenCompute_User` and `NebulaiNetwork/OpenCompute_Worker`. That split is the interesting architectural decision visible from here. Client and node have genuinely different dependencies and security postures, and separating them means a contributor can work on the submission interface without any relation to the sandboxing and isolation code. It also means the two sides can version independently.

The consequence for a reader is that everything worth evaluating lives one repository over. Any question about the SDK's API surface, the worker's isolation model, or how work is verified has to be answered there. The same README also links the project website at nebulai.network, which is the other place to look.

An MVP notice and a release named verifier

Two signals in the record say the same thing, and it is worth quoting them rather than smoothing them over.

The first is the notice at the bottom of the README, which states plainly that OpenCompute remains under active development and that the current version reflects an MVP and may differ from future stable releases. An MVP label from a project whose user base would include people running code and donating hardware is a meaningful caveat, because it means interface changes can break a submitted workload.

The second is the release history, which has exactly one entry: v1.0.0, published 2025-08-27, titled `verifier`, with an empty body. A v1.0.0 tag on a project whose README calls itself an MVP is a contradiction worth naming rather than resolving. Both facts hold. The tag may refer to a verifier component rather than the whole network, or the version number may simply have been chosen early. Either way, do not read `v1.0.0` as a statement of API stability, because the README states the opposite about the same software.

The website is the actual documentation

The README is short, and there is no docs directory, no example directory and no contributing guide to make up for it. Every path out of it leads somewhere else: the two module repositories, the website, and a logo.

That is not unusual for a project that treats its repository as a signpost, but it does mean the usual evaluation method, clone it and see what happens, does not apply. There is nothing to run here. What you can do instead is read the two module repositories for the shape of the SDK and the worker, check whether the worker module's isolation story holds up, and look at the seven open issues to see whether other people are asking the questions you would have asked.

For a project in this category, the questions that decide whether it is worth your time are about economics and verification rather than code quality: how work is priced, how a submitted task is checked for completion, what happens when a worker claims credit it did not earn, and how you withdraw. None of those are answered here. The `verifier` release title suggests verification is a named component of the system, which makes the module repositories the right place to start looking for it.

Editorial conclusion

Judge this repository for what it is: a landing page with a project description, not a codebase you can clone and run. The architecture it describes, a user module that submits tasks, a worker module that executes them, and a Python SDK on the user side, is coherent and the split into two repositories is a sensible way to keep client and node code separate. What the README does not give you is any of it. Start at the two linked module repositories and the linked website, and read the MVP notice as a statement that the interface may still change underneath you.

Frequently asked questions

Official sources

1. Issues
2. NebulaiNetwork/OpenCompute on GitHub
3. README
4. Releases