Il confronto tra Bambu Lab e una parte della comunità open source della stampa 3D è tornato al centro della discussione dopo la chiusura del progetto OrcaSlicer-BambuLab, un fork sviluppato da Paweł Jarczak per ripristinare alcune modalità di collegamento tra OrcaSlicer e le stampanti Bambu Lab tramite rete cloud. La questione non riguarda solo una funzione software, ma tocca un tema più ampio: fino a che punto un produttore può controllare l’accesso ai propri servizi cloud quando il software client nasce da una base open source?
Bambu Lab sostiene che il problema non sia la modifica del codice open source, né l’esistenza di OrcaSlicer come fork, ma l’uso del cloud aziendale. In una nota del 7 maggio 2026 l’azienda ha dichiarato che Bambu Studio è distribuito sotto licenza AGPL-3.0 e può essere modificato e ridistribuito, ma ha distinto il codice del programma dall’infrastruttura cloud, definita un servizio privato regolato da accordi d’uso. Secondo Bambu Lab, il fork contestato si sarebbe presentato ai server come client ufficiale Bambu Studio, creando un problema di identificazione e stabilità del servizio.
Il punto di partenza: Bambu Studio nasce da una filiera open source
Per capire perché il caso ha acceso così tanto il dibattito, bisogna partire da Bambu Studio. Il software di slicing di Bambu Lab non nasce in un ecosistema chiuso: il repository ufficiale spiega che Bambu Studio è basato su PrusaSlicer, a sua volta derivato da Slic3r, progetto creato da Alessandro Ranellucci e dalla comunità RepRap. La licenza indicata è la GNU Affero General Public License versione 3, la stessa famiglia di licenze che impone la pubblicazione del codice quando si distribuiscono modifiche derivate.
Anche OrcaSlicer si colloca in questa continuità. Il progetto descrive la propria origine come derivata da Bambu Studio, PrusaSlicer e da idee provenienti da Cura e SuperSlicer. Nel repository di OrcaSlicer viene indicata la licenza AGPL-3.0 e viene specificato che il plugin di rete Bambu si basa su librerie non libere di Bambu Lab, opzionali rispetto al programma principale.
Questa struttura crea una situazione ibrida: da un lato c’è un programma open source, modificabile e distribuibile; dall’altro ci sono funzioni di rete collegate a servizi e componenti non completamente aperti. Finché l’esperienza dell’utente funziona senza frizioni, questa distinzione resta poco visibile. Quando il produttore cambia le regole di accesso, diventa invece il centro del problema.
Bambu Connect e la nuova architettura di accesso
Nel gennaio 2025 Bambu Lab ha annunciato un nuovo sistema di controllo autorizzato per alcune operazioni di rete. La modifica ha interessato soprattutto gli utenti che usano slicer di terze parti, come OrcaSlicer, per inviare lavori alle stampanti. L’azienda ha introdotto Bambu Connect, un’applicazione intermedia pensata per collegare i file generati da software esterni alle stampanti Bambu Lab, mantenendo però i comandi all’interno di un canale verificato.
Nella comunicazione successiva, Bambu Lab ha insistito su tre punti: l’aggiornamento non avrebbe avuto lo scopo di bloccare i software di terze parti, Bambu Connect avrebbe dovuto garantire continuità d’uso con maggiore sicurezza, e gli utenti più avanzati avrebbero potuto usare modalità alternative come LAN Mode e Developer Mode. Nella modalità LAN aggiornata, l’azienda ha promesso che il collegamento locale tramite Bambu Connect non avrebbe richiesto internet né un account utente; in Developer Mode, invece, gli utenti avrebbero potuto lasciare aperti MQTT, livestream e FTP assumendosi la responsabilità della sicurezza della propria rete.
Per una parte della comunità, però, l’introduzione di un’app proprietaria come passaggio obbligato ha cambiato il senso pratico dell’ecosistema. Prima il flusso era più diretto: slicer, stampante, invio del lavoro. Dopo l’aggiornamento, il produttore è diventato l’intermediario necessario per alcune funzioni. Anche se Bambu Lab presenta questa scelta come misura di sicurezza, molti utenti l’hanno letta come un passo verso un ecosistema più controllato.
Il fork OrcaSlicer-BambuLab e la reazione di Bambu Lab
Paweł Jarczak ha sviluppato un fork chiamato OrcaSlicer-BambuLab con l’obiettivo di ripristinare il supporto BambuNetwork e riportare alcune funzioni di accesso diretto che gli utenti associavano al vecchio flusso di lavoro. Il repository oggi non contiene più il codice originario: rimane una nota storica in cui lo sviluppatore spiega di aver rimosso implementazione, release, tag e materiali collegati dopo un contatto diretto da parte di Bambu Lab.
Secondo la ricostruzione pubblicata da Jarczak, Bambu Lab avrebbe chiesto la rimozione della soluzione e avrebbe contestato diversi aspetti: impersonificazione di Bambu Studio, aggiramento dei controlli di autorizzazione, violazione dei termini d’uso, reverse engineering e possibilità per fork modificati di inviare comandi arbitrari alle stampanti. Lo sviluppatore dichiara di non accettare queste contestazioni come fatti stabiliti e afferma di aver chiesto chiarimenti tecnici e legali più precisi, senza ricevere il livello di dettaglio richiesto.
Jarczak sostiene inoltre che il suo lavoro fosse basato su codice pubblico di Bambu Studio distribuito sotto AGPL, senza ridistribuire i binari proprietari del plugin di rete. In un passaggio della sua nota, indica che la costruzione dello user-agent contestata da Bambu Lab deriva dal codice pubblico AGPL di Bambu Studio e non da reverse engineering di un binario proprietario.
Il punto è delicato perché le due parti descrivono lo stesso fatto tecnico con parole diverse. Bambu Lab parla di identità falsificata e accesso non autorizzato al cloud. Jarczak parla di uso di codice pubblico AGPL, di metadati client e di una funzione ancora tecnicamente accessibile nel percorso Linux. Non è un dettaglio semantico: dalla definizione dipende il modo in cui la comunità interpreta l’episodio.
La posizione di Bambu Lab: il cloud non è open source
Nella propria risposta pubblica, Bambu Lab ha cercato di separare due livelli. Il primo è il software: Bambu Studio è AGPL, quindi può essere modificato, biforcato e distribuito. L’azienda riconosce l’esistenza di OrcaSlicer e di centinaia di fork, dichiarando di non avere problemi con questa attività. Il secondo livello è il cloud: secondo Bambu Lab, il fatto che il codice client sia open source non dà automaticamente il diritto di usare i server aziendali in qualsiasi modo.
L’azienda afferma che il fork contestato si presentava ai server come Bambu Studio ufficiale, con numero di versione hardcoded. Secondo Bambu Lab, questo impedirebbe ai server di distinguere tra traffico proveniente dal client ufficiale e traffico generato da software modificato, aumentando il rischio di sovraccarico e instabilità. Nella stessa nota, l’azienda collega il tema a episodi di traffico non autorizzato e interruzioni di servizio.
Bambu Lab invita inoltre gli utenti a usare canali come Bug Bounty Program, Bambu Connect, LAN Mode e Developer Mode per mantenere un equilibrio tra apertura, controllo locale e protezione dell’infrastruttura cloud. L’azienda sostiene che modificare e distribuire codice AGPL sia legittimo, mentre presentarsi ai server cloud come client ufficiale non lo sia.
La posizione della comunità: proprietà del dispositivo e diritto alla modifica
La risposta della comunità non si è limitata al caso specifico di un repository. Molti utenti vedono nella vicenda un segnale su come potrebbe evolvere la stampa 3D desktop: meno controllo locale, più servizi intermedi, più dipendenza dall’account del produttore e meno libertà di integrare strumenti esterni.
Questa preoccupazione non nasce dal nulla. Nel 2025, quando Bambu Lab ha annunciato il nuovo sistema di autorizzazione, diversi utenti avevano già espresso timori su un possibile “giardino recintato”. The Verge aveva riportato domande puntuali su abbonamenti, uso di filamenti di terze parti, accesso LAN e permanenza della Developer Mode. Bambu Lab aveva risposto che, per le linee di prodotto allora esistenti, non avrebbe richiesto un abbonamento per controllare o stampare via rete locale, non avrebbe messo funzioni esistenti dietro un abbonamento e non aveva piani per limitare l’uso di filamenti di terze parti.
Il problema è la fiducia. Anche quando un produttore fornisce rassicurazioni, una parte degli utenti teme che le architetture basate su cloud, autenticazione proprietaria e applicazioni intermedie rendano più facile cambiare le regole in futuro. Per chi proviene dalla cultura RepRap, dalla modifica firmware, da Klipper, da OctoPrint o dai slicer open source, la stampante 3D non è solo un elettrodomestico: è una macchina che l’utente deve poter controllare, riparare, integrare e modificare.
Il precedente del cloud outage
La sensibilità verso il cloud Bambu Lab è stata rafforzata anche da episodi precedenti. Nell’agosto 2023 l’azienda ha riconosciuto un’interruzione temporanea del cloud che aveva provocato problemi agli utenti e ha dichiarato di accettare la responsabilità dell’incidente. In quella comunicazione Bambu Lab spiegava di voler introdurre ulteriori verifiche prima dell’avvio di una stampa e ribadiva l’impegno a sviluppare la modalità LAN come alternativa in caso di problemi cloud.
Questo precedente mostra perché l’infrastruttura cloud non è un dettaglio secondario. Se il cloud permette di avviare lavori, monitorare la stampa e collegare MakerWorld, allora sicurezza e affidabilità diventano essenziali. Allo stesso tempo, se una parte importante dell’esperienza dipende dal cloud, gli utenti più tecnici chiedono garanzie su controllo locale, indipendenza e continuità d’uso.
Bambu Farm Manager e la risposta al mondo professionale
Bambu Lab non ha ignorato la richiesta di gestione locale. Nel 2025 ha introdotto Bambu Farm Manager, un software gratuito per gestire flotte di stampanti Bambu Lab in rete locale, senza uso del cloud dopo la fase iniziale di configurazione. Il programma è pensato per print farm, aziende, scuole e realtà con requisiti di privacy o policy IT più rigide. Tom’s Hardware ha riportato che il sistema richiede accesso a internet per attivazione, verifica stampanti e download firmware, ma poi opera interamente su LAN.
Questo passaggio è importante perché mostra una doppia direzione nella strategia Bambu Lab. Da un lato l’azienda spinge un ecosistema integrato, semplice, connesso a MakerWorld, Bambu Handy e Bambu Studio. Dall’altro deve offrire strumenti più controllabili a chi usa le stampanti in ambienti professionali, dove privacy, NDA e gestione locale dei file non sono opzionali.
Il problema, però, resta aperto per gli utenti che non vogliono adottare soltanto strumenti ufficiali. Una print farm può usare Bambu Farm Manager, ma uno sviluppatore open source può voler integrare la macchina in un flusso diverso. È qui che nasce la frizione tra sicurezza centralizzata e interoperabilità.
Una questione tecnica, ma anche culturale
Il caso Bambu Lab-OrcaSlicer mostra uno scontro tra due culture della stampa 3D desktop. La prima è quella maker/open source: l’utente compra la macchina, la studia, la modifica, cambia software, integra accessori, compila firmware, automatizza flussi e accetta una quota di rischio tecnico. La seconda è quella consumer: l’utente vuole una stampante che funzioni subito, con app, cloud, account, sincronizzazione e meno impostazioni da gestire.
Bambu Lab ha costruito gran parte del proprio successo proprio sulla seconda visione. Le sue stampanti sono diventate popolari perché riducono molte complessità tipiche della stampa 3D: calibrazione, velocità, gestione multi-materiale, profili, invio file, monitoraggio remoto. Ma il settore da cui Bambu Lab proviene è nato anche dalla prima visione, quella in cui software libero, modifiche e comunità hanno reso possibile l’evoluzione delle macchine desktop.
Questa tensione non è facile da risolvere. Se Bambu Lab lascia aperti troppi canali, aumenta il rischio di traffico anomalo, supporto ingestibile e problemi di sicurezza. Se chiude troppo, perde la fiducia degli utenti più tecnici, cioè proprio quelli che spesso influenzano recensioni, comunità, profili di stampa, modelli e consigli d’acquisto.
Che cosa significa AGPL in questo contesto
La licenza AGPL tutela la possibilità di usare, modificare e distribuire il codice del software, con obblighi di condivisione delle modifiche. Non garantisce però accesso illimitato a servizi online privati. Questo è il punto su cui Bambu Lab insiste: la licenza riguarda Bambu Studio come codice, non i server cloud come infrastruttura aziendale.
Dall’altra parte, la comunità nota che quando un’azienda costruisce un ecosistema commerciale sopra software derivato da progetti open source, deve aspettarsi che altri sviluppatori usino quello stesso codice per creare fork e funzioni alternative. OrcaSlicer, per esempio, indica chiaramente di essere AGPL-3.0 e di includere un plugin di rete Bambu basato su librerie non libere, opzionale rispetto al programma.
Il conflitto non nasce quindi dal principio astratto “open source sì o no”. Nasce dal punto di contatto tra codice aperto, plugin chiusi, server privati e stampanti fisiche già acquistate dagli utenti. È una zona grigia che molti produttori hardware stanno affrontando, non solo nella stampa 3D.
Perché il tema interessa anche chi non usa OrcaSlicer
Molti utenti non hanno mai compilato un fork e non hanno interesse a modificare codice. Per loro la domanda è più semplice: la stampante continuerà a funzionare come promesso anche tra tre, cinque o sette anni? Sarà possibile usarla senza cloud? Sarà possibile ripararla, controllarla in LAN, usarla con software esterni o gestirla se l’azienda cambia strategia?
La vicenda è importante perché le stampanti 3D desktop stanno diventando più simili ad altri prodotti connessi: smartphone, videocamere, elettrodomestici smart, stampanti 2D, robot domestici. Quando hardware e servizio online diventano inseparabili, il controllo si sposta dal proprietario della macchina al gestore della piattaforma.
Bambu Lab non è l’unica azienda a muoversi in questa direzione, ma è una delle più visibili nel settore consumer e prosumer. Per questo ogni cambiamento nel suo ecosistema viene osservato con attenzione. Le decisioni di Bambu Lab possono influenzare anche il comportamento di concorrenti, sviluppatori di slicer, produttori di accessori e comunità di modding.
Cosa potrebbe succedere ora
Nel breve periodo, Bambu Lab continuerà probabilmente a difendere Bambu Connect, LAN Mode e Developer Mode come compromesso tra sicurezza e apertura. Il progetto OrcaSlicer-BambuLab di Jarczak, nella forma contestata, non viene più distribuito dal repository originale. Lo sviluppatore ha indicato l’intenzione di concentrarsi su supporto BMCU per stampanti basate su Klipper, temendo che la compatibilità con l’ecosistema Bambu possa diventare più difficile.
La comunità, invece, continuerà a chiedere soluzioni più interoperabili: autenticazione locale documentata, API stabili, chiavi generate dalla stampante, modalità sviluppatore garantita e separazione più netta tra cloud opzionale e controllo della macchina. Non è detto che tutte queste richieste siano realistiche dal punto di vista della sicurezza e del supporto, ma sono coerenti con la tradizione open source della stampa 3D.
Per Bambu Lab, il rischio maggiore non è perdere tutti gli utenti tecnici. È perdere la percezione di fiducia che ha accompagnato l’ascesa del marchio. Chi compra una stampante 3D avanzata non valuta solo velocità, qualità e prezzo: valuta anche quanto il prodotto resterà controllabile nel tempo.
Un caso che riguarda il futuro della stampa 3D desktop
Il caso Bambu Lab-OrcaSlicer non va ridotto a una lite tra azienda e sviluppatore. È un segnale di maturazione del mercato. La stampa 3D desktop non è più composta solo da kit aperti, firmware modificabili e utenti disposti a passare ore in configurazione. Sta diventando un mercato di massa, dove molti clienti vogliono semplicità, assistenza, sicurezza e integrazione.
Ma la semplicità ha un costo: più l’esperienza viene centralizzata, più l’utente dipende da chi controlla l’ecosistema. Per alcuni è un compromesso accettabile. Per altri è una perdita di controllo su una macchina acquistata.
Bambu Lab ha ragioni tecniche quando sostiene di dover proteggere il proprio cloud. La comunità ha ragioni altrettanto concrete quando chiede che una stampante 3D resti utilizzabile, modificabile e integrabile senza dipendere da passaggi proprietari non documentati. La soluzione non arriverà da slogan, ma da scelte tecniche trasparenti: API chiare, modalità locali solide, documentazione per sviluppatori, comunicazione più precisa e limiti espliciti tra ciò che è open source e ciò che appartiene al servizio cloud.
Per ora, la vicenda lascia una lezione utile: nella stampa 3D moderna il software non è più un accessorio. È parte della macchina. E quando il software passa dal desktop al cloud, la domanda non è soltanto “che cosa posso stampare?”, ma “chi controlla davvero il percorso tra il file e la stampante?”.
