Open Source Robotics: What’s Open on Viam and Why It Matters

Viam’s rule is simple: the software that runs on your machine is open source, and the cloud services for managing many machines are the commercial product. That rule answers the three questions every engineer evaluating a robotics platform eventually asks. What runs on my robot? Can I see it? What happens to my code if I stop paying?

Here is what the rule means technically when you build on Viam, and why robotics in particular needs it.

The philosophy: open on the machine, commercial in the cloud

The software that runs on your machine and controls your hardware is open source. The cloud services that help you manage many machines are the commercial product.

The line sits there for a reason. Code on the machine decides what a physical system does: how an arm moves, when it stops, what it refuses to do. Engineers should be able to read that code, build it themselves, and keep running it no matter what happens to any vendor, Viam included. The cloud side is different. Connectivity, storage, compute, and fleet operations cost money no matter who provides them. Viam charges for making those things easier, not for access to your own robot.

What’s open source in the Viam platform

viam-server. This is the runtime on your machine, licensed under AGPL-3.0. You can clone the repo, build it from source with make server, and run it against a local JSON config file. The repo ships a sample config with fake components (go run ./web/cmd/server -config etc/configs/fake.json), so you can try it on a laptop with no hardware attached.

The APIs. Public protobuf files define every component and service API, served over gRPC. An arm, camera, or gripper exposes the same interface regardless of who manufactured it. The API definitions are public and Apache 2.0, so the contract is the contract: there’s no guessing what a call does.

The SDKs. Viam’s Python, TypeScript, Flutter and C++ SDKs are open source under Apache 2.0. The Go SDK ships inside the viam-server repository, so it is AGPL-3.0 like the runtime. All of them are clients for those gRPC APIs. Your application can run on the machine, on another computer on the network, or in the cloud, and talks to viam-server the same way in each case.

Modules. Drivers, vision models, and task logic are packaged as modules, built by Viam and by the community. A module runs as its own process and talks to viam-server over the API. That separation matters: your module is your code. You choose whether to publish it to the Registry publicly, share it privately within your organization, or keep it entirely to yourself.

The Viam app and the cloud services behind it are not open source. That includes remote configuration, fleet management, data sync and storage, model training, staged rollouts, and teleoperation over the internet. All of it is optional: a machine running viam-server with a local config works without them.

Why open source matters for robotics

Plenty of software categories are fine with closed tools. Robotics has three properties that make open source more than a preference.

1. Safety has to be verifiable.

On Viam, limits live in the layer below the application. When a move is planned through the motion service, viam-server checks it against the declared obstacles and refuses paths that violate them. If the caller’s connection drops, its session lapses and the actuators it was driving stop. Your code, or an agent writing code for you, proposes moves; the runtime decides whether a planned move is allowed.

That design only earns trust if you can check it. With a closed runtime, “the arm refuses unsafe paths” is a vendor claim. With an open one, you can read the motion planning code, read the disconnect behavior, and run the tests. When a safety reviewer asks how your system prevents a collision, you can show them the source.

This matters more every month. Engineers increasingly use coding agents to write robot behavior. An agent can write bad code. Route its actuation through the motion service and scope its key to what it needs, and it cannot bypass the planner; and because the runtime is open, you can read the source and confirm exactly what that guarantee covers.

2. Robots outlive vendors.

A deployed robot can run for a decade. Robotics teams have watched controller vendors change terms, end support for a model, or disappear, leaving working hardware stranded behind closed software.

Because viam-server is open source and runs on your hardware, that risk doesn’t apply to the layer controlling your machines. The AGPL-3.0 license is a deliberate choice: if someone modifies viam-server and distributes it or offers it over a network, they have to share those changes. Improvements to the runtime stay available to everyone running it.

3. Hardware diversity is the core problem.

Robotics doesn’t lack hardware. It lacks interoperability. Every vendor ships its own drivers, data formats, and control software, and every team integrating them repeats the same work.

Open, standard APIs are how that work stops repeating. When one team writes a module for a new lidar or arm against the public API, the next team installs it instead of writing it again. Code written against the arm API runs on another vendor’s arm unchanged, because both implement the same contract. That kind of shared ecosystem only works when the foundation is inspectable and nobody controls the gate.

How open source changes the way you build robots

You can debug all the way down. When a call behaves in a way you don’t expect, you don’t file a ticket and wait. Open the source for that component or service and read what it does. The coding agent you’re working with can read it too, which means it reasons about the actual implementation instead of guessing from the docs.

You can test independently. Build viam-server locally, point it at a config file, and run your application against fake or simulated components in CI. Your test pipeline doesn’t depend on Viam’s cloud being reachable.

You can extend instead of waiting. If the hardware you need isn’t supported, write a module against the public API. No permission or partnership agreement is required to make a new arm or sensor work on Viam.

You keep what you build. Your application code and modules are yours. They run against an open runtime and a public API, so the work you put into a robot doesn’t become stranded if plans change, yours or Viam’s.

Opening the layer that touches the machine is what makes building a robot feel like building any other software system.

See for yourself

The best way to evaluate Viam’s open source position is to read the code. Viam’s repositories are on GitHub at github.com/viamrobotics. Build viam-server, run it against the sample config, and read how the motion service handles obstacles in the motionplan package.

To start building right away, take a free course at viam.com/education. You can begin in simulation, then take the same code to real hardware.