# Announcing the modular registry

Eliot Horowitz  
CEO & Founder

Starting today, it is **easier than ever to extend Viam with the launch of the modular registry**. Because we cannot foresee every new piece of hardware, algorithm, or service our users will need, Viam is designed as an extensible platform, with an **open source community** such that our users, developers, can build what they want. With the registry, **adding new functionality to Viam is easy**, without esoteric things to learn; it becomes a **simple coding exercise** with great tooling, making it **easy to publish, share, and use a rich ecosystem of modules**.

Viam’s goal is to be the **platform for all smart machines**. To define that clearly let’s clarify that a smart machine is a machine or device that: _lives in_ the real world; has some ability to _perceive_ the world (simple sensor, camera, anything); perhaps _does something to_ the world (motor, to a full robot), and that _might need some interaction_ with other systems, the cloud, or users.

Considered in those terms, even if they don’t meet every one of those criteria yet, a huge variety of machines might be thought of as smart, from **household devices like thermostats and coffeemakers** to **industrial machinery like assembly line robots and autonomous vehicle** s. So we’ve given ourselves a massive mandate. And we’ve defined potentially smart machines in that way because **we’re surrounded by devices that have more compute power than the Apollo spacecraft**, but are also far too often surprised by their lack of “smartness.” The **technology has not been available to quickly and easily transform a machine from being sort of useful, to fully ‘smart’** in the way I’ve defined above. And that’s been a massive problem.

Our belief is that the world has a lot of real **problems that we think automation and machinery are the best solutions for**, whether it be **climate change, cleaning oceans, or cleaning up after the kids**. But **we need smarter machines** and we need them urgently to address these kinds of challenges. In order to have any chance at solving the biggest real world problems we face, we need a much **larger ecosystem of developers working together**, solving those problems, and implementing new solutions.

For that ecosystem of developers to expand to meet the breadth of the challenges, Viam has to be **incredibly easy for every developer to extend and work with**. And that is why we believe **the registry we’re launching today** is such a significant step into a more hopeful future.

## How the modular registry Works

To get a sense of how the registry works it’s good to keep in mind that the core building blocks of any machine are **components and services**:

Components are generally **mapped to physical things**, and there are a number of types of components: **cameras, motors, sensors, and GPS chips** for example. For each component type, there are different models: for cameras for instance, there are drivers for webcams, Intel RealSense, OAK-D, etc…

Services are **software services, algorithms, state management,** and the like. As with components, there are different types of services: **SLAM, motion, navigation, computer vision**, and so forth. And for each service type, there are different implementations: Cartographer and ORB-SLAM for SLAM, for example.

For both components and services, **the registry provides a number of opinionated APIs**, but also some **generic fallbacks** if you need something that doesn’t quite fit. Some of these implementations are built into the core viam-server, but most are built as modules. These **modules can be written in almost any language** (Python, C++, Go, Rust, etc…) and since they are built on top of consistent APIs they can be **plugged into any Viam deployment**.

So if you need to support a **new type of hardware**, you can now **just write a driver**. I’ve personally done this for RTSP cameras, a certain marine motor, and a kinematic model for boats.

By the same token, if you need a **new type of state management**, now you can **simply write a service**. I recently did this for a [sprinkler](https://github.com/erh/sprinkler) system I’ve deployed at home that I’ll blog about in a week or so, but the salient point is that the registry makes it not only **easy to write these sorts of modules**, it also makes it incredibly **easy to deploy, share, and use them**.

**Anyone can publish a module** to the registry, either manually or via continuous integration. These modules can be private to your organization, or public to everyone. Once a module is in the registry, **adding it to any machine’s configuration is done with a few clicks**. You can control the module version and upgrade policy. Module upgrades are deployed automatically to your machine. You can do this per machine, or for a fleet using fragments.

## Additional modular registry Use Cases

Being able to develop and deploy new components and services like this is only the first of the registry's use cases. The same system can also be used to **deploy anything to any existing machine**. If you’ve got an existing fleet deployed, you can **deploy your code or content using the registry** as well.

There are two additional use cases the registry will support in the near future. The first is **custom APIs**. We already have a way to flexibly do whatever you need with generic methods, but we’ll soon **let people publish APIs** that they can implement, or others can implement, giving you more options for full abstractions.

Also coming soon is the **ability to charge for modules you publish**. Currently modules can be open or closed source, but with the ability to charge, it means you can write a module, publish it to the registry, and then **flexibly charge users** of that module in Viam. So new companies can **focus on building key algorithms and services** for machines, and **not on distribution and billing**.

The registry is a powerful resource for developers working on **any hardware-plus-software project**. It keeps the kind of **composability and extensibility** we expect in a software project and brings it to everything from the **hardware component level** all the way through to the **data back end**. It’s a concept and a resource that has been **missing from the stack**, and has been preventing so many important machines from becoming as smart, as versatile and as useful as they need to be. With the introduction of the registry today we hope Viam will be **empowering a generation of developers** to focus their full talents to bear on some of the world’s most important challenges, by making it far easier to **build, configure, test, and deploy the smart machines** we need in the real world.

**For more information** about Viam’s Modular Registry feature, please see the **following resources**:

- [Viam’s product website on modularity features](/content//product/modularity/index.html)
- [The Modular Registry](http://app.viam.com/registry)
- [Viam’s documentation on the modular registry](https://docs.viam.com/extend/modular-resources/)