These companies always pick the most ridiculous tinfoil hat bullshit list of complaints to debunk when trying to explain why they want to close off their API. The real reason almost always comes down to money. The mention of Panda Touch is very telling. While I'm sure Bambu doesn't want to maintain documentation for a non-public (is that the right term)? API, they definitely don't want other companies making money off their ecosystem.
who cares if Panda Touch/BigTreeTech was making money off the ecosystem? it did nothing more than sell more bambu printers. It's not net-zero--money for BigTreeTech is not coming out of Bambu's pockets; I seriously doubt it was net-negative for Bambu.
Because the writing on the wall is that this was always meant to be a subscription based, continual revenue stream for Bamboo Labs. They are just edging that direction.
Whether or not it’s simply greed or that they didn’t make as much selling the printers as they had thought. The next step to closing an API and killing 3rd party interactions is almost always so they can introduce some form of continuous monetization scheme.
That was always something that rubbed me the wrong way with Bamboo Labs. They threw an absolutely obscene amount of money at influencers. Essentially buying a ringing endorsement from nearly the whole hobbyist community and made their brand a household name.
Having 2nd and 3rd party support only make an ecosystem more robust.
This whole kerfuffle only sours me to them. I like the printer but the desktop software quality is low and features in LAN mode are not available for what one can only think of as a shity move to Hoover up data for the enshitification
What if this is not about closing off an API. Maintaining a stable API is difficult - especially if mistakes were made in earlier designs (no versioning, bad abstraction, wrong protocol...) and there is a plan to fix things in the future.
Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.
From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)
In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.
Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?
Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.
From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?
Comments
These companies always pick the most ridiculous tinfoil hat bullshit list of complaints to debunk when trying to explain why they want to close off their API. The real reason almost always comes down to money. The mention of Panda Touch is very telling. While I'm sure Bambu doesn't want to maintain documentation for a non-public (is that the right term)? API, they definitely don't want other companies making money off their ecosystem.
who cares if Panda Touch/BigTreeTech was making money off the ecosystem? it did nothing more than sell more bambu printers. It's not net-zero--money for BigTreeTech is not coming out of Bambu's pockets; I seriously doubt it was net-negative for Bambu.
Because the writing on the wall is that this was always meant to be a subscription based, continual revenue stream for Bamboo Labs. They are just edging that direction.
Whether or not it’s simply greed or that they didn’t make as much selling the printers as they had thought. The next step to closing an API and killing 3rd party interactions is almost always so they can introduce some form of continuous monetization scheme.
That was always something that rubbed me the wrong way with Bamboo Labs. They threw an absolutely obscene amount of money at influencers. Essentially buying a ringing endorsement from nearly the whole hobbyist community and made their brand a household name.
The time was right to pull the switch.
Having 2nd and 3rd party support only make an ecosystem more robust.
This whole kerfuffle only sours me to them. I like the printer but the desktop software quality is low and features in LAN mode are not available for what one can only think of as a shity move to Hoover up data for the enshitification
What if this is not about closing off an API. Maintaining a stable API is difficult - especially if mistakes were made in earlier designs (no versioning, bad abstraction, wrong protocol...) and there is a plan to fix things in the future.
Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.
From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)
In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.
Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?
Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.
From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?
That's why any sane software uses a stable public API and an internal one that can be closed off or has breaking changes all the time.
It's currently handled like this: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md. Would it be a far stretch to add an "api_version":x field and a "internal_" prefix for some commands?