Traduzione mia dell’intervento “A Group Is Its Onw Worst Enemy” di Clay Shirky. Abbiate pietà della mia traduzione, è stato particolarmente ostico gestire “pattern”, talvolta ho usato “schema”, talvolta “modalità”, talvolta “soluzione”. Ho cercato di rimanere fedele allo stile proprio del parlato, non è un’opera letteraria.
«Un intervento presso ETech, Aprile, 2003
Questa è una versione leggermente modificata del discorso d’apertura che diedi sul Software Sociale alla conferenza O’Reilly Emerging Technology a Santa Clara il 24 aprile 2003
Buongiorno a tutti. Questa mattina voglio parlare di software sociale … c’è una sorpresa. Voglio parlare di uno schema che ho visto ripetersi varie volte in software sociali che supportano gruppi grandi e duraturi. E lo schema è descritto nel titolo di questo intervento: “Un Gruppo È Il Proprio Peggior Nemico”.
In particolare, voglio parlare di ciò che ora credo sia una delle sfide principali nel design di software sociale su grande scala. Lasciatemi offrire una definizione di software sociale, perché è un termine ancora abbastanza amorfo. La mia definizione è molto semplice: È software che supporta l’interazione di gruppo. Voglio anche enfatizzare, anche se è una definizione semplice, quanto ciò sia radicale. L’Internet supporta molti modi di comunicazione, principalmente uno-a-uno bidirezionale, uno-a-molti unidirezionale, e molti-a-molti bidirezionale.
Prima dell’Internet, avevamo molti sistemi che supportavano uno-a-uno bidirezionale. Avevamo i telefoni, avevamo il telegrafo. Ci era famigliare la mediazione tecnologica di quei tipi di conversazioni. Prima dell’Internet, avevamo molti sistemi che supportavano uno-a-molti unidirezionale. Potevo mandare qualcosa alla televisione o in radio, potevo pubblicare un quotidiano. Avevamo la stampa. Quindi anche se l’Internet fa del bene a quei sistemi, sono modi che conoscevamo da prima.
Prima del’Internet, l’ultima tecnologia che aveva qualsiasi effetto reale sul modo in cui le persone si sedevano e parlavano insieme era il tavolo. Non c’era mediazione tecnologica per la conversazione di gruppo. La cosa più simile era la teleconferenza, che non ha mai funzionato bene –“Pronto? Premo questo tasto ora? Ops, ho appena riagganciato”. Non è facile iniziare una teleconferenza, ma è molto facile inviare un email a cinque amici e dire “Hey, dove andiamo per una pizza?” Quindi un modo estremamente semplice di formare gruppi è davvero una notizia.
Abbiamo avuto software sociale per 40 anni al massimo, a partire dal sistema BBS Plato, e sono solo 10 anni che questo è ampiamente disponibile, quindi stiamo ancora scoprendo cosa funziona. Stiamo imparando come fare questo genere di cose.
Ora, software che supporta l’interazione di gruppo è una definizione fondamentalmente insoddisfacente in vari modi, perché non non individua una specifica classe di tecnologie. Se guardate all’email, ovviamente supporta modi sociali, ma può anche supportare la modalità uno-a-molti unidirezionale. Se sono uno spammer, invierò roba a milioni di persone, ma non si parleranno fra loro, e non parlerò a loro — lo spam è email, ma non è sociale. Se scrivo a te, e tu mi rispondi, stiamo avendo una conversazione bidirezionale uno-a-uno, ma non una che crea dinamiche di gruppo.
Quindi l’email non supporta necessariamente modi sociali, di gruppo, ma può farlo. Stesso per un weblog. Se sono Glenn Reynolds [autore di un blog molto seguito], e sto pubblicando qualcosa con i commenti disattivati e raggiungendo un milione di utenti al mese, in realtà è uno-a-molti unidirezionale. È interessante che io lo possa fare come singolo individuo, ma è un modo pià simile alla [emittente televisiva] MSNBC che ad una conversazione. Se è un raggruppamento di mezza dozzina di utenti di LiveJournal, d’altra parte, che parlano delle proprie vite l’uno con l’altro, è sociale. Quindi, di nuovo, i weblog non sono necessariamente sociali, ma possono supportare modi sociali.
Comunque, penso che la definizione sia quella giusta, perché riconosce la natura fondamentalmente sociale del problema. I gruppi sono un effetto runtime [emergono dall’interazione fra le persone]. Non potete specificare prima cosa farà il gruppo, e non potete esprimere via software tutto ciò che vi aspettate succederà.
Ora, c’è una gran massa di letteratura che dice “Abbiamo costruito questo software, è venuto un gruppo e l’ha usato, e hanno iniziato a esibire comportamenti che ci hanno sorpreso enormemente, quindi li abbiamo documentati.” E ancora e ancora e ancora questo si ripete. (Sento Stewart [Brand, del WELL] ridere.) Il WELL è uno di quei casi in cui questo è capitato varie volte.
Questo intervento è in tre parti. La miglior spiegazione che abbia trovato per questo genere di cose che succedono quando gruppi di umani interagiscono è una ricerca psicologica che precede l’Internet, quindi la prima parte sarà riguardo la ricerca di W.R. Bion, di cui parlerò fra un momento, ricerca che credo spieghi come e quando un gruppo è il proprio peggior nemico.
La seconda parte è: Perché adesso? Cosa sta succedendo ora che renda questo degno di essere discusso? Penso che stiamo vedendo una rivoluzione nel software sociale nell’ambiente contemporaneo che è molto interessante.
E terzo, voglio identificare alcune cose, circa mezza dozzina di cose, infatti, che penso siano il cuore di ogni software che supporti gruppi grandi e duraturi.
Parte Uno: Come fa un gruppo ad essere il proprio peggior nemico?
Quindi, Parte Uno. La miglior spiegazione che ho trovato per i modi in cui questo schema si auto-stabilisce, il gruppo è il proprio peggior nemico, viene da un libro di W.R. Bion dal titolo “Esperienze nei gruppi,” scritto a metà del secolo scorso.
Bion era uno psicologo che stava facendo terapia di gruppo con gruppi di neurotici. (Fare paralleli fra quello e l’Internet è lasciato come esercizio al lettore.) La cosa che Bion scoprì era che i neurotici in cura presso di lui stavano, come gruppo, cospirando per sconfiggere la terapia.
Non c’era comunicazione esplicita o coordinamento. Ma poté osservare che ogni volta che provava a fare qualcosa che avrebbe dovuto avere un effetto, il gruppo in qualche modo lo smorzava. E stava diventando pazzo, nel senso colloquiale del termine, provando a capire se dovesse guardare alla situazione come: Questi individui stanno agendo da soli? O questo è un gruppo coordinato?
Non poté risolvere la questione, e così decise che l’irrisolvibilità della questione era la risposta. Alla domanda: Vedi i gruppi di persone come aggregazioni di individui o come un gruppo coeso, la sua risposta era: “Disperatamente fedele ad entrambi.”
Disse che gli uomini sono fondamentalmente individui, e anche fondamentalmente sociali. Ognuno di noi ha una sorta di mente razionale in grado di prendere decisioni ove possiamo valutare cosa stia succedendo e prendere decisioni e agire di conseguenza. E siamo tutti anche in grado di stringere visceralmente legami con altri gruppi di persone che trascendono gli aspetti intellettuali dell’individuo.
Infatti, Bion era così convinto che questa fosse la risposta giusta che l’immagine sulla copertina del libro era un cubo di Necker, uno di quelli che potete guardare e interpretare in una di due maniere, ma non potrete mai vedere entrambe le interpretazioni contemporaneamente. Quindi i grupi possono essere analizzati sia come collezione di individui, sia avendo questa specie di esperienza emotiva di gruppo.
Cubo di Necker
Ora, è facile vedere come gruppi di persone con un’appartenenza formale, gruppi che sono etichettati e nominati come “sono un membro della gilda così-cosà in un videogioco online multi-giocatore,” è facile vedere come ci sarà della coesione di gruppo lì. Ma la tesi di Bion è che questo effetto sia molto, molto più profondo e entri in gioco molto, molto prima di quando molti di noi si aspetterebbero. Così voglio illustrare questo con una storia, e per illustrare l’illustrazione, userò una storia dalla vostra vita. Perché anche se non vi conosco, so che ciò che sto per descrivere vi è accaduto.
Sei ad una festa, e ti annoi. Dici “Non mi va più. Preferirei essere altrove. Preferirei essere a casa a dormire. Le persone con cui vorrei parlare non sono qui.” In ogni caso la festa non raggiunge una qualche soglia d’interesse. Allora qualcosa di notevole succede: non te ne vai. Prendi la decisione “non mi piace questo.” Se fossi in una libreria e dicessi “ho chiuso,” usciresti. Se fossi in un bar e dicessi “Questo è noioso,” usciresti.
Sei seduto ad una festa, decidi “Non mi piace; non voglio essere qui.” E poi non te ne vai. Quel tipo di collosità sociale è ciò di cui parla Bion.
E poi, un’altra cosa notevole succede. Venti minuti dopo, una persona si alza e prende il cappotto, e cosa succede? Improvvisamente tutti stanno prendendo i cappotti, tutti nello stesso momento. Che significa che tutti avevano deciso che la festa non era per loro, e nessuno aveva fatto nulla, finché finalmente questo evento scatenante aveva liberato la pressione dal gruppo, e tutti si sentivano a posto andandosene.
Quest’effetto è così stabile che talvolta è chiamato il paradosso dei gruppi. È ovvio che non ci sono gruppi senza membri. Ma ciò che è meno ovvio è che non ci sono membri senza un gruppo. Perché di cosa sareste membri?
Quindi c’è questo momento veramente complicato in cui un gruppo conviene insieme, dove abbastanza individui, per qualche ragione, concordano che qualcosa di importante stia accadendo, e la decisione che prendono in quell’istante è: Questo è bene e deve essere protetto. In quel momento, anche se è subconscio, iniziate ad avere effetti di gruppo. E gli effetti che abbiamo visto manifestarsi ancora e ancora nelle comunità online.
Ora, Bion decise che ciò che vedeva coi neurotici era il gruppo che si difendeva dai suoi tentativi di far fare al gruppo ciò che dicevano di dover fare. Il gruppo si era riunito per stare meglio, questo gruppo di persone era in terapia per stare meglio. Ma stavano ostacolando l’obiettivo. E disse, ci sono schemi molto specifici in cui entrano per sconfiggere insieme lo scopo esplicito della riunione. E descrisse tre schemi.
Il primo era chiacchiere a sfondo sessuale, ciò che chiamò, nella sua prosa di metà secolo, “Un gruppo si incontrò per accoppiarsi.” E ciò significa che, il gruppo concepisce il proprio scopo come quello di ospitare chiacchiere lascive o civettuole o emozioni che scorrono fra coppie di membri.
Andate su IRC e scorrete la lista dei canali, e dite “Oh, so di cosa tratta quel gruppo, perché vedo il nome del canale.” E quando entrate nel gruppo, quasi invariabilmente scoprite che è anche riguardo a chiacchiere a sfondo sessuale. Non necessariamente esplicite. Ma è sempre in tema nelle conversazioni umane, secondo Bion. Questo è uno degli schemi base in cui i gruppi possono sempre entrare, lontano dagli scopi sofisticati e verso uno di questi scopi basilari.
Il secondo schema base che descrisse Bion: L’identificazione e vilipendio dei nemici esterni. Questo è uno schema molto comune. Chiunque fosse attorno al movimento Open Source a metà degli anni novanta poteva vederlo costantemente. Se vi interessava Linux sul desktop, c’era una lunga lista di lavori da fare. Ma potevate sempre invece entrare in una discussione su Microsoft e Bill Gates. E le persone iniziavano a sanguinare dalle orecchie, si arrabbiavano così tanto.
Se vuoi migliorarlo, c’è la lista di cose da fare. È Open Source, giusto? Aggiustalo. “No, no, Microsoft e Bill Gates grrr …”, la schiuma iniziava a colare. Il nemico esterno — niente galvanizza un gruppo più di un nemico esterno.
Quindi anche se qualcuno non è realmente il vostro nemico, identificarlo come nemico può provocare un piacevole senso di coesione. E i gruppi spesso gravitano verso i membri che sono più paranoici e li rendono leader, perché quelle sono le persone più brave a identificare i nemici esterni.
Il terzo schema identificato da Bion: Venerazione religiosa. La nomina e adorazione di un icona religiosa o un insieme di concetti religiosi. Lo schema religioso consiste, essenzialmente, nel nominare qualcosa che non può essere criticato. Potete vedere questo sull’Internet qualsiasi giorno vogliate. Andate in un newsgroup su Tolkien o un forum di discussione, e provate a dire “Sapete, Le Due Torri è un po’ insipido. Voglio dire luuuungo. Non ci serviva tutta quella descrizione della foresta, perché è la stessa foresta per tutta la strada.”
Provate a fare quella discussione. Sulla porta il gruppo scriverà: “Qui si discute dei lavori di Tolkien.” Entrate e provate a fare quella discussione.
Ora, in alcuni casi le persone diranno “Sì, ma era necessario, doveva comunicare il senso di letargia,” o qualcos’altro. Ma nella maggior parte dei casi verrete semplicemente flammati fino al cielo, perché state interferendo col testo religioso.
Così questi sono schemi umani che sono apparsi sull’Internet, non a causa del software, ma perché viene usato da umani. Bion ha identificato questa possibilità dei gruppi di isolare i propri scopi sofisticati con questi bisogni primari. E ciò a cui è arrivato alla fine, analizzando questa tensione, è che la struttura di gruppo è necessaria. Le Regole d’Ordine di Robert sono necessarie. Le costituzioni sono necessarie. Norme, rituali, leggi, l’intera lista di modi in cui diciamo “nell’universo di tutti i possibili comportamenti, definiremo un insieme relativamente piccolo di quelli accettabili.”
Disse che la struttura di gruppo è necessaria per difendere il gruppo da sè stesso. La struttura di gruppo esiste per mantere un gruppo in mira, in carreggiata, in tema, e così via. Per mantenere un gruppo focalizzato sui propri obiettivi sofisticati e impedirgli di scivolare in questi schemi base. La struttura di gruppo difende il gruppo dalle azioni dei suoi membri.
Negli anni Settanta — questo è uno schema che si è presentato varie volte in rete — negli anni Settanta, venne lanciata una BBS chiamata Communitree, una delle prime BBS dial-up. Venne lanciata quando le persone non possedevano computer, le istituzioni possedevano computer.
Communitree venne fondata sui principi dell’accesso aperto e dialogo libero. “Communitree” — il nome significa “California negli anni Settanta.” E l’idea era, effettivamente, abbandoniamo le strutture e nuovi magnifici schemi sorgeranno.
E, effettivamente, come ha visto chiunque abbia aggiunto software di discussione in gruppi precedentemente disconnessi, ciò accade. Cose incredibili accadono. I primi tempi di Echo, i primi tempi di usenet, i primi tempi di Habitat della Lucasfilm, e ancora e ancora, vedete tutto questo incredibile sollevamento di persone che improvvisamente sono connesse in modi in cui prima non lo erano.
E poi, quando il tempo è passato, emergono difficoltà. In questo caso, una delle difficoltà fu occasionato dal fatto che una delle istituzioni che ottenne dei modem era una scuola superiore. E chi, nel 1978, stava nella stanza col computer e i modem, se non i ragazzi di quella scuola. E i ragazzi non erano terribilmente interessati in conversazioni sofisticate da adulti. Erano interessati alle battute sulle scoregge. Erano interessati alle chiacchiere lascive. Erano interessati a fare casino e scrivere parolacce e la-la-la, su tutta la bulletin board.
E gli adulti che avevano tirato su Communitree erano inorriditi, e oltrepassati da questi studenti. Il luogo che era stato fondato sull’accesso aperto aveva troppo accesso aperto, troppa apertura. Non potevano difendersi dai propri stessi utenti. Il luogo che era stato fondato sulla libertà di parola aveva troppa libertà. Non avevano modo di dire “No, quello non è il tipo di libertà di parola che intendevamo.”
Ma ciò era una necessità. Per difendersi dall’essere oltrepassati, era qualcosa che necessitavano di avere che non avevano, e come risultato, semplicemente chiusero il sito.
Ora potreste chiedere se l’inabilità dei fondatori di difendersi da questo assalto, dall’essere oltrepassati, fosse un problema tecnico o sociale. Il software non permetteva di risolvere il problema? O era la configurazione sociale del gruppo fondatore, dove semplicemente non potevano digerire l’idea di aggiungere la censura per proteggere i propri sistemi. Ma da un certo punto di vista, non importa, perché le questioni tecniche e sociali sono profondamente intrecciate. Non c’è modo di separarle completamente.
Ciò che conta è, un gruppo progettò questo e poi fu incapace, nel contesto che aveva realizzato, parzialmente un contesto tecnico e parzialmente sociale, di salvarlo da questo attacco interno. Un attacco dall’interno è ciò che conta. Communitree non venne chiuso da persone che provavano a schiantare o inondare il server. Venne chiuso da persone che accedevano e scrivevano, che era ciò che il sistema era stato progettato per fare. Gli aspetti tecnologici di normale utilizzo e attacco erano identici a livello macchina, quindi non c’era modo di definire tecnologicamente cosa dovesse o non dovesse accadere. Alcuni utenti volevano che il sistema continuasse ad esistere e fornire un forum di discussione. E altri, i ragazzi delle superiori, o non erano interessati o erano attivamente nemici. E il sistema non forniva alcun modo per il primo gruppo di difendersi dal secondo.
Ora, questa storia è stata scritta molte volte. È addirittura frustrante vedere quante volte è stata scritta. Sperereste che ad un certo punto qualcuno l’abbia scritta, e spesso lo fanno, ma poi ciò che non succede è che altri la leggano.
La descrizione più gentile di questo schema ripetitivo è “imparare dall’esperienza.” Ma imparare dall’esperienza è il modo peggiore per imparare qualcosa. Imparare dall’esperienza è appena sopra ricordare. Non è bello. La miglior maniera per imparare qualcosa è quando qualcun altro lo capisce e ti dice: “Non andare in quella palude. Ci sono i coccodrilli.”
Imparare dall’esperienza dei coccodrilli è da schiappe, al confronto con imparare leggendo, per dire. Non c’è stato, sfortunatamente, in quest’ambito, molto apprendimente dalla lettura. E così, le lezioni da Habitat della Lucasfilm, scritto nel 1990, sembrano molto le descrizioni di Commmunitree di Rose Stone del 1978.
Questo schema si è ripetuto ancora e ancora. Qualcuno ha costruito il sistema, presupponendo alcuni comportamenti degli utenti. gli utenti sono venuti e hanno esibito comportamenti diversi. E le persone che facevano funzionare il sistema hanno scoperto con orrore che le questioni sociali e tecnologiche non potevano effettivamente essere disaccoppiate.
C’è un bel documento chiamato “LambdaMOO Prende una Nuova Direzione,” [“LambdaMOO Takes a New Direction“] che è riguardo ai maghi di LambdaMOO, l’esperimento di Pavel Curtis presso lo Xerox PARC di costruire un mondo MUD [Multi-User Dungeon, ovvero Labirinto sotterraneo Multi-Utente]. E un giorno i maghi di LambdaMOO annunciarono: “Abbiamo questo sistema funzionante, e tutti questi effetti sociali interessanti. Quindi noi maghi ci occuperemo solo di questioni tecnologiche. Non saremo coinvolti in alcuna di quelle faccende sociali.”
E poi, penso 18 mesi dopo — non ricordo l’esatto periodo di tempo — tornarono. I maghi tornarono, estremamente scontrosi. E dissero: “Ciò che abbiamo imparato da voi utenti lamentosi è che non possiamo fare ciò che dicemmo che avremmo fatto. Non possiamo separare gli aspetti tecnologici da quelli sociali nel mandare avanti un mondo virtuale.
“Quindi siamo tornati, e ci riprendiamo i poteri magici, e faremo cose per mandare avanti il sistema. Ci stiamo effettivamente sistemando come un governo, perché questo posto ha bisogno di un governo, perché senza noi, questo posto stava crollando.”
Le persone che lavorano su software sociale hanno uno spirito più vicino a economisti e scienziati politici che alle persone che fanno compilatori. Entrambi apprezzano la programmazione, ma quando stanno gestendo un gruppo di persone come uno dei fenomeni runtime, è una pratica incredibilmente diversa. Nell’ambito politico, chiameremmo questo tipo di crisi una crisi costituzionale. È ciò che succede quando la tensione fra l’individuo e il gruppo, e i diritti e responsabilità di individui e gruppi, diventa così seria che bisogna fare qualcosa.
E la peggior crisi è la prima crisi, perché non è solo “Dobbiamo avere delle regole.” È anche “Dobbiamo avere delle regole per fare delle regole.” E questo è ciò che vediamo ancora e ancora in sistemi di software sociale grandi e duraturi. Le costituzioni sono una componente necessaria di gruppi eterogenei grandi e duraturi.
Geoff Cohen ha fatto una bella osservazione a questo riguardo. Ha detto “La probabilità che qualsiasi gruppo non moderato entri in una disputa sull’avere o non avere un moderatore si avvicina ad uno mano a mano che il tempo aumenta.” Quando un gruppo si dedica alla propria esistenza come gruppo, e inizia a pensare che il gruppo sia bene e importante, la probabilità che inizino a chiedere ulteriore struttura, per potersi difendere da se stessi, diventa molto, molto alta.
Parte Due: Perché ora?
Se queste cose che sto dicendo sono successe così spesso in passato, sono successe e sono state documentate e abbiamo letteratura psicologica che precede l’Internet, cosa sta succedendo ora da renderle importanti?
Non posso dirvi precisamente perché, ma a occhio sta avvenendo una rivoluzione nel software sociale. Il numero di persone che scrivono strumenti per supportare o migliorare la collaborazione o la comunicazione di gruppo è stupefacente.
Il web ci ha trasformato tutti in regine della misura per sei o otto anni. Era scarsamente accoppiato, senza stato, scalava da matti, e tutto divenne riguardo Quanto grande puoi diventare? “Quanti utenti ha Yahoo? Quanti clienti ha Amazon? Quanti lettori ha MSNBC?” E la risposta poteva essere “Veramente molti!” Ma poteva essere veramente molti solo se non chiedevi a MSNBC di rispondere a quei lettori, e se non chiedevi a quei lettori di parlarsi l’un l’altro.
Lo svantaggio di puntare alle dimensioni e alla scala sopra ogni altra cosa è che schemi densi, interconnessi che promuovono la conversazione e collaborazione di gruppo non sono supportabili a larga scala. Meno è diverso — gruppi piccoli di persone possono interagire in modi nei quali gruppi grandi non possono. E così abbiamo passato quella scala interessante dei gruppi piccoli. Più larghi di una dozzina, più piccoli di poche centinaia, ove le persone possono effettivamente avere conversazioni che non possono essere supportate quando state parlando di decine di migliaia o milioni di utenti, almeno in un singolo gruppo.
Abbiamo avuto cose come le mailing list e le BBS per lungo tempo, e più recentemente abbiamo avuto la Messaggistica Istantanea [MSN Messenger], abbiamo avuto questi vari schemi. E ora, di colpo, queste cose stanno spuntando. Abbiamo weblog e wiki, e penso, ancora più importante, abbiamo roba a livello di piattaforma. Abbiamo RSS. Stiamo raggiungendo oggetti Flash condivisi. Stiamo arrivando a modi per costruire rapidamente su infrastruttura che diamo per scontata, che ci permette di provare cose nuove molto rapidamente.
Stavo parlando con Stewart Butterfield riguardo all’applicazione di chat che stanno provando qui. Gli ho detto “Hey, come va?” Ha detto: “Bene, abbiamo avuto l’idea solo due settimane fa. Quindi ora c’è il lancio.” Quando puoi passare da “Hey, ho un’idea” a “Lanciamo questo per qualche centinaia di appasionati e vediamo come va,” questo suggerisce che ci sia lì una piattaforma che sta permettendo alle persone di fare cose molto interessanti molto rapidamente. Non è che non avreste potuto costruire un’applicazione simile un paio di anni fa, ma che il costo sarebbe stato molto superiore. E quando abbassi i costi, succedono cose nuove interessanti.
Quindi la prima risposta a Perché Ora? è semplicemente “Perché è ora.” Non posso dirvi perché ci sia voluto così tanto per i weblog, eccetto che non ha assolutamente nulla a che fare colla tecnologia. Avevamo ogni pezzo di tecnologia che ci serviva per fare i weblog il giorno in cui Mosaic lanciò il primo browser che supportava form d’immissione. Ogni singolo pezzo era proprio lì. Invece, abbiamo ottenuto Geocities. Perché abbiamo avuto Geocities e non i weblog? Non sapevamo cosa stavamo facendo.
Una era una cattiva idea, l’altra è risultata essere un’idea veramente buona. C’è voluto molto tempo per capire che persone che si parlano reciprocamente, anziché semplicemente caricare foto scannerizzate male dei propri gatti, sarebbe stata una modalità utile.
Arrivammo alla modalità weblog attorno al ’96 con Drudge. Arrivammo a piattaforme per weblog a partire dal ’98. La cosa stava veramente decollando nel 2000. L’anno scorso, chiunque ha realizzato: Ommioddio, questa cosa sta diventando mainstream, e cambierà tutto.
Il momento culminante per me fu quando Phil Gyford lanciò il weblog di Pepys, i diari di Samuel Pepys degli anni 1660 trasformati in forma di weblog, con un nuovo pezzo ogni giorno dal diario di Pepys. Ciò mi diceva: Phil sta asserendo, e io ora credo, che i weblog saranno in giro per almeno 10 anni, perché quello è il periodo in cui Pepys ha tenuto un diario. E quello fu il momento di proiettare nel futuro: Questa ora è infrastruttura che diamo per scontata.
Perché ci fu un intervallo di 8 anni fra un browser che supportava i form e i diari di Pepys? Non lo so. Ci vuole un po’ affinché la gente si abitui a queste idee.
Così, prima di tutto, c’è una rivoluzione in parte perché c’è una rivoluzione. Abbiamo internalizzato le idee e le persone ora ci stanno lavorando. Secondo, le cose che le persone stanno costruendo ora sono web-native.
Quando provavate software sociale sul web a metà degli anni Novanta, molto era: “Questa è la Gigante Corazzata Lotus, ora con la Nuova Interfaccia Web Leggera!” Non sembrava mai come il web. Sembrava una cosa mastodontica, con un piccolo, tipo “Ecco delle icone. Non guardare dietro le tende.”
Un weblog è web-native. È tutto web. Un wiki è una maniera web-native di ospitare collaborazione. È leggero, scarsamente accoppiato, facile da estendere, facile da scomporre. E non solo la superficie, tipo oh, puoi fare queste cose in un form. Presuppone che http sia il trasporto. Presuppone le annotazioni nel codice. RSS è un modo web-native di distribuire notizie. Quindi stiamo prendendo tutti questi strumenti e li stiamo estendendo affinché ci permettano di costruire cose nuove molto velocemente.
Terzo, nella felice frase di David Weinberger, possiamo ora iniziare ad avere schemi di Pezzi Piccoli Liberamente Legati. Vale veramente la pena guardare ciò che Joi Ito sta facendo col movimento Emergent Democracy, anche se non siete interessati nei temi della democrazia emergente. Questo è iniziato perché durante una conversazione, Ito disse “Sono frustrato. Sto seduto qui in Giappone, e so che tutte queste persone stanno facendo conversazioni in tempo reale fra loro. Voglio anch’io avere una conversazione di gruppo. Inizierò una teleconferenza.
“Ma dato che le teleconferenze sono scarse in sè, terrò una finestra di chat nello stesso momento.” E poi, nella prima riunione, penso sia stato Pete Kaminski a dire “Beh, ho aperto anche un wiki, e qui c’è l’indirizzo URL.” E scrisse l’indirizzo nella finestra di chat. E le persone possono iniziare ad annotare cose. Le persone possono aggiungere segnalibri; ecco le liste.
Così, improvvisamente avete questa riunione, che sta procedendo in tre modalità contemporaneamente, due in tempo reale e una annotata. Avete la teleconferenza in corso, e sapete come siano. O una o due persone dominano, o tutti sono tipo “Oh, posso — no, ma –“, tutti si interrompono a vicenda.
È molto difficile coordinare una teleconferenza, perché le persone non possono vedersi, che rende difficile gestire la logica di interruzione. Nella teleconferenza di Joi, la logica di interruzione è stata spostata nella chat. Le persone scrivevano “Mano,” e il moderatore scriveva “Parli per prossimo”. Così la teleconferenza scorreva liscia.
Contemporaneamente, in chat, la gente annotava ciò che la gente diceva. “Oh, mi ricorda del lavoro di coso.” O “Dovresti vedere questo URL… potresti vedere [il libro con] questo ISBN.” In una teleconferenza, per leggere un URL, devi pronunciare ogni lettera — “No, no, no, è w w w punto net trattino….” In una finestra di chat, ce l’hai e puoi cliccarlo. Puoi dire, in conferenza o in chat: “Vai sul wiki e guarda questo.”
Questa è una teleconferenza a banda larga, ma non è una cosa enorme. Sono solo tre piccoli pezzi di software affiancati e tenuti insieme con un po’ di colla sociale. È una modalità incredibilmente potente. È diverso da: Prendiamo il Lotus colosso e aggiungiamogli un’interfaccia web.
E finalmente, e questa è la cosa che penso sia veramente spaventosa, è l’ubiquità. Il web è cresciuto per un lungo periodo. E così alcune persone avevano accesso al web, e poi molte persone avevano accesso al web, e poi la maggior parte delle persone avevano accesso al web.
Ma qualcosa di diverso sta succedendo ora. Non è nemmeno ovunque nel mondo sviluppato. Ma per alcuni gruppi di persone — studenti, persone in uffici ad alta tecnologia, lavoratori della conoscenza — tutti quelli con cui lavorano sono online. Tutti quelli di cui sono amici sono online. Tutti nella loro famiglia sono online.
E questo schema di ubiquità vi consente di iniziare a dare questo per scontato. Bill Joy una volta ha detto “Il mio metodo è guardare a qualcosa che sembra una buona idea e assumere che sia vero.” Iniziamo a vedere software che semplicemente presuppone che tutti i gruppi offline avranno una componente online.
È ora possibile per ogni gruppo, dalle Scout in su, avere una componente online, e che sia leggera e semplice da gestire. Ed è una modalità diversa dalla vecchia “comunità online.” Ho quest’immagine di due hula hoop, il vecchio mondo con due hula hoop, dove la mia vita reale è lì, e la mia vita online è là, e non c’era molta sovrapposizione. Se gl hula hoop vengono uniti, e tutti quelli che sono offline sono anche online, dal mio punto di vista, è una modalità diversa.
C’è un secondo tipo di ubiquità, quello di cui stiamo godendo qui grazie al Wi-Fi. Se presupponete che ogni volta che un gruppo di persone è riunito, possa essere sia faccia a faccia e online contemporaneamente, potete iniziare a fare diversi tipi di cose. Ora non faccio mai una riunione senza avere una chat o un wiki funzionante. Tre settimane fa ho fatto una riunione per la Library of Congress. Avevamo un wiki, tirato su da Socialtext, per catturare le tante e fitte informazioni sulla preservazione digitale nel lungo termine.
Le persone che hanno organizzato la riunione non avevano mai usato un wiki, e ora la Library of Congress parla come se avessero sempre avuto un wiki nelle loro riunioni, e presuppongono che ci sarà anche alla prossima — il wiki è passato da novità a normale in un paio di giorni.
Diventa veramente rapidamente un assunto che un gruppo possa fare cose tipo “Oh, ho preso le mie slide PowerPoint, le ho mostrate, e lo ho piazzate nel wiki. Così ora potete averle.” Diventa una sorta di magazzino condiviso per la memoria di gruppo. Questo è nuovo. Questi tipi di ubiquità, sia ognuno online, e tutti quelli in una stanza possono essere online insieme nello stesso momento, può portare a nuove modalità.
Parte Tre: Cosa possiamo dare per scontato?
Se questi assunti sono giusti, uno che un gruppo sia il proprio peggior nemico, e due, stiamo vedendo un’esplosione di software sociale, cosa dovremmo fare? C’è qualcosa che possiamo dire con certezza riguardo al costruire software sociale, almeno per gruppi grandi e duraturi?
Penso che ci sia. Poco più di 10 anni fa, lasciai il mio lavoro, perché Usenet era così interessante, pensai: Questo diventerà veramente grande. Ed effettivamente scrissi un libro riguardo la cultura delle rete allora: Usenet, Well Echo, IRC e così via. Uscì nell’aprile del ’95, proprio quando il mondo stava venendo sommerso dal web. Ma era il mio interesse originario, quindi ho affrontato il problema in un modo o nell’altro per 10 anni, e me ne sono occupato molto attentamente nell’ultimo anno e mezzo.
Così c’è questa domanda “Cosa serve per rendere di successo un gruppo grande e duraturo?” e penso di poter rispondere con una certa confidenza: “Dipende.” Spero di abbozzare meglio quella risposta nei prossimi dieci anni.
Ma posso almeno dire alcune delle cose dalle quali dipende. I calvinisti avevano una dottrina della grazia naturale e sovrannaturale. La grazia naturale era “Devi fare tutte le cose giuste nel mondo per andare in paradiso…” e la grazia sovrannaturale era “… e Dio ti deve consacrare.” E non sapevi mai se avevi la grazia sovrannaturale o no. Questo era il loro modo di aggirare il fatto che il libro dell’Apocalisse pone un limite superiore al numero di persone che andranno in paradiso.
Il software sociale è così. Potete trovare lo stesso codice che gira in tanti, tantissimi ambienti. E talvolta funziona e talvolta non funziona. Quindi c’è qualcosa di sovrannaturale per il fatto dei gruppi di essere un’esperienza runtime.
L’esperienza normale del software sociale è il fallimento. Se vai su Yahoo e mappi le sottoscrizioni, è, non sorprendentemente, una legge di potenza. C’è un piccolo numero di gruppi molto popolati, un numero moderato di gruppi moderatamente popolati, e questa lunga, piatta coda di fallimento. E il fallimento è inevitabilmente più del 50% delle mailing list totali in qualsiasi categoria. Quindi non è come la ricetta per una torta. Non c’è nulla che possiate fare per farla uscire giusta ogni volta.
Ci sono, però, penso, circa mezza dozzina di cose che sono vere in senso lato per tutti i gurppi che abbia guardato e tutte le costituzioni online che abbia letto per software che supporta gruppi grandi e duraturi. E dividerei questa lista a metà. Direi, se state per creare un pezzo di software sociale per gruppi grandi, dovete accettare tre cose, e progettare per quattro.
Tre Cose da Accettare
- Delle cose da accettare, la prima è che non potete completamente separare questioni tecniche e sociali. Ci sono due soluzioni attraenti. Una dice, gestiremo la tecnologia qui, le questioni sociali lì. Avremo mailing list con gruppi di discussione separati, o avremo una traccia qui e una lì. Non funziona. Non è mai stato scritto più chiaramente che nella coppia di documenti chiamati “LambdaMOO Takes a New Direction.” Non posso fare di meglio che indicarveli.
Ma recentemente abbiamo avuto quest’esperienza ove c’era una lista di discussione del software sociale, e qualcuno ha detto “Lo so, tiriamo su una seconda mailing list per le questioni tecniche.” E nessuno s’è spostato dalla prima lista, perché nessuno poteva separare la conversazione fra questioni sociali e tecniche, perché la conversazione non può essere suddivisa.
L’altra soluzione è molto, molto attraente — chiunque affronti questa roba ha la stessa epifania, che è:”Ommioddio, questo software determina ciò che le persone fanno!” E ciò è vero, fino ad un certo punto. Ma non potete nemmeno programmare completamente le questioni sociali. Quindi non potete separare le due cose, e non potete specificare tutte le questioni sociali nella tecnologia. Il gruppo affermerà i propri diritti in qualche modo, e otterrete una combinazione di effetti sociali e tecnologici.
Quindi il gruppo è reale. mostrerà effetti emergenti. Non può essere ignorato, e non può essere programmato, che significa che avrete un problema perenne. E la soluzione migliore, o almeno quella che ha funzionato più spesso, è di mettere nelle mani del gruppo stesso la responsabilità di definire quale sia il valore, e difenderlo, anziché provare ad ascrivere quelle cose al software anticipatamente.
- La seconda cosa che dovete accettare: I membri sono diversi dagli utenti. Emergerà uno schema per cui c’è un gruppo di utenti che tiene maggiormente all’integrità e al successo del gruppo nel suo insieme. E quello diventa il vostro nucleo, la frase di Art Kleiner per “il gruppo dentro al gruppo che conta di più”.
Il nucleo su Communitree era indifferenziato dal gruppo di utenti casuali che entravano. Erano separanti nelle loro menti, poiché sapevano ciò che volevano fare, ma non potevano difendersi dagli altri utenti. Ma in tutte le comunità online di successo che abbia indagato, emerge un nucleo che ci tiene e si prende cura in modo efficace. Cura l’ambiente, per mantenerlo florido, per mantenerlo sano.
Ora, il software non sempre permette al nucleo di esprimersi, che è il motivo per cui dico che dovete accettarlo. Perché se il software non permette al nuclo di esprimersi, inventerà nuovi modi di farlo.
Su alt.folklore.urban, il gruppo di discussione su folklore urbano su Usenet, c’era un gruppo di persone che passava il tempo e aveva fatto amicizia. E arrivarono a tenere all’esistenza di AFU, al punto in cui, poiché Usenet non faceva distinzione fra membri rispettabili e utenti mordi e fuggi, attivarono una mailing list chiamata The Old Hats. la mailing list era per meta-discussioni, discussioni su AFU, così potevano coordinare formalmente gli sforzi se trollavano o flammavano o ignoravano qualcuno.
Addendum, 2 luglio 2003: Un partecipante di lunga data di a.f.u. dice che la lista Old Hats venne creata per consentire ai membri risiedenti nella Silicon Valley di pianificare un barbecue, così che potessero aggiungere una dimensione faccia-a-faccia alla loro interazione virtuale. L’uso di una lista come dietro le quinte per discutere del newsgroup pubblico emerse dopo il fatto.
Poi, mentre Usenet continuava a crescere, molti nuovi arrivati giunsero e parvero apprezzare l’ambiente, perché era ben gestito. Per difendersi dalle questioni di scala che vengono dall’aggiungere molti membri nuovi alla lista Old Hats, dissero “Inizieremo una seconda lista, chiamata Young Hats.”
Così crearono questo sistema a tre livelli, non diverso dai livelli di codardi anonimi, utenti loggati e persone con karma alto su Slashdot. Ma poiché Usenet non permetteva loro di farlo in software, presero altri pezzi di software, queste mailing list, di cui avevano bisogno per costruire la struttura. Quindi non potete programmare gli utenti, i membri rispettabili si troveranno e riconosceranno l’un l’altro.
- La terza cosa che dovete accettare: Il nucleo ha diritti che superano i diritti individuali in alcune situazioni. Questo si scontra contro la visione libertaria che è [era] piuttosto comune sulla rete, e si scontra assolutamente contro la nozione una testa/un voto. Ma potete vedere esempi di quanto cattiva sia l’idea quando la cittadinzanza corrisponde all’abilità di loggarsi.
Nei primi anni Novanta, uscì una proposta per creare un gruppo Usenet per discutere di cultura tibetana, chiamato soc.culture.tibet. E venne bocciata, in larga parte perché un grande numero di studenti cinesi che avevano accesso Internet la bocciarono, seguendo la logica che il Tibet non era un Paese; era una regione della Cina. E secondo il loro parere, dato che il Tibet non era un Paese, non ci dovevano essere luoghi per discuterne la cultura, perché sarebbe stato ossimorico.
Ora, chiunque poteva vedere che questa era la risposta sbagliata. Le persone che volevano un posto per discutere la cultura Tibetana avrebbero dovuto ottenerlo. Quello era il nucleo. Ma poiché il modo una testa/un voto su Usenet diceva “Chiunque sia su Usenet può votare su qualsiasi gruppo,” un gruppo sufficientemente discutibile poteva esser semplicemente bocciato.
Immaginate se oggi, negli Stati Uniti, gli utenti Internet andassero sondati prima di poter creare qualsiasi gruppo anti-guerra. O gli utenti francesi sondati prima che qualsiasi gruppo pro-guerra venisse creato. Le persone che vogliono avere quelle discussioni sono quelle che contano. E la cittandinanza assoluta, con l’idea che se puoi accedere, sei un cittadino, è pericolosa, perché è la tirannia della maggioranza.
Quindi il nucleo ha bisogno di modi per difendersi — sia nello stabilirsi e per gli effetti di cui ho parlato prima — il nucleo ha bisogno di difendersi affinché possa rimanere sui propri obiettivi sofisticati e lontano dagli istinti di base.
La Wikipedia ha un sistema simile oggi, con un dipartimento volontario di pompieri, un gruppo di persone che tiene in modo inusuale al successo della Wikipedia. E hanno abbastanza leva, per il modo in cui i wiki funzionano, che possono sempre ripristinare i graffiti e così via, che quella roba è rimasta su nonostante attacchi ripetuti. Quindi sfruttare il nucleo è un sistema veramente potente.
Ora, quando dico che queste sono tre cose che dovete accettare, intendo che dovete accettarle. Perché se non le accettate subito, vi succederanno comunque. E poi finirete per scrivere uno di quei documenti che dicono “Oh, abbiamo lanciato questo e l’abbiamo provato, e poi gli utenti sono arrivati e hanno fatto tutte queste cose strane. E ora le documentiamo così le future generazioni non faranno questo errore.” Anche se non avete letto le cose che vennero scritte nel 1978,
Tutti i gruppi di qualsiasi integrità hanno una costituzione. La costituzione è sempre in parte formale e in parte informale. Come minimo, la parte formale è ciò che è sostanziato nel codice — “il software funziona in questo modo.”
La parte informale è il senso in cui “facciamo le cose qui.” E indipendentemente da come sia sostanziata nel codice o scritta in un documento la parte formale, ci sarà sempre anche una parte informale. Non potete separarle.
Quattro Cose Per Cui Progettare
- Se steste costruendo un pezzo di software sociale per supportare gruppi grandi e duraturi, per cosa dovreste progettare? La prima cosa per cui progettereste sarebbe per pseudonimi sui quali gli utenti possano investire.
Ora, ho detto “pseudonimi,” perché non voglio dire “identità,” perché l’identità è improvvisamente diventata una di quelle idee, dove tirando il piccolo filo che volete, questa grossa mole di roba gli viene dietro. L’identità è un tema così caldo, ma per la roba tranquilla richiesta per il software sociale, è in verità solo lo pseudonimo che conta.
Il miglior sistema al mondo di gestione della reputazione è proprio qui, nel cervello. E veramente, è proprio qui, nel retro, nella parte emotiva. Quasi tutto il lavoro fatto oggi sui sistemi di reputazione è banale o inutile o entrambi, perché le reputazioni non sono linearizzabili, e non sono trasferibili.
Ci sono persone che tradiscono il partner ma non imbrogliano a carte, e viceversa, ed in entrambi i casi, e in nessun caso. La reputazione non è necessariamente trasferibile da una situazione a un altra, e non è facilmente espressa.
eBay ha reso a noi tutti un disservizio enorme, perché eBay funziona in transazioni atomiche non ripetute, che sono l’opposto delle situazioni sociali. Il sistema di reputazione di eBay funziona incredibilmente bene, perché inizia con una transazione linearizzabile — “Quanti soldi per quanti Puffi?” — e la trasforma in una metrica ugualmente lineare.
Ciò non funziona bene nelle situazioni sociali. Se volete un buon sistema di reputazione, ricordatemi chi siete. E se mi fate un favore, lo ricorderò. E non lo piazzerò nella parte frontale del cevello, lo piazzerò qui, nel retro. Avrò una sensazione piacevole la prossima volta che riceverò un’email da voi; non ricorderò nemmeno perché. E se mi renderete un disservizio e riceverò un email da voi, le mie tempie inizieranno a pulsare, e non ricorderò nemmeno perché. Se date agli utenti moti di ricordarsi l’uno dell’altro, la reputazione succederà, e ciò richiede nulla più che pseudonimi semplici e in qualche modo persistenti.
Gli utenti devono potersi identificare e ci dev’essere una penalità per chi cambia pseudonimi. La penalità non dev’essere totale. Ma se cambio il mio pseudonimo nel sistema, devo perdere qualche tipo di reputazione o di contesto. Questo mantiene in funziona il sistema.
Ora, questo cozza contro tutto ciò che abbiamo fin dai primi scritti psicologici sull’Internet. “Oh, sull’internet cambieremo tutti identità e genere come cambiamo i calzini.”
E poi vedete cose come la storia di Kaycee Nicole, dove una donna del Kansas finse di essere studente delle superiori, e poi siccome gli amici della studentessa inventata si fecero coinvolgere emotivamente così tanto, che poi provò a uccidere il personaggio Kaycee Nicole. “Oh, ha il cancro e sta morendo ed è tutto molto tragico.” E ovviamente, tutti volevano volare per incontrarla. Così poi tipo si impanicò e sparì. E alcuni luoghi sull’Internet, in particolare la comunità MetaFilter, si attivarono per scoprire cosa stava succedendo, e scoprirono la bufala. Fu una specie di movimento distribuito d’investigazione.
Ora alcune persone indicano questo e dicono “Vedi, ti avevo detto dell’identità!” Ma la storia di Kaycee Nicole è questa: cambiare la propria identità è veramente strano. E quando la comunità capisce che l’hai fatto e stai fingendo, è visto come un’enorme trasgressione violenta. E spenderanno una stupefacente quantità di energia per trovarti e puntirti. Quindi l’identità è molto meno fluida di quanto la prima letteratura voglia farci credere.
- Secondo, dovete progettare un modo affinché ci siano membri rispettabili. Perché in qualche modo i membri rispettabili emergeranno. Ma più e più sistemi che vedo partire in questi giorni hanno qualche genere di accumulazione aggiuntiva affinché possiate dire quanto coinvolgimento abbiano i membri col sistema.
C’è uno schema che vedo nei gruppi di condivisione musicale operanti fra Tokyo e Hong Kong. Operano su una mailing list, che si sono attivati. Ma quando si scambiano musica, ciò che fanno è, si inviano con Fed-Ex dischi rigidi da 180 giga l’un l’altro. [nel 2003, alla scrittura, 180 giga era quasi il massimo disponibile sul mercato, oggi nel 2018 sarebbero circa 2 o 3 TB].
Ora, potete immaginare che un tale sistema possa essere un obiettivo per le organizzazioni che biasimerebbero quest’attività. Così quando ti unisci a quel gruppo, il tuo nome utente è concatenato con quello della persone che è il tuo sponsor. Non puoi entrare senza che il tuo nome sia legato a qualcun altro. Potete vedere immediatamente gli effetti reputazionali in gioco, solo legando due pseudonimi.
Così in quel sistema, diventate membri rispettabili quando il vostro legame sponsor se ne va e siete solo voi. Se, d’altro canto, tradite, non solo siete cacciati, ma il vostro sponsor è cacciato. Ci sono tanti e tanti modi leggeri per accettare e lavorare con l’idea di membri rispettabili.
- Tre, vi servono barriere alla partecipazione. Questa è una delle cose che uccise Usenet. Dovete avere qualche costo di ingresso o partecipazione, se non al livello più basso, almeno a quelli superiori. Ci dev’essere qualche segmentazione delle competenze.
Ora, la segmentazione può essere totale — siete dentro o siete fuori, come col gruppo musicale appena citato. O può essere parziale — chiunque può leggere Slashdot, codardi anonimi possono scrivere, codardi non anonimi possono scrivere con punteggio superiore. Ma per moderare, dovete veramente esser stati nel giro per un po’.
Deve essere difficile fare almeno alcune cose sul sistema per alcuni utenti, o il nucleo non avrà gli strumenti necessari per difendersi.
Ora, questo cozza contro la virtù cardinale della facilità d’utilizzo. Ma la facilità d’utilizzo è sbagliata. La facilità di unitlizzo è il modo sbagliato di guardare la situazione, perché avete il cubo di Necker girato nella direzione sbagliata. L’utente del software sociale è il gruppo, non l’individuo.
Penso che siamo stati tutti in riunioni dove tutti sono stati bene, ci parliamo tutti l’un l’altro e scherziamo e ridiamo, ed è stata una gran riunione, eccetto che non abbiamo combinato nulla. Chiunque si stava talmente divertendo che l’obiettivo del gruppo è stato sconfitto dagli interventi individuali.
L’utente del software sociale è il gruppo, e la facilità di utilizzo dovrebbe essere del gruppo. Se la facilità di utilizzo è calcolata solo dal punto di vista dell’utente, sarà difficile difendere il gruppo da attacchi in stile “il gruppo è il proprio peggior nemico” dall’interno.
- E, infine, dovete avere un modo per salvare il gruppo dalla dimensione. La dimensione da sola uccide le conversazioni, perché le conversazioni necessitano di conversazioni bidirezionali dense. In contesti conversazionali, la legge di Metcalfe [“L’utilità e il valore di una rete sono proporzionali al quadrato del numero degli utenti”] è un peso. Il fatto che l’ammontare di connessioni bidirezionali che dovete supportare cresca col quadrato degli utenti significa che la densità della conversazione cola a picco molto rapidamente mentre il sistema cresce anche di poco. Dovete avere un modo per permettere agli utenti di fissarsi sulla modalità “meno è più”, per rimanere associati l’un l’altro.
Questo è un valore inverso rispetto alla questione dimensionale. Pensate alla vostra rubrica. Mille contatti, magari 150 persone che potete chiamare amici, 30 persone che potete chiamare amici intimi, due o tre personche alle quali donereste un rente. Il valore è inverso alla dimensione del gruppo. E dovete trovare un modo per proteggere il gruppo nel contesto di quegli effetti.
Talvolta potete fare una suddivisione morbida. LiveJournal fa la miglior suddivisione morbida di qualsiasi software che abbia mai visto, dove i concetti di “tu” e “il tuo gruppo” sono abbastanza intrecciati. La dimensione media di un gruppo LiveJournal è circa una dozzina di persone. E la dimensione mediana è attorno a cinque.
Ma ogni utente è un po’ connesso ad altri raggruppamenti simili, tramite i propri amici, e così mentre i raggruppamenti sono veri, non sono completamente limitati — c’è una sovrapposizione che significa che sebbene la maggior parte degli utenti partecipano a gruppi piccoli, la maggior parte del mezzo milione di utenti LiveJournal è connessa l’uno con l’altro tramite qualche tipo di catena.
I canali IRC e le mailing list sono auto-moderanti con la dimensione, perché quando il rapporto segnale/rumore peggiora, la gente inizia ad abbandonare, finché non migliora, così la gente si aggiunge, e così peggiora. Avete questa sorta di schema oscillante. Ma si auto-corregge.
E poi il mio schema preferito è da MetaFilter, che è: Quando iniziamo a vedere effetti dimensionali, chiudiamo la pagina dei nuovi utenti. “Qualcuno ci nomina nella stampa e quanto bravi siamo? Ciao!” Quello è un modo di alzare l’asticella, è creare una soglia alla partecipazione. E chiunque metta un segnalibro per quella pagina [metta quella pagina nei “Preferiti”] dicendo “Sai, voglio veramente essere lì; magari più tardi tornerò,” quello è il tipo di utente che MeFi vuole avere.
Dovete trovare qualche modo per proteggere i vostri utenti dalla dimensione. Questo non significa che la dimensione dell’intero sistema non possa crescere. Ma non potete provare a rendere grande il sistema prendendo le conversazioni individuali e gonfiandole come un pallone; l’interazione umana, interazione molti-a-molti, non si gonfia come un pallone. O si dissipa, o diventa uno-a-molti unidirezionale, o collassa. Quindi pianificate in anticipo per gestire la dimensione, perché succederà comunque.
Conclusione
Ora, quelle quattro cose sono ovviamente condizioni necessarie ma non sufficienti. Le propongo più come una piattaforma su cui costruire le differenze. Ci sono tanti e tanti altri effetti che rendono pezzi diversi di software interessanti abbastanza da voler più di un tipo di modalità in giro. Ma quelle sono costanti che sto vedendo attraverso un intervallo di software sociali per gruppi grandi e duraturi.
In aggiunta, potete fare molte cose con raggruppamenti espliciti, che siano gilde in giochi massivamente multi-giocatore, o comunità su LiveJournal o ciò che vi pare. Potete fare cose con artefatti conversazionali, dove la partecipazione di gruppo si lascia dietro qualche documento. La Wikipedia proprio adesso, l’enciclopedia online collaborativa di gruppo è l’artefatto conversazionale più interessante che conosca, dove il prodotto è il risultato di un processo. Anziché “Ci uniremo specificamente e creeremo questa presentazione” è solo “Ciò che rimane è il documento di ciò che abbiamo detto.”
Ci sono tutte queste cose, e ovviamente cambiano da piattaforma a piattaforma. Ma c’è questo, credo, nucleo comune di cose che succedereanno sia che pianifichiate per esse o no, e cose per cui dovreste pianificare, che penso siano invarianti per tutto il software comunitario.
Scrivere software sociale è difficile. E, come detto, l’atto di scrivere software sociale è più simile al lavoro di un economista o di uno scienziato politico. E l’atto di ospitare software sociale, la relazione di qualcuno che lo ospiti è più simile alla relazione fra locatario e affittuario che quella fra di proprietari di scatole in un magazzino.
Le persone che usano il vostro software, anche se lo possedete e avete pagato per esso, hanno diritti e si comporteranno come se ne avessero. E se abrogate quei diritti, ne sentirete parlare molto rapidamente.
Quella è parte del problema per cui la teoria della comunità di John Hegel — la comunità porta al contenuto, che porta al commercio — non ha mai funzionato. Perché vedete, non importava chi arrivasse sulle chat board Clairol, talvolta volevano parlare di cose che non erano prodotti Clairol.
“Ma abbiamo pagato per questo! Questo è il sito Clairol!” Non importa. Gli utenti sono lì l’uno per l’altro. Possono essere su hardware e software pagati da voi, ma gli utenti sono lì l’uno per l’altro.
Gli schemi qui, suggerisco, sia le cose da accettare che quelle per cui progettare, sono dati. Assumeteli come un tipo di piattaforma sociale, e poi potete iniziare ad andare e costruire su di essi roba interessante che penso sarà il vero risultato di questo periodo di sperimentazione col software sociale.
Grazie mille.»