Developer Mode - Help Define!

After tremendous outcry from users and influencers over the new firmware “Authorization” fiasco, Bambu Lab has made some small concessions and will include a “Developer Mode.” As many have pointed out, their tone was not contrite, and much of the responsibility was placed on users for “misunderstanding.” This is disheartening, but let’s not allow our emotions to cloud our vision - we have made some small progress. This “Developer Mode” is a good first step, and likely would not have been included had we not spoken out strongly with our words and our money.

This is a first step - but not the last. I believe the ultimate goal should be a fully realized “Developer Mode” as a user choice on all current and future printers. As such, I am starting a new thread to keep this conversation squarely on the topic of defining this.

Such a mode should include, but not be limited to:

-LAN mode with no cloud connection or cloud authorization whatsoever. (They have said this will remain.)

-Direct printer control via MQTT and/or other API endpoint with locally configurable key-based security. (In the Dev. mode as proposed, there is no mention of local security)

-All Dev. Mode accessible protocols (like MQTT) should be fully documented with an API reference. This should not need to be reverse engineered by users.

-Continued development of and support for this MQTT or API implementation. (Not a “use it but don’t expect it to work because it may or may not be incomplete” approach.)

-Bypass of all brand lock-in features like RFID tagged filament spools. Even Apple, the king of lock-in allows third party accessories on iPhone to enumerate themselves - and if the manufacturers wants they can achieve a higher level of recognition through paid MFi certification. Bambu, at minimum should allow users in Dev. Mode to define their own RFID-coded filament profiles, and if manufacturers of filament want to get in the game offer them an MFi-style certification via a small licensing fee. this allow experts to play in the sandbox and companies to offer quality, tested filament profiles - and Bambu Lab can even make a profit.

Fundamentally this Developer Mode ought to be “Real.”

1 - It is a real user mode. It is for those advanced users who choose to accept the responsibility of operating with fewer safeguards.

2 - It is not half baked. Often “Developer Mode” is just shorthand for hack-y, unsupported, and not guaranteed to actually work.

3 - It says what it does. It gives a user Privileged access to their own machine. This is akin to enabling “root” on MacOS or Linux. With great power comes great responsibility.

Please feel free to add your own thoughtful, realistic suggestions.

16 Likes

As long as you accept full responsibility for any damage caused while using Dev Mode, I have no objections. This includes damage resulting from Dev Mode itself, user errors, or external factors such as security breaches.

What you’re asking for is additional functionality that doesn’t currently exist. Why should it be included in this release?

3 Likes
  • If your phone / tablet is connected to the same LAN as the printers allow the Handy app to view the cameras and have the same functionality as it does when not in lan-only mode.
6 Likes

In my opinion, a “dev. mode” ought to be a real mode that is documented and locally secure.

I am totally ok with no warranty support for actions taken in dev mode.

1 Like

When enabling Developer Mode in systems like Windows, you acknowledge that you understand the risks and take full responsibility for any issues that may arise. Why shouldn’t the same principle apply to a 3D printer?

2 Likes

I agree. More power = more responsibility.

2 Likes

Developer mode = I know what I am doing (or so I claim, so I if tell it to do something that breaks it, therefore I must to be the one to blame).

I think in the first instance developer mode will/should only allow for current “unsecured” behaviours/APIs to continue to work… but since it is a developer mode, rather than an “unsecure mode”, it would be great to see advanced features added or even tested via that mode.

Developer Mode = Unclear whether it will be available in all future models.

Agreed. That is why we should push for it.

1 Like

I’m willing to bet it won’t be… and is only being done to keep the status quo for existing user base. New models would be expected to only use the new authentication system… but time and $$$ will tell. I wonder though if it has a warranty risk with it…

1 Like

Let’s make our expectations clear then.

2 Likes

A post was merged into an existing topic: This new auth system will make me sell my printers

I’m down for Dev.Mode.
With this, Bambu has said support is withdrawn, that’s fine, now let us access our printers and root them, let the big boys and girls who know what their doing change the system to how they want the printer to be, after all Bambu, your withdrawing support.

2 Likes

Unsupported Developer Mode = What was sold to us as supported “LAN Mode” when we bought the printer.

8 Likes

And you still have it… LAN mode isn’t going away.

I’m not really okay with that. Not even a little bit.

It depends on what we’re doing with it. Just like a warranty always depends on what you did.

If you use dev mode simply to avoid using Bambu Connect and any cloud dependencies–normal use basically–our warranty should be fully intact the same as any other customer*.

*I would be okay with an exception for “damage caused due to a security issue”.

But to put it bluntly, voiding our warranties automatically for enabling this Dev Mode is a load of :poop:.

(And I realize it was probably given this inaccurate name specifically to excuse voiding warranties.)

4 Likes

Why is it that you want the freedom to do anything with the device but avoid taking responsibility for the consequences? Developer mode on all units I work with includes clear and explicit disclaimers, as it always has. Expecting to bypass these limitations while holding Bambu Lab accountable for potential damage seems unfair. If you’ve purchased the hardware and insist on the ability to modify it freely, it’s only reasonable that any risks associated with activating a developer mode fall on the user, not the manufacturer.

3 Likes

Respectfully… re-read the post, I didn’t say anything remotely resembling that.

If I do some weird stuff that “Developer Mode” makes possible, having that void the warranty is fine.

But if I’m literally just turning LAN + Dev Mode on and then using the machine normally… why should Bambu Lab be off the hook if their power supply catches fire or your board capacitors blow up, which has nothing to do with the Dev Mode setting?

Like a normal warranty clause, it should depend on what you’ve done with the product.

But also, why the heck are you so vigorously defending Bambu’s profit margin? Don’t worry about them, they can handle that just fine.

2 Likes

So, if I activate developer mode on a unit solely to use feature X, and the unit becomes damaged by something that developer mode would have otherwise prevented, wouldn’t I be responsible for that? I chose to activate developer mode with the responsibility it entails, regardless of whether I was using the specific feature that ultimately caused damage to the unit.

2 Likes

I’m not defending Bambu Lab; I’m questioning why you think you should have the right to disable safety features or access developer settings that compromise the unit, only to shift the responsibility onto Bambu Lab when something goes wrong. It seems you’re not fully grasping that if a potential developer mode doesn’t allow modifications that could harm components—like altering power settings or disabling critical safety features such as cooling fans—you would still retain your warranty. However, it would then fall on you to prove that the damage wasn’t caused by enabling the developer mode. Ultimately, this depends on how such a developer mode is implemented. If it grants unrestricted control over key safety-critical systems, the warranty could very well be voided. We simply don’t know that yet.

2 Likes