Comunità

Parto da una constatazione personale: il software ha un target e uno scopo o non è software. Nel senso, o si pensa ad un software utilizzato e utilizzabile da una persona o un tipo di persone specifiche (anche sè stessi) per fare esattamente una funzione oppure è una gioiosa masturbazione mentale. Doverosa, giusta, bella, ma nulla più che una masturbazione mentale. O una mega-libreria o un mega-framework sempre più informe e utilizzabile per qualsiasi cosa, e quindi statisticamente inutile nell’immediato. Questo vale per applicazioni “al consumatore” così come per librerie ad uso e consumo di sviluppatori. Perchè come sottolineava Luca, buona parte del lavoro consiste soprattutto nel costruire una interazione fra mondi diversi. E il software non è altro che una scusa per facilitare o complicare queste interazioni.

E a questo punto parliamo di comunità.

Omogeneità

La comunità è rappresentata da un gruppo di individui che si identificano in un insieme di caratteristiche condivise, un linguaggio comune e una serie di pattern che rendono i membri della comunità riconoscibili tra loro. Fra questi pattern ci sono anche i traumi, ma ci torneremo. Questo vale per ogni tipo di comunità: La comunità nazionale che condivide una lingua “verbale” e in parte una lingua “non verbale”, la comunità locale di un comune, che condivide nomignoli per alcuni posti specifici per identificare chi è “del paese” e chi non lo è. Quando si va ad una conferenza di sviluppatori questi pattern diventano assolutamente evidenti: dal semplice name-dropping di librerie condivise alla esposizione di modelli di sviluppo più o meno astrusi si riesce ad incasellare il proprio interlocutore sia nella propria comunità che a collocarlo internamente alla comunità di appartenenza. Per la comunità di sviluppo Open Source, poi, ci sono i traumi: Da software gestiti da comunità che improvvisamente vengono resi proprietari a strani mix open/proprietario a donazioni dubbie e litigi di singoli sviluppatori che portano a grandi scismi. Dalle distribuzioni Linux ai vari tool di Office, la liberalizzazione del pensiero del singolo e l’empowerment di poter fare quello che si vuole, la dispersione di forze è immane e forsennata. Ma non è dei problemi interni della comunità che vogliamo parlare, anche se ci sono e sono enormi.

Il problema nasce quando due comunità diverse decidono di interagire. Luca nota giustamente l’importanza dello sforzo di interazione. A mio avviso è molto ben definito, ed è in realtà lo sforzo di creazione di un glossario fra le lingue diverse. Ad esempio, per un pubblico amministratore il “Tracciato Record” è una cosa sensata, mentre per un programmatore non ha nessun significato reale. Viceversa, per il programmatore può avere senso definire una “API”, che per un amministratore diviene una “Porta di Dominio”. Da programmatore la definizione di Porta di dominio mi da i brividi, ma ho imparato che se voglio farmi capire da un membro della comunità PA devo parlare in quel modo. Ed è puramente una questione di linguaggio. Quando in uno strumento presenterò un pulsante “esporta csv”, per la mia comunità ha un senso, mentre per un amministratore che non si ponga troppe domande non ha senso e mi chiederà, dopo una lunga e frustrante spiegazione, di sostituirla con il pulsante “esporta tracciato record”.

Aggiungo anche che comunque la comunità è fatta di individui. Ognuno con la propria agenda, con le proprie volontà, con i propri obiettivi, a volte (ma non necessariamente) legati alla propria comunità.

Volontà

Il problema di molte comunità, come sottolinea anche Luca, è il ritenersi un elemento perfetto nella propria sociopatia di gruppo e nella propria volontà di non interagire con il mondo esterno. E le comunità di sviluppatori hanno sicuramente questa tendenza, ma non sono nè le prime nè le ultime, consiglio di interagire con alcune comunità accademiche. Ma per la comunità di sviluppatori, posso certificare un aspetto più complesso aggiuntivo, dato da una triste dose di frustrazione data dall’interazione con le altre comunità.

Frustrazione

Per spiegare la frustrazione proporrei una domanda più triste e complessa: una comunità che interesse avrebbe ad evolversi talmente tanto da scomparire? Rispondendo alla domanda di Luca

soprattutto dal punto di vista tecnico: come ridurre i passaggi per ottenere una condivisione massiccia in cui l’intermediazione è ridotta al minimo?

In che modo la riduzione di passaggi e la disintermediazione non vanno a ledere la struttura stessa della comunità di biblioteche e soprattutto delle persone che interagiscono all’interno di questa comunità? In che modo la riduzione di passaggi migliorerebbe la vita di Mario Rossi Bibliotecario senza renderlo inutile alla propria istituzione?

Inoltre, osserviamo il mondo in modo realistico, anche il programmatore open source deve pagare il mutuo, deve comprare la spesa, deve pagare le tasse. E per farlo deve fatturare. O lo fa attraverso strumenti generici (vendendo sevizi basati su Drupal/Wordpress/Mediawiki) o

Dall’altra parte, la frustrazione viene anche dal fattore velocità: Fare riunioni per spiegare l’agile e raccontare come si sta migliorando il mondo con delle righe di codice che nell’immediato non hanno particolare impatto ma nel medio periodo cambieranno tutto è forse la parte più terribile per un programmatore che ritiene comunque questo passaggio assolutamente inutile e una terribile perdita di tempo. Il programmatore non nasce per lo storytelling ma, anzi, quasi odia l’aspetto markettaro. E torniamo alla comunità: Chi programma è in una comunità diversa da chi “vende” il risultato.

Anomalia

E arriviamo all’insorgenza dell’anomalia. Questa operazione di traduzione fra mondi è il motivo per cui, a mio avviso, è sbagliata la premessa stessa di “appartenenza ad una comunità”. Nessuno racconta la storia degli anatroccoli, mentre la storia è quella del brutto anatroccolo. L’entità che si distacca dal campione ha un nome, “Anomalia”.

Il progresso non arriva dall’omologazione ma dalla mutazione.

Contatto

Non sto dicendo che le comunità di sviluppatori sono sacre e perfette, anzi, siamo fra i peggiori reazionari. Quello che significa la questione dell’anomalia è che bisogna allevare una nuova generazione di sviluppatori “embedded” in ambienti anomali, ma che siano effettivamente sviluppatori. Non “matematici fisici passati allo sviluppo”, ma “informatici con basi di fisica”. E siano, quindi, “bilingue”. Magari brutti anatroccoli di entrambe le comunità, ma affascinanti esseri poliedrici che capiranno come spiegare il problema della mono-numerazione Dewey del GEB come 510.1 (filosofia matematica) e non come romanzo o come trattato di AI ad uno sviluppatore che, giustamente, utilizzerebbe un sistema di tagging multipli per definire i vari libri nella biblioteca, così come sappiano proporre dei cambiamenti anche non tecnici o parzialmente tali nella gestione della biblioteca. Personaggi capaci di utilizzare la programmazione multiprocesso senza farla immaginare o ripensare al team di fisici, che ignorerebbero volentieri il concetto potendosi lanciare ancor di più in voli pindarici di analisi fisica.

Sintesi

I “Wikipedian in residence” sono un passo enorme in questa direzione, così come lo sono azioni come l’annuale Knight-Mozilla Fellowship. In entrambi i casi sono operazioni nelle quali dal basso entità già consapevoli cercano esplicitamente questo contatto all’interno di comunità che nascono trasversali.

Sottolineo la trasversalità delle comunità di supporto perché la non-adesione ad una specifica tecnologia è l’elemento cardine: standard di fatto e di laboratorio per l’interazione e l’integrazione fra mondi e libreire e strumenti open per la strutturazione degli strumenti, senza mai dimenticare che l’Utente è Sacro, che ci piaccia o meno (ovvero: open source non deve essere una scusa per software brutto o non integrabile o non integrato).

A questo punto il vero balzo in avanti sarebbe imporre dall’alto questa integrazione attraverso, mi si conceda la parafrasi, delle “Quote IT” non gestite internamente dalle realtà in cui lavorano, ma come elementi trasversali che abbiano come obiettivo il supporto di altre comunità attraverso la propria comunità di appartenenza.

Associazioni come Wikimedia Italia, Fondazioni e altre entità che possono porsi come super-partes sono il cardine di questo discorso e di questo tipo di interazione.