Indice dei contenuti
Per anni abbiamo dato quasi per scontato un modello: se ti serviva un software professionale, dovevi scegliere tra pagare una licenza, sottoscrivere un abbonamento oppure accontentarti di un’alternativa gratuita, magari valida ma con un’interfaccia diversa e qualche compromesso.
Poi arriva uno sviluppatore che, dopo essersi stancato delle politiche di abbonamento di Adobe, decide di usare l’intelligenza artificiale per costruire alternative open source ai principali strumenti della Creative Cloud. E, pochi giorni dopo, aggiunge anche applicazioni ispirate a Word, Excel e PowerPoint.
Il progetto si chiama ArtCraft, il linguaggio scelto è Rust e l’AI utilizzata nello sviluppo è Claude. Le applicazioni sono disponibili pubblicamente e il progetto propone anche un launcher che consente di installarle e mantenerle aggiornate.
La prima reazione è quasi inevitabile: se oggi una persona può tentare di ricreare software che hanno richiesto anni di lavoro e team numerosi, che cosa succederà al mercato delle applicazioni commerciali?
La risposta, secondo me, è più interessante di un semplice “il software a pagamento è finito”. Per capirla, vale la pena guardare a ciò che è stato realizzato, ai suoi limiti e soprattutto al cambiamento che questo esperimento rappresenta. 🚀
Che cos’è ArtCraft e perché se ne parla?
ArtCraft è un progetto che raccoglie applicazioni open source pensate per offrire funzionalità simili a quelle di strumenti commerciali conosciuti. La prima ondata ha riguardato software creativi associati al mondo Adobe; successivamente sono arrivate applicazioni ispirate alla suite Microsoft Office.
Tra i nomi più riconoscibili troviamo:
- PhotoCraft: editor di immagini ispirato a Photoshop.
- VectorCraft: strumento di illustrazione vettoriale ispirato a Illustrator.
- FilmCraft: editor video ispirato a Premiere Pro.
- LightCraft: gestione e sviluppo fotografico ispirati a Lightroom.
- EffectCraft: strumenti per effetti visivi e motion graphics.
- DesignCraft: impaginazione e publishing.
- PdfCraft: strumenti per lavorare con documenti PDF.
- WordCraft: elaborazione testi ispirata a Word.
- GridCraft: fogli di calcolo ispirati a Excel.
- DeckCraft: presentazioni ispirate a PowerPoint.
Il progetto si è poi esteso ad altre categorie di software. L’elenco e lo stato delle singole applicazioni possono cambiare con l’avanzare dello sviluppo, quindi conviene consultare la pagina ufficiale per verificare quali strumenti siano effettivamente disponibili e a quale stadio si trovino.
Puoi esplorare il progetto qui: ArtCraft — applicazioni open source.
Secondo la presentazione del progetto, le applicazioni sono scritte in Rust, vengono distribuite per i principali sistemi desktop e, per alcuni strumenti, sono disponibili anche versioni utilizzabili dal browser tramite WebAssembly. Il launcher permette di installare le app e gestirne gli aggiornamenti.
È un dettaglio importante: non stiamo parlando soltanto di una demo generata in una chat, ma di un tentativo di trasformare il codice prodotto con l’aiuto dell’AI in applicazioni installabili e utilizzabili.
Reverse engineering: è stata davvero copiata tutta Adobe?
Qui conviene fermarsi un momento, perché la formulazione delle notizie può creare un equivoco.
Nel linguaggio comune si parla spesso di “reverse engineering” quando qualcuno cerca di capire come funziona un software esistente per realizzare un’alternativa compatibile. Questo non significa necessariamente decompilare il programma originale, estrarne il codice e ripubblicarlo.
Nel caso di ArtCraft, il progetto viene presentato come una serie di reimplementazioni indipendenti: l’obiettivo è ricreare comportamenti e strumenti simili, utilizzando codice nuovo e facendo riferimento al comportamento osservabile, alle specifiche pubbliche e ad altre informazioni disponibili.
La distinzione è sostanziale. Il codice originale di Photoshop, Premiere, Word o Excel non viene semplicemente trasformato in Rust e pubblicato come open source. L’ambizione è costruire applicazioni alternative che offrano funzionalità analoghe.
Questa differenza non elimina automaticamente ogni questione legale. Interfacce, marchi, risorse grafiche, brevetti, licenze e modalità di implementazione possono sollevare problemi specifici, che dipendono dai dettagli del progetto e dalla giurisdizione. Per questo non è corretto affermare che qualsiasi clone sia sempre legale, né che ogni reimplementazione costituisca automaticamente una violazione.
Per un approfondimento giornalistico sul progetto e sulle questioni ancora aperte puoi leggere l’analisi di Ars Technica su ArtCraft e le alternative open source ad Adobe.
Perché l’intelligenza artificiale cambia le regole del gioco
Il punto più interessante non è che l’AI sappia scrivere codice. Questa capacità è ormai parte del lavoro quotidiano di molti sviluppatori. La novità è la possibilità di ridurre drasticamente il costo di una parte del processo necessario per costruire un’applicazione complessa.
Tradizionalmente, realizzare un software professionale richiede un insieme molto ampio di competenze e attività:
- analisi dei requisiti e progettazione dell’architettura;
- sviluppo dell’interfaccia e delle interazioni;
- implementazione delle funzionalità principali;
- gestione dei formati di file e della compatibilità;
- test, correzione dei bug e verifica delle prestazioni;
- documentazione, distribuzione e aggiornamenti;
- supporto agli utenti e manutenzione nel lungo periodo.
Un coding agent può contribuire a molte di queste attività. Può analizzare un comportamento, proporre un’implementazione, generare codice, scrivere test, correggere errori e ripetere il ciclo di sviluppo con una velocità che sarebbe difficile ottenere con il solo lavoro manuale.
Questo non significa che l’AI possa sempre completare correttamente ogni passaggio in autonomia. Significa però che una persona competente può tentare progetti molto più ambiziosi di quelli che avrebbe potuto affrontare da sola con gli strumenti tradizionali.
È proprio questo il cambiamento che ArtCraft rende visibile: un singolo sviluppatore, con l’aiuto di un modello avanzato e di un processo di lavoro adeguato, può provare a competere in categorie di prodotto che fino a poco tempo fa sembravano fuori portata.
Rust, app leggere e un launcher: perché la distribuzione conta
Uno degli aspetti che colpiscono del progetto è la scelta di Rust per realizzare applicazioni desktop native. Rust offre prestazioni elevate e strumenti per prevenire diverse categorie di errori legati alla gestione della memoria. È una scelta interessante per software che lavorano con immagini, video, documenti e altri contenuti complessi.
Naturalmente, usare Rust non garantisce automaticamente che un’applicazione sia veloce, sicura o leggera. Le prestazioni dipendono dall’architettura, dagli algoritmi, dalle dipendenze e dalla qualità dell’implementazione. Un programma scritto in un linguaggio performante può comunque avere bug, consumare molte risorse o gestire male file di grandi dimensioni.
La scelta tecnologica è soltanto una parte della storia. L’altra è la distribuzione.
Un launcher che permette di scaricare le applicazioni e mantenerle aggiornate rende il progetto più accessibile. L’utente non deve necessariamente clonare un repository, installare un compilatore o imparare a costruire il software dai sorgenti prima di provarlo.
È un aspetto spesso sottovalutato nei progetti open source: il codice può essere liberamente disponibile, ma se installazione, aggiornamenti e documentazione sono complicati, molti utenti non arriveranno mai a utilizzarlo davvero.
ArtCraft cerca di ridurre questa distanza tra repository e applicazione pronta all’uso. La pagina ufficiale descrive il launcher e rimanda anche agli installer delle singole app: consulta le opzioni di installazione di ArtCraft.
Ma queste applicazioni sono già alternative valide ad Adobe e Microsoft?
Questa è la domanda più importante per chi vorrebbe abbandonare un abbonamento costoso.
La risposta prudente è: non bisogna confondere una reimplementazione promettente con un prodotto già pronto per ogni utilizzo professionale.
Riprodurre l’aspetto di un’applicazione è soltanto una parte del lavoro. Un software maturo deve gestire migliaia di casi d’uso, documenti reali, formati complessi, periferiche, scorciatoie, operazioni annullabili, prestazioni sotto carico e comportamenti che emergono soltanto dopo anni di utilizzo.
Per un editor di immagini, per esempio, non basta visualizzare livelli e strumenti simili a quelli di Photoshop. Bisogna verificare la compatibilità con file PSD complessi, maschere, profili colore, metadati, font, filtri, livelli di regolazione ed esportazioni.
Per un foglio di calcolo, non basta disegnare una griglia e consentire di inserire formule semplici. Servono compatibilità con file esistenti, formule, grafici, formattazioni, macro quando previste, importazione ed esportazione affidabili.
Per un editor di documenti, la vera prova è aprire file DOCX reali, con tabelle, immagini, stili, commenti, impaginazioni e oggetti incorporati, e verificare che il risultato rimanga fedele.
Le prime versioni di ArtCraft sono state descritte dalla stampa come software ancora in fase iniziale, con funzionalità mancanti e differenze rispetto ai prodotti maturi. Anche le singole applicazioni non avanzano tutte allo stesso ritmo.
Perciò, prima di utilizzarle per un lavoro importante, controlla lo stato di sviluppo della specifica app, la sua roadmap e i problemi aperti. Puoi consultare anche la prova di The Register dedicata a WordCraft, che evidenzia proprio la differenza tra un’alternativa promettente e un prodotto già pronto per carichi di lavoro professionali.
Il vero valore potrebbe essere il tempo necessario per arrivare a una prima versione
Quando si parla di queste applicazioni, il dibattito finisce spesso su una domanda: “Funzionano già meglio degli originali?”. È una domanda legittima, ma forse non è quella che permette di capire meglio la portata dell’esperimento.
Una domanda altrettanto interessante è: quanto tempo e quante risorse servono oggi per costruire una prima alternativa utilizzabile a un software commerciale?
Se un progetto che un tempo avrebbe richiesto un gruppo di sviluppatori per un periodo prolungato può raggiungere una prima versione in tempi molto più brevi, cambiano le possibilità per startup, piccoli team, sviluppatori indipendenti e comunità open source.
Il costo di creare una prima implementazione può scendere molto più velocemente del costo di mantenere un prodotto affidabile. È una distinzione fondamentale.
Scrivere una prima versione è soltanto l’inizio. Poi bisogna correggere bug, mantenere la compatibilità con nuovi formati, adattarsi ai sistemi operativi, rispondere alle segnalazioni e impedire che il progetto si trasformi in un accumulo di codice difficile da mantenere.
L’AI può accelerare anche queste fasi, ma non le elimina. La qualità del risultato dipende dalla capacità di guidare gli agenti, verificare il codice, progettare test efficaci e decidere quali compromessi siano accettabili.
Stiamo davvero arrivando alla fine del software a pagamento?
È la provocazione più forte che emerge da questa vicenda. Se ricreare un’applicazione diventa più semplice, perché continuare a pagare per un prodotto commerciale?
Secondo me, la risposta è che non stiamo necessariamente andando verso la fine del software a pagamento, ma verso un mercato in cui sarà più difficile giustificare il prezzo soltanto con il possesso di una funzionalità.
Per molti anni, realizzare un’applicazione complessa richiedeva investimenti importanti. Questo creava una barriera d’ingresso che proteggeva i prodotti consolidati. Se il costo iniziale di sviluppo scende, nuovi concorrenti possono tentare di entrare in mercati che prima erano difficilmente accessibili.
Ma un cliente non acquista soltanto codice. Spesso paga per un insieme di elementi che sono più difficili da replicare di una schermata:
- Affidabilità: il software deve funzionare in modo prevedibile anche nei casi meno comuni.
- Compatibilità: deve aprire correttamente i file già presenti nei flussi di lavoro degli utenti.
- Assistenza: quando qualcosa si rompe, qualcuno deve poter intervenire.
- Aggiornamenti: il prodotto deve adattarsi a sistemi operativi, formati e standard che cambiano.
- Integrazioni: deve funzionare con gli altri strumenti utilizzati da un’organizzazione.
- Responsabilità: in un contesto aziendale, qualcuno deve rispondere della continuità del servizio e della gestione dei problemi.
Un programma gratuito può essere perfettamente sufficiente per un uso personale. In un ambiente professionale, invece, il costo di un’interruzione, di un documento danneggiato o di un flusso di lavoro incompatibile può superare rapidamente quello dell’abbonamento.
Questo non significa che il software commerciale abbia sempre un valore proporzionato al prezzo. Significa che il prezzo deve essere confrontato con il valore reale del prodotto, non soltanto con la presenza di un’alternativa gratuita.
Il modello dell’abbonamento potrebbe essere quello più esposto
Un aspetto interessante riguarda la differenza tra pagare per un software e pagare per un servizio continuativo.
Se un’applicazione svolge principalmente operazioni locali e le sue funzioni possono essere riprodotte da un progetto open source, diventa più difficile convincere un utente a sostenere un abbonamento soltanto per accedere a quelle funzioni.
La pressione competitiva potrebbe essere particolarmente forte per:
- strumenti desktop con funzionalità relativamente circoscritte;
- applicazioni per produttività personale;
- utility tecniche e convertitori di formato;
- editor e strumenti di elaborazione con requisiti ben definiti;
- software che dipendono soprattutto da un’interfaccia e da operazioni ripetibili.
Questo non vuol dire che tutti questi prodotti siano facili da ricreare completamente. Vuol dire che un concorrente può iniziare offrendo un sottoinsieme delle funzioni e crescere in base alle esigenze degli utenti.
Al contrario, i servizi che offrono collaborazione in tempo reale, infrastrutture cloud, librerie di contenuti, sincronizzazione, supporto professionale o integrazioni complesse hanno altre componenti da mantenere. In questi casi, anche se l’applicazione è open source, il servizio può continuare ad avere un valore economico significativo.
Open source non significa necessariamente gratis per sempre
Un’altra distinzione importante riguarda il modello economico.
Un software open source può essere gratuito da scaricare e utilizzare, ma il suo sviluppo ha comunque dei costi. Qualcuno deve correggere i bug, gestire le richieste, mantenere le infrastrutture, verificare la sicurezza e preparare le release.
Esistono diversi modelli sostenibili:
- Donazioni e sponsorizzazioni: gli utenti e le aziende finanziano il progetto.
- Supporto professionale: il codice è disponibile, ma assistenza e garanzie vengono offerte a pagamento.
- Funzioni cloud: l’applicazione di base è gratuita, mentre servizi remoti e sincronizzazione possono essere a pagamento.
- Servizi aggiuntivi: il software resta open source, mentre vengono venduti strumenti, modelli o funzionalità opzionali.
Anche ArtCraft distingue tra le applicazioni open source e alcune funzionalità di generazione basate su modelli AI, per le quali possono essere previste condizioni commerciali separate. È un esempio di come il codice gratuito e un’attività economica possano convivere.
Il punto non è eliminare ogni forma di monetizzazione, ma rendere più chiaro che cosa si sta pagando e quale valore aggiuntivo si riceve.
Ci sono anche rischi: il codice generato dall’AI va verificato
La velocità con cui si può produrre software è impressionante, ma introduce un rischio evidente: la facilità di generare codice può superare la capacità di controllarlo.
Un’applicazione può sembrare completa perché l’interfaccia è rifinita, i menu si aprono e le funzioni principali sembrano funzionare. Questo non dimostra che sia pronta per gestire documenti importanti o dati riservati.
Prima di affidare a un’applicazione nuova il proprio lavoro, è ragionevole verificare:
- la licenza del progetto e delle sue dipendenze;
- la provenienza degli installer e degli aggiornamenti;
- la gestione dei file locali e degli eventuali servizi remoti;
- le modalità di telemetria e raccolta dei dati, se presenti;
- la frequenza degli aggiornamenti e la risposta ai problemi segnalati;
- la compatibilità con i formati che utilizzi davvero;
- la presenza di test, documentazione e procedure di segnalazione delle vulnerabilità.
Quando si tratta di software che apre file ricevuti da altre persone, come documenti, immagini o archivi, è particolarmente importante considerare anche la sicurezza del parser e la gestione dei contenuti potenzialmente malevoli.
Il fatto che un progetto sia open source permette di esaminare il codice, ma non garantisce automaticamente che qualcuno lo abbia controllato in modo approfondito. E il fatto che sia stato scritto con l’aiuto di un modello AI non lo rende, da solo, né sicuro né insicuro.
Che cosa significa tutto questo per chi sviluppa software?
Per chi lavora nello sviluppo web, nelle integrazioni di sistema o nella realizzazione di applicazioni personalizzate, la lezione è concreta.
Se il codice diventa più economico da produrre, il valore del lavoro si sposta sempre più verso le decisioni che determinano se quel codice risolve davvero un problema.
Un cliente non ha bisogno soltanto di una schermata che sembra funzionare. Ha bisogno di un sistema che si integri con i processi esistenti, gestisca gli errori, protegga i dati, possa essere aggiornato e continui a funzionare quando cambiano le condizioni.
In questo scenario diventano ancora più importanti:
- la capacità di tradurre un’esigenza reale in requisiti verificabili;
- la progettazione di architetture semplici da mantenere;
- la conoscenza delle tecnologie e dei loro limiti;
- i test automatici e la revisione del codice generato;
- la sicurezza applicativa e la gestione dei permessi;
- la documentazione e la manutenzione nel lungo periodo.
In altre parole, l’AI può aiutare a costruire molto più velocemente, ma qualcuno deve comunque sapere che cosa costruire, come verificarlo e come mantenerlo.
Come provare ArtCraft senza confondere una demo con uno strumento di produzione
Se vuoi esplorare il progetto, il modo più sensato è partire da un’attività semplice e non critica.
- Consulta la pagina ufficiale: verifica quali applicazioni sono disponibili e in quale fase di sviluppo si trovano.
- Scarica il software soltanto dai canali ufficiali: evita pacchetti ripubblicati da siti sconosciuti.
- Leggi la licenza: controlla le condizioni applicabili al progetto e alle componenti utilizzate.
- Prova con copie dei tuoi file: non iniziare da un documento di lavoro importante o dall’unica copia di un progetto.
- Confronta il risultato: apri lo stesso file nell’applicazione originale o in un’alternativa consolidata e controlla differenze, esportazioni e funzionalità.
- Verifica gli aggiornamenti: controlla le note di rilascio e la gestione delle versioni.
Puoi iniziare da getartcraft.com/apps e consultare il repository GitHub del progetto ArtCraft.
Un’ultima cautela: se un’applicazione è ancora in fase iniziale, non utilizzarla come unico strumento per attività professionali critiche finché non hai verificato che soddisfi i requisiti di affidabilità, compatibilità e sicurezza di cui hai bisogno.
Conclusione: forse non è la fine del software, ma l’inizio di un mercato diverso
La storia di ArtCraft è affascinante perché mostra quanto sia cambiato il rapporto tra competenze individuali e ambizione tecnica. Un singolo sviluppatore può oggi tentare di costruire alternative a prodotti che hanno alle spalle anni di lavoro, team numerosi e investimenti importanti.
Non significa che quelle alternative siano già equivalenti agli originali, né che gli abbonamenti software scompariranno domani. La distanza tra una prima versione e un prodotto professionale resta significativa, e mantenere un’applicazione nel tempo è un lavoro a tutti gli effetti.
Ma la barriera per entrare nel mercato si sta abbassando. Se creare un’alternativa diventa più accessibile, anche le aziende consolidate dovranno dimostrare con maggiore chiarezza perché vale la pena pagare per i loro prodotti.
Personalmente, trovo questa prospettiva molto stimolante: non tanto perché il software debba diventare tutto gratuito, ma perché gli utenti potrebbero avere più scelta, più controllo e meno dipendenza da un singolo fornitore.
La vera domanda, quindi, non è se l’AI eliminerà tutto il software a pagamento. È se renderà sempre più difficile vendere un prodotto soltanto perché costruirne uno alternativo era, fino a ieri, troppo costoso o complicato.
E se la risposta fosse sì, il cambiamento potrebbe essere molto più grande di una nuova suite di applicazioni open source. 💡