Da quando ho iniziato a lavorare, insieme alla mia azienda, al progetto europeo per la sovranità digitale, sto capendo una cosa che prima intuivo soltanto: sull’open source si è abbattuto un disastro di proporzioni epocali.

La versione enterprise.

Succede essenzialmente questo. Tu lavori a un software capace, almeno in apparenza, di unificare qualcosa, centralizzarlo, consolidarlo. Un software che fa esattamente quello che dovrebbe fare: prende una situazione in cui prima avevi, che so io, decine di persone che gestivano ticket, ciascuna con il proprio processo dipartimentale, con il proprio lessico, le proprie eccezioni, le proprie abitudini locali, e la porta dentro un sistema coerente.

Installi il nostro meraviglioso software OSS, ed ecco che i processi diventano finalmente comparabili. Non necessariamente identici in ogni dettaglio, ma almeno parlano la stessa lingua. Usano la stessa terminologia, lo stesso ciclo di vita, gli stessi stati, gli stessi passaggi, la stessa idea generale di “aperto”, “in lavorazione”, “chiuso”, “rifiutato”, “assegnato”, e così via.

Insomma: il software semplifica. Consolida. Riduce il casino.

Bene.

Poi arriva il mondo enterprise.

"Si puo' avere cosi', ma multitenant"?

E lì succede che la moglie di Manager A è diventata “multi tenant”, e uno dei nuovi tenant è Manager B. Funziona anche coi mariti, sia chiaro: il modello è perfettamente gender neutral. Comunque, succede che un coniuge diventi multitenant, e improvvisamente ci sono due manager che non si possono più vedere.

A quel punto, per una di quelle misteriose leggi non scritte dell’organizzazione aziendale, la multitenancy coniugale produce una richiesta tecnica. Al board che gestisce la roadmap dell’OSS arriva infatti una richiesta serissima, redatta nel linguaggio sacro del management:

“Per ragioni organizzative legate a <mettete qui una buzzword>, la nostra enorme azienda ha preso la decisione strategica di adottare soltanto software che lavorino in modalità multitenant. Volevamo quindi sapere se questa funzionalità sia già prevista nella vostra roadmap, oppure se possa essere presa in considerazione per una futura release.”

La risposta corretta sarebbe:

“No, guarda, questo è un software che nasce per semplificare qualcosa, per eliminare differenze inutili di processo, per consolidare procedure che prima erano sparse, incoerenti e dipartimentali. Quindi il fatto che il coniuge di un manager sia diventato o diventata multitenant non implica, automaticamente, che anche la nostra applicazione debba diventarlo.”

Perché il punto è esattamente questo. Il software era nato per ridurre la frammentazione, non per istituzionalizzarla. Era nato per togliere eccezioni, non per trasformare ogni eccezione in una feature. Era nato per dire: “Adesso lavoriamo tutti dentro lo stesso modello”, non per dire: “Creiamo un universo separato per ogni principino aziendale, con le sue regole, i suoi permessi, le sue visibilità, le sue eccezioni, i suoi piccoli feudi e i suoi traumi sentimentali travestiti da requisito architetturale.”

Ma questa risposta non si può dare.

Perché il Cuckold Management dell’azienda non sa gestire la multitenancy dei coniugi come dovrebbe, e quindi pretende che il software rifletta la stessa patologia organizzativa. Se non gli date lo stesso multitenant dei coniugi, minacciano di “scegliere un altro prodotto”.

E questa frase, nel mondo enterprise, è l’equivalente del pulsante rosso.

A quel punto partono le pressioni. Qualcuno comincia a dire che “il cliente è importante”. Qualcun altro osserva che “in fondo la multitenancy potrebbe servire anche ad altri”. Un altro ancora propone di “non chiudere la porta a una possibile evoluzione architetturale”. E così, poco alla volta, un software nato per semplificare viene spinto a diventare il contrario di se stesso: una macchina per replicare, in forma tecnica, tutte le disfunzioni politiche, personali e gerarchiche dell’azienda che lo vuole adottare.

Perché l’enterprise non compra software.

Compra specchi.

E ogni volta che il Cuckold Management fallisce, ogni volta che due dipartimenti non collaborano più perché il palco di corna non fa parte del dress code aziendale, ecco che qualcosa deve diventare “multitenant”, in modo che quei due dipartimenti possano smettere di cooperare senza doverlo ammettere.

Il risultato è che prima le aziende adottano qualcosa per “semplificare”. Gli piace la filosofia OSS, gli piace questa cosa dei piccoli componenti che fanno poco ma bene, gli piace l’idea di un software con un perimetro chiaro, che non pretende di risolvere l’intera tragedia organizzativa dell’azienda.

Poi arrivano i manager che non rientrano nel Cuckold Management, oppure che ne subiscono le conseguenze, e tutte le volte che due dipartimenti non riescono a cooperare, ecco che nasce un nuovo requisito.

Non perché il software sia davvero insufficiente. Non perché il problema tecnico non fosse stato previsto. Ma perché qualcuno, dentro l’azienda, non ha la forza politica di imporre una procedura comune, un lessico comune, una responsabilità comune.

E allora la frattura organizzativa viene trasformata in feature. Due reparti non si parlano? Serve il multitenant. Due manager non vogliono vedere gli stessi dati? Serve il multitenant. Due processi dovrebbero essere unificati, ma nessuno ha il coraggio di dire “da domani si fa così”? Serve il multitenant.

Così il software nato per semplificare comincia a incorporare esattamente ciò che doveva eliminare: eccezioni, feudi, confini artificiali, procedure separate, configurazioni diverse, piccole sovranità locali travestite da requisiti architetturali.

E alla fine non hai più un software open source elegante, modulare, pulito.

Hai un organigramma con una REST API.

L' RBAC piu' Granulare

Un’altra sciagura che si abbatte sull’OSS è quella dell’RBAC granulare.

Anche questo, in fondo, è un problema di Cuckold Management: a un certo punto, siccome un coniuge ha concesso privilegi troppo elevati a qualcuno, allora occorre fare in modo che in azienda nessuno possa più concedere privilegi simili senza passare attraverso una liturgia bizantina.

Quindi, zac: diventa improvvisamente indispensabile un RBAC granulare. Ma non un RBAC semplice, umano, comprensibile. No. Un RBAC che si interfacci con tutti i sistemi di RBAC del mondo, che parli con LDAP, Active Directory, SAML, OIDC, gruppi annidati, ruoli ereditati, claim inventati da un consulente morto dentro, e che quindi diventa immediatamente troppo complesso per qualsiasi piccola realtà che voleva solo installare un software e usarlo.

Ma non basta.

Occorre anche fare in modo che il coniuge non possa concedere alcuni privilegi. O che possa concederli solo in certi casi. O che possa concederli solo se il dipartimento A non si incazza, perché il dipartimento B può fare una cosa che apparentemente gli compete, ma che in realtà ha un impatto laterale su qualcun altro. E quindi parte l’escalation.

Onestamente, la risposta sarebbe spesso: “disegnate decentemente i vostri use-case”. Oppure: “che ne dite di controllare come cazzo disegnate i processi interni?”

Ma la realtà è un’altra: un dipartimento è guidato da un coniuge irritato per la privilege escalation che alcuni coniugi consentono. E non è un baco. È il requisito.

Risultato: arriva la richiesta di poter limitare l’azione di visualizzare fotografie se si indossa una cravatta a pois, purché la persona non sia del segno dello Scorpione e non appartenga al gruppo “Finance”, salvo eccezioni approvate dal Legal il giovedì mattina. Tutto questo, ovviamente, viene chiamato “principio del least privilege”.

Che sarebbe anche un principio sensato, se non fosse usato come alibi per trasformare ogni nevrosi aziendale in una matrice dei permessi.

E quindi un OSS nato per avere utenti e amministratori si trova a implementare un intero sistema di AAA: autenticazione, autorizzazione, accounting. Un apparato capace di decidere, utente per utente, ruolo per ruolo, reparto per reparto, quali mutande debbano indossare quando cliccano su un determinato pulsante.

“L’utente può vedere il ticket, ma non il commento, tranne se il commento è interno, ma solo se appartiene al gruppo Finance, però non se il ticket è stato aperto da Legal, salvo escalation approvata da un deputy manager della regione DACH. Del saggittario. Vegano. Ho gia' detto quanto fa bene la quinoa?”

"Rendetelo configurabile".

Quando un software è semplice, monolitico, e fa una sola cosa bene, arriva sempre quello della versione enterprise che chiede la cosa più innocente del mondo:

“Rendete configurabile questa cosa.”

Sembra una richiesta ragionevole. In fondo, cosa costa? Basta mettere un parametro. Basta aggiungere una variabile d’ambiente. Basta esporre una checkbox. Basta non “hardcodare” certe scelte.

Il problema è che spesso i programmi sono efficienti proprio perché usano specifiche intelligenti, e sono costruiti attorno a quelle specifiche. Non sono veloci per magia. Sono veloci perché qualcuno ha fatto delle assunzioni ragionevoli, ha scelto dei limiti, ha disegnato il software per lavorare bene dentro quei limiti.

Ma attenzione: siccome qualche coniuge ha deciso di farsi riconfigurare da qualche collega, ecco che anche i dipartimenti vogliono il software ognuno per i cavoli suoi. Ognuno con la propria eccezione, il proprio parametro, il proprio limite diverso, la propria interpretazione locale della realtà.

Il management, però, giustamente, non vuole spendere soldi per due software. Non vuole due installazioni, due manutenzioni, due team, due contratti, due incidenti separati.

E allora?

E allora: “rendetelo configurabile”.

Così, magari, qualcuno aveva fatto una scelta di scalabilità partendo da qualche assunzione razionale. Aveva stabilito un numero massimo, una dimensione massima, una coda massima, un certo modello di concorrenza. Non per pigrizia, ma perché quel vincolo era un pilastro del software. Serviva a renderlo efficiente. Quindi veloce. Quindi prevedibile. Quindi, spesso, anche sicuro.

E invece no.

Arriva il requisito aziendale: “rendetelo configurabile”.

Hai costruito il tutto per un massimo di 100 thread? No. Quel numero deve essere configurabile. Poi ci scriveranno 13 miliardi di thread, e si lamenteranno della lentezza.

“Ok, abbiamo aumentato il numero di thread un pochino, ma non mi aspettavo una cosa del genere.”

Certo. Perché per l’enterprise “configurabile” significa sempre questo: trasformare una decisione architetturale in una manopola, consegnarla a qualcuno che non ne capisce le conseguenze, e poi aprire un ticket quando la manopola viene girata fino a staccarsi dal cruscotto.

Un dipartimento usa un ERP. Un altro dipartimento usa un framework per fare CRM. Ma noi vogliamo un solo software. E allora?

"Rendetelo configurabile": basta mettere "ERP" o "CRM" in un parametro, e via.

Ecco, questo e' il disastro delle "versioni enterprise". Se gestite un software OSS, fate una cosa. Quando ricevete una richiesta da qualcuno di una grossa corporation, chiedete di parlare con il loro Cuckold Management.

Almeno sara' divertente.