Sistemi Informativi: FLOSS

 

Con questo mio intervento vorrei ulteriormente approfondire il significato del termine hacker. La parola hacker indica un soggetto che affronta sfide intellettuali con lo scopo di aggirare o superare in modo creativo i limiti che gli vengono imposti, non solo esclusivamente all’interno dei suoi ambiti d'interesse, che solitamente rientrano nel campo informatico o dell'ingegneria elettronica, ma in tutti gli aspetti della vita. Nel linguaggio comune il termine viene per tanto utilizzato erroneamente per designare un pirata informatico, la cui definizione corretta sarebbe invece cracker. Entrando in alcuni forum che trattano dell’argomento si nota come gli hacker amino definirsi come inventori, studiosi del mondo, creatori, una sorta di filosofi del mondo moderno. All’interno del mondo hacker vi è accordo a far risalire l'etimologia della parola al MIT (Massachusetts Institute of technology), dove il termine fece la sua comparsa nel gergo studentesco all'inizio degli anni '50. In questo periodo, il sostantivo hacker, veniva utilizzato come sinonimo della parola "goof", la cui traduzione in italiano può essere resa con i termini scemenza o goliardata. In seguito, verso la fine degli anni ‘50, il termine "hack" acquistò una connotazione più forte, poiché gli studenti iniziarono ad assumere un comportamento maggiormente ribelle allo scopo di opporsi alle rigide regole imposte all’interno del campus. Scherzi e burle varie divennero un modo per scaricare la tensione accumulata, per deridere l'amministrazione dell’istituto e per dare sfogo a quei pensieri e comportamenti creativi che venivano repressi dal rigoroso percorso di studio affrontato. Questa combinazione, tra divertimento creativo ed esplorazioni senza limiti determinerà le i futuri cambiamenti del termine hacking. I primi ad auto-qualificarsi come "computer hacker", all’interno del campus del MIT negli anni '60, erano un gruppo di studenti appassionati di modellismo ferroviario. In maniera sottile, il termine hacking si trasformò da sinonimo di gioco ozioso, a un gioco in grado di migliorare le prestazioni o l'efficienza complessiva del sistema ferroviario del club. In seguito, quando all’interno del campus fecero la loro comparsa i primi modelli di computer, gli studenti abbandonarono il mondo del modellismo per concentrare le loro capacità sul nuovo mondo dell’informatica. L’affermarsi del vasto reame della programmazione informatica determinò un'ulteriore mutamento etimologico della parola. In questo periodo si iniziò ad utilizzare il verbo"To hack" per indicare l’attività che aveva lo scopo di comporre assieme vari programmi, senza rispettare le procedure e i metodi utilizzati nella scrittura del software "ufficiale". Questo lavoro aveva come scopo principale perfezionamento dell'efficienza e la della velocità del software già esistente. Ed è proprio in riferimento a questa attività che si individua successivamente una diversa radice del verbo "to hack" che sta ad indicare il verbo "tagliare", "sfrondare", "sminuzzare", "ridurre", "aprirsi un varco", appunto fra le righe di codice che compongono i programmi software. Un hacker era quindi uno che era capace di ridurre la lunghezza e la complessità  del codice sorgente con un "hack" ossia con una procedura grezza ma efficace, che potrebbe essere tradotta in italiano come "zappata" o "accettata" o altrimenti con "furbata". Rimanendo fedele alla sua radice, il termine indicava anche la creazione di programmi aventi come unico scopo quello di divertire o di intrattenere l'utente. Saranno i concetti di innovazione collettiva e di proprietà condivisa del software a distinguere l'attività di computer hacking degli anni '60 da quelle del decennio precedente. I computer hacker di questo periodo incominciarono a operare all'interno di una disciplina scientifica fondata sulla collaborazione e sull'aperto riconoscimento dell'innovazione. Nella seconda metà degli anni '70 il termine "hacker" aveva assunto la connotazione di élite. In generale computer hacker era chiunque scrivesse il codice software per il solo gusto di riuscirci. In senso specifico, indicava capacità e abilità nella programmazione, un po’ al pari del termine "artista". Con il restringimento della definizione, l'attività di computer hacking acquisì nuove connotazioni semantiche. Per potersi definire hacker una persona doveva riuscire a fare qualcosa di più che scrivere programmi interessanti, doveva condividere l'omonima cultura e onorarne le tradizioni. Gli hacker di istituzioni elitarie come il MIT, Stanford e Carnegie Mellon iniziarono a parlare specificatamente di "etica hacker" per indicare le norme non ancora scritte che governavano il comportamento quotidiano dell'hacker. Successivamente l'immagine di una comunità hacker analoga a una corporazione medievale è stata superata con l’avvento delle tendenze eccessivamente populiste dell'industria del software. Partendo dai primi anni '80 i computer si diffusero un po' ovunque, e i programmatori improvvisamente si trovarono a stretto contatto con hacker di grande livello per mezzo di Arpanet. Per mezzo di questa vicinanza, i comuni programmatori presero ad appropriarsi delle filosofie sovversive tipiche della cultura hacker di ambiti come quello del MIT. Tuttavia nel corso di una simile trasmigrazione di valori, andò perduto il tabù culturale prodotto all’interno MIT, contro ogni comportamento avverso e doloso. Mentre, i programmatori più giovani iniziarono a sperimentare le proprie capacità con finalità dannose, generando e disseminando, ad esempio, virus e facendo invasioni nei sistemi informatici militari, il termine "hacker" assunse connotati punk, nichilisti. Quando polizia e imprenditori iniziarono a far risalire quei reati a un gruppo di programmatori rinnegati che si rifacevano per propria difesa a frasi fatte tratte dall'etica hacker, quest'ultimo termine prese ad apparire all’interno dei mezzi d’informazione con connotazioni di taglio negativo.  Questo nonostante testi inerenti al mondo hacker avevano cercato di documentare lo spirito originale di esplorazione da cui traeva origine la cultura dell'hacking. Per la maggioranza dei giornalisti "computer hacker" divenne sinonimo di "rapinatore elettronico". Negli ultimi vent’anni, le forti lamentele degli stessi hacker contro questi presunti abusi, si sono fatte insistenti, a tal punto da spingere la maggioranza degli hacker ad usare il termine cracker per indicare un soggetto che volontariamente decide di violare un sistema di sicurezza informatico allo scopo di rubare o di manomettere dei dati. Questo fondamentale tabù contro gli atti dolosi resta il principale collegamento culturale tra l'idea di hacking del primo scorcio del XXI secolo e quello degli anni '50. È importante notare come, mentre la definizione di computer hacking abbia subito un'evoluzione durante gli ultimi quarant’anni, il concetto originario di hacking in generale (come burlarsi di qualcuno) sia rimasto invece inalterato.

 

Fonte: Wikipedia

« La società ha bisogno di libertà: quando un programma ha un proprietario, l'utilizzatore perde la libertà di controllare parte della sua vita. » (Richard Stallman)

 

« Non siamo contro nessuno, siamo solo a favore della libertà, abbiamo scopi costruttivi. » (Richard Stallman)

 

« Il "controllo sull'uso delle proprie idee" in realtà costituisce un controllo sulle vite degli altri; e di solito viene usato per rendere più difficili le loro vite. » (Richard Stallman)

 

« La legislazione sui brevetti fu introdotta per incoraggiare gli inventori a rivelare i dettagli delle loro invenzioni. Lo scopo era avvantaggiare la società più che avvantaggiare gli inventori. A quel tempo la validità di 17 anni per un brevetto era breve se confrontata con la velocità di avanzamento dello stato dell'arte. Poiché i brevetti riguardano solo i produttori, per i quali il costo e lo sforzo degli accordi di licenza sono piccoli in confronto all'organizzazione della produzione, spesso i brevetti non costituiscono un gran danno. E non ostacolano la gran parte degli individui che usano prodotti coperti da brevetto. » (Richard Stallman)

 

« Pagare per dei byte è come pagare l'aria, il problema è che di questo passo prima o poi pagheremo anche l'aria. » (Anonimo)

 

« Il software è come il sesso, è meglio quando è libero. » (Linus Torvalds)

 

 

 

In questo saggio l’autore esplora i modelli di interazione sociale e tecnologica, che emegono nello sviluppo di progetti di free/open source software (F/OSSD).

Una delle caratteristiche più importanti dello sviluppo di progetti di free/open source software è la formazione e la divulgazione di complessi processi di sviluppo di software, eseguiti da sviluppatori e contributori vagamente coordinati. Queste persone danno volontariamente il loro tempo e le loro abilità per tale impegno e inoltre lavorano solo a loro personale discrezione anziché secondo compiti stabiliti e fissati. In più gli sviluppatori F/OSS lavorano in progetti di software che non hanno tipicamente un proprietario corporativo o un management staff che organizza, dirige, e monitora il lavoro.

Scacchi si pone le seguenti domande: perché gli sviluppatori di software partecipano ai progetti F/OSSD? Come sono i grandi progetti F/OSSD coordinati, controllati e gestiti senza un tradizionale management team?

L’autore, per rispondere a queste domande, utilizza il concetto di socio-technical interaction networks (STINs). Questi legami sono un framework concettuale, che serve per identificare, organizzare e analizzare comparativamente i modelli di interazione sociale, lo sviluppo del sistema e la configurazione delle componenti che costituiscono un sistema informativo. Più specificatamente un STINs denota un insieme di relazioni collettive tra:

“… persone (incluse le organizzazioni), attrezzature, dati, diverse risorse (soldi, abilità, status), documenti e messaggi, accordi legali e meccanismi di applicazione, e flussi di risorsa. Gli elementi di un STINs sono eterogenei. Le relazioni e legami tra questi elementi includono interazioni sociali, economiche, politiche.” (Kling 2003)

Di conseguenza un STINs fornisce uno schema per esaminare i legami tra le persone che lavorano insieme attraverso processi sociali e tecnici intercorrelati, che sorgono per creare complessi sistemi e prodotti informativi.

Il concetto di STINs può essere visto come la crescita concettuale dei sistemi socio-tecnici e della “actor network theory”. La prospettiva socio-tecnica prevede un mondo di organizzazioni complesse che impiegano continuamente tecnici e ingegneri per sviluppare sistemi per gli utenti, dove il successo nello sviluppo di un sistema dipende dalla partecipazione e dal coinvolgimento intenso degli utenti del sistema. Inoltre il disegno socio-tecnico cercò di coinvolgere e bilanciare gli interessi delle persone (sviluppatori e utenti finali), i prodotti (sistemi, documentazione, …) e i processi (disegno del sistema e utilizzo) focalizzandosi sulla partecipazione e il coinvolgimento di tutti gli stakeholders del sistema.

Actor-network theory (Callon, Latour, Law) da un lato pone l’attenzione ai processi che diventano chiusi e razionalizzati, alle idee che sono accettate e ai metodi e agli strumenti che sono adottati; e dall’altro pone l’attenzione al bisogno dello studio empirico di cosa le persone fanno nel loro lavoro, di quali strumenti, risorse e artefatti producono, usano e consumano. Inoltre la actor-network theory si focalizza sulle relazioni.

 

 

Capire le pratiche e i processi di sviluppo del F/OSS

 

Non essendoci un modello precedente o una struttura globalmente accettata che definisca come il F/OSS si sia sviluppato in pratica, Scacchi decide di investigare le pratiche F/OSS in differenti comunità. I progetti F/OSSD sono stati studiati dall’autore in almeno sei differenti e diverse comunità F/OSS, al fine di identificarne le pratiche generali.

Dallo studio dei dati emergono almeno quattro aree dove la formazione e l’attività di STINs è più chiara:

1. partecipare, unirsi e contribuire ai progetti F/OSS;
2. formare alleanze e costruire comunità di pratiche attraverso artefatti collegati;
3. coordinare, cooperare e controllare i progetti F/OSS;
4. co-evoluzione dei sistemi sociali e tecnici F/OSS.

Nessuna di queste aree è indipendente o più importante delle altre e ognuna può verificarsi simultaneamente ad un’altra e quindi non sono ordinate all’interno di un tradizionale modello circolare o all’interno di uno a spirale.

 

1. Partecipare, unirsi e contribuire ai progetti F/OSS:

 

Ci sono complesse motivazioni che spiegano la disponibilità degli sviluppatori ad allocare il loro tempo, le loro abilità e il loro impegno nei progetti F/OSS. Qualche volta essi possono vedere il loro sforzo come qualcosa che è divertente, che da’ soddisfazione personale o che fornisce un luogo dove essi possono esercitare e migliorare le loro competenze tecniche in un modo che non sarebbe possibile all’interno del loro attuale lavoro. Comunque, le persone che partecipano, contribuiscono e si uniscono ai progetti F/OSS tendono ad agire in strade dove la costruzione della fiducia e della reputazione, la realizzazione di “geek fame” (fama di essere capace con i PC), oltre che la donazione di tempo, esperienza e codice sorgente, sono tratti di valore.

Inoltre diventare un nodo centrale nel network sociale degli sviluppatori software, che interconnette multipli progetti F/OSS, è anche un modo per accumulare capitale sociale e riconoscimento dal gruppo dei pari. In più, la partecipazione in progetti F/OSS come sviluppatore centrale può comportare ricompense finanziarie, in termini di più alti salari, per i lavori convenzionali di sviluppo di software. Infine permette anche la fusione di sistemi F/OSS indipendenti in sistemi compositi più ampi.

Le persone che partecipano ai progetti F/OSS hanno uno o più ruoli. Gacek e Arief forniscono una classificazione della gerarchia dei ruoli, che le persone assumono, e dei compiti che esse compiono quando partecipano ad un progetto F/OSS (Figura 1). Tipicamente accade che le persone si uniscono a un progetto e si specializzano in un ruolo (o in multipli ruoli) che esse trovano personalmente confortevole e intrinsecamente motivante, infatti non c’è un esplicita assegnazione degli sviluppatori ai ruoli, come nei progetti tradizionali di sviluppo di software.

 

 

 

 

 

 

 

 

 

 

In un progetto F/OSS è comune trovare un utente finale che diventa un contributore o sviluppatore e uno sviluppatore che agisce come utente finale. Comunque la maggior parte dei partecipanti, probabilmente, preferisce essere un semplice utente. Inoltre i partecipanti spesso partecipano in differenti ruoli all’interno dei networks sociali e tecnici nel corso dello sviluppo, dell’uso e dell’evoluzione dei sistemi F/OSS (Figura 2).

 

 

 

 

 

 

 

 

 

Dare contributi è spesso un prerequisito per l’avanzamento tecnico e sociale all’interno della comunità. Molto comunemente, i partecipanti contribuiscono con differenti tipi di contenuti.

Frequentemente, i partecipanti ai progetti F/OSS partecipano ai forums di discussione online o si inviano mail, ma comunque partecipano anche a discussioni offline o private online, il cui contenuto non viene divulgato.

Centrale, per lo sviluppo dei progetti F/OSS, sono i meccanismi software di ampliamento e le licenze, che assicurano libertà e/o apertura. I meccanismi di ampliamento permettono la modifica della funzionalità o dell’architettura dei sistemi di software. Le licenze spesso derivano da GNU (GNU is not Unix) Public License (GPL).

 

2. Formare alleanze e costruire comunità di pratiche attraverso artefatti collegati;

 

Gli sviluppatori software si trovano e connettono l’un l’altro attraverso F/OSS Web sites e i discorsi online e condividono molte competenze tecniche, valori e credenze. Questa condivisione di credenze, valori, artefatti e strumenti permette non solo la cooperazione, ma fornisce anche una base per esperienze condivise, cameratismo e apprendimento. Gli sviluppatori F/OSS partecipano e contribuiscono per scelta più che per incarico. Anche la GNU General Public License (GPL) per il software libero cerca di conservare e reiterare le credenze e le pratiche di condivisione, esaminazione, modificazione e redistribuzione dei sistemi F/OSS.

 

Lo sviluppo dei sistemi F/OSS avviene all’interno di una comunità e il processo di costruzione del project team deve essere istituzionalizzato all’interno della comunità. Anche downloading, installare e usare i sistemi F/OSS, acquistati da altri F/OSS Web sites, fa parte del processo di costruzione della comunità. I sistemi F/OSS, gli artefatti e gli strumenti collegati e i project Web sites servono come luoghi per socializzare, costruire relazioni e fiducia, condividere e apprendere con altri. Questi Web sites sono generalmente globali in portata e accessibilità e quindi i vari contributori possono provenire da multiple nazioni e aree e rappresentare gli interessi di multiple culture.

Costruire comunità, formare alleanze e contribuire partecipando sono attività essenziali e ricorrenti che permettono ai progetti F/OSS di persistere senza una autorità centrale. La figura 3 rappresenta un esempio di un network sociale.

 

 

 

 

 

 

 

 

3. Coordinare, cooperare e controllare i progetti F/OSS

 

Il dover ricercare delle modalità per risolvere i conflitti che sorgono all’interno delle comunità di sviluppatori F/OSS comporta dei costi in termini di capitale sociale. Per questo la ricerca di strumenti e di forme organizzative capaci di minimizzare o di mitigare i più frequenti conflitti diventa un fine importante per gli sviluppatori competenti. Gli strumenti CVS (Software version control) sono stati estesamente adottati all’interno dei progetti F/OSS per tale scopo. L’uso di questi strumenti comporta che ciascun gruppo di progetto o amministratore depositario di CVS debba decidere cosa possa essere controllato o chi sarà in grado di controllare nuovi o modificati contenuti di codici sorgente. Il ricorso ad una politica di questo tipo alle volte è esplicitamente fatta ricorrendo ad una votazione formale mentre altre volteè fatta tramite un sistema informale, implicito e soggetto a negoziazione. I progetti F/OSS possono assumere la forma organizzativa di una meritocrazia stratificata, la quale opera come un’impresa virtuale organizzata funzionalmente. Una meritocrazia stratificata coincide con una forma organizzativa gerarchica la quale centralizza e concentra certe forme d’autorità, di fiducia e di rispetto per l’esperienza e l’abilità dentro il gruppo. Comunque, questa non consiste implicitamente con una singola autorità poiché questa può essere condivisa fra gli sviluppatori centrali, i quali agiscono come pari all’interno dello strato più alto. La figura illustra la forma organizzativa meritocratica comune a diversi progetti F/OSS. In questa forma il lavoro dello sviluppo del software appare essere logicamente centralizzato, mentre è fisicamente distribuito in maniera autonoma e decentralizzata. Questa modalità organizzativa non può comunque essere definita semplicemente ne a “cattedrale” ne a “bazar”, termini che possono essere utilizzati per descrivere alternativi modi di organizzare progetti di sviluppo software. Quando la meritocrazia stratificata opera secondo le modalità di un’impresa virtuale, questa fa affidamento ad un progetto di gestione virtuale (VPM) per mobilitare, coordinare, controllare, costruire e assicurare la qualità dello sviluppo delle attività F/OSS. Un progetto di gestione virtuale richiede molteplici persone che agiscono all’interno dei ruoli di team manager, manager di sotto sistema o proprietari di moduli sistema.

4. Co-sviluppare sistemi socio-tecnici per F/OSS

La manutenzione del software, la quale consiste nell’aggiunta o sottrazione di funzionalità al sistema, è molto diffusa all’interno delle comunità di sviluppo F/OSS. Probabilmente questo non risulta essere sorprendente, poiché la manutenzione è considerata generalmente come l’attività maggiormente costosa per un sistema software nell’arco del suo ciclo di vita. La manutenzione del software comunque non da giustizia di quanto effettivamente accada all’interno delle molteplici comunità F/OSS. Questo è invece reso in maniera più evidente dall’attività di reinvenzione. La reinvenzione permette infatti  la condivisione, l’esame, la modifica e la redistribuzione di concetti e tecniche che sono presenti all’interno di sistemi a codice chiuso, di ricerche e pubblicazioni, di conferenze e all’interno dell’interazione e del discorso tra sviluppatori e utenti tramite molteplici progetti F/OSS. Così la reinvenzione è una continua fonte di miglioramento della funzionalità e della qualità F/OSS, come pure un approccio collettivo all’apprendimento organizzativo nei progetti F/OSS.

 

Molti dei più grandi e popolari progetti F/OSS come Linux Kernel sono cresciuti ad una velocità esponenziale, ma la vasta maggioranza dei progetti F/OSS è piccola, di breve durata e spesso coinvolge gli sforzi di un solo sviluppatore. Quindi solo pochi progetti si ritrovano ad avere una massa critica di 5-15 sviluppatori centrali che agiscono condividendo ruoli di leadership nel progetto. Questi sono contemporaneamente circondati da dozzine di centinaia di altri collaboratori e da centinaia di milioni di utenti finali. Questi progetti F/OSS, che riescono a raggiungere e a sopportare una massa critica di tali dimensioni, sono quelli che riescono inevitabilmente a raccogliere la maggior attenzione e il maggior utilizzo. D’altra parte la vasta maggioranza dei progetti F/OSS è piccola, manca di massa critica ed è per questo molto improbabile che possa fiorire e crescere. La meritocrazia stratificata presente all’interno dei progetti F/OSS tende ad abbracciare innovazioni incrementali radicali innovazioni. Questo consiste nell’esplorazione d’ inesperti o sufficientemente differenti sistemi di funzionalità, di architetture o di metodi di sviluppo. Radicali cambiamenti del sistema potrebbero essere difesi da una minoranza di collaboratori al codice i quali sfidano la status quo degli sviluppatori centrali. Il loro successo comunque implica la creazione o il mantenimento di una separata versione del sistema e la potenziale perdita di una critica massa di altri sviluppatori F/OSS. Per questo i mutamenti incrementali tendono a vincere e a prevalere nel corso del tempo. Solitamente i sistemi F/OSS co-evolvono con le loro comunità di sviluppo. Questo significa che l’evoluzione dell’uno dipende dall’evoluzione dell’altra. Detto in modo differente, un progetto F/OSS con un piccolo numero di sviluppatori non produrrà un vitale sistema a meno che o finché il gruppo raggiunge una più larga critica massa composta da almeno 5-15 sviluppatori. Inoltre la comunità d’utenti finali co-evolve con il sistema in maniera reciproca, e l’architettura del sistema e la sua funzionalità cresce in modo discontinuo. Quello che questi trend segnalano è che le pratiche di sviluppo dei processi F/OSS è differente dalle tradizionali pratiche di sviluppo difese e sostenute dall’ingegneria software.

Limitazioni e costrizioni di STINs sui processi di sviluppo F/OSS.

F/OSS non è certamente una panacea per il complesso sviluppo di sistemi software e non è nemmeno ingegneria software fatta poveramente. Il F/OSS deve essere considerato come un approccio alternativo per sviluppare sistemi software e i relativi artefatti, come pure allo stesso tempo anche le relazioni sociali. Questo comunque non deve essere considerato privo di limitazioni e costrizioni. La prima limitazione è collegata ai termini di partecipazione, collegamento e contributo ai progetti F/OSS. L’interesse dello sviluppatore, la sua motivazione e il suo impegno al progetto è infatti dinamico e indefinito. Gli stessi sviluppatori F/OSS sono disgustati nel dover ricercare in prima persona dei contributi per un progetto che deve essere realizzato commercialmente. Alcune forme di reciprocità sembrano essere indispensabili per sostenere la partecipazione, mentre la percezione di sfruttamento da parte dei collaboratori può rapidamente dissolvere l’impegno dei partecipanti i quali possono rapidamente giungere a dissuadere altri partecipanti ad abbandonare un progetto open source. Se gli sviluppatori arrivano a perdere l’interesse il sistema F/OSS può rapidamente diventare instabile, fragile e difficile da mantenere. In questo caso risulta indispensabile che altri collaboratori vadano a ricoprire il ruolo e a prendersi la responsabilità del coordinamento dell’attività. La seconda limitazione riguarda la formazione di alleanze e la costruzione  di comunità attraverso la partecipazione,  tramite l’uso di artefatti e di strumenti che derivano dalla crescente dipendenza da altri progetti F/OSS. L’aumento di fondazioni no-profit che sono state create per proteggere i diritti di proprietà di una larga parte di progetti F/OSS ha fatto aumentare la domanda di sostegno e protezione di tali fondazioni. Nel caso in cui una fondazione diventi troppo burocratica questa può condurre i collaboratori ad allontanarsi dal progetto. Così, se queste fondazioni vogliono sopravvivere ed evolversi, devono rimanere magre e non devono diventare una fonte di carriere occupazionali.

 

Il terzo limite è relativo ai termini di cooperazione, coordinazione e controllo dei progetti F/OSS, i quali non si sottraggono ai conflitti riguardo a chi debba prendere decisioni socio-tecniche o nello scegliere chi debba lavorare su cosa o chi debba aggiornare o modificare cosa. I progetti F/OSS generalmente mancano di manager di progetto e per questo i partecipanti devono prendere fiducia nelle loro abilità per mitigare o risolvere notevoli conflitti e disaccordi. Le credenze e i valori che formano le scelte della progettazione dei sistemi, come pure le scelte su quali strumenti usare e su quali artefatti software produrre o usare, sono determinate attraverso negoziazione piuttosto che attraverso l’assegnazione di compiti amministrativi. L’ultimo limite riguarda i termini della co-evoluzione dei sistemi F/OSS e delle comunità. Come già notato in precedenza sia risorse individuali che condivise risorse di tempo, di sforzi, d’ attenzione, di capacità, di sentimenti (credenze e valori) e di calcolate risorse fanno parte di una rete socio tecnica che costituisce il F/OSS. Reinventare gli esistenti sistemi software coincide con l’emergere o la reinvenzione di una comunità che cerca di far sì che tale sistema di reinvenzione avvenga. I sistemi F/OSS sono comuni fondi di risorse che richiedono l’azione collettiva della comunità al progetto F/OSS.