The editorial argues the Fisker Ocean is a preview of what happens to every connected device when its parent company dies — smart thermostats, IoT sensors, and cloud-dependent dev tools all carry this same risk. The Ocean owners were simply technically capable enough and financially motivated enough to fight back.
The Electrek article frames owners as having built 'an open source car company from the ashes' — positioning the community's Discord/GitHub-organized effort to document CAN bus protocols, build diagnostic tools, and create alternative firmware as an ambitious evolution from survival into a fully open-source vehicle software stack.
The editorial positions this story at the intersection of cloud-dependent hardware fragility, open-source community engineering power, and the accelerating right-to-repair movement. It emphasizes the technical impressiveness of the scope — reverse-engineering a modern vehicle involves multiple ECUs and communication protocols far beyond typical consumer device jailbreaking.
When Fisker Inc. filed for Chapter 11 bankruptcy in June 2024, it left approximately 10,000 Fisker Ocean owners in an unprecedented situation: stranded with software-defined vehicles that would receive no further updates, bug fixes, or server-side support. The Ocean wasn't just a car — it was a rolling computer that depended on cloud connectivity for features, OTA updates, and even basic diagnostics.
Within months of the bankruptcy, a community of technically-skilled owners began reverse-engineering the Ocean's firmware, CAN bus protocols, and cloud API endpoints. What started as survival — keeping their $40,000+ vehicles functional — evolved into something more ambitious: a fully open-source vehicle software stack, maintained and improved by the people who actually drive the cars.
The community organized primarily through Discord and GitHub, pooling expertise from embedded systems engineers, automotive software developers, and security researchers who happened to own Oceans. They've documented the vehicle's communication protocols, built open-source diagnostic tools, and created alternative firmware that restores features that went dark when Fisker's servers shut down.
This story sits at the intersection of three trends that every developer building connected products should care about: the fragility of cloud-dependent hardware, the power of open-source community engineering, and the accelerating right-to-repair movement.
The Fisker Ocean is a preview of what happens to every connected device when its parent company dies. Your smart thermostat, your IoT sensors, your cloud-dependent dev tools — they all carry this risk. The Ocean owners just happened to be technically capable enough to do something about it, and their vehicle expensive enough to justify the effort.
What makes this technically impressive is the scope. Reverse-engineering a modern vehicle isn't like jailbreaking a phone. You're dealing with multiple ECUs (Electronic Control Units), proprietary CAN bus messages, safety-critical systems where a wrong bit flip could affect braking or steering, and encryption layers designed specifically to prevent this kind of access. The community had to build custom hardware adapters, write CAN bus sniffers, decompile firmware binaries, and reconstruct API protocols from network traffic captures — all while being extremely careful not to brick vehicles that people depend on for daily transportation.
The project also highlights a structural problem in the EV industry. Traditional cars degrade gracefully — a 2005 Honda Civic still drives fine without calling home to Honda's servers. Software-defined vehicles don't have this property. When the company dies, features die with it. The Fisker community is proving that open-source firmware can restore this durability, but only because they have the skills and determination to reverse-engineer proprietary systems.
From a community engineering perspective, the coordination challenge is as interesting as the technical one. You need to maintain safety standards without a formal QA organization. You need to distribute firmware updates without bricking cars. You need to manage contributions from dozens of developers with varying skill levels, all working on safety-critical code. They've adopted practices from aerospace and medical device open-source projects: mandatory code review by multiple domain experts, staged rollouts starting with volunteer test vehicles, and formal verification of safety-critical paths.
If you're building connected hardware or software-dependent physical products, this should reshape how you think about end-of-life planning. The responsible approach is to have an open-source escape hatch baked in from day one — documented protocols, published firmware source (or at minimum, unlockable bootloaders), and local-first fallback modes that work without phoning home.
For developers in the automotive or IoT space specifically: the legal landscape is shifting. The community's work has been bolstered by right-to-repair legislation that's expanded in multiple states and the EU since 2024. Building proprietary lock-in into vehicle firmware is becoming both a legal liability and a PR risk. Companies like Tesla have faced pressure to open their diagnostic interfaces, and the Fisker community's success provides a template for what determined owners can accomplish regardless of manufacturer intent.
If you work on embedded systems, the toolchain this community has built is worth studying. Their approach to safe OTA updates for a vehicle fleet — using cryptographic signing, staged rollouts, automatic rollback on fault detection, and community-operated update servers — is a reference architecture for any open-source firmware distribution system managing safety-critical hardware.
The Fisker Ocean community has inadvertently created a template that will be reused every time a connected-device company goes bankrupt. As more vehicles become software-defined and more hardware companies flame out, expect to see similar communities form around other orphaned products. The question for the industry is whether manufacturers will proactively plan for this scenario — publishing source code in escrow, designing for local-first operation, supporting community maintenance — or whether every product death will require this same heroic reverse-engineering effort. The Fisker owners chose to fork their car. The next generation of product designers should make sure that's never necessary.
>Fisker had built what Cory Doctorow, the digital rights author and activist, pointedly called a “software-based car.” Virtually every subsystem in the Ocean — brakes, airbags, shifting, battery management, door locks — needed to periodically connect with Fisker’s cloud servers for diagnostics or
Oh, not the owners of the company, the owners of the cars the company made.
> We had reviewed the Ocean in late 2023 and found the hardware genuinely attractive — but the software was simply not ready for prime time. The irony of that headline — “Coming soon, in a future software update” — now reads like an epitaph. Those future updates never came from Fisker. They came
I'd buy any Tesla, even the big truck, if it came with open source software! I don't want a car that's spyware like a phone. Let me be in control of it, let me mod it, let me own it.Who's going to sell me one?
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Fisker may have been especially vulnerable to this (my understanding from some very brief searching is that core vehicle functionality required cloud check ins without fallback), but nothing about this is inherent to EVs (this is response to Weisenthal's tweet early in the article). An ICE vehi