Bambu Lab Is Picking Fights It Doesn't Need to Win

Okay so imagine you bought a really good 3D printer. You love it. You've even gone out of your way to lock it off the internet and run it in developer mode because you're particular about your data. And then the company — completely unprompted — decides to threaten a random open-source developer with legal action and post a blog calling him out publicly. You'd make a video about it too.

That's essentially where Jeff Geerling is right now, and honestly? The situation is more revealing than it first looks.

Geerling, a hardware-focused YouTuber with a substantial following, dropped a short but pointed video this week titled Bambu Lab 3D Printers: Never Again. He's been critical of Bambu before — a year ago he said he'd probably never recommend one of their printers again — but he kept using his P1S anyway, running it firewalled and locked down, making peace with the situation. He opens the new video with this: "Bambu Lab could have just left the status quo at that and I wouldn't be making this video, but they didn't."

So what did they do?

The open-source family tree matters here

To get why this is a bigger deal than "company has beef with developer," you need to understand the lineage of the software involved — because Bambu Lab is, quite literally, built on open-source community work.

The chain goes like this: Slic3r is an open-source slicer (the software that translates 3D models into printer instructions). PrusaSlicer forked from Slic3r. Bambu Studio — Bambu Lab's own slicer software — is widely reported in the community to have forked from PrusaSlicer, though the exact licensing compliance in that lineage has itself been a point of contention worth flagging. OrcaSlicer then forked from Bambu Studio, and it's become popular with power users precisely because it offers more flexibility than Bambu's default setup.

[Editor's note: Bambu Lab's official documentation on the Bambu Studio lineage should be checked before final publication to confirm the fork chain and any associated licensing claims.]

Now here's Bambu's default behavior that makes a lot of people uncomfortable: every file you print goes through their cloud servers. By default, Bambu can see everything you print, when you print it, and presumably a lot more. Some users are fine with that — cloud connectivity lets you kick off a print job remotely, which is genuinely convenient if you don't have your own VPN set up at home. Geerling acknowledges this: "Some people are okay with using Orca and printing through Bambu's cloud. I mean, I get it. It's convenient."

But a developer created a fork of OrcaSlicer — one specifically tailored for Bambu printers — that let users connect to their printers without routing everything through Bambu's infrastructure. A niche tool, for a niche group, doing something that Bambu's own open-source code technically enables anyway.

Bambu's response was to threaten that developer with legal action and publish a blog post — titled something to the effect of "Setting the Record Straight on Cloud Access and Community" (title pending verification against Bambu's official blog) — framing the developer as someone trying to "impersonate" their app. As Geerling pointedly notes: the developer was using the same open-source code that Bambu's own Linux app uses.

What Bambu is actually doing here

I've covered enough of these corporate-versus-community flareups to recognize the playbook. When a company can't or won't fix a genuine infrastructure vulnerability, it's a lot easier to write a lengthy blog post about security risks and instabilities — true things, technically — that buries the actual story, which is: we are aggressively blocking users from having local control over hardware they purchased.

Geerling calls this out directly: "They spend hundreds of words talking about vulnerabilities, bugs, and instabilities as if that has anything to do with this current situation." He's right. The security framing is doing a lot of rhetorical work here that it hasn't actually earned. Listing real bugs doesn't explain why a developer who built a local-connection tool for a small slice of power users represents a threat to Bambu's cloud infrastructure — unless the real concern is the precedent, not the security hole.

And this is where it gets interesting to me. There's a version of Bambu's position that actually makes sense: they built a cloud-first product, they have infrastructure costs and liability concerns, and they don't want third-party tools poking around in their systems in ways they can't audit. That's a real argument. But it's one you make by improving your local-mode documentation, not by targeting an individual developer with legal threats over open-source code.

I've seen this movie before

If you've been following the right-to-repair space at all, this pattern is going to feel extremely familiar. Think John Deere spending years using software locks and DMCA threats to prevent farmers from fixing their own tractors — equipment they'd bought and owned outright, sitting in a field, unable to run because a dealer 200 miles away hadn't authorized the repair. Or think about Apple's years-long war against sideloading, framing user autonomy as a security crisis until regulators in the EU basically forced their hand.

The through-line in all of these is the same: a company sells you hardware, then treats the software layer as an ongoing subscription to their ecosystem that you never actually opted into. You thought you bought a thing. They think you licensed access to a service.

What makes the 3D printing version of this story a little sharper is how nakedly the open-source dependency contradicts Bambu's position. You can't build your product on community-developed code and then turn around and legally threaten community developers for using that same code. That's not a legal argument; that's a vibe conflict. Geerling calls it "abusing the open-source social contract," and I don't think that's hyperbole.

Repairability and community advocate Louis Rossmann apparently agrees — he posted a video pledging $10,000 to help the developer fight Bambu's legal threats. (Rossmann's pledge is referenced in Geerling's video; readers should check Rossmann's channel directly to verify the current status of that offer.)

Okay, where do I actually land on this?

I don't own a Bambu printer. I've watched friends go through the setup process and clock the slightly raised-eyebrow moment when you realize all your print data is heading to someone else's servers by default — and then watch most of them shrug and keep printing because the hardware genuinely is good and the friction of locking it down is real. I get it.

But here's my honest read: Bambu is making the mistake that a lot of hardware companies make when they get successful fast. They start optimizing for retention and data collection after building a loyal community on the promise of good, hackable hardware. And then they're surprised when that community feels like the terms changed midgame. Geerling says he's "one of the nuts who likes to own something after they buy it" — framing his own reasonable expectation as a personality quirk. That framing is doing a lot of work, and I think it's worth sitting with.

Would I buy a Bambu printer today, knowing what I know? Genuinely, no. Not because the hardware isn't impressive — apparently it is — but because the company's pattern here is legible and it's pointing somewhere I don't want to follow. A year ago it was policy changes that blindsided existing customers. Now it's legal threats against a solo open-source developer. The trajectory matters.

Geerling's conclusion is pretty simple: "Nothing I say here and no amount of complaining in the comments below is gonna change Bambu's behavior, but spending a little more for a printer from another company just might."

He's probably right about the first part. Whether the second part is enough pressure to actually change anything — that depends entirely on how many people decide their printer being genuinely theirs is worth the premium.

---

Zara Chen is a tech and politics correspondent for Buzzrag. She covers the places where platforms, policy, and people collide.