Jira, il software di tracciamento delle attività sviluppato da Atlassian, è nato nel 2002 come bug tracker per piccoli team di sviluppo software. Lo adottai nel 2004, due anni dopo il rilascio, quando era ancora uno strumento giovane e la comunità italiana dei suoi utilizzatori professionali si contava sulle dita di una mano. Da allora sono trascorsi oltre vent'anni di uso diretto, di configurazioni, di migrazioni, di formazione erogata a team di ogni tipo e dimensione.
Migliaia di organizzazioni nel mondo utilizzano ancora Jira. Eppure, tra i suoi utilizzatori professionali, è difficile trovare qualcuno che lo difenda con autentico entusiasmo. Più comune è l'atteggiamento di chi descrive un rapporto di dipendenza scomoda: l'abitudine rassegnata di chi convive con un vecchio mobile ingombrante che nessuno trova il tempo di consegnare al rigattiere. Questo saggio percorre due livelli di analisi. Il primo, concreto e operativo, riguarda le disfunzioni documentate di Jira, il suo modello economico e le alternative che il mercato ha già prodotto. Il secondo, teorico, riguarda i meccanismi epistemici, economici e culturali che inducono le organizzazioni a restare prigioniere di sistemi tecnologici che hanno esaurito la propria vita utile.
Se usi Jira tutti i giorni, ti sarà capitato di notare un paio di cose: la clessidra (o il cursore che gira, dipende da che tipo di computer stai usando) che ruota all'infinito, la pagina che si carica dopo diversi secondi, e dopo anche l'esperante l’attesa prima che il ticket si apra. Nel 2025, Easy Redmine riportava la testimonianza di un consulente italiano che sincronizzava le pause caffè con il riavvio di Jira, a causa dei lunghi tempi di attesa.
La lentezza ha conseguenze: studi nel Regno Unito mostrano che il 48% dei lavoratori perde tre ore o più al giorno per sistemi inefficienti. In contesti dove la velocità di aggiornamento dei task è fondamentale, uno strumento che crea attrito consuma energia organizzativa, come una piccola perdita d’olio in un motore che gira da anni: non blocca nulla, ma usura le parti in movimento.
Il successo di Jira è dovuto in parte al fatto che fino ad oggi non c'erano vere alternative, e in parte al fatto che è altamente flessibile, permettendo la personalizzazione di workflow, schemi di permesso, tipi di issue, campi personalizzati e regole di automazione. Questa versatilità richiede purtroppo anche una grande attenzione e manutenzione continua, operazioni di solito affidate agli Jira Administrator. Imparare a usare Jira può richiedere dalle due alle tre settimane per gli utenti non tecnici, mentre altre alternative richiedono solo poche ore. Se imparare uno strumento diventa un progetto a sé stante, forse è il momento di riconsiderarlo.
Un successo inspiegabile se si considera che Atlassian ha costruito il proprio modello commerciale su un principio semplice: vendere un prodotto dimezzato e far pagare il resto a parte. Il marketplace esiste per questo. Funzioni che qualsiasi alternativa include nel prezzo base, come il time tracking, la gestione delle roadmap, la reportistica di portafoglio o il calcolo della velocity, in Jira appartengono a plugin di terze parti, ciascuno con la propria licenza, calcolata per utente, con il proprio ciclo di aggiornamento e la propria traiettoria di prezzo. Un ambiente Jira funzionante dipende, nella pratica, da decine di prodotti aggiuntivi per coprire funzionalità che altrove sono già incluse.
A febbraio 2024, Atlassian ha chiuso il supporto per tutte le installazioni server on-premise. A ottobre 2024, i prezzi cloud sono saliti tra il 5% e il 10% per Jira Software e Confluence, e tra l'8% e il 20% per Jira Service Management. A febbraio 2025, il Data Center ha subito un aumento del 30%. A marzo 2026, Atlassian ha smesso di vendere nuove licenze Data Center ai nuovi clienti. La data finale, il 28 marzo 2029, prevede la messa in sola lettura di tutte le installazioni on-premise: da quel giorno, chi non è migrato al cloud ha un archivio, non uno strumento.
A luglio 2025 è arrivato il Maximum Quantity Billing. Il sistema addebita il picco di utenti attivi nel mese, non la media. Un'organizzazione che aggiunge dieci collaboratori temporanei per due settimane paga come se li avesse mantenuti per l'intero ciclo. La rimozione di un utente a metà mese non genera alcun credito prima del ciclo successivo. Sulla community Atlassian, nel marzo 2025, un utente che aveva appena ricevuto il preventivo di rinnovo ha scritto di essersi aspettato l'incremento del 5-10% annunciato in ottobre, e di aver trovato invece qualcosa di sostanzialmente diverso, che ha chiamato con precisione "rapina in piena regola". La moderazione lo ha rimandato al supporto billing. Nessun commento nel merito.
Facciamo un confronto tra piattaforme
Faccio adesso un confronto con le piattaforme concorrenti per far capire che soluzioni diverse producono risultati diversi. Linear si è affermato tra i team di ingegneria per la sua velocità di esecuzione senza rinunciare alla profondità funzionale. I tempi di risposta si misurano in millisecondi, la curva di apprendimento si esaurisce nell'ordine di ore. Asana ha risolto il problema della separazione tra team tecnici e non tecnici: la configurazione iniziale richiede minuti, e lo strumento risulta adottato da funzioni di marketing, risorse umane e operations senza formazione specializzata. ClickUp ha scelto la strada dell'integrazione: gestione delle attività, documenti, obiettivi, time tracking e comunicazione interna in un'unica piattaforma, con una riduzione strutturale del numero di abbonamenti paralleli che le organizzazioni tipicamente accumulano.
Per chi necessita di controllo completo sui dati, sovranità dell'infrastruttura o conformità normativa, l'ecosistema open source offre soluzioni di qualità enterprise. Tra tutti voglio citare OpenProject, sviluppato in Germania, che mette a disposizione funzionalità native di project management agile e classico, con gestione delle roadmap, tracciamento del tempo e dei costi, tutto disponibile senza plugin. Un accenno a Taiga, una applicazione ottimizzata per i team agile, supporta nativamente sprint, Kanban, epics e backlog, ed è disponibile sia come servizio cloud che in versione self-hosted. Entrambe sono conformi al GDPR, ospitate su infrastruttura europea, e prive di lock-in proprietario.
Le cifre parlano da sole. Il Data Center di Jira Software per 500 utenti ha un costo di licenza base di circa 51.000 dollari annui. Con tre plugin medi del marketplace, il totale indicativo sale agli 80.000-100.000 dollari annui, ai quali si aggiungono i costi di infrastruttura, di amministrazione di sistema e di supporto specializzato. Le alternative si collocano in fasce significativamente inferiori, con strutture di prezzo che eliminano la variabilità per utente. La differenza, calcolata su tre anni per un'organizzazione di medie dimensioni, si misura in decine o centinaia di migliaia di dollari. Un caso documentato da Businessmap nel settore bancario ha registrato 200.000 dollari di risparmio annuo, una riduzione dei tempi di delivery del 60% e un incremento di produttività superiore al 30% dopo la migrazione verso una piattaforma alternativa.
Purtroppo le organizzazioni che continuano a usare Jira lo fanno perché smettere è diventato, nel tempo, costoso e rischioso. Questa difficoltà ha spiegazione credo sufficientemente chiara nel concetto di path dependence, che è stato sviluppato in forma rigorosa dagli economisti Paul David e W. Brian Arthur negli anni Ottanta.
David, nel celebre articolo del 1985 "Clio and the Economics of QWERTY", ha mostrato come la disposizione di tasti ancora in uso sulle tastiere di tutto il mondo, progettata per le macchine da scrivere meccaniche degli anni Settanta dell'Ottocento allo scopo di ridurre le inceppature dei martelletti, abbia mantenuto la propria posizione dominante per oltre un secolo, anche quando le limitazioni ergonomiche erano documentate e le alternative tecnicamente superiori erano disponibili. La ragione risiede nei meccanismi che tengono in vita lo standard: la formazione, i materiali didattici, le aspettative dei datori di lavoro, la compatibilità con i sistemi esistenti. Arthur ha formalizzato questo meccanismo come increasing returns to adoption: una tecnologia, una volta raggiunta una massa critica di adozione, diventa progressivamente più vantaggiosa da adottare ulteriormente, indipendentemente dalle sue qualità intrinseche, perché cambiare produce costi di transizione che annullano i benefici attesi.
Sydow, Schreyögg e Koch, in un articolo del 2009 pubblicato sull'Academy of Management Review, hanno esteso questa teoria al livello organizzativo, distinguendo tre fasi del processo. La fase di apertura, in cui le scelte non sono ancora vincolate dalla storia. La fase di formazione del percorso, in cui le prime decisioni creano meccanismi auto-rinforzanti. La fase di lock-in, in cui il percorso è talmente consolidato da rendere ogni deviazione insostenibile. Il lock-in si produce per accumulo progressivo di irreversibilità, come una sedimentazione lenta di cui ci si accorge soltanto quando il terreno è già diventato roccia.
Ho fatto altre ricerche e ho trovato che Gernot Grabher, nel suo studio del 1993 sul declino industriale della Ruhr, ha distinto tre forme di lock-in che si sovrappongono e si rinforzano a vicenda.
Il lock-in funzionale riguarda le interdipendenze operative. Per tornare al mio esempio, una organizzazione che usa Jira da dieci anni porta con sé diverse di migliaia di ticket, centinaia di progetti, anni di commenti, allegati, workflow personalizzati, campi custom, storico delle modifiche, integrazioni con sistemi di CI/CD, repository di codice, strumenti di deployment e piattaforme di monitoraggio. Spostare questo patrimonio informativo verso un sistema alternativo è un'operazione che la letteratura tecnica descrive invariabilmente come complessa, rischiosa e lunga. Exalate, specializzata in migrazioni enterprise, avverte che le organizzazioni tendono a trattare la migrazione come un compito principalmente tecnico, mentre assicurarsi che il nuovo sistema soddisfi i requisiti operativi reali richiede molto più tempo del semplice trasferimento dei dati.
Il lock-in cognitivo riguarda le categorie mentali. Gli utenti e gli amministratori di sistema hanno interiorizzato i concetti, la terminologia e il modello mentale della piattaforma. Passare a un sistema alternativo significa, prima ancora che installare un nuovo software, ridefinire il modo in cui il team pensa al proprio lavoro.
Il lock-in politico, infine, riguarda le relazioni di potere interne. I team che presidiano la configurazione di Jira, i consulenti certificati Atlassian, i responsabili IT, molto spesso detengono un interesse personale nel mantenimento dello status quo. Ogni proposta di migrazione attraversa diversi strati di resistenza, spesso silenziosa e diffusa, prima di arrivare a una decisione formale.
Le organizzazioni che mantengono sistemi legacy accumulano nel frattempo quello che nel settore informatico si chiama debito tecnico: la distanza crescente tra lo stato attuale di un sistema e lo stato che sarebbe necessario per sostenere le esigenze operative correnti. Ne ho già parlato in un altro articolo sempre qui sulla Stultifera Navis.
Il debito tecnico si configura come il debito finanziario: richiede pagamenti di interessi crescenti, sotto forma di patch di sicurezza, aggiustamenti improvvisati, integrazioni artigianali e costi di supporto elevati, senza mai ridurre il capitale. Le organizzazioni che più avrebbero bisogno di modernizzarsi sono spesso quelle che meno possono permetterselo, perché la quota del budget già impegnata nella manutenzione dell'esistente non lascia spazio per finanziare la transizione.
Accanto ai costi visibili, esistono costi nascosti che raramente entrano nei calcoli formali del TCO ma che pesano sul funzionamento quotidiano delle organizzazioni. Ne ho parlato sulla Stultiferanavis qui e in qui.
Il primo è il costo dell'adattamento mentale. Le organizzazioni, nella grande maggioranza dei casi, configurano i propri processi per adattarli a Jira, con una deformazione silenziosa dei metodi di lavoro che tende a privilegiare ciò che lo strumento rende facile a scapito di ciò che il business richiederebbe.
Il secondo è il costo del capitale umano. Il Jira Administrator è una figura professionale che esiste perché lo strumento la richiede, visibile nei bilanci come voce di personale ma raramente ricondotta alla sua causa.
Il terzo è il costo del carico cognitivo. La ricerca in psicologia del lavoro ha documentato che le interfacce inefficienti producono un affaticamento supplementare che si traduce in riduzione della concentrazione e aumento degli errori. Lavorare quotidianamente con uno strumento lento e ridondante ha un costo reale, sostenuto prima dalle persone che dalle organizzazioni, e quasi mai presente nelle metriche di produttività.
Il quarto è il costo dell'inibizione metodologica. Quando la gestione del lavoro diventa essa stessa un vincolo operativo, l'organizzazione perde la capacità di sperimentare nuovi approcci. I team che adottano Linear o ClickUp riferiscono spesso di aver cambiato il proprio modo di concepire il lavoro, liberando possibilità che l'architettura rigida di Jira aveva sempre impedito di esplorare.
C'è un aspetto del fenomeno che ho provato ad approfondire, perché tocca direttamente la questione che mi ha portato a scrivere per la Stultifera Navis. Nelle organizzazioni che continuano a usare Jira nel 2026, la valutazione razionale della situazione esiste. I responsabili tecnici sanno che le alternative sono migliori. I responsabili finanziari vedono i preventivi di rinnovo crescere ogni anno. Gli utenti esprimono frustrazione quotidiana. La conoscenza del problema non manca. Eppure il comportamento prevalente è il rinnovo automatico dei contratti, il rinvio del cambiamento, la tolleranza del disagio degli utenti.
Karl Weick, nel suo lavoro sull'organizzazione come processo di sensemaking, ha descritto con precisione il fenomeno delle organizzazioni che sviluppano una consapevolezza della propria situazione senza riuscire ad agire su di essa. La conoscenza rimane inerte perché priva dei meccanismi istituzionali, finanziari e culturali necessari per trasformarsi in decisione. La scelta di non cambiare si produce per inerzia, per assenza di un riferimento autorevole che sostenga il cambiamento, per la percezione di una migrazione irta di rischi e priva di un agente che la animi.
La metafora geologica proposta da Varanini, Melgrati, Nastri e Flacco in un'analisi dell'adozione ICT nelle imprese italiane del 2005 secondo me descrive con precisione questa struttura. Il lavoro del ricercatore intento a studiare la relazione tra ICT e imprese, osservano gli autori, è paragonabile a quello del geologo che, studiando i diversi strati di roccia sedimentati l'uno sull'altro, ricostruisce le ere che hanno caratterizzato la storia di un territorio. Ogni grande organizzazione informaticamente matura presenta questa stratigrafia: sistemi sovrapposti, ciascuno introdotto per rispondere a una necessità specifica, nessuno mai rimosso, tutti ancora attivi, ciascuno con le proprie integrazioni, i propri responsabili, i propri utenti. Jira è, in molte organizzazioni, uno degli strati intermedi: non il più antico, ma già abbastanza sedimentato da essere difficile da estrarre senza compromettere ciò che vi si appoggia sopra.
La letteratura sulla path dependence offre una serie di precedenti che corroborano le mie ricerche. Robin Cowan, in un articolo del 1990 pubblicato sull'Economic Journal, ha mostrato come il design dei reattori nucleari civili a "acqua leggera" si sia affermato come standard globale non per superiorità tecnica, bensì perché era il design già sviluppato per i sottomarini nucleari americani durante la Guerra Fredda. La necessità politica di dimostrare usi pacifici dell'energia nucleare aveva imposto un'accelerazione che aveva precluso la valutazione sistematica delle alternative.
I binari ferroviari offrono un esempio ancora più istruttivo. Il calibro standard mondiale, 1.435 millimetri, coincide con quello scelto da George Stephenson per la ferrovia Liverpool-Manchester del 1830, derivato a sua volta dalla larghezza dei carri romani. Oltre la metà delle ferrovie mondiali usa oggi quel calibro non perché gli ingegneri contemporanei lo ritengano ottimale, ma perché il costo di riconversione dell'intera infrastruttura ferroviaria mondiale supera di gran lunga qualunque beneficio tecnico ottenibile. Il software enterprise segue la stessa logica. Jira è il calibro ferroviario delle organizzazioni che lo adottarono nei primi anni Duemila, quando era genuinamente innovativo. Il peso delle configurazioni, delle integrazioni, dei dati storici e della competenza accumulata ha trasformato una scelta contingente in un vincolo strutturale.
Tra le mie ricerche, ad un certo punto è spuntato anche un testo di Francesco Varanini del 2015 intitolato "Avventure informatiche". Dato che io per molti anni, prima di adottare Jira, ero considerato un valido esperto di Lotus Domino & Notes, ho deciso di inserire una nota in questo articolo, perché mi trovo concorde con l'autore. Varanini osserva che, vent'anni dopo una certa adozione tecnologica, in grandi organizzazioni si sudava sangue per dismettere Lotus Notes, da tempo una evidente palla al piede. Il sistema di groupware di IBM, adottato massicciamente negli anni Novanta, ha resistito nelle grandi organizzazioni per decenni oltre la propria utilità effettiva, per ragioni strutturalmente identiche a quelle che tengono in vita Jira oggi. La storia si ripete.
L'annuncio della fine del supporto al Data Center ha prodotto, per ironia, un effetto non previsto: ha reso esplicita la natura del rapporto tra Atlassian e i propri clienti enterprise. Molte organizzazioni che avrebbero continuato a rinnovare passivamente hanno avviato valutazioni delle alternative proprio perché l'evento di fine vita ha costretto una ricognizione che altrimenti non avrebbe mai avuto luogo. La creazione di urgenza senza panico, la pressione verso il cloud proprietario piuttosto che verso la concorrenza, appartiene a una strategia che trasforma la dipendenza tecnologica in rendita.
Nella maggior parte dei casi documentati, il cambiamento si produce o per shock esterno, un evento dirompente che rende il costo dell'inazione superiore al costo del cambiamento, o per l'emergere di un agente interno dotato di sufficiente autorità e risorse per rompere il circolo auto-rinforzante. Esiste però una condizione più favorevole: quella delle organizzazioni che sviluppano una cultura della revisione periodica dei propri strumenti, imparando a distinguere tra il valore operativo corrente di un sistema e il peso storico della sua adozione. Questa capacità si può chiamare alfabetizzazione epistemica strumentale. Consiste nel saper guardare gli strumenti come artefatti che mediano il rapporto con il lavoro, e che vanno quindi sottoposti alla stessa valutazione critica applicata ai metodi, ai processi e alle strutture organizzative.
Ho trovato che André Leroi-Gourhan, scrive nel suo studio sull'evoluzione degli strumenti tecnici, che ogni utensile porta con sé la logica del problema che dovrebbe servire a risolvere, diciamo per semplificare. Provo a spiegarmi meglio, quando il problema cambia, l'utensile resta, come forma sedimentata di una necessità passata, finché qualcuno decide di sostituirlo con qualcosa che risponde alla necessità presente. Jira risponde ancora molto bene alla necessità del 2002: tracciare bug in un piccolo team di sviluppo software collocato fisicamente nello stesso ufficio. Risponde con crescente difficoltà alle necessità impellenti odierne: coordinare team distribuiti e compositi, che lavorano su prodotti complessi con cicli di feedback rapidi e una necessità di integrazione trasparente tra funzioni tecniche e non tecniche.
Non scrivo una conclusione, perché non c'è. Lo scopo di questo scritto è quello di stimolare la riflessione e sollecitare una decisione, laddove è necessario ma anche, lo ammetto candidamente, di esercitarmi con la funzione "Referenze Stultifere" di recente messa a disposizione degli autori.
Bibliografia
Arthur, W. Brian. "Competing Technologies, Increasing Returns, and Lock-In by Historical Events." The Economic Journal 99, n. 394 (1989): 116–131.
Arthur, W. Brian. Increasing Returns and Path Dependence in the Economy. Ann Arbor: University of Michigan Press, 1994. ISBN: 978-0472064953.
Cowan, Robin. "Nuclear Power Reactors: A Study in Technological Lock-In." The Economic Journal 100, n. 401 (1990): 541–567.
David, Paul A. "Clio and the Economics of QWERTY." American Economic Review 75, n. 2 (1985): 332–337.
Grabher, Gernot. "The Weakness of Strong Ties: The Lock-In of Regional Development in the Ruhr Area." In The Embedded Firm: On the Socioeconomics of Industrial Networks, a cura di Gernot Grabher, 255–277. Londra: Routledge, 1993. ISBN: 978-0415079754.
Leroi-Gourhan, André. Il gesto e la parola. Tecnica e linguaggio. Torino: Einaudi, 1977. ISBN: 978-8806347369. [Ed. orig.: Le Geste et la Parole, Parigi: Albin Michel, 1964–1965.]
Sydow, Jörg, Georg Schreyögg e Jochen Koch. "Organizational Path Dependence: Opening the Black Box." Academy of Management Review 34, n. 4 (2009): 689–709.
Varanini, Francesco, Alberto Melgrati, Antonio Nastri e Federico Flacco. L'Information & Communication Technology al servizio dell'azienda. Appunti in merito allo scenario emergente. Documento di lavoro, 2005. Disponibile qui
Vergne, Jean-Philippe e Rodolphe Durand. "The Missing Link Between the Theory and Empirics of Path Dependence: Conceptual Clarification, Testability Issue, and Methodological Implications." Journal of Management Studies 47, n. 4 (2010): 736–759.
Weick, Karl E. Sensemaking in Organizations. Thousand Oaks: Sage Publications, 1995. ISBN: 978-0803971776.
Webografia
Atlassian Community. "Massive Price Increase for Jira Cloud Enterprise and Apps?" Discussione pubblica, marzo 2025.
Easy Redmine. "Key Risks in Jira Data Migration and How to Overcome Them." Settembre 2025.
Getint..Jira Data Center End of Life: What It Means for Enterprises." 2025.
Mechanical Orchard. "$1.14 Trillion to Keep the Lights on: Legacy's Drag on Productivity." 2023.
OpenProject. "Alternative to Atlassian Jira Data Center." 2025.
Varanini, Francesco. "Avventure informatiche." Blog personale, ottobre 2015.