There is something strangely hypnotic about pulling a water-damaged motherboard out of a discarded nine-hundred-dollar scooter and realizing the only thing truly broken about it is the code. We treat micromobility like disposable paper cups, scattering lime-green and bright-orange aluminum across our sidewalks until a controller trips an error code, at which point the entire machine gets tossed into a scrap heap. I started wondering: what happens if you treat the metal as permanent, but the brain as a draft?
A growing subculture of embedded programmers has stopped waiting for manufacturers to push bug fixes. Instead, they are cracking open dashboard potting compound, probing serial buses with twenty-dollar logic analyzers, and rewriting entire motor-control stacks from scratch in Rust. It feels like an act of quiet rebellion, but it might actually be an accidental blueprint for modern environmental conservation.
The Anatomy of an Artificial Death
When a rental scooter company goes belly-up or cycles out its fleet, perfectly functional hardware becomes instant e-waste. Back in 2019, when the first wave of dockless scooter sharing swept through American cities, researchers at North Carolina State University calculated that a typical shared scooter had an average lifespan of roughly several months, generating an estimated 202 grams of CO2-equivalent per passenger-mile over its life cycle. Most of that footprint wasn't the electricity charging the pack; it was the sheer carbon intensity of manufacturing an aluminum chassis and a 36-volt lithium-ion battery over and over again.
Why do these machines die so young? Often, it is entirely software-induced necrosis.
- Proprietary CAN bus protocols lock the motor controller to an inactive remote server.
- A single cell in a 10S3P battery pack slips slightly out of balance, tripping a permanent software lockout that refuses to charge.
- The original vendor goes bankrupt, shuts down their Amazon Web Services endpoints, and suddenly the dashboard controller bricks itself on boot.
- Factory firmware written in brittle, safety-blind C suffers memory leaks that cause phantom braking or sudden acceleration, prompting cities to ban the models entirely.
Photo by Katja Burger on Pexels
It is an absurd supply chain loop. We mine bauxite in Guinea, ship it across oceans to be smelted into structural aluminum, refine cobalt and nickel for the energy storage, and then let the whole rig rot in an impound lot because a three-dollar microcontroller ran out of dynamic memory. What if we just cleared the flash memory and treated the metal as an open canvas?
Why Rust Changes the Chemistry of the Hack
Reverse-engineering scooter firmware is not new; teenagers have been flashing cracked hex files onto Xiaomi M365s to push them past 30 kilometers per hour for years. But rewriting an entire real-time operating system in a memory-safe language is an entirely different beast. Embedded systems run on tiny margins, often on chips like the STM32F103, an ARM Cortex-M3 processor with just 64 kilobytes of flash storage and 20 kilobytes of RAM.
Historically, writing bare-metal firmware for these chips meant hand-tuning C or assembly code. One misplaced pointer, one subtle buffer overflow in the throttle-reading interrupt, and you have a vehicle that accelerates into a curb because an array index went out of bounds. The genius of using modern embedded Rust in this space is that the language enforces compile-time guarantees about memory safety and thread safety without requiring a heavy runtime or a garbage collector. It makes rock-solid motor control achievable for weekend hobbyists.
Think about what that unlocks. You take an STM32 chip that someone discarded in an alley, wire up an ST-Link programmer, completely wipe the closed-source binary, and compile a clean, open-source motor controller written in pure Rust. Suddenly, field-oriented control (FOC)—which makes brushless motors run whisper-quiet and dramatically increases battery efficiency—is accessible, auditable, and easily modified. The machine doesn't just work again; it runs cooler and safer than it did when it rolled off the assembly line.
Firmware as the New Land Ethic
We have spent decades thinking about conservation in terms of materials: recycling aluminum cans, composting organic waste, sorting plastics into blue bins. But software is the invisible hand that determines whether physical matter remains useful or becomes landfill sludge. Code is a material constraint.
Photo by https://kaboompics.com/ on Pexels
If a piece of software can unilaterally terminate the operational lifespan of a sixty-pound metal artifact, then writing open, modular replacement firmware is literally an act of environmental remediation. It bridges the chasm between two movements that rarely share a room: the hardcore systems hackers who care about register allocation, and the circular-economy advocates who care about carbon footprints.
Consider what happens when you decouple the hardware from the vendor's cloud:
- Diagnostic granularity: Open firmware lets you read individual cell voltages, so you can rebuild a degraded battery pack by swapping a single 18650 cell instead of tossing forty of them.
- Universal communication: By standardizing the communication protocols between throttles, batteries, and motor controllers, components from five different dead scooter brands can suddenly talk to each other.
- Longevity over growth: A community-maintained codebase has no quarterly incentive to make an older vehicle feel sluggish or unsupported.
This makes me wonder if our entire framework for consumer protection needs to flip. We spend millions regulating battery chemistry and crash safety, but almost nothing requiring that the microchips driving these vehicles be reflashable once the manufacturer walks away. What if open firmware headers were as legally mandated as seatbelts?
What This Actually Means
The real promise of the firmware-as-conservation movement isn't just about saving a few thousand electric scooters from an undignified grave behind an impound yard. It is a proof-of-concept for how we interact with the entire impending wave of electrified physical objects that surround us. E-bikes, home heat pumps, lawnmowers, electric outboard motors—they are all essentially the same architecture: a battery, an inverter, a microcontroller, and code.
If we accept the premise that hardware lives and dies by the proprietary firmware burned into its flash storage, we are quietly agreeing to an unprecedented rate of industrial waste. We are letting software developers thousands of miles away decide the structural lifespan of physical steel and copper.
The hobbyists sitting at workbenches late into the night, scoping out SPI buses and writing memory-safe device drivers, are offering an alternative path. They are proving that an obsolete device is often just a device whose software authors stopped caring before the machine did. If we can learn to rewrite the soul of the machine, the body might last as long as we need it to.
Quick Answers
Is it legal to wipe the firmware on a scooter and write your own?
Yes, if you own the vehicle outright. While unlocking stolen fleet scooters is illegal, reverse-engineering and replacing firmware on salvage or privately purchased hardware falls squarely within consumer right-to-repair boundaries in most jurisdictions.
Why choose Rust over standard C for low-level motor controllers?
Rust prevents memory corruption bugs at compile time without adding a memory-hungry garbage collector, meaning hobbyist developers can build complex, multi-threaded safety routines without the risk of software crashes causing hardware failure.
Does community firmware actually make an old scooter run better?
Often, yes. Open firmware projects frequently implement superior motor-control algorithms like field-oriented control, which increases motor efficiency, smooths out throttle curves, and reduces thermal stress on aging battery cells.
