• Non ci sono risultati.

Queste cifre, pur non essendo esaustive dell’intera attività di sviluppo perseguita, sono comunque indicative delle dimensioni dei progetti

N/A
N/A
Protected

Academic year: 2021

Condividi "Queste cifre, pur non essendo esaustive dell’intera attività di sviluppo perseguita, sono comunque indicative delle dimensioni dei progetti"

Copied!
37
0
0

Testo completo

(1)

5)LE IMPRESE E I PROGETTI OPEN SOURCE

5.1 Il campione di progetti Open Source

Come indicato nel paragrafo 3.2, il campione su cui si è basata l’analisi è composto da 300 progetti selezionati attraverso una statistica mirata ad individuare il grado di attività di un progetto nel periodo della rilevazione. Per cominciare si intende mostrare quale sia il “progetto medio” che può essere individuato: si è cercato di capire in che modo si distribuissero certe grandezze e con quale occorrenza si presentassero determinate situazioni (sia che si tratti di un tipo di licenza, di un linguaggio di programmazione o di una categoria merceologica). Lo scopo fondamentale è stato capire se certi assunti consolidati nella letteratura abbiano ancora dei riscontri oggettivi: riguardano ad esempio la maggior propensione verso piattaforme Linux, così come l’utilizzo di licenze di tipo GPL.

Una prima informazione fondamentale è quanti degli iniziali 300 progetti vedano coinvolte delle imprese a qualche titolo nelle fasi di sviluppo (dalla programmazione al testing): dell’intero campione, 97 risultano appartenere a questo caso specifico, con un rapporto circa di 1:3. Il dato risulta essere più elevato delle aspettative avute ad inizio lavoro ed anche delle assunzioni di molti testi presenti in letteratura, che tendono invece a puntare maggiore attenzione sull’aspetto volontaristico di adesione al movimento Open Source; al contrario non stupisce eccessivamente se si pensa al filone di letteratura in cui questo lavoro si inserisce, per quanto il risultato atteso fosse ad ogni modo inferiore. L’abbondanza di occorrenze per questo sotto-campione ha reso anche possibile una ulteriore suddivisione in alcune categorie di “tipologia di intervento dell’impresa”:

sulle caratteristiche di questi progetti nello specifico, così come di questa suddivisione, sarà fatta chiarezza nei paragrafi a seguire.

Altra informazione è il numero di persone che lavorano ad un determinato progetto. A tal proposito, è necessaria una premessa: i numeri evidenziati da SourceForge riguardano il computo totale di amministratori e sviluppatori ufficiali, senza quindi tenere traccia di tutti quegli utenti che possono offrire aiuti nello sviluppo (per quanto, solitamente, i singoli contributi siano molto circoscritti e spesso limitati a segnalazioni di bug). Queste cifre, pur non essendo esaustive dell’intera attività di sviluppo perseguita, sono comunque indicative delle dimensioni dei progetti. Per quanto riguarda gli amministratori (informazione, tra le due, meno rilevante), la media è di 2.58; per quanto riguarda gli sviluppatori, invece, si attesta a 13.67 (il valore non eccessivamente elevato trova numerose conferme nella letteratura sul fenomeno Open Source: un possibile riferimento è a Lerner e Tirole).

(2)

Il solo dato medio, tuttavia, non permette di sciogliere un dubbio di fondo: il valore medio è legato ad una generale situazione di questo tipo, o piuttosto il panorama è quello di un’abbondanza di micro-progetti affiancati da rari casi di grandissime esperienze? In tal senso, risulta interessante analizzare anche la distribuzione delle occorrenze: si più quindi evidenziare come il 64 % dei casi preveda al più 10 sviluppatori (192 occorrenze), dato che unito al 17 % di quelli con un numero compreso tra 11 e 20 fa intuire come lo scenario più realistico sia il secondo (aggregando, avremo una percentuale del 81 % per i casi con al massimo 20 sviluppatori). Su 300 progetti, infatti, sono solo 11 (il 3.65 %) quelli con un numero di sviluppatori superiore a 50 (con una punta massima di 136, verificatosi in occasione di un software senza collaborazioni con imprese).

11 11

192 18

17

51

1-10 11-20 21-30 31-40 41-50 51-140

Dettagliando ulteriormente l’intervallo dove la concentrazione è maggiore, si scopre che il 15 % dei progetti (45) prevede un solo sviluppatore, accanto al 10.33 % (31) per i casi con due sviluppatori , con un 46.66 % entro i 5 sviluppatori (140 casi). Il panorama è dunque quello di una forte concentrazione verso il basso, con rari casi di dimensioni nettamente più ampie dal comune, tali da far lievitare la media generale.

0 5 10 15 20 25 30 35 40 45 50

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

(3)

Queste argomentazioni sono ulteriormente confermate dai valori di moda (1) e mediana (7), nettamente inferiori al valore medio prima calcolato.

Per quanto riguarda gli amministratori, dato il loro numero molto più esiguo (solo in rari casi si raggiunge o si supera la decina), non risulta interessante approfondire la distribuzione come fatto in precedenza. Può essere notato, però, come la mediana sia pari a 2 e la moda a 1.

Prima di scendere all’interno delle caratteristiche tecniche e di sviluppo, possono essere riportate alcune statistiche relative all’utilizzo di alcuni strumenti offerti da SourceForge, nell’ottica di dimostrare l’importanza di quest’ultimo e in quale misura gli sviluppatori vi si appoggino. Un primo dato interessante è che dei 300 siti Web dei progetti, 159 (il 53 %) sono ospitati sullo spazio offerto da SourceForge. Per quanto riguarda invece le mailing list interne al repository, esse sono state evidenziate in 200 casi (2 su 3); è inoltre da notare come, in molti casi, si abbiano più di una mailing list: una distinzione molto frequente è quella tra lista destinata agli sviluppatori (con scambi di informazioni tecniche e annotazioni di bug rilevati nel codice) e agli utenti (con domande e scambi di idee sull’utilizzo del software). Mediamente si hanno circa 2 mailing list per progetto;

dettagliando la distribuzione per i casi in cui questo strumento è utilizzato abbiamo:

0 10 20 30 40 50 60

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Come si può notare, il 75 % dei casi prevede al massimo 3 mailing list (i casi di grande abbondanza sono molto rari e dettati da esigenze specifiche del progetto).

Ancor più interessante risulta analizzare il livello d’attività relativo ai forum (strumento che, nel corso dell’analisi, è risultato generalmente quello più utilizzato per lo scambio di informazioni): di questi, 191 sono interni a SourceForge (circa il 64 %), poco meno dunque delle mailing list, ma va rilevato come non siano rari i casi di utilizzazione di altri forum esterni al repository (meno frequente invece per le liste). La media che si ottiene come messaggi postati (al momento delle rilevazione) è di 1576, senza però tener conto di tutti i casi di forum inesistenti: se infatti si restringe l’analisi solo ai casi significativi, la media sale naturalmente, fino ad attestarsi a 2475. Sorge il dubbio, analogamente a quanto evidenziato per gli sviluppatori, se lo scenario sia omogeneo intorno

(4)

a questo valore o se al contrario la moda sia notevolmente più bassa della media. Dettagliando inizialmente in gruppi da 5000 (suddividendo, cioè, il campione tra forum con meno di 5000 messaggi, quelli tra 5001 e 10000 messaggi, e così via), si evidenzia come l’87.43 % dei casi ricade nell’intervallo più piccolo e addirittura il 92.66 % non supera i 10000. Andando più in dettaglio, con un passo di 500 messaggi, si evidenzia come persista sempre un 56.54 % dei casi con al più 500 messaggi presenti in forum. Compiendo un ultimo passo in questa direzione, infine, continua ad essere considerevole una percentuale del 27.75 % per i forum con al massimo 50 messaggi (più di un quarto) e una del 33.51 % (circa un terzo del campione) se si fissa il limite a 100 interventi.

Nonostante l’ampia diffusione dello strumento, dunque, solo in rari casi si ha un’alta e soprattutto costante utilizzazione, a fronte invece di una maggioranza di realtà più frammentate. Si può ipotizzare, stante questo panorama, che un consistente scambio di informazioni avvenga anche in forma privata (mail dirette alle singole persone), principalmente dagli utilizzatori agli sviluppatori (per richieste di informazioni o per proporre migliorie): non sussiste però la possibilità (per ovvi motivi di privacy) di avere accesso a simili statistiche. A conferma di quanto già emerso, si può evidenziare come la mediana sia pari solamente a 27.

Rimanendo ancora sulle funzioni offerte da SourceForge, meritano un’annotazione i premi che, con cadenza mensile ed annuale (questa seconda opzione è valida solo dal 2006), vengono attribuiti all’interno del repository: dei 300 progetti del campione, 30 (10 %) hanno ottenuto almeno un riconoscimento. Per finire, prima di passare ai dettagli relativi allo sviluppo e alle prestazioni dei software, è sta investigata brevemente anche la propensione a ricevere donazioni dagli altri utenti:

esso sono risultate abilitate nel 40 % dei casi. In particolare, il 47.5 % di questi ha avuto al momento un solo donatore e il 20 % due donatori (rari i casi con più alta numerosità, con un massimo di 5). Da notare come, in più di un caso, i donatori abbiano deciso di restare in forma anonima.

Oltre agli strumenti già descritti, SourceForge ne offre altri, dalla possibilità di postare report di bug e patch a quella di inserire richieste per modifiche ai software; a queste possono essere affiancate delle statistiche, dal numero di download a quello delle pagine visitate, che permettono di capire la mole di traffico a cui il repository è sottoposto e soprattutto identificare delle grandezze potenzialmente interessanti per identificare differenze tra progetti con imprese coinvolte o meno.

Nella tabella sottostante vengono riportate le dimensioni e per ciascuna i valori di media, moda e mediana.

(5)

Media Moda Mediana

Report di Bugs aperti 59 0 14

Report di Bugs totali 476 0 105

Richieste di Supporto aperte 12 0 1

Richieste di Supporto totali 69 0 4

Patches aperti 431 0 3

Patches totali 389 0 16

Richieste di Caratteristiche aperte 7245 0 53

Richieste di Caratteristiche totali 4039 0 82

Sottoscrizioni nel SVN 2326 0 319

Letture nel SVN 20580 0 721

Download giornalieri 4854 5 251

Click alla pagina principale giornalieri 62878 0 1982

Pagine visitate giornaliere 15717 4976 1943

La moda, in quasi tutti i casi, è pari a 0, a causa dell’ampiezza dei range lungo cui i lavori si dispongono; più significativa invece la mediana, maggiormente rappresentativa dell’andamento dei valori.

Passando ad aspetti più strettamente legati al software, può essere interessante avere un’idea dell’età dei progetti stessi: va comunque specificato che l’informazione è relativa alla data di registrazione del progetto presso SourceForge (senza dunque considerare le fasi precedenti di lavoro, in genere però temporalmente limitate rispetto alle fasi successive rilevabili).

Volendo visualizzare un andamento temporale all’interno del campione, la distribuzione risulta la seguente:

(6)

0 10 20 30 40 50 60

'99 '00 '01 '02 '03 '04 '05 '06

A partire dal nuovo millennio l’andamento risulta essere abbastanza costante nella registrazione di nuovi progetti, con una dominanza verso gli ultimi quattro anni (evidenza probabilmente del fatto che spesso, dopo 5 e più anni di sviluppo, il software raggiunge una conformazione stabile e perde lentamente di interesse, soppiantato da soluzioni più innovative e recenti).

È stata anche analizzata la distribuzione dei progetti nelle varie fasi di sviluppo: su come queste siano definite si rimanda al paragrafo 3.2. Essa risulta essere:

55%

10% 0%

28%

1% 6% Planning

Pre-alpha Alpha Beta Produzione stabile Maturo

Oltre la metà dei software sono già arrivati ad una produzione stabile: questo conferma le indicazioni già riportate nel paragrafo 3.2 secondo cui la modalità con cui i software sono stati selezionati favorisce i prodotti effettivamente sviluppati all’interno del repository, escludendo tutti quei casi di progetti che ristagnano indefinitamente nelle fasi preliminari. All’interno dei progetti effettivamente attivi, lo stesso paragrafo evidenzia come il campione qui utilizzato risulta essere rappresentativo.

Passando alle fasi di sviluppo vero e proprio, una prima domanda è verso quali piattaforme questi sistemi rivolgano in particolare la loro attenzione: un’idea diffusa vorrebbe un’alta propensione verso sistemi Linux nello specifico e un’avversione verso le soluzioni Windows. La realtà risulta tuttavia differente: su 300 software 167 sono compatibili col sistema operativo di Microsoft ed in 50 casi si tratta di soluzioni esclusive per questo ambiente. La maggiore attenzione è ancora rivolta

(7)

verso soluzioni differenti (242 casi complessivi, con 125 in cui il programma non è compatibile con Windows), ma il fenomeno è meno marcato di quanto ipotizzato da molti studiosi. Lo stesso Linux (nelle versioni vere e proprie, senza dunque considerare le varie derivazioni e diramazioni: un esempio è Solaris, sviluppato dalla Sun Microsystems e basato anch’esso su kernel Unix) è risultato compatibile in 144 casi (poco meno della metà).

Passando ai linguaggi di programmazione utilizzati, il panorama risulta essere vario, con 27 differenti linguaggi, dalla famiglia del C (C, C++, C#) al java, da sistemi più datati come Fortran e Pascal ad altri come Python, dal PHP al Delphi/Kylix ad altri ancora. Data l’estrema frammentazione, viene fornita una visualizzazione della distribuzione con particolare attenzione alle soluzioni più diffuse (tra cui spiccano, in ordine decrescente, java, C++, C, PHP, javascript, Python, Perl e C#) ed accorpando quelle con meno di 6 occorrenze come “altro” (per dovere di cronaca, l’elenco di questo raggruppamento prevede: TCL, Visual Basic, Assembly, PL/SQL, XSL, Fortran, Pascal, Unix Shell, Cold Fusion, Lua, Objective C, Visual Basic .NET, Lisp, Object Pascal, Asp.net, Ada e Asp).

56 9 8

19 23

32 30

90

40 64

88

java C++

C PHP javascript Python Perl C#

Delphi/Kylix JSP Altro

La grande eterogeneità dei linguaggi utilizzati, per altro, ha dissuaso (dopo alcuni tentativi iniziali) dall’uso del numero di righe di codice come metrica significativa per misurare l’intensità del lavoro di sviluppo, a causa delle differenti strutture e sintassi riscontrabili.

Per quanto riguarda i database di riferimento (ove essi siano previsti) si tratta dell’informazione più raramente diffusa (evidenziata in 74 casi). Nonostante il minor campione, anche in questo caso si è annotata un’ampia gamma di probabilità (23 database differenti), con una maggioranza per MySQL (presente nel 37.30 % dei casi) e un buon numero di occorrenze per PostgreSQL (28.38 %) e JDBC (seguiti da Oracle e Microsoft SQL Server). Per fornire una rappresentazione grafica indicativa dell’andamento, viene riportato un grafico analogo al precedente.

(8)

32 6

6

8 9

9 10

35

12 19

21

MySQL PostgreSQL JDBC Oracle

Microsoft SQL Server HSQL

XML-based SQL-based IBM DB2 Flat-file Altro

Come fatto per i linguaggi di programmazione, per semplice precisione l’elenco di tutti i database con non più di 5 occorrenze è il seguente: SyBase, SQLite, Python Database API, Firebird/Interbase, ODBC, ADOdb, DBMS-based, Microsoft Access, PHP Pear :: DB, API, Perl DBI/DBD, Berkeley/Sleepycat/GDBM e altri API.

Una volta analizzate le fasi dello sviluppo, alcune statistiche restanti riguardano il prodotto stesso del progetto e la sua destinazione.

Una prima informazione è con quale licenza questi software siano distribuiti. Seguendo quanto evidenziato in molti studi, la licenza di tipo GPL è quella nettamente più frequente (57.91 % dei casi, con 194 occorrenze), seguita a distanza da una sua derivazione (la LGLP, col 12.84 %). Più indietro la BSD (7.76 %), la Mozilla Public License 1.1 (5.37 %), la Apache License 2.0 (3.88 %) e tutte le altre (Common Public License, licenze proprietarie specifiche, Python License, zlib/libpng license, Eclipse public license, MIT license, artistic license, open software license, wxWindows library, zope public license e OSI_approved Open Source), per un totale complessivo di 17 differenti tipi di licenza (il numero reale sarebbe poi ulteriormente maggiore, dati i 9 casi di “altra licenza proprietaria”, di cui 7 identificabili con una precisa impresa sviluppatrice).

Un’altra dimensione di analisi è costituita dalla categoria verso cui il software è destinato: può infatti essere indicativo capire se si tenda a rivolgersi verso utenti con un elevato grado di conoscenze informatiche, utenti domestici meno esperti o realtà aziendali. Il caso più frequente (29.16 %) è quello dei cosiddetti “end-user”, seguiti a breve distanza dagli sviluppatori (26.9 %).

Sembra sussistere dunque un certo bilanciamento da un punto di vista delle conoscenze, ma agli sviluppatori possono essere affiancati gli amministratori di sistemi (9.98 %) e gli utenti più avanzati (4.19 %), elementi che fanno ipotizzare una propensione verso profili medio-alti. La stessa incidenza di progetti destinati alla scienza e alla ricerca (4.51 %) avvalora questa affermazione. Per quanto riguarda invece le imprese, il 29.77 % dei casi evidenzia un riferimento diretto ad uno specifico settore o area aziendale; nel computo, tuttavia, non vanno esclusi a priori i casi prima elencati (ad esempio utenti avanzati e sviluppatori). In questa ottica sembrano coesistere soluzioni

(9)

assai differenti e rivolte a realtà imprenditoriali e non (maggiori evidenze si possono cogliere studiando le categorie merceologiche di riferimento dei progetti); una visione riassuntiva dei casi più frequenti è la seguente :

77 20 19

28 26

181

41

62 167

Utente Sviluppatore

Amministratore IT

Ricerca Utente avanzato

Finanziario Apprendimento

Altro

Per dovere di cronaca, come fatto in precedenza per le altre dimensioni, l’elenco delle categorie definite come “altro” sono: servizio clienti, sanità, manufacturing, ingegneria della qualità, telecomunicazioni, settore legale, organizzazioni no-profit, settore aerospaziale e governi.

Un’ultima dimensione di analisi è quali siano le categorie merceologiche o i settori di appartenenza di ciascun progetto (ognuno di essi è generalmente definito da più di una etichetta). Risulta impossibile, per praticità, elencare tutte le categorie riscontrate: ne esistono infatti 177 differenti, e nonostante ciò in 9 casi si fa anche riferimento ad una categoria “altro”. Si passa, dunque, da strumenti a carattere matematico/scientifico a videogiochi, da software aziendali (ERP, CRM) a sistemi di sicurezza (firewall, filtri), da applicazioni legate al Web (Internet, client di mail) a soluzioni multimediali, da software grafici (in 2D e 3D, con funzioni di modellazione e rendering) ad applicativi molto specifici (calendari, fogli di testo). Una rappresentazione grafica, in questo caso, risulta eccessivamente dispersiva e dunque poco funzionale. Dovendo evidenziare le maggiori occorrenze, meritano un’annotazione la categoria dei “contenuti dinamici” (etichetta forse troppo generica in cui rientrano 37 progetti), i software per lo sviluppo (26), applicazioni Internet in senso stretto (20), la generica categoria “impresa” (16), i framework (12), i front-end (12), i giochi di intrattenimento (12), la sicurezza (12), il business d’ufficio (11), il file sharing (11), l’accounting (10) e la gestione di siti (10). Tutte le altre categorie compaiono meno di dieci volte (citando in ordine sparso alcune delle più significative avremo strumenti di sviluppo, chat, calendari, compilatori, CRM, ERP, strumenti di conversione, database, strumenti per il desktop, editor di testo, client e-mail, gestione di file, applicazioni legate a Gnome, grafica, matematica/fisica, monitoraggio, clustering, networking, gestione di punti vendita, giochi di ruolo, amministrazione di sistema, interfacce utente e visualizzazioni). Spingersi ulteriormente nella trattazione di questa specifica dimensione risulta però scarsamente rilevante, sia per l’estrema frammentazione (il

(10)

proliferare di categorie rende mediamente basso il numero di occorrenze e dunque le considerazioni ottenibili), sia per la discrezionalità degli sviluppatori nell’attribuzione delle etichette (è infatti il responsabile del progetto a fare l’associazione: non sono quindi da escludere casi in cui ne siano state evidenziate alcune più generiche trascurandone invece altre più specifiche).

Un’ultima dimensione è il numero di lingue in cui il software è reso disponibile: il caso più frequente è quello di una sola opzione (moda e mediana sono entrambe pari a 1), sebbene esistano casi più ampi (la media complessiva è di 6.39) con una punta massima di 46.

5.2 I tipi di interventi di imprese

Per entrare nel problema dell’intervento delle imprese nel fenomeno Open Source, il primo passo è capire in quali mezzi questo possa realizzarsi.

Sono state evidenziate 3 macro-categorie (al suo interno ciascuna può prevedere molteplici casi, come specificato in seguito):

1) l’impresa si limita a fornire porzioni di codice o protocolli agli sviluppatori, senza intervenire attivamente nelle fasi di programmazione e testing;

2) l’impresa collabora attivamente al progetto, nella sua interezza o con singoli dipendenti (anche uno) destinati al progetto (senza però avere un controllo diretto e gerarchico): i contributi possono essere di varia rilevanza e natura, da contributi nelle fasi di scrittura del codice a quelli nelle fasi di testing;

3) l’impresa gestisce e controlla l’intero progetto, a cui possono partecipare anche esterni.

Il primo fattore da evidenziare è l’occorrenza di ciascuna casistica, sintetizzata nel grafico seguente (si noti come il computo totale risulti essere pari a 104 e non a 97, che è il numero di progetti che vedono imprese coinvolte: questo perché vi sono casi in cui coesistono più imprese che apportano differenti contributi al progetto in questione; si noti ulteriormente come, nel caso invece di più imprese che forniscano la stessa tipologia di intervento, tutte quante contino esclusivamente per uno, in quanto in questa fase il focus non è tanto sulle imprese direttamente, quanto piuttosto sui progetti e sulle tipologie di interventi possibili su di essi):

(11)

7

37

60

0 10 20 30 40 50 60

Fornisce codice Collabora Gestisce Tipo intervento d'impresa

Si nota immediatamente la prevalenza di collaborazioni (presenti nel 38.14 % dei progetti che vedono una o più imprese coinvolte) e soprattutto gestioni (61.86 %) a fronte dell’altra categoria (7.22 %): non sempre un’impresa può avere grande interesse a diffondere il proprio codice ad un progetto di cui non fa parte attivamente (una possibile motivazione può essere l’indiretta pubblicità conseguente all’introdurre un proprio protocollo all’interno di un progetto famoso e di grandi dimensioni).

Un’attenzione particolare merita però il gruppo principale delle gestioni, in quanto può essere ulteriormente suddiviso in 3 casistiche:

3.1) l’impresa ha fondato il progetto e tuttora ne ha il controllo per lo sviluppo e l’eventuale commercializzazione;

3.2) l’impresa subentra a progetto già avviato, assumendone in fasi successive il controllo;

3.3) l’impresa, che tuttora gestisce il progetto, è diretta conseguenza del successo di questo ultimo (solitamente i membri del team originario di sviluppo, per far fronte alle sempre maggiori richieste ed impegni, decidono di riunirsi in un’impresa, spesso costituita da pochissimi elementi, anche uno, specializzata sul business relativo al software o alla famiglia di software legati al progetto).

Risulta dunque interessante capire quale dei tre fenomeni sia il più frequente.

Per quanto riguarda la fondazione dell’impresa in seguito al successo del progetto, essa compare in 7 occasioni, con un’incidenza dunque del 11.67 % rispetto al gruppo delle gestioni (i 60 progetti che prevedono questa modalità) e del 7.22 % se si considera l’intero computo di 97 progetti che vedono imprese coinvolte. Interessante notare come in nessuno di questi casi siano coinvolte altre imprese a qualche titolo.

Più frequente è invece il caso di imprese che sono subentrate a progetto già avviato: questo caso è stato riscontrato in 17 occasioni (il 28.33 % dei progetti gestiti da imprese e, più in generale, il 17.53 % dei coinvolgimenti di qualsiasi tipo). I modi in cui l’impresa può inserirsi ed acquisire il

(12)

controllo dei lavori sono vari: alle volte l’impresa si limita ad assumere lo sviluppatore del progetto (acquisendo, al tempo stesso, il copyright), mentre in altri casi l’impresa inizialmente si affianca al progetto fornendo collaborazione nelle operazioni di supporto e distribuzione ma acquisendo al tempo stesso sempre più importanza interna (facendo entrare, ad esempio, membri del proprio staff nel team di sviluppo con posizioni privilegiate).

L’ultimo caso, quello peraltro più diffuso, vede l’impresa fondare essa stessa il progetto, aprendolo (immediatamente o in fasi successive) a comunità Open Source e più in generale alla collaborazione con l’esterno. Questa evenienza è stata riscontrata 36 volte: il 60 % delle gestioni da parte dell’impresa, ovvero il 37.11 % dei progetti che vedono coinvolte imprese (dunque più di un terzo).

Questa alta numerosità rimarca ancor più l’importanza delle realtà aziendali nel fenomeno Open Source: non solo infatti le imprese partecipano alle comunità ma riescono a gestire un numero consistente di progetti che in molti casi sono stati avviati da esse stesse (dunque seguendo strade e modalità di sviluppo dettate dalle loro esigenze). La realtà dei fatti è quanto mai distante da alcune assunzioni ormai datate sulla natura stessa del movimento Open Source e sulle forze che lo guidano.

7

17

36

0 5 10 15 20 25 30 35 40

Impresa fondata in seguito

Impresa sopraggiunta

Impresa fondatrice del progetto

Imprese che gestiscono progetti

Un altro aspetto da annotare è come, in molti casi, la presenza non si esaurisca con una sola impresa, ma si estenda anzi a più realtà, finanche a raggruppamenti di esse, in più di un caso legate non solo attraverso i progetti in esame (quasi tutte le imprese individuate, infatti, sia che siano specializzate sul solo Open Source sia che applichino soluzioni miste, sono impegnate su vari fronti e comunità legati al software a codice libero). In 7 casi le imprese intervengono con modalità differenti nello stesso progetto: un’impresa che gestisce direttamente un progetto, al quale però collaborano anche (senza alcuna possibilità di controllo) una o più altre imprese.

La tipologia stessa di imprese coinvolte risulta estremamente variegata, sia per la filosofia e il modus operandi (principalmente imprese legate esclusivamente all’Open Source o che si rivolgono anche ad altri sistemi di distribuzione), sia per il mercato di sbocco (spaziando tra vari business, principalmente legati a soluzioni di Information Technology e gestione imprenditoriale), sia per le

(13)

dimensioni (da realtà di piccola grandezza fino ad arrivare a colossi come Intel, Sun Microsystems e Red Hat). Anche la distribuzione territoriale è molto variabile, andando ad includere anche casi di imprese italiane (come CreaLabs, Cripta Sistemi, Ethea, Euristic, Liscor, Newsoft, SynTech e Demetra).

Il passo successivo è individuare comportamenti peculiari all’interno dei sottogruppi, con un occhio particolare ai due più numerosi (proprio grazie alla più alta presenza permettono di svolgere delle analisi statistiche).

Partendo con il caso meno frequente, ovvero quello di imprese che forniscono codice, si deve sottolineare come l’eccessiva ristrettezza della statistica (7) renda impossibile definire in maniera precisa e certa alcuni tratti peculiari. Si potranno dunque, al più, cogliere degli indizi che andrebbero però avvalorati da un più ampio campione specifico. Si può anzitutto annotare come 5 di questi progetti abbiano un sito ospitato su SourceForge, annotazione che insieme ad un utilizzo medio di mailing list e forum superiore alle medie riscontrate negli altri sottocampioni fa sospettare un più alto affidarsi agli strumenti offerti dal repository, spiegabile pensando che, in questi casi, l’impresa non fornisce vere e proprie risorse (fatta eccezione per il codice diffuso). Un’analisi attenta dei software sviluppati fornisce alcune indicazioni: i destinatari non sono mai esplicitamente delle imprese (solitamente sono utenti finali e sviluppatori), i linguaggi usati sono spesso della famiglia del C (il java è utilizzato in un solo caso) e le categorie merceologiche sono in generale rivolte soprattutto ad utenti domestici (applicazioni multimediali, videogames, messaggeria istantanea, sicurezza). Quello che ne esce, dunque, è un quadro che si avvicina parzialmente al campione complessivo di progetti studiati, discostandosi invece dalle caratteristiche più frequenti di lavori con imprese coinvolte (maggiori informazioni su questo profilo sono disponibili nel successivo paragrafo). Si può assumere, in questo senso, che la tipologia in esame costituisce un caso ponte tra una realtà Open Source fatta di appassionati (come vuole parte della letteratura) ed un’altra più concentrata intorno alle imprese (un settore dunque composto da professionisti, come ritenuto da altri lavori).

Per le collaborazioni si evidenzia una minor incidenza nell’utilizzo degli strumenti offerti da SourceForge, sintomo di una più diffusa “indipendenza” dei casi in esame. Allo stesso tempo sale anche il profilo dei destinatari: gli utenti domestici lasciano infatti spazio a settori specifici di mercato (37.14 %) e utenti maggiormente esperti (sviluppatori al 67.57 %, amministratori di sistema al 22.86 %). Anche come linguaggio di programmazione le cose cambiano: la famiglia java trova riscontri in 21 occasioni (56.76 %), risultando la più numerosa (l’intera famiglia del C raggiunge il 40 %). Cambia anche il tipo di prodotto sviluppato: si hanno software per la gestione d’impresa (anche settori specifici), per lo sviluppo e per l’ufficio. Quello che si delinea è un profilo

(14)

maggiormente rispondente all’identikit di quei progetti che vedono coinvolte le imprese (si veda il paragrafo 5.3 per ulteriori dettagli): si può assumere che, pur non controllando direttamente i progetti, l’influenza apportata dalle imprese collaboratrici è spesso determinante per tracciare il percorso di sviluppo. Va anche evidenziato come, dei 7 casi complessivi in cui si sono riscontrati differenti tipi di approcci contemporanei nello stesso progetto, tutti ricadono nel binomio

“collabora/gestisce”: un’impresa cioè a gestire il progetto ed un’altra (in 5 casi più di una) a fornire collaborazione di qualche tipo (dallo sviluppo alle fasi di testing, supporto e distribuzione). Si delinea una fitta rete di interconnessioni tra realtà che operano a stretto contatto, traendo giovamento da queste collaborazioni.

L’ultima categoria su cui soffermare l’analisi è quella dei progetti gestiti direttamente dalle imprese:

essendo la più numerosa (60) i dati a disposizione sono più consistenti. Va evidenziato come già preliminarmente sia paventabile una profonda assonanza tra questo raggruppamento e l’intero campione di progetti che vedono coinvolte imprese, sia in quanto sotto-gruppo nettamente più diffuso, sia perché a maggior ragione in questi casi dovrebbero emergere tutte le indicazioni che saranno evidenziate nel successivo paragrafo nel corso del confronto tra progetti con imprese e senza. I riscontri, sulle dimensioni dei progetti e sull’utilizzo degli strumenti offerti da SourceForge, si attestano su statistiche prossime a quelle rilevate per l’intero gruppo di 97 progetti con imprese coinvolte, con variazioni minime. Discorso analogo può essere fatto in generale per le piattaforme di riferimento, le licenze di rilascio e i linguaggi di programmazione (sebbene sia da evidenziare una percentuale ancor più bassa della famiglia del C, intorno al 23 %). Per quanto riguarda i destinatari dei prodotti, l’ambito imprenditoriale giunge ad occupare il 54.24 % dei casi (molto superiore al 39.91 % di tutti i casi di interventi di imprese), sintomo di come, quando più forte si fa sentire la volontà dell’impresa, gli intenti vengono rivolti in questa direzione. Anche i software destinati a sviluppatori aumentano rispetto al caso di collaborazioni (76.27 %), così come quelli per amministratori di sistema (25.42 %). Nulla cambia per quanto riguarda le categorie merceologiche (in generale rivolte ad ambiti imprenditoriali, come i sistemi ERP e CRM, nella quasi totalità concentrati in questo raggruppamento) e i database di riferimento.

Come già evidenziato in precedenza, questo ultimo raggruppamento può essere ulteriormente suddiviso in 3 casi particolari. In generale, tuttavia, non sono state riscontrate rilevanti oscillazioni nei valori medi per le dimensioni aziendali. Una delle poche eccezioni è costituita dal numero di sviluppatori: si passa infatti da una media di 34.71 per i casi di progetti nati all’interno di imprese ad una del 8.43 per le imprese subentrate in seguito (in mezzo si inseriscono i progetti con imprese fondate successivamente ad essi, con una media del 30.29: va però notato che su questa incide pesantemente un progetto con 117 sviluppatori, a causa soprattutto del numero ristretto di casi).

(15)

Un’altra dimensione lungo la quale si evidenziano dei cambiamenti è quella dei linguaggi di programmazione: nei casi di imprese fondatrici di progetti l’utilizzo del java è riscontrato nel 51.43 % dei casi, percentuale che sale al 58.82 % quando le imprese subentrano in corso d’opera. In entrambi i casi, tuttavia, risulta difficile comprendere se vi sia una precisa causa per queste fluttuazioni o se al contrario siano frutto della casualità (essendo insiemi composti da 17 e 36 elementi questa seconda eventualità non è da sottovalutare). Un’analisi a più ampio spettro di questi aspetti peculiari potrebbe permettere di capire se questi comportamenti continuano a sussistere e nell’eventualità formulare delle ipotesi.

5.3 La presenza delle imprese e le modifiche alla struttura dei progetti

In questo paragrafo viene affrontato il confronto tra progetti che hanno imprese coinvolte e quelli in cui invece non si hanno questi interventi.

Per prima cosa sono stati calcolati i valori medi per il numero di amministratori e sviluppatori per il primo gruppo, rispettivamente 3.09 e 19.35. In entrambi i casi si possono rilevare valori maggiori rispetto agli altri, che si attestano rispettivamente su 2.33 e 10.96. Per gli sviluppatori si nota una differenza anche nella moda, con valori di 5 ed 1 rispettivamente tra i due raggruppamenti. Questi dati, per quanto sintetici, forniscono una prima indicazione sulla maggiore attitudine verso progetti più grandi per il sotto-campione con imprese coinvolte. Con queste ultime coinvolte è ipotizzabile che ci siano da un lato maggiori risorse a disposizione e dall’altro un numero minimo di propri dipendenti dedicati al progetto (affermazione che può subire un’oscillazione nella sua validità a seconda del tipo e dell’intensità del rapporto instaurato); a ciò si può aggiungere un maggiore interessamento da parte di taluni utenti esterni all’impresa che vedono, nella collaborazione attiva, una possibilità di mettersi in mostra ed eventualmente ricevere una proposta di lavoro (elemento già evidenziato in letteratura e per il quale si rimanda al capitolo 2). Dettagliando la situazione relativa agli sviluppatori quando le imprese sono coinvolte, si possono notare le differenze con l’altro raggruppamento. La fascia di progetti con al massimo 10 dipendenti si attesta al 51 % (il 71 % nell’altro caso) ed anche considerando i progetti fino a 20 sviluppatori si raggiunge quota 72 % (rispetto all’87 %). Anche la fascia “intermedia” risulta maggiormente rappresentata, con il 21 % dei casi compresi tra 21 e 50 dipendenti (contro l’11 %), mentre sopra questa soglia resta ancora il 7

% (2 % per gli altri).

(16)

Distribuzione sviluppatori con imprese

7% 7%

51%

5%

9%

21%

1-10 11-20 21-30 31-40 41-50 51-140

Distribuzione sviluppatori senza imprese

1% 2%

71%

4% 6%

16%

1-10 11-20 21-30 31-40 41-50 51-140

Si può ulteriormente dettagliare l’andamento nell’ intervallo fino a 20:

0,00 3,00 6,00 9,00 12,00 15,00 18,00

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Distribuzione sviluppatori (1-20)

% con imprese % senza imprese

Passando agli strumenti utilizzati all’interno di SourceForge, un’ipotesi preliminare che potrebbe essere fatta è quella di una minore incidenza in caso di presenza di imprese: si può infatti assumere che in questi casi essi vengano sostituiti da risorse già in dotazione all’impresa. Per quanto riguarda i siti Web, l’ipotesi è confermata pienamente: da una percentuale del 62 % di progetti ospitati su

(17)

spazi offerti da SourceForge quando le imprese non sono presenti si arriva, per questo sotto- campione, al 35 % (34 casi).

Discorso opposto è stato evidenziato per quanto riguarda mailing list e forum: in ciò influisce principalmente il più alto afflusso di sviluppatori e collaboratori saltuari (anche attirati dalle possibilità di impiego) che comportano una più alta attività di scambio informativo.

Per quanto riguarda le liste, il loro valor medio sale da 1.69 (progetti senza imprese) a 2.61, trovando per altro una più alta incidenza (il 74.2 % dei progetti vi fa ricorso, percentuale maggiore rispetto al 63.05 % dell’altro gruppo). Dettagliando la distribuzione dei valori:

0 2 4 6 8 10 12 14 16 18 20 22

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Mailing Lists

% con imprese % senza imprese

Come si può notare, la moda nel primo caso è pari a 2 (spesso con la distinzione tra lista per utenti e lista per sviluppatori), con una percentuale del 18.5 % e del 51.55 % considerando fino a tre occorrenze; nel secondo la moda risulta uguale a 1, con una percentuale del 20.20 %.

Per quanto concerne i messaggi contenuti nei forum, i valori riscontrati sono ancora maggiori nel caso di presenza di imprese: si passa da 2118 a 1317 che diventano rispettivamente 3604 e 1980 se si escludono i casi che non prevedono forum su SourceForge. Questa disparità risiede nel fatto che, accanto ad una maggiore utilizzazione ove essi siano presenti, si ha un minore sfruttamento di questo strumento: si passa infatti dal 66 % senza imprese coinvolte al 59 %. Ad esclusione delle mailing list, dunque, il quadro che si delinea è quello di un effettivo minor utilizzo degli strumenti offerti dal repository nel caso di interventi imprenditoriali; dall’altro lato, nel momento in cui si decide di far ricorso a queste funzionalità, il maggior coinvolgimento di sviluppatori ed utenti comporta un innalzamento delle relative statistiche. Dettagliando i messaggi in forum ad intervalli di 5000 messaggi, per i progetti con imprese si ha una percentuale del 85.96 % con meno di 5000.

Da notare come 4 dei 6 forum con più di 20000 messaggi risiedano in questo gruppo, ivi compreso

(18)

anche il caso più ampio (41512 messaggi al momento della rilevazione). Diminuendo invece la dimensione degli intervalli e concentrandosi esclusivamente sui forum fino a 5000 messaggi, l’intervallo fino a 500 raggiunge quota 43.86 % (sempre concentrandosi sui progetti con imprese) e quello fino a 1000 quota 17.54 %. Soffermandosi su intervalli da 50 messaggi, il confronto tra i due raggruppamenti è visualizzabile come segue.

0 2 4 6 8 10 12 14 16 18 20 22

1-50 51- 100

101- 150

151- 200

201- 250

251- 300

301- 350

351- 400

401- 450

451- 500 Messaggi in forum (1-500)

% con imprese % senza imprese

Proseguendo con le funzionalità e gli aspetti legati al repository, è da rilevare come 16 dei 97 progetti con imprese abbiano ricevuto almeno un premio interno a SourceForge: la loro incidenza è dunque del 16.5 %, superiore a quella dell’altro gruppo (6.9 %).

Non si annotano, al contrario, forti oscillazioni per quanto riguarda la possibilità di donazioni: la percentuale di casi passa dal 39 % con imprese al 40,8 % senza, e la media di donatori da 1.23 a 1.41.

-2 1 4 7 10 13 16 19 22

0 1 2 3 4 5

Donatori

% con imprese % senza imprese

(19)

Come per l’intero campione di software, è possibile calcolare i valori di media e mediana (non la moda: data la dispersività dei valori non riveste particolare interesse) per alcuni strumenti e statistiche offerti dal repository. I risultati sono riportati in tabella:

Media con Media senza

Mediana con

Mediana senza

Report di Bugs aperti 101 41 25 11

Report di Bugs totali 744 358 284 63

Richieste di Supporto aperte 11 9 1 0

Richieste di Supporto totali 175 32 10 2

Patches aperti 17 6 3 0

Patches totali 189 60 27 6

Richieste di Caratteristiche aperte 92 61 48.5 15

Richieste di Caratteristiche totali 222 144 113.5 35.5

Sottoscrizioni nel SVN 605 391 341 198.5

Letture nel SVN 11716 5044 1811.5 520

Download giornalieri 2183 6076 343 220

Click alla pagina principale giornalieri 98796 45715 1409 2158

Pagine visitate giornaliere 11164 17662 3844 1361

Per tutti gli strumenti in esame sono stati riscontrati valori di media e mediana superiori per i progetti con imprese coinvolte. Per le medie delle statistiche, sono stati riscontrati valori superiori per i progetti senza coinvolgimento sia per i download sia per le pagine visitate, al contrario dei riferimenti alla pagina principale; i valori della mediana seguo un andamento opposto.

La successiva dimensione da considerare è quella temporale, andando ad analizzare come siano distribuite cronologicamente le registrazioni dei progetti. Gli andamenti dei due gruppi sono rappresentati come segue:

(20)

0 3 6 9 12 15 18 21

'99 '00 '01 '02 '03 '04 '05 '06

Anno registrazione

% con imprese % senza imprese

Si può evidenziare una maggiore incidenza percentuale per i progetti senza imprese a partire dal 2003, mentre per l’altro gruppo si evidenziano, a partire dal 2000, oscillazioni a carattere annuale (con punte massime tra il 2001 ed il 2003).

L’andamento per quanto riguarda le fasi di sviluppo è invece il seguente:

0 5 10 15 20 25 30 35 40 45 50 55 60

1 2 3 4 5 6

Fase di sviluppo

% con imprese % senza imprese

Si può evidenziare una maggior percentuale di progetti con imprese nelle fasi di sviluppo stabile (5 e 6), mentre andamento opposto può essere rilevato per l’altro gruppo nelle fasi immediatamente precedenti.

Passando agli aspetti legati alle fasi di sviluppo, il primo problema è quello delle piattaforme e delle compatibilità. Per i progetti con imprese la percentuale di quelli compatibili con gli ambienti Windows si attesta sul 53.61 %, contro il 56.65 % dell’altro raggruppamento; le realizzazioni esclusive per questo ambiente sono invece rispettivamente il 9.28 % e il 19.70 %. Emerge dunque una più diffusa presenza di software compatibili con Windows nel caso di progetti senza imprese coinvolte. Per quanto riguarda i sistemi Linux, le compatibilità si attestano sul 50.5 % e 46.8 %

(21)

rispettivamente, mentre prendendo in generale i sistemi Open Source si ottiene 90.7 % e 80.7 %:

una presenza maggiore dunque di piattaforme differenti da quella di Microsoft per i progetti che vedono degli interventi di imprese.

Per quanto riguarda i linguaggi di programmazione, va annotato come, per i progetti che prevedono imprese, il numero complessivo risulti essere di 22 (5 degli originali 27, infatti, non hanno trovato applicazione in questo sotto-campione): lo stesso dato si ottiene anche nel secondo gruppo (dove mancano, in particolare, PL/SQL, XSL, cold fusion, asp.net e asp). Più interessante risulta capire se varino in qualche misura le preferenze nell’utilizzo.

Linguaggi con imprese

19 17 12

46

8

17 10

8 25

24 javaC++

C PHP javascript Python Perl C#

Delphi/Kylix JSP Altro

Linguaggi senza imprese

3 32 11 7 13

15 22

44

23 52

69

java C++

C PHP javascript Python Perl C#

Delphi/Kylix JSP Altro

Dalla distribuzione può essere evidenziata una maggiore importanza del java rispetto alla famiglia del C per i progetti con imprese coinvolte: per il primo si passa dal 47.42 % per questo gruppo al 21.67 % dell’altro, la seconda dal 40.21 % al 65.02 %. Dopo il java, il linguaggio più usato è il C++, col 19.59 %, seguito da PHP e javascript, entrambi al 18.08 %. Per i progetti senza interventi, invece, il primato va al C++ (33.99 %), seguito dal C (25.62 %) e solo successivamente dal java (21.67 %). Davanti a questi risultati, la conclusione che ne emerge è che la famiglia di linguaggi C, data anche la sua ormai lunga storia, comincia a risultare poco appetibile per le imprese, attente a restare al passo coi tempi e ad utilizzare gli strumenti più funzionali (in particolare il java, che ad ogni modo aveva dimostrato la sua maggior diffusione anche nell’intero campione di software).

(22)

La domanda successiva è se qualcosa di interessante può emergere analizzando l’utilizzo dei database (ove sia previsto). Nel caso di presenza di imprese il database più diffuso è MySQL (19 % dei casi) seguito da PostgreSQL (15 %) e JDBC (10 %); per l’alto gruppo il caso più frequente resta MySQL (per quanto più presente, con il 24 %), seguito da JDBC (13 %) e PostgreSQL (10 %). Una rappresentazione grafica della distribuzione è la seguente:

DB con imprese

19 1

4

5 4

8 4

18

9 10

14

MySQL PostgreSQL JDBC Oracle

Microsoft SQL Server HSQL

XML-based SQL-based IBM DB2 Flat-file Altro

DB senza imprese

13

5

2 3

5

5 2

17

3 9

7

MySQL PostgreSQL JDBC Oracle

Microsoft SQL Server HSQL

XML-based SQL-based IBM DB2 Flat-file Altro

Le ultime dimensioni lungo cui svolgere il confronto sono quelle relative al prodotto stesso e alle sue caratteristiche.

Un primo aspetto sono le licenze con cui i software sono rilasciati. La licenza nettamente più diffusa è la GPL, per quanto ci sia una netta differenza tra il 45.36 % dei progetti con imprese e il 73.89 % dell’altro gruppo. Il calo della GPL può essere interpretato come un più difficile adeguamento al modo di diffondere i software perseguito dalle imprese, come per altro già era stato accennato nel capitolo 2, dove erano emerse alcune critiche a questa licenza, ritenuta troppo stringente e più adatta ad utenti piuttosto che ad imprese. La LGPL, derivata dalla stessa GPL, è in entrambi i casi la seconda più diffusa, seguita dalla BSD. Notevole anche la differenza per la categoria delle altre licenze a carattere proprietario: si tratta generalmente di soluzioni specifiche

(23)

sviluppate da imprese e dunque non classificabili nelle categorie più standardizzate.

Schematizzando graficamente quanto scritto in precedenza:

Licenze con imprese 12

7 7

44

11

12 14

GPL

LGPL

BSD

mozilla public license 1.1

apache license 2.0

altra licenza proprietaria

altro

Licenze senza imprese 6 14

6 2

150 7

14

29

GPL

LGPL

BSD

mozilla public license 1.1

apache license 2.0

altra licenza proprietaria

common public license

altro

Altro aspetto di interesse è l’utenza verso cui il progetto si rivolge. Nel caso di assenza di intervento imprenditoriale il destinatario preferenziale sono gli end user, presenti nel 66.50 % dei casi, seguiti dagli sviluppatori al 47.29 %. Nell’altro gruppo la situazione è invertita: più frequenti infatti i software destinati a questi ultimi (73.20 %) rispetto agli utenti finali (47.42 %). Si delinea, per i progetti con imprese, una maggiore sensibilità per figure professionali, come confermato dalle statistiche sull’IT (24.74 % in questo caso, 8.37 % nell’altro) e sul settore finanziario (14.43 % e 2.96 %). Sembra riscontrarsi dunque una maggiore propensione dell’industria software a sviluppare applicativi utili a se stessa o ad altri settori (sempre restando in ambito aziendale), mentre in caso di assenza di impresa ci si rivolge più diffusamente all’ambito casalingo: oltre agli utenti semplici, anche quelli esperti sono in maggioranza rispetto all’altro gruppo. Qualche differenza anche per un’altra categoria molto diffusa, quella degli amministratori di sistema: si passa dal 24.74 % con imprese coinvolte al 18.72 %. Quel che segue è una rappresentazione grafica dei due differenti andamenti.

Riferimenti

Documenti correlati

– Write-non-allocate: la linea non viene portata in cache (viene solo aggiornata la memoria centrale). Ha senso in considerazione del

Lo mondo è ben così tutto diserto d'ogne virtute, come tu mi sone, e di malizia gravido e coverto;.. ma priego che m'addite la cagione, sì ch'i' la veggia e ch'i' la

Come detto questo è un prototipo e quindi può essere ovviamente migliorato: ad esempio con un database diverso da uno relazionale o con attributi multivalore

Il metodo validate(), restituisce un oggetto di tipo ActionError che potrà essere cattu- rato dalla pagina chiamante tramite un apposito tag delle librerie Struts, che si incari-..

Danno subito dal DNA in cellule di apici radicali di Vicia faba fatti crescere in vasi di vetro su sei diversi substrati (A: sabbia di quarzo; B: terriccio universale commerciale;

Se il nodo rimosso è il System Master, viene inviato un interrupt ad ogni Peripheral attivo che, di conseguenza, rende invalido qualsiasi tentativo di utilizzo della memoria

In pratica la fase termicamente reversibile agisce da reticolante fisico (physical crosslink) , ma questo effetto è inversamente proporzionale alla temperatura, infatti

• Un programma Java puo accedere a files conte- nenti suoni, immagini, testi ed altri programmi Java ovunque situati sulla rete WEB, mediante dei riferimenti basati su indirizzi