Fisker Died. Its Owners Open-Sourced the Car.

4 min read 1 source clear_take
├── "Community-driven reverse engineering of abandoned EVs is a genuine technical achievement and a model for owner autonomy"
│  └── breve (Electrek) → read

The article frames the Fisker Ocean community's effort as a remarkable success story — owners decoded CAN bus protocols, built open-source diagnostic tools, and issued their own firmware patches. By May 2026, they had effectively built an open-source car company with community-maintained firmware and governance structures.

├── "Connected vehicles that depend on cloud services are a ticking time bomb for consumers when companies fail"
│  └── top10.dev editorial (top10.dev) → read below

The editorial highlights that owners of a $70,000 vehicle were left with hardware that would never receive another software update, no service network, and a mobile app connected to servers on borrowed time. This case demonstrates the fundamental risk of cloud-dependent vehicles where bankruptcy can instantly strand owners.

├── "The success of volunteer firmware maintenance on safety-critical vehicles reveals how straightforward modern car software actually is"
│  └── top10.dev editorial (top10.dev) → read below

The editorial argues that a distributed community successfully reverse-engineering and maintaining vehicle firmware 'without killing anyone' is either a testament to their engineering discipline or a damning indictment of how simple modern car software actually is — probably both. This cuts against automaker claims that vehicle software is too complex for independent maintenance.

└── "This effort goes beyond prior open-source hardware rescues because cars are safety-critical systems operating at highway speeds"
  └── top10.dev editorial (top10.dev) → read below

The editorial explicitly distinguishes this from Pebble watches and Sonos speakers, noting that a car is a '4,000-pound, highway-speed, safety-critical system.' The CAN bus reverse engineering required oscilloscopes, patience, and a willingness to risk bricking a daily driver, placing this in a fundamentally different risk category than prior community firmware projects.

What happened

Fisker Inc. filed for Chapter 11 bankruptcy in June 2024, then liquidated under Chapter 7 shortly after. The company left behind roughly 10,000 Fisker Ocean SUVs — connected electric vehicles that depended on cloud services for OTA updates, remote diagnostics, and several key features. Overnight, owners of a $70,000 vehicle found themselves holding hardware that would never receive another software update, with no authorized service network and a mobile app connected to servers running on borrowed time.

What happened next is the part worth paying attention to. A community of Fisker Ocean owners — many of them software engineers, embedded systems developers, and automotive enthusiasts — organized through Discord and forums to reverse-engineer their own vehicles. By mid-2025, they had decoded the Ocean's CAN bus protocols, built open-source diagnostic tools, and begun issuing their own firmware patches to fix bugs Fisker never got around to addressing. By May 2026, the project had matured into something resembling an open-source car company: community-maintained firmware, shared repair documentation, unlocked features that Fisker had gated behind subscription paywalls, and a governance structure for deciding what gets merged.

Why it matters

This isn't the first time users have reverse-engineered abandoned hardware. Pebble watch owners did it. Sonos speakers got community firmware. But a *car* is a different category entirely — it's a 4,000-pound, highway-speed, safety-critical system. The fact that a distributed community of volunteers successfully reverse-engineered and maintained vehicle firmware without killing anyone is either a testament to their engineering discipline or a damning indictment of how simple modern car software actually is. Probably both.

The technical achievement is genuine. CAN bus reverse engineering requires patience, oscilloscopes, and a willingness to brick your own daily driver in the name of science. The community mapped out the Ocean's controller network, identified the telematics module's communication protocols, built tools to flash modified firmware over the OBD-II port, and documented the entire battery management system well enough to perform cell-level diagnostics. They've fixed phantom braking issues, improved charging curve behavior, and unlocked the "Hyper" mode that Fisker originally planned as a paid upgrade.

The organizational model is equally interesting. Without a corporate hierarchy, they adopted something closer to Linux kernel governance: maintainers for specific subsystems (drivetrain, infotainment, ADAS, charging), pull request reviews for safety-critical changes, and a mandatory testing protocol on isolated bench setups before any firmware touches a road-going vehicle. Changes to brake or steering-adjacent systems require sign-off from at least three maintainers with verified automotive engineering backgrounds.

The legal landscape remains murky. The DMCA's exemption for vehicle repair (expanded in 2021) provides some cover, but the community operates in a gray zone between "repair" and "modification." No one has challenged them yet — there's no Fisker left to object, and the bankruptcy trustee has bigger problems. But the precedent matters for every other connected vehicle on the road.

What this means for your stack

If you're building any connected product — not just vehicles — this story is a design constraint, not just a news item. When your company dies, your users' hardware doesn't die with it. Plan the shutdown path, or your users will find one you didn't intend.

Practical implications for developers shipping connected hardware or IoT products:

Design for orphaning. Include a local-first fallback mode that activates when cloud services become unreachable for extended periods. If your device becomes a brick when your servers go dark, you've built a liability, not a product. The Fisker Ocean's deep cloud dependency meant basic features degraded when the servers went offline — a design choice that looked like lock-in during the company's life and looked like negligence after its death.

Document your protocols. The Fisker community spent months reverse-engineering what could have been a published spec. If you're building on CAN bus, MQTT, or any device communication layer, consider what happens when your proprietary protocol documentation is the only thing standing between your users and a functional product. Some companies (Tesla, to partial credit) publish enough that independent repair is feasible. Others treat protocol documentation like trade secrets right up until bankruptcy makes it moot.

Governance scales better than you think. The Fisker community's maintainer model — subsystem ownership, mandatory multi-party review for safety-critical paths, bench testing requirements — is essentially what any responsible embedded systems team does internally. The open-source model didn't lower the engineering bar; it just distributed the responsibility across people who are personally motivated because they drive the result every day.

Looking ahead

The Fisker Ocean community is a proof of concept for something larger: community-maintained vehicles as a viable long-term ownership model. As more EV startups face the same financial pressures that killed Fisker — capital-intensive manufacturing, thin margins, brutal competition from legacy automakers and Tesla — the question isn't whether more EV companies will die. It's whether the next ones will die gracefully, with published specs and open protocols, or whether their owners will have to fork the car from scratch. The smart startup founders are watching this story and planning accordingly. The rest will become the next case study.

Hacker News 147 pts 56 comments

Fisker went bankrupt and owners built an open source car company from the ashes

→ read on Hacker News
MostlyStable · Hacker News

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

fsckboy · Hacker News

>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

cosmotic · Hacker News

Oh, not the owners of the company, the owners of the cars the company made.

rafram · Hacker News

> 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

purpleidea · Hacker News

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?

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.