Democrazia

Ansel dovrebbe essere gestito in modo democratico ed equo verso tutte le persone coinvolte.

Definire un’organizzazione cooperativa oltre il codice open-source

Si presume che gli sviluppatori e gli utenti che approdano qui condividano un interesse comune: vogliono la libertà nel modo in cui modificano le loro foto, ora e in futuro. Vale a dire:

• avere un sufficiente controllo tecnico sul contenuto e sulle proprietà delle proprie immagini,
• essere liberi dai capitalisti che potrebbero:
  • aumentare il prezzo della loro applicazione a esclusivo vantaggio degli azionisti,
  • sfruttare le foto dei clienti per addestrare modelli di IA senza consenso,
  • dismettere le applicazioni senza rilasciare il codice sorgente,
• avere il diritto di decidere sui contorni e sull’attuazione di tale libertà.

Il DNA di Ansel è più orientato alla tecnica e più minuzioso rispetto alla maggior parte degli editor di foto RAW, pur enfatizzando la facilità d’uso dove possibile, per lo più nei tipici compiti incentrati sul desktop (interazioni con dispositivi di input e file, paradigmi dell’interfaccia grafica, ecc.). Ansel non è Darktable  o ART  perché la sua visione di ciò che dovrebbe essere un buon software di ritocco delle immagini è piuttosto diversa.

Ansel è rilasciato sotto licenza GNU/GPL , il che ne fa un software libero/open-source. Sebbene ciò dia una (errata) sensazione di disponibilità a lungo termine, la realtà è che la sua disponibilità a lungo termine dipende esclusivamente dalla volontà e dalla capacità di alcuni sviluppatori di svolgere la (tediosa) manutenzione quotidiana per mantenerlo funzionante, continuare a supportare nuove fotocamere, ecc., un compito sottovalutato perché non produce note di rilascio o keynote spettacolari.

Peggio ancora, la cosiddetta «libertà» concessa dalla licenza GNU/GPL riguarda solo il codice sorgente: è la libertà dell’ingegnere. Le licenze open-source rinunciano essenzialmente alla proprietà intellettuale sul codice, il che significa che gli ingegneri possono studiarlo e modificarlo, per poi condividere le loro modifiche. Dato che meno del 6 % della popolazione mondiale¹ è effettivamente in grado di scrivere codice, questo è un diritto solo per una minoranza privilegiata. Quanto agli utenti, beh, la licenza GPL è piuttosto chiara:

Questo programma è distribuito nella speranza che sia utile, ma SENZA ALCUNA GARANZIA;

Questa affermazione esclude essenzialmente gli utenti finali dalla transazione: non hanno altri diritti se non quello di eseguire il codice così com’è, in particolare nessun diritto a ottenere supporto e correzioni di bug, tanto meno a far modellare il software sulle loro esigenze. Se un qualche supporto viene comunque fornito, è a discrezione degli sviluppatori e gli utenti dovrebbero essergliene eternamente grati. Ciò viene abusato nelle cosiddette «comunità open-source» (ovvero i «forum di software») per zittire e invalidare qualsiasi lamentela degli utenti: semplicemente non possono lamentarsi dato che stanno usando lavoro gratuito, anche se il marketing dei progetti open-source spesso si profonde in lodi sulla idoneità «professionale» di quelle applicazioni. Ma… erano state fatte delle promesse, la parola «pro» era stata pronunciata ma non mantenuta, quindi c’è da qualche parte un’ingannevole incoerenza.

Anche rinunciando a qualsiasi responsabilità verso gli utenti, molti progetti cercano comunque di trasformarli, se non in clienti, almeno in donatori. Il che si scontra con un triste stato di cose: 350 anni di capitalismo ci hanno marcito il cervello facendoci pensare che le applicazioni open-source fossero il concorrente più economico del software proprietario. Gli utenti se ne stanno semplicemente seduti sui loro sederi ad aspettare che i progetti consegnino un prodotto prima di decidere se si degneranno di fare una donazione. È come iniziare a finanziare la NASA dopo che il primo razzo è stato lanciato per dimostrare che il progetto è davvero in grado di consegnare: non può essere così. Bisogna pagare il lavoro ancor prima che ci sia un prodotto da vendere. E quando il prodotto è rilasciato, progetti come Wikipedia faticano comunque a ottenere meno di 3 $/anno dal 2 % della loro base di utenti.

Le applicazioni open-source sono concorrenti delle applicazioni proprietarie proprio come gli ospedali pubblici sono concorrenti delle cliniche private: non lo sono. Da un lato abbiamo un progetto socialista avviato dalla convinzione che tutti abbiano diritto all’assistenza sanitaria, e se non possono permettersela, ci arrangeremo trovando fondi extra nella comunità. Dall’altro lato abbiamo azionisti che cercano di fare profitti, assumendo chirurghi che cercano di pagarsi la casa a Malibu e la loro collezione di Porsche. Come possono essere concorrenti? Un servizio pubblico è un modo per garantire che le persone abbiano le risorse per esercitare i propri diritti, perché la libertà è solo teorica finché non si hanno i mezzi per fare effettivamente uso dei propri diritti. Un’azienda privata che vende beni o servizi è un modo per fare soldi dagli investimenti. La differenza è politica. È anche economica, dato che non avere gli azionisti sul libro paga rende comunque il prodotto finale più accessibile.

Il punto cieco del movimento del «Software Libero» è stato evitare di pensare al contesto e alla struttura lavorativa in cui tale software nasce, viene sviluppato e mantenuto. Ciò può essere ricondotto alla cultura hacker , individualista per natura e compatibile con il capitalismo per procura, attraverso la tecnofilia  e il tecnosoluzionismo . «Condividere così com’è» (il tuo lavoro, il tuo codice, i tuoi hack) è stato scambiato per «prendersi cura di» (bisogni, limiti, sfide altrui) e alimentato con narrazioni quasi agiografiche. Quando hai un martello, tutto sembra un chiodo: quando tutto ciò che conosci è il codice, il codice è la soluzione a tutto, e cercare di avvolgerlo in filosofia e politica (non rivoluzionaria) per definire la «libertà del codice» continua comunque a mancare il quadro d’insieme, che è lo sfruttamento del lavoro di tutti da parte di una classe sociale piccola ma potente e auto-riproducentesi. Mentre nel 2021 il 6 % della popolazione mondiale sapeva scrivere codice, la percentuale di chi poteva anche solo permettersi un personal computer negli anni ‘80, quando il movimento del Software Libero ebbe inizio, era molto più piccola. Le minoranze privilegiate sono sempre cieche ai propri privilegi: è così che le riconosci. Non sono riusciti a vedere che il Software libero non era altro che il frutto di quei privilegi. È libertà solo per chi può permettersela. E il fatto che il cartellino del prezzo non abbia un simbolo del dollaro attaccato lo rende subdolo. Ha comunque un cartellino del prezzo.

Il movimento del Software Libero è stato costruito per adattarsi a questo capitalismo individualista, della libera impresa, del mercato liberale, e ha fatto credere a tutti che bastasse lasciare che ciascuno avviasse il proprio progetto o lo forkasse da quello di altri. Poi, il darwinismo sociale  avrebbe sistemato le cose. Sì, ma… chi paga il lavoro? Peggio ancora, dato che il capitalismo attribuisce valore al lavoro solo quando il suo prodotto è venduto su un mercato liberale, e quel valore è indicizzato sulla scarsità del prodotto, come diavolo dovremmo convincere gli utenti che qualcosa di dematerializzato, scaricabile all’infinito gratuitamente, abbia un qualche valore? Molti progetti open-source hanno provato molte strategie diverse per finanziare il proprio lavoro, sono tutte precarie e paralizzate perché vogliono comunque far entrare una struttura lavorativa che è comunista per natura in una cornice capitalista (maggiori dettagli più avanti).

Mentre le organizzazioni senza scopo di lucro possono funzionare per i progetti umanitari, dove i donatori non saranno mai i destinatari del lavoro, per i progetti software le donazioni sono interessate perché i donatori sono utenti. Ciò alimenta un comportamento da consumatore, in cui consumatori passivi (e in qualche modo oppressi) attendono i beni consegnati da una élite minoritaria di membri del consiglio che dettano le regole. Quelle organizzazioni senza scopo di lucro sono comunque gestite privatamente, e il pubblico non ha altro diritto che smettere di donare se non si sente ascoltato. Il consiglio della Linux Foundation  è composto quasi esclusivamente da dirigenti di produttori di hardware e delle GAFAM , il consiglio della Free Software Foundation  è composto da scienziati e tecnici informatici. Non vi è alcuna rappresentanza degli utenti, vi sono strutture gerarchiche verticali di «coloro che sanno» sopra «coloro che hanno bisogno», che perpetuano lo stesso tipo di dominazione del capitalismo, meno i profitti.

Ciò è giustificato dal fatto che le licenze open-source rinunciano a qualsiasi forma di responsabilità (garanzia) da parte degli sviluppatori verso gli utenti, il che ne fa una transazione a senso unico che apparentemente attribuisce tutto il potere decisionale agli sviluppatori. Ma tutto ciò è ovviamente un costrutto, e non una conclusione scontata. All’altro estremo, poiché il dogma capitalista è così profondamente impregnato nel cervello degli utenti, il codice sorgente porta un software su un mercato libero, dematerializzato e non scarso che annulla ogni nozione di valore capitalista, il che rende accettabile per gli utenti ottenere il prodotto del lavoro senza contributo: un’altra transazione a senso unico. Nel frattempo, alcuni sviluppatori si bruciano e si sfiniscono per fornire un ragionevole supporto agli utenti, senza ottenere un reddito ragionevole dal loro lavoro (sfruttato), forse nella speranza che finirà per pagare nel lungo periodo, una volta che «ce l’avranno fatta». Oppure gli sviluppatori accettano la regola non detta dell’open-source (dovrebbe essere solo un hobby/part-time), che inevitabilmente fa regredire l’open-source, come fratello per sempre povero del software proprietario. Oppure, infine, alcune aziende open-source come Automattic  o RedHat  iniziano a diventare sempre più aggressivamente avide nel tempo, affrontando il contraccolpo delle loro comunità. Ciò non è sostenibile, per nessuna delle parti coinvolte.

Dobbiamo trasformare queste due transazioni parallele a senso unico in un cerchio. Ecco come:

1. Nessuna tecnologia può esistere al di fuori della società che la produce. La tecnologia ha bisogno della scienza. La scienza ha bisogno della ricerca. La ricerca ha bisogno di strutture in cui poter essere condotta liberamente. La società è l’ambiente in cui tutto ciò accade, oltre che il sistema di supporto che lo rende possibile.
2. Nessuna tecnologia può esistere senza lavoro. Se il prodotto del lavoro sfugge al sistema capitalista (mercato liberale basato sulla scarsità e sulla concorrenza), allora anche il lavoro che lo produce dovrebbe sfuggirvi.
3. Nessuna tecnologia di proprietà privata servirà il bene comune e l’interesse pubblico. Le tecnologie, non solo i dispositivi, dovrebbero essere di proprietà dei loro utenti, non solo dei loro fabbricanti.
4. Il lavoro è l’unica ricchezza. I lavoratori dovrebbero beneficiare del proprio lavoro, che sia venduto su un mercato liberale o no: dovrebbe essere pagato in ogni caso. Il lavoro dovrebbe svolgersi in un ambiente sicuro ed equo. È una responsabilità collettiva e sociale far sì che ciò accada, perché il prodotto del lavoro serve il bene comune e l’interesse pubblico. Il lavoro che non serve questi scopi dovrebbe semplicemente essere fermato.
5. Le tecnologie di proprietà dei loro utenti aprono la strada a un nuovo tipo di produzione: la collaborazione tra fabbricanti e utenti, invece della concorrenza tra fabbricanti e delle guerre societarie per conquistare mercati convincendo i clienti della superiorità di qualche prodotto (facendo pagare alla fine agli utenti la pubblicità…). Ma il capitalismo non sa come vendere il prodotto della cooperazione, perché non c’è più un acquirente o un venditore separato, ma solo una comunità di persone che lavorano insieme verso qualcosa: soddisfare i propri bisogni, trasformare i propri diritti teorici in libertà effettiva creando il contesto per esercitarli.
6. Esiste una responsabilità reciproca dei fabbricanti verso gli utenti (soddisfare i loro bisogni attraverso/con la tecnologia), e degli utenti verso i fabbricanti (dare loro un ambiente di lavoro sicuro ed equo e condizioni materiali di vita). Questo è il fondamento stesso di una comunitಅ
7. L’open-source che conduce alla vera libertà può avvenire solo all’interno di una struttura cooperativa . Che è un comunismo antico, collaudato e già funzionante, in cui l’azienda (quindi il progetto open-source nel suo complesso) è di proprietà dei suoi clienti e dei suoi lavoratori, che condividono i poteri di voto. Ciò va ben oltre una semplice rinuncia alla proprietà intellettuale (licenza open-source/libera).

Una cooperativa è un modo per spezzare questa dicotomia tra «noi» e «loro», fabbricanti contro utenti, che alimenta il risentimento reciproco: gli sviluppatori sono i dittatori che prendono l’applicazione come loro terreno di gioco personale, verso i quali gli utenti dovrebbero essere sempre grati per quanto la distruggano, gli utenti sono le fastidiose sanguisughe che continuano a sollevare issue criptiche e richieste di funzioni, donando troppo poco.

In una cooperativa, fabbricanti e utenti sono allo stesso modo soci-azionisti. Possiedono tutti il progetto, hanno tutti un voto nell’assemblea generale. Il progetto consiste nel rendere l’editing fotografico libero per il prossimo futuro, secondo una visione unificata di cosa sia l’editing fotografico (quanto debba essere tecnico e minuzioso rispetto a quanto debba essere facile e intuitivo). Per raggiungere tale obiettivo, sono coinvolti molti mezzi, come l’istruzione, la promozione, la documentazione e, ovviamente, un’applicazione software. Il progetto è più di un semplice prodotto finale, che può richiedere del tempo per comparire ed essere pronto: il progetto è tutto ciò che sta sopra e attorno, è un obiettivo e tutti i mezzi per renderlo realtà.

La responsabilità dei soci è quella di assicurare un budget annuale per coprire tutti i costi del progetto, molto probabilmente dalle quote annuali dei soci. Da quel budget, una certa quantità di ore di lavoro a una certa tariffa oraria viene decisa in assemblea generale. Come questo budget verrà speso (che tipo di compiti, hardware, strumenti, ecc.) è anch’esso deciso in assemblea generale. Per i compiti tecnici, come lo sviluppo software, saranno le orientazioni di alto livello (come migliorare il mascheramento, il flusso di lavoro in batch, ecc.) e non i dettagli di implementazione o la progettazione effettiva, che sono poco adatti ai processi democratici. Gli sviluppatori potrebbero spingere per compiti orientati al backend (come riscrivere o rifattorizzare il debito tecnico, per ridurre i costi di manutenzione a lungo termine), gli utenti potrebbero spingere per compiti orientati alle funzioni (come supportare nuove funzioni delle fotocamere, formati di immagine, ecc.): lo scopo dell’assemblea generale è deliberare e classificare le priorità.

I compiti concordati verranno poi affrontati da lavoratori retribuiti nell’ordine di priorità, fino a esaurimento del budget del lavoro. Ciò non si limita al lavoro tecnologico e allo sviluppo, ma si applica a qualsiasi tipo di lavoro precedentemente concordato. Quando il budget è esaurito, i lavoratori riferiranno dove si sono fermati nella lista delle cose da fare, cosa hanno potuto terminare, cosa non hanno potuto, e quali risorse mancavano per finire. L’assemblea generale deciderà poi se è possibile e desiderabile investire più risorse per finire, o far slittare i compiti rimanenti nel budget annuale successivo. Ciò dà ai lavoratori visibilità sul proprio reddito annuale senza promuovere l’eccesso di impegno e il burnout.

Gli utenti possono formare gruppi per lavorare con gli sviluppatori alla comprensione dei problemi effettivamente riscontrati, testare e convalidare soluzioni all’interno di un processo di progettazione. Qualsiasi utente può essere trasformato in lavoratore e iniziare a percepire un reddito per il proprio lavoro su compiti concordati, previa approvazione dell’assemblea generale.

Ciò rende responsabilità di tutti garantire che le risorse per andare avanti vengano raccolte, e dare ai lavoratori ciò di cui hanno bisogno per lavorare in modo dignitoso, sicuro, senza essere sfruttati. Nessuna quantità di lavoro dovrebbe essere gratuita, indipendentemente dal compito. Il lavoro non dovrebbe limitarsi alla programmazione o ad altri compiti tecnici.

I limiti della democrazia

La democrazia per voto consiste essenzialmente nell’esprimere la volontà della maggioranza, che è nota per opprimere le minoranze. Non è quindi perfetta. Le minoranze potrebbero esprimere preoccupazioni ragionevoli e legittime, solo che non saranno condivise dalla maggioranza. Vengono in mente le persone con disabilità: alcuni dettagli di progettazione potrebbero rendere l’intera applicazione completamente inutilizzabile per loro, anche se non hanno i numeri per imporre le proprie opinioni in un voto. All’altro estremo, non è possibile assecondare i bisogni particolari di ognuno senza creare mostri. Ciò va valutato e arbitrato con attenzione.

La responsabilità della maggioranza è quindi di identificare chi sono le minoranze strutturali, cioè quali proprietà legano insieme quelle minoranze (condizione di salute, origine sociale, istruzione, livello di reddito, ecc.). Se una minoranza solleva un problema che è bloccante per loro a causa di una delle proprietà definenti di tale minoranza, dovrebbe esserci un modo per aggirare o riponderare il voto della maggioranza. Ciò resta da definire, ma il modo più semplice per abbracciare questo è durante le deliberazioni, che si basano sull’empatia e sulla comprensione della maggioranza.

Un altro problema di qualsiasi gruppo sociale è il pensiero di gruppo , perché qualsiasi gruppo sociale tende a degradare in un club nel tempo. Il pensiero di gruppo è quando gli individui non si sentono liberi di sollevare questioni che vanno contro il (presunto) consenso del gruppo, per paura di ripercussioni riguardo al proprio posto e alla propria percezione nel gruppo. Quelle ripercussioni possono essere molto sottili eppure molto reali. Diventa dannoso quando gli individui iniziano a sostenere decisioni, all’interno del gruppo, che non avrebbero sostenuto da soli: è questo il punto di svolta in cui la razionalità individuale si perde. Per evitarlo, si può usare il voto anonimo, ma non si applica alle deliberazioni dove c’è necessariamente un oratore. C’è una cultura del sano dissenso da costruire, mantenere e incoraggiare. Un modo per risolvere questo problema è nominare a caso un «avvocato del diavolo» per ogni sessione, il cui compito sarà quello di dissentire costantemente ed esporre gli argomenti corrispondenti.

Ci si aspetta che qualsiasi comunità basata su un interesse condiviso per la fotografia e il software libero sia sbilanciata a favore di uomini ricchi, istruiti, esperti di informatica e di lingua inglese. Sarà necessario uno sforzo consapevole per cercare di includere donne, persone meno istruite, cittadini non occidentali, ecc. Combinato con la democrazia per voto e il pensiero di gruppo, può essere davvero dannoso partire da un gruppo così socialmente omogeneo, se non gestito con attenzione. Sarà una sfida quotidiana di cui tutti devono essere consapevoli. Alimenterà anche il bias del sopravvissuto , dove gli esclusi non sono qui a fornire feedback sul perché non si sono uniti, non hanno partecipato o non si sono sentiti benvenuti, e gli esclusi avranno bisogno di cure extra per essere raggiunti e accolti.³ Nessuna dose di razzismo o sessismo può essere tollerata in un tale ambiente, nemmeno come battuta, perché ciò farebbe ridere la maggioranza a spese delle minoranze in un contesto da cui sono già filtrate fuori.

La democrazia è anche un processo lento. Possono accadere cose che richiedono una decisione tempestiva, come una violazione della sicurezza nel server del progetto o negli account dei social media, o qualsiasi questione legale pressante. Qualcuno dovrebbe essere eletto per mandati a breve termine per poter prendere rapidamente quelle decisioni a nome della comunità.

I limiti tra esperti e profani

Proprio come i medici o gli avvocati, gli sviluppatori hanno competenze ed esperienze di nicchia, che daranno loro una sorta di potere e persino carisma sui profani. Questo potere può essere abusato per opprimere la maggioranza sfruttando la sua mancanza di conoscenza a vantaggio dell’oppressore. Questa relazione sarà sempre asimmetrica, e ciò va riconosciuto. Inoltre, gli sviluppatori dovranno essere consultati durante le deliberazioni in assemblea generale, per valutare la fattibilità dei compiti e le risorse necessarie, prima che avvengano i voti.

Proprio come medici, avvocati, ecc., gli sviluppatori dovrebbero attenersi a una sorta di codice etico che accompagna il loro potere simbolico, tra cui:

1. il dovere di informare onestamente, al meglio delle proprie conoscenze, e di spiegare in modo semplice ciò che può essere spiegato in modo semplice,
2. il dovere di correttezza procedurale e di diligenza dovuta nel ricercare e sviluppare soluzioni,
3. l’impegno a lavorare nel migliore interesse della comunità.

All’altro estremo, gli sviluppatori (o qualsiasi altro esperto) potrebbero essere percepiti dai profani come maghi onniscienti e onnipotenti, che potrebbero quindi chiedere loro troppo. Sebbene il software sia un mezzo piuttosto malleabile, ci sono comunque vincoli tecnici non negoziabili che si applicano, e non tutto ciò che è tecnicamente possibile potrebbe esserlo nelle circostanze attuali con le risorse attuali.

Entrambe queste posizioni dovranno essere comprese per prevenire il crescere del risentimento reciproco.

I limiti della collaborazione

Tutti sono designer.

Ogni lavoro di cui non sai nulla sembra facile da fare. Progettare e costruire oggetti tecnici è uno di questi. È persino entusiasmante contribuirvi. Ma un software che sarà usato come strumento da migliaia di utenti oltre a te stesso non è la stessa cosa del tuo comodino.

Gli utenti dovrebbero essere accolti a partecipare alla definizione del problema: partire da uno o più utenti che hanno un problema particolare in un flusso di lavoro particolare, vedere se non possa già essere risolto con gli strumenti attuali e forse un po’ di istruzione, e in caso contrario, cercare di rilevare quanti utenti condividono lo stesso problema. Se il problema non è esattamente lo stesso per tutti, cercare di trovare un’espressione comune del problema che permetta di generalizzarlo.

Una volta definito il problema, inizia il processo di progettazione, che segue passaggi formali per evitare di precipitarsi verso la prima soluzione (e molto probabilmente non ottimale) perché, di nuovo, l’intuizione umana è migliore per costruire comodini piuttosto che strumenti usati da migliaia. Ma seguire il processo non è sufficiente.

La psicologia e le scienze cognitive convergono verso un consenso: la dimensione migliore per i team di lavoro è tra 4 e 7 membri. A partire da 8 membri, la produttività inizia a calare drasticamente.⁴⁵⁶ Per un team di 4 membri, ci sono 6 canali di comunicazione interpersonale, mentre per 8 membri ci sono 28 canali di comunicazione. Ciò rende difficile tenere traccia cognitivamente di tutti i coinvolti, di chi è incaricato di cosa, elaborare i segnali non verbali, il che crea un sovraccarico di comunicazione. Oltre i 9 membri, iniziano a formarsi clan, la politica si mescola nel processo, e il poltronismo sociale  si mette in gioco.⁴⁵

Ciò significa che il lavoro dovrebbe essere suddiviso in team di lavoro aventi ciascuno non più di 6 o 7 membri, anche se potrebbe risultare entusiasmante per la comunità nel suo complesso interessarsi a tutto. La comunicazione è qui il punto di svolta: ne serve esattamente la giusta quantità, né più né meno, altrimenti satura cognitivamente i membri del team e ostacola la comunicazione stessa. A quel punto, è il lavoro in sé a subire un colpo.