There’s been a bit of a controversy brewing over Bambu Lab’s policies, but it’s really a collision of concepts.
Here’s the background: Bambu Lab’s initial releases of their software tool, BambuStudio, connected to their equipment directly from operators’ desktops. This allows the operator to dispatch jobs, monitor printing, and even stop printing. It’s a hugely valuable feature.
Since BambuStudio is open source (it is based on PrusaSlicer, which is based on Slic3r), others could modify and use it. One fork is OrcaSlicer. It’s very similar to BambuStudio, but with a few more advanced features.
Initially, OrcaSlicer could connect to the printers in the same way as BambuStudio. However, this was only because Bambu Lab had a poor security architecture for their cloud network. They feared (and possibly experienced) attacks against their cloud. The nightmare scenario would be hackers taking control of connected 3D printers, which could cause damage. That damage would make Bambu Labs liable for compensation, since it was their cloud that was used to perform the attack.
Bambu Lab straightened out their security architecture by restricting direct access to the printers to only their software tool, BambuStudio.
They recognized that some operators don’t want to use their cloud or prefer a different slicing software tool. For these groups, they provided LAN Mode, which allows operators to directly connect to their own equipment over a LAN — but not participate in the larger Bambu Lab cloud. They also provided Bambu Connect, a utility program under their control that allows GCODE generated by third-party slicers to be sent to the printers securely. That worked, but was an extra step from the previous OrcaSlicer setup.
The latest development is that an independent programmer, Pawel Jarczak, created a modification for OrcaSlicer that allows direct connection to the equipment via the Bambu Lab cloud, just as it had done before.
Bambu Lab saw this as a violation and requested that the software be removed. Jarczak explains on GitHub:
“Bambu Lab contacted me directly and demanded the removal of the solution.
In that correspondence, they alleged, among other things, that the removed implementation:
impersonated Bambu Studio,
bypassed their authorization controls,
violated their Terms of Use,
involved “reverse engineering”,
and could allow modified forks to send arbitrary commands to printers.They also referred to legal materials and stated that a cease and desist letter had been prepared.”
This action caused a kerfuffle in the open source community, who believe that one should be able to do whatever they like with their equipment and software. Normally, if something is required, someone builds it, and it is used. But that can’t happen in this case because Bambu Lab is blocking the work.
Since then, I’ve seen countless posts where many state “they will never use Bambu Lab equipment again”, or similar intents. They feel that by doing so, they would support open source principles.
The backlash was sufficient enough that Bambu Lab has specifically responded to the situation in a rather long blog post, which I encourage you to read.
The TL/DR of their post is simply this: the software is open source and can be treated as such, but their cloud system is NOT open source and cannot be arbitrarily used. This aligns with their original issue of protecting their cloud system from attack. Unlike a chunk of open source software that is just a file that isn’t running until someone launches it, their cloud system is an active instance of their non-open source cloud code.
To flip this around as an analogy, from Bambu Lab’s point of view, it would be as if an open source engineer launched some private software on their own server, and the open source community decided that they need to access it without permission. That’s obviously wrong and is essentially what’s going on here.
In the post, Bambu Lab writes:
“At the same time, a license for code is not a pass to our cloud infrastructure.
These are two completely different things, and the distinction between them is absolutely critical.
Our cloud is a private service. Access to it is governed by a user agreement, not the AGPL license.
And this is where the actual issue arises: the modification in question worked by injecting falsified identity metadata into network communication.”
Their update will no doubt infuriate the open source community, but I believe there’s something more going on here. It’s a collision of the two cultures.
In order for Bambu Lab to expand their sales, they have to make equipment and software increasingly easier to use. That’s done by automating and controlling every aspect of the printer’s activity. There’s no room for fiddling; it has to “just work.” This enables those who are NOT technically savvy to become customers.
And there are a lot more of them than technical users.
Therein lies the problem: going forward, there will always be far more non-technical Bambu Lab customers than technical customers. The open source community may not agree with Bambu Lab’s policies, but as time passes, their technical customers become less and less important.
There are countless products where this same scenario has taken place. For example, do we see any 2D paper printers built for open source tweaking? Nope, they are just tools you buy and use. The need for and interest in open source capabilities for that particular produce expired a long time ago.
That’s where desktop 3D printers seem to be headed in future years.
