"MicroDuck is open source."

That sounds straightforward.

It is also not a very useful description on its own.

Open source can mean:

  • the application is open
  • the SDK is open
  • the robot's runtime is open
  • the training environment is open
  • the trained models are open
  • the hardware design is open
  • the whole product can be reproduced
  • the community can modify and redistribute everything

Those are very different things.

MicroDuck is genuinely open in some important ways.

But it is more useful to look at exactly which layers are open rather than stopping at the label.

The Short Answer

MicroDuck's software stack is substantially open.

Pollen publishes the main robot runtime, the reinforcement-learning training environment, simulation tooling, documentation, and the policies used by the robot.

The main MicroDuck repository is public and contains the onboard software that runs the robot.

The separate microduck_rl repository contains the reinforcement-learning environments and training workflow used to produce the physical behaviors.

Both repositories use Apache-2.0 licensing for their software, while the RL repository also notes separate licensing for its 3D model files.

So this is not an "open source marketing page with a small SDK attached."

There is a real software stack available to inspect, build, modify, and experiment with.

But that still does not mean every part of MicroDuck is open in exactly the same way.

That distinction matters.

What Is Actually Open?

The easiest way to understand MicroDuck is to split it into layers.

Layer 1: The Robot Runtime

The main MicroDuck repository is not just a tiny example SDK.

Pollen describes it as the robot's "brain."

It contains the onboard runtime and the services that make the physical robot operate.

The repository includes components for:

  • robot control
  • motor communication
  • configuration
  • Bluetooth
  • gamepad input
  • camera streaming
  • depth sensing
  • updates
  • logging
  • command-line control

The runtime is written primarily in Rust and organized as a workspace.

That means the software controlling the physical robot is available for developers to inspect rather than being treated as a completely private black box.

This is a meaningful level of openness.

You are not merely getting:

"Here is an API that sends commands to our robot."

You can actually see much of the software underneath that API.

Layer 2: The Training Stack

The runtime is only half of the interesting part.

The robot's learned behaviors are trained separately.

Pollen's microduck_rl repository contains the reinforcement-learning environments used to train MicroDuck policies.

The current stack uses MuJoCo-based simulation and PPO.

The policies are trained at 50 Hz, exported to ONNX, and then loaded by the runtime running on the physical robot.

That creates a complete path:

simulation
    ↓
reinforcement learning
    ↓
policy
    ↓
ONNX export
    ↓
robot runtime
    ↓
physical behavior

That is much more interesting than simply publishing the final model files.

It gives developers access to the machinery that produced the behavior.

Layer 3: The Simulation

The simulation is another important part of the open stack.

Pollen's simulation documentation describes a virtual MicroDuck driven by the same major daemons and interfaces used by the physical robot.

The goal is not simply to draw a duck that looks like the real robot.

The simulation is designed so that software above the hardware boundary can interact with a simulated body using the same control concepts as a physical robot.

That includes:

  • control
  • policies
  • safety
  • fall detection
  • kinematics
  • odometry
  • IPC
  • robot commands

The physical hardware is replaced by a MuJoCo model.

The surrounding software remains much closer to the real system.

This matters because it makes the robot significantly easier to experiment with.

You do not necessarily need to put the physical machine through every experiment first.

You can build and test against a simulated robot.

The Simulation Is Not a Perfect Copy

This is an important boundary.

A simulator is still a model.

Pollen's own documentation explicitly identifies hardware components that are not represented in the simulation, including things such as:

  • the Dynamixel bus
  • BLE radio
  • camera ISP
  • NPU
  • hardware video encoder

That means simulation cannot tell you everything about physical MicroDuck behavior.

A policy can look correct in simulation and still encounter a hardware-specific problem on the real robot.

That is the same fundamental challenge behind sim-to-real robotics.

So the openness of the simulator is valuable.

But it does not remove the gap between software and reality.

Layer 4: The Policies

The trained policies are another interesting part.

Pollen's documentation says the seven shipped behaviors are published as retrainable policies.

The RL repository contains the environments and training configuration used to produce those policies.

That changes the meaning of "seven behaviors."

A closed robot might give you:

seven behaviors, permanently defined by the manufacturer.

MicroDuck gives you something closer to:

seven shipped behaviors plus the machinery needed to investigate how those behaviors were trained and potentially create others.

That is a much stronger platform proposition.

It also means that the behavior layer is not necessarily the permanent limit of the hardware.

What Can You Actually Change?

This is where the question becomes useful for someone considering MicroDuck.

You can inspect the runtime

You can read the code responsible for the robot's services and interfaces.

You can understand how different components communicate.

You can inspect the commands available through the robot's control interfaces.

The repository documents the design rather than hiding all the interesting parts behind a proprietary API.

You can build software changes

The project supports local development, branch builds, development boards, release candidates, and installing development builds onto robots.

The project documentation even describes a workflow for pushing a branch build to a robot over SSH.

That means the repository is not merely there for browsing.

It is structured to support actual development.

You can run the simulated robot

The simulation tooling lets you run the robot's software against a MuJoCo body.

That gives developers a way to experiment without having to physically move the robot for every iteration.

You can work with the training stack

The RL repository gives access to the training environments and the simulation-side machinery used to produce physical behavior.

This is where MicroDuck moves from:

"open robot software"

toward:

"open physical-AI development platform."

What You Cannot Infer From "Open Source"

This is where I think many MicroDuck discussions go too far.

Seeing two GitHub repositories does not mean:

"Everything is open."

It does not automatically mean:

"I can reproduce the entire commercial product from source."

It does not mean:

"Every piece of hardware is open."

It does not mean:

"Every component has the same license."

And it does not mean:

"Anyone can modify everything without restrictions."

The repositories themselves are more precise than the marketing phrase.

That is what you should actually read.

Software Licensing Is Part of the Story

The main MicroDuck software repository uses the Apache-2.0 license.

The reinforcement-learning repository is also licensed under Apache-2.0.

That is a meaningful choice because Apache-2.0 is a permissive open-source license that allows broad use, modification, and redistribution subject to its terms.

But the RL repository separately notes that its 3D model files are licensed under CC BY-SA-NC.

That is a good example of why saying:

"The whole thing is Apache-2.0"

would be inaccurate.

Different assets can have different licenses.

So if you are planning to build commercial software or redistribute modified assets, you need to check the actual license attached to the specific material you are using.

Open Hardware Is a Separate Question

This is another area where I would be careful with terminology.

An open-source software repository does not automatically make the hardware open source.

MicroDuck's software repositories give you a substantial amount of software and training infrastructure.

That does not by itself establish that every mechanical drawing, electronics design, manufacturing specification, or physical component is released under an open hardware license.

So I would describe MicroDuck as:

an open-source physical AI software platform running on a commercially produced robot

rather than casually calling every layer of the product "open source."

That distinction is more accurate.

The Most Interesting Part: Same Hardware, Different Intelligence

This is where I think MicroDuck becomes much more interesting than a normal open-source gadget.

The physical body is relatively fixed.

But the software above it can change.

Consider the layers:

Hardware
    ↓
Sensors / Motors
    ↓
Runtime
    ↓
Control Policies
    ↓
Perception
    ↓
Applications
    ↓
AI Models
    ↓
User Experience

You can change different layers without replacing the whole robot.

A new policy can change movement.

A new perception system can change what the robot understands.

A new application can change what the robot is used for.

A new AI model can change how it communicates.

A new memory layer can change how interactions accumulate over time.

The physical body remains the same.

That is a very powerful idea for physical AI.

This Is Why Software Can Matter More Than Another Sensor

Hardware specifications are easy to compare.

One robot has a camera.

Another has LiDAR.

Another has more motors.

Another has a better processor.

Those differences matter.

But once a robot becomes software-defined, the quality of the software can determine how much value the hardware actually delivers.

A sensor is only valuable if software can use the information.

A motor is only useful if software can control it.

A microphone is only useful if software can interpret the audio.

A speaker is only useful if software gives it something meaningful to say.

A camera is only useful if the perception layer knows what to do with what it sees.

That is why the openness of the software stack matters.

It gives developers access to the layer where raw hardware becomes behavior.

The Community Layer May Be More Important Than the Code

There is another level of openness that the repositories cannot guarantee.

Community.

An open repository can exist with almost nobody contributing.

A technically excellent SDK can still produce very few applications.

A robot can have a sophisticated training pipeline without developing a large ecosystem.

So I would distinguish:

Technical openness

Can I inspect the code?

Can I modify it?

Can I run the simulator?

Can I train policies?

Can I build and deploy software?

MicroDuck currently scores very well here.

Ecosystem openness

Are people actually building?

Are useful behaviors being shared?

Can ordinary owners discover them?

Are developers creating tools that solve problems other owners have?

That second layer takes time.

And it is ultimately what determines whether an open platform becomes a real ecosystem instead of simply a public repository.

One of the Best Signs Is the Development Workflow

I think one of the strongest signals about MicroDuck is not the words "open source."

It is the structure of the project itself.

The repository includes:

  • development setup
  • simulation
  • branch builds
  • release candidates
  • deployment tools
  • logs
  • rollback mechanisms
  • design documentation
  • contribution guidelines
  • project documentation

The project is therefore treating the robot as something that will be developed continuously.

That is very different from publishing a few sample files after a product launch.

It looks much more like a software project that happens to have a physical machine attached to it.

The Update System Matters Too

This is one detail that is easy to overlook.

The MicroDuck runtime includes an updater responsible for installing signed releases and rolling back when the robot becomes unhealthy.

That sounds like an engineering detail.

It actually reveals something important about the product philosophy.

The robot is expected to change after it leaves the factory.

Updates are part of the product.

The software running today is not necessarily the software running a year from now.

That is normal for phones and computers.

It is much more interesting when the updated software changes a machine that physically moves.

So Is MicroDuck Truly Open?

I think the answer is:

Yes, in the software and development layers, substantially.

But not in the simplistic sense of:

"Everything is open and you can do anything."

The more accurate description is:

MicroDuck exposes a substantial part of the software stack that turns its hardware into a physical robot, including the runtime, simulation environment, training stack, and retrainable behavior pipeline.

That is the part that matters.

How Open Is It Compared With a Closed Robot?

Imagine a completely closed consumer robot.

You might get:

Robot
↓
Manufacturer app
↓
Manufacturer cloud
↓
Manufacturer updates

Your ability to change the product is limited.

Now compare that with MicroDuck:

Robot
↓
Open runtime
↓
Open control interfaces
↓
Open simulation
↓
Open RL training environment
↓
Retrainable policies
↓
Your software
↓
Community software

That does not mean the second system is automatically better.

It means the ceiling is different.

A closed robot can be more polished.

An open robot can give you much more room to change what the product becomes.

For developers, that difference can be enormous.

The Bigger Idea Is Not "Open Source Robot"

I think the more useful phrase is:

software-defined physical AI

That is what makes this class of product interesting.

The physical body provides:

  • sensors
  • motors
  • space
  • presence

Software provides:

  • perception
  • control
  • memory
  • language
  • behavior
  • applications

AI provides another layer of intelligence.

And the boundary between those layers does not have to remain fixed.

That creates a very different kind of hardware product.

A traditional hardware company might compete by adding more sensors.

A software-defined robot company can also compete by making better use of the same sensors.

The hardware may remain similar.

The experience can change dramatically.

My Take

I would not buy MicroDuck simply because someone says:

"It is open source."

That phrase is too vague.

I would buy it because the actual repositories demonstrate something much more valuable:

the robot's software is accessible enough that you can understand how the machine works, run it in simulation, inspect its runtime, experiment with the training stack, and potentially change the behaviors it expresses.

That is a real difference.

The important question is no longer:

"Can I download the source code?"

It is:

"How much of the physical AI experience can I actually change?"

With MicroDuck, the answer is surprisingly large.

And that may ultimately matter more than the duck itself.