Il seguente documento Ŕ la traduzione in italiano di un memorandum interno Microsoft e riguarda strategie e tattiche commerciali nei confronti del procedimento open source. Ci sono tre documenti, denominati Halloween I, Halloween II e Halloween III che riguardano rispettivamente Microsoft contro open source, Microsoft contro Linux e la risposta ufficiale data da Microsoft dopo che Halloween I fu pubblicato in rete. Le traduzioni in italiano sono ospitate da SET, Syntax Error Technology. Indice e links ai documenti originali e alle relative traduzioni si trovano alla pagina msdn&news. Se cercate ulteriori informazioni sul procedimento open source, sulla reazione della stampa ai documenti Halloween, ecc., il posto migliore Ŕ il sito Open Source (in inglese). I documenti sono stati tradotti da LuLaVio: contattatelo per commenti o per segnalare eventuali errori.

The following document is the Italian translation of an internal Micrososoft memorandum and is about MS business strategies and tactics against the open source process. There are three paper, named Halloween I, Halloween II and Halloween III concerning respectively MS agaist Open Source, MS against Linux, and MS official response after Halloween I was pubblished on the web. Italian translations are hosted by SET, Syntax Error Technology. You can find an index and links to the original documents and their Italian translations at the msdn&news page. If you are looking for further information about open-source process, press coverage about the Halloween documents, etc., the best place is the Open Source site (in English). The documents have been translated in Italian by LuLaVio: please, contact him for comments and/or mistakes.



{ Halloween I -- 1.9}

Software a sorgente aperta

Una (nuova?) metodologia di sviluppo

{ Il corpo dell'Halloween Document Ŕ un memorandum interno di strategia sulle possibili risposte della Microsoft al fenomeno Linux/Open-Source.

(Questa versione corretta Ŕ stata rinominata ``Halloween I''; c'Ŕ un seguito, ``Halloween II'', con un secondo memorandum rivolto specificatamente a Linux.)

La Microsoft ha pubblicamente riconosciuto che questo memorandum Ŕ autentico, liquidandolo per˛ come un semplice studio ingenieristico che non delinea la politica Microsoft.

Comunque, la lista dei collaboratori menzionati alla fine include alcune persone che sono conosciute per il loro ruolo chiave nella Microsoft, e il documento mostra che lo sforzo di ricerca ha avuto la cooperazione dei quadri direttivi; Ŕ anche possibile che sia stato commissionato come libro bianco con linee di condotta da sottoporre all'attenzione di Bill Gates (l'autore sembra si aspettasse che Gates l'avrebbe letto).

In qualsiasi caso, ci fornisce, oltre ad un moto di rigetto gestionale di Microsoft riguardo open-source, una visione molto preziosa su ci˛ che la compagnia in realtÓ pensa -- che, come vedrete, Ŕ una bizzarra combinazione di astuzia e di miopia istituzionale.

Vi sono state delle speculazioni sul fatto che questa sia stata una fuga intenzionale di notizie, ma ci˛ sembra alquanto improbabile. Il documento Ŕ troppo incriminante; parti di esso possono essere considerate delle prove di pratiche anti-competitive per il processo DOJ. Inoltre, l'autore ``ha rifiutato di confermare o negare'' quando Ŕ stato inizialmente contattato, e ci˛ fa capire che Microsoft non aveva previsto una risposta.

PoichŔ l'autore cita delle mie analisi sulle dinamiche della comunitÓ open-source (The Cathedral and the Bazaar e Homesteading the Noosphere) in modo estensivo, mi sembra giusto rispondere a nome della comunitÓ. :-)

Citazioni chiave:

Qui ci sono alcune citazioni di rilievo prese dal documento, con collegamenti ai punti in cui sono posizionate. Pu˛ essere d'aiuto sapere che "OSS" Ŕ l'abbreviazione usata dall'autore per "Open Source Software". FUD, una tattica caratteristica della Microsoft, Ŕ spiegata qui.

* OSS nel breve periodo si pone come una minaccia diretta alle entrate e alla piattaforma Microsoft, in particolar modo nello spazio server. Inoltre, il parallelismo intrinseco e il libero scambio di idee nell'OSS ha dei benefici che non sono replicabili dal nostro attuale modello di produzione e presenta perci˛ a lungo termine una minaccia per lo scambio di idee tra sviluppatori.
* Studi recenti (Internet) hanno provato... che la qualitÓ commerciale pu˛ essere conseguita/ superata dai progetti OSS.
* ...per capire come competere con OSS, dobbiamo avere come bersaglio un procedimento pi¨ che una compagnia.
* OSS Ŕ credibile a lungo termine ... le tattiche FUD non possono essere adoperate per combatterlo.
* Linux e altri difensori dell'OSS stanno portando ragioni via via sempre pi¨ credibili sul fatto che il software OSS Ŕ solido almeno quanto -- se non pi¨ -- le sue alternative commerciali. Internet fornisce una vetrina ideale e ad alta visibilitÓ per il mondo OSS.
* Linux Ŕ stato dispiegato in mission critical, in ambienti commerciali alla presenza di testimoni pubblici. ... Linux supera molti altri UNIXes ... Linux Ŕ sulla strada buona per possedere alla fine il mercato del x86 UNIX ...
* Linux pu˛ vincere finchŔ servizi / protocolli saranno merce soggetta alla vendita.
* I progetti OSS sono stati in grado di conquistare un punto d'appoggio in molte applicazioni server a causa del grande vantaggio dato da protocolli semplici e altamente personalizzabili. Estendendo questi protocolli e sviluppandone di nuovi, possiamo respingere l'entrata nel mercato dei proggetti OSS.
* La capacita del procedimento OSS di radunare e sfruttare l'IQ (coefficiente intellettuale N.d.T.) collettivo di migliaia di individui attraverso Internet Ŕ semplicemente stupefacente. E, cosa pi¨ rilevante, l'evangelizzazione di OSS aumenta proporzionalmente con le dimensioni di Internet in modo molto pi¨ veloce di quanto facciano i nostri sforzi di evangelizzazione.
Come leggere questo documento:

I commenti in verde, contenuti in parentesi graffe, sono miei (Eric S. Raymond). Ho evidenziato, mettendoli in rosso, quelli che penso siano i punti chiave del testo originale. Ho inserito dei commenti vicino a questi punti chiave; potete scorrere il documento usando questo indice di commenti in sequenza.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

Ho incluso in verde alcune altre osservazioni che non sono associate a punti chiave e non sono nell'indice. Queste osservazioni addizzionali possono interessare solo se si legge il documento per intero.

A parte ci˛ ho lasciato il documento completamente come Ŕ (neanche corretto la battitura), cosý potete leggere ci˛ che Bill Gates sta leggendo riguardo la Sorgente Aperta. E' un po' lungo, ma perseverate. Per avere un quadro preciso del pensiero dell'opposizione vale la pena di fare qualche sforzo -- e ci sono una o due questioni veramente sorprendenti sepolte nel linguaggio corporativo.

Valutazione del pericolo:

Credo che comunque la tattica pi¨ pericolosa sostenuta in questo memorandum sia quella contenuta nella frase sinistra ``de-standardizzazione dei protocolli''.

Spero che la pubblicazione di questo documento, se non altro, metta tutti in guardia sul soffocamento della competizione, sull'erosione della possibilitÓ di scelta, sui costi pi¨ alti, e sul monopolio blindato che questa tattica implica.

Il parallelo col tentativo di Microsoft dirottare Java, e i suoi tentativi di guastare il potenziale "scrivi una volta e vai dappertutto" di questa tecnologia dovrebbe essere ovvio.

Ho incluso una ampia discussione di questo punto nei miei commenti in interlinea. Per evitare che questa strategia abbia successo, credo che i sostenitori di open-source debbano iniziare mettendo in evidenza questi punti:

  1. Ai compratori piace avere un mercato di prodotti. Ai venditori no.

  2. Servizi e protocolli standardizzati sono una buona cosa per i clienti; sono meno costosi, promuovono la competizione e generano buone scelte.

  3. "De-commoditizing" protocols significa riduzione di scelta, innalzamento dei prezzi, e soppressione della competizione.

  4. Quindi, se la Microsoft vince, il cliente ci perde.

  5. Open-source spinge -- in realtÓ si basa sui -- servizi e protocolli standardizzati. Quindi Ŕ in armonia con gli interessi del cliente.

Cronologia:

La prima (1.1) bozza del memorandum VinodV Ŕ stata preparata a cavallo del weekend del 31 ottobre-1 novembre 1998. In onore della data, e con la profonda speranza che la sua pubblicazione possa far fare alla Microsoft il peggiore degli incubi, ho dato a questo documento il nome di "Halloween Document"'.

La versione 1.2 Ŕ stata ripulita dai caratteri non-ASCII da David Levine <davidl@co.intel.com>.

La versione 1.3 rileva il riconoscimento di autenticitÓ da parte della Microsoft.

La versione 1.4 include un po' pi¨ di analisi e la sezione sulla valutazione del pericolo.

La versione 1.5 ha qualche bit aggiuntivo nel preambolo.

La versione 1.6 ha qualcosa in pi¨ in uno dei commenti.

Nella versione 1.7 viene aggiunto il riferimento ai Fuzz papers.

Nella versione 1.8 viene aggiunto un link al documento Halloween II.

Nella versione 1.9 si aggiunge una nota riguardo HTTP-DAV support.

}

 

 

Vinod Valloppillil (VinodV)

Aug 11, 1998 -- v1.00

Microsoft Confidential

Elenco dei contenuti

Elenco dei contenuti *

Sommario esecutivo *

Software a sorgente aperta *

Che cos'Ŕ? *

Tassonomia delle licenze software *

Il software a sorgente aperta Ŕ importante per Microsoft *

Cronologia *

Procedimento open-source *

Team di sviluppo open-source *

Coordinazione dello sviluppo di OSS *

Sviluppo parallelo *

Correzione parallela *

Soluzione del conflitto *

Motivazioni *

Biforcazione del codice *

Punti di forza di open-source *

Attributi esponenziali di OSS *

CredibilitÓ nel lungo periodo *

Correzione parallela *

Sviluppo parallelo *

OSS = perfetta evangelizzazione / documentazione API *

Tasso di uscita *

Punti deboli di open-source *

Costi di gestione *

Questioni sul procedimento *

CredibilitÓ organizzativa *

Modelli di commercio open-source *

Servizi secondari *

Articoli civetta -- accesso al mercato *

Commoditizing Downstream Suppliers *

Primo fautore -- costruisci ora, $$ dopo *

Linux *

Che cos'Ŕ? *

Linux Ŕ un autentico, credibile OS + procedimento di sviluppo *

Linux Ŕ una minaccia a breve/medio termine nel campo dei server *

Linux Ŕ improbabile che sia una minaccia nel campo dei desktop *

Colpire Linux *

Netscape *

Organizzazione & licenza *

Punti di forza *

Punti deboli *

Previsioni *

Apache *

Cronologia *

Organizzazione *

Punti di forza *

Punti deboli *

IBM & Apache *

Altri progetti OSS *

Risposta di Microsoft *

VulnerabilitÓ del prodotto *

Acquisire i vantaggi di OSS -- interscambio di idee tra sviluppatori *

Acquisire i vantaggi di OSS OSS -- Processi interni di Microsoft *

Estendere i vantaggi di OSS -- infrastruttura dei servizi *

Attutire gli attacchi di OSS *

Altri links interessanti *

Ringraziamenti *

Cronologia della revisione *

 

Software a sorgente aperta

Una (nuova?) metodologia di sviluppo

Sommario esecutivo

Open-source Software (OSS) Ŕ un procedimento di sviluppo che promuove la creazione e il dispiegamento rapido di caratteristiche aggiuntive e correzzioni di bug in un codice esistente / conoscenza base. Negli ultimi anni, parallelamente alla crescita di Internet, i progetti OSS hanno acquisito la profonditÓ & complessitÓ tradizionalmente associata a progetti commerciali come gli Operating Systems e i server mission critical.

Di conseguenza, OSS si pone come una minaccia diretta a breve termine a reddito e piattaforma di Microsoft -- particolarmente nel campo dei server. Inoltre, l'intrinseco parallelismo e il libero scambio di idee di OSS ha dei vantaggi che non sono replicabili con il nostro attuale modello di licenza e quindi a lungo termine si configura come un pericolo per lo scambio di idee fra sviluppatori.

{ OK, da qui si capisce che Microsoft non dorme durante il cambio. }

Comunque, altri punti deboli di OSS danno modo a Microsoft di trarre profitto in aree chiave come miglioramenti dell'architettura (ad es. storage+), integrazione (ad es. schemas), facilitÓ-d'uso, e supporto organizzativo.

{ Questa concisa raccomandazione Ŕ interessante principalmente per il fatto che non menziona gli specifici consigli che si trovano pi¨ avanti nel documento riguardo la de-standardizzazione dei protocolli ecc. }

Software Open-source

Che cos'Ŕ?

Open-source Software (OSS) Ŕ un software in cui sia la sorgente che i binaries sono distribuiti o accessibili per un dato prodotto, solitamente free. Oss Ŕ spesso confuso come "shareware" o "freeware" ma ci sono grosse differenze tra questi modelli di licenza e il procedimento di ciascun prodotto.

Tassonomia delle licenze software

Tipo di software

             

Commerciale

             

Software in prova

X

(incompleto nelle sue caratteristiche)

X

Uso non commerciale

X

(dipendente dall'utilizzo)

X

         

Shareware

X-(licenza non imposta)

X

         

Binary liberi da diritti ("Freeware")

X

X

X

       

Biblioteche libere da diritti

X

X

X

X

     

Open-source (BSD-Style)

X

X

X

X

X

   

Open-source (Apache Style)

X

X

X

X

X

X

 

Open-source (Linux/GNU style)

X

X

X

X

X

X

X

Caratteristiche della licenza

Accesso a costo zero

Redistribuibile

Utilizzo illimitato

Codice sorgente disponibile

Codice sorgente modificabile

"Check-ins" pubblici al nucleo del codice base

Tutti i derivati devono essere free

 

L'ampia categoria di licenze include:

Il software commerciale Ŕ il pane quotidiano di Microsoft. Deve essere acquistato, non pu˛ essere redistribuito, e solitamente Ŕ disponibile solo come binaries all'utente finale.

I software ridotti in prova sono di solito versioni con funzioni limitate di software commerciali, sono distribuite gratuitamente con l'intento di portare all'acquisto del codice in commercio. Gli esempi includono prodotti con 60 giorni di tempo per la valutazione.

I prodotti Shareware hanno una funzionalitÓ completa e sono distribuiti liberamente ma hanno una licenza con mandato di acquisto finale sia da parte di singoli che di societÓ. Molte utilities di Internet (come "WinZip") si avvantaggiano dello shareware come metodo di distribuzione.

Il software ad uso non commerciale Ŕ disponibile e ridistribuibile liberamente da organismi non-profit. SocietÓ, etc. devono comperare il prodotto. Un esempio potrebbe essere Netscape Navigator.

I binaries senza diritti consistono in software che possono essere usati e distribuiti liberamente solo in forma binaria. I binaries di Internet Explorer e NetMeeting corrispondono a questo modello.

Le biblioteche senza diritti sono prodotti software i cui codici sia sorgente che binario possono essere usati e distribuiti liberamente ma NON possono essere modificati dall'acquirente finale senza violare la licenza. Esempi di questo tipo includono biblioteche class, header files, ecc.

Un piccolo e circoscritto gruppo di sviluppatori sviluppa prodotti a sorgente aperta BSD-style & e consente libero uso e distribuzione di binaries e codice. Mentre agli utenti Ŕ consentita la modifica del codice, il team di sviluppo generalmente NON accetta apporti dall'esterno.

Apache prende il modello di sorgente aperta BSD-style e lo estende permettendo apporti al nucleo del codice base da parte di esterni.

Il software CopyLeft o GPL (General Public License) fa fare alla licenza open-source un pericoloso passo in avanti. Mentre il software BSD e Apache style permette agli utenti di "biforcare" il codice base e apllicare le proprie clausole di licenza al loro codice modificato (per esempio facendolo diventare commerciale), la licenza GPL richiede che tutti i lavori derivati debbano essere in codice GPL. "Tu sei libero di piratare (hack N.d.T.) questo codice a patto che i tuoi derivati siano anch'essi piratabili (hackable N.d.T.)"

{ E' interessante notare la differenza fra il modo in cui sono inquadrate le ultime tre distinzioni e come vengano invece generalmente intese dalla comunitÓ open-source.

Per noi, sono fondamentali i diritti che la licenza open-source garantisce agli utenti e ai terzi, e una specifica pratica di sviluppo varia ad-hoc ed in modo non abbinato in particolar modo alle nostre variazioni di licenza. In questa tassonomia Microsoft, d'altra parte, la distinzione principale si basa su chi ha accesso ad un nucleo privilegiato del codice base.

Ci˛ riflette una visione della realtÓ molto pi¨ centralizzata, e riflette una mancanza di immaginazione o di comprensione da parte dell'autore del memorandum. Non riesce a cogliere completamente la nostra tradizione di sviluppo distribuito. La qual cosa non stupisce per niente... }

Il software open-source Ŕ importante per Microsoft

Questo documento si ocupa del software open-source (OSS). OSS Ŕ profondamente diverso dalle altre forme di licenze (in particolare "shareware") rispetto a due punti molto importanti:

    1. Esiste sempre una via d'acquisto del nucleo del codice base completamente libera da diritti di brevetto
    2. Diversamente dai binaries distribuiti free, open-source incoraggia un procedimento attorno al nucleo del codice base e incoraggia estensioni del codice base da parte di altri sviluppatori.

OSS Ŕ un problema per Microsoft per diverse ragioni:

    1. I progetti OSS hanno acquisito "qualitÓ commerciale"
    2. Una barriera chiave che impediva l'ingresso di OSS in molti strati di clientela Ŕ stata la sensazione di mancanza di qualitÓ. I sostenitori di OSS replicano che il maggior controllo & correzione del software OSS porta ad un codice con uno standard di qualitÓ pi¨ alto del software commerciale.

      Studi su un caso recente (Internet) hanno mostrato agli occhi dei clienti la prova molto evidente che la qualitÓ commerciale pu˛ essere raggiunta / superata dai progetti OSS. In questo momento, comunque, non c'Ŕ una prova forte della qualitÓ di OSS al di lÓ dell'aneddottica.

      { Queste frasi, nel loro insieme, sono alquanto contraddittorie, salvo che ``gli studi su un caso recente'' siano tutti ``aneddottica''. Ma se Ŕ cosý, perchŔ chiamarla ``prova molto evidente''?

      Sembra ci sia un po' di marcia indietro autoprotettiva nella seconda frase. Tuttavia, la prima frase Ŕ una concessione enorme da parte di Microsoft (anche se per uso interno).

      In qualsiasi caso, Ŕ falso affermare che si tratti di `aneddottica'. Vedi Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services .

      Qui ci sono alcune righe sul tema tratte da questo documento:

      "Il tasso di insuccesso delle utilities nella versione commerciale di UNIX che abbiamo testato... variava dal 15-43%." "Il tasso di insuccesso delle utilities della versione Linux di UNIX distribuita free si attestava penultimo, al 9%." "Il tasso di insuccesso delle utilities di GNU pubblico si attestava all'ultimo posto in assoluto nei nostri studi, a solo il 7%.
      }

    3. I progetti OSS sono diventati processi complessi & su larga scala
    4. Un altro impedimento all'ingresso che Ŕ stato affrontato da OSS Ŕ la complessitÓ del progetto. I team di OSS si stanno impegnando in progetti di una dimensione & complessitÓ tale da essere prima d'ora di esclusivo dominio dei team di sviluppatori commerciali, economicamente organizzati/motivati. Esempi includono il Linux Operating System e Xfree86 GUI.

      La vitalitÓ del procedimento OSS Ŕ direttamente legata ad Internet per la distribuzione di risorse di sviluppo in scala mastodontica. Esempi della dimensione di alcuni progetti OSS:

    Progetto

    Linee di codice

    Linux Kernel (x86 only)

    500,000

    Apache Web Server

    80,000

    SendMail

    57,000

    Xfree86 X-windows server

    1.5 Million

    "K" desktop environment

    90,000

    Full Linux distribution

    ~10 Million

  1. OSS ha un unico procedimento di sviluppo con punti di forza e punti deboli comuni.

Il procedimento OSS Ŕ singolare per le motivazioni che spingono chi vi partecipa e per le risorse che vengono apportate nel mettere a nudo i problemi. OSS, quindi, ha alcuni pregi interessanti che dovrebbero essere compresi in profonditÓ.

Cronologia

Il software open-source ha le sue radici nella comunitÓ scientifica e hobbystica ed Ŕ stato tipicizzato attraverso uno scambio ad hoc del codice sorgente dagli sviluppatori/utenti.

Internet Software

Il pi¨ grande caso studiato di OSS Ŕ Internet. La maggio parte del primo codice su Internet era, ed Ŕ ancora, basata su OSS, come descritto in una intervista a Tim O'Reilly (http://www.techweb.com/internet/profile/toreilly/interview ):

TIM O'REILLY: Lo slogan principale con cui iniziammo era,"open-source software funziona." ... BIND ha una quota di mercato assolutamente dominante come singolo pezzo di software pi¨ mission-critical su Internet. Apache Ŕ il Web server dominante. SendMail fa girare probabilmente l'ottanta per cento dei mail servers e probabilmente tocca ogni singola parte di e-mail su Internet

Fondazione Free Software / Progetto GNU

Il merito per aver realizzato il primo esempio di un moderno e organizzato OSS Ŕ generalmente attribuito a Richard Stallman del MIT. Alla fine del 1983, Stallman cre˛ la Free Software Foundation (FSF) -- http://www.gnu.ai.mit.edu/fsf/fsf.html -- con l'obbiettivo di creare una versione free del sistema operativo UNIX. La FSF fece uscire una serie di codici e binaries sotto l'acronimo GNU (che sta per "Gnu's Not Unix").

Le iniziative originarie FSF / GNU non conseguirono l'obbiettivo originario di creare un completo OSS Unix. Tuttavia, contribuirono a molte applicazioni e strumenti di programmazione conosciuti e usati oggigiorno che includono:

Licenza CopyLeft

Il software FSF/GNU ha introdotto lo schema di licenza "copyleft" che non solo rende illegale il nascondere il codice sorgente dal software GNU ma rende anche illegale il nascondere la sorgente dal lavoro derivato dal software GNU. Il documento che descrive questa licenza Ŕ conosciuto come General Public License (GPL).

Il magazine Wired ha il seguente riassunto di questo schema & del suo scopo (http://www.wired.com/wired/5.08/linux.html):

La General Public License, o GPL, permette agli utenti di vendere, copiare, e cambiare programmi che sono sotto copylef - che possono anche essere messi sotto copyright - ma ci deve essere la stessa libertÓ di vendere o copiare le modifiche e cambiarle ulteriormente. Si deve inoltre rendere il codice sorgente delle modifiche liberamente disponibile.

La seconda clausola -- codice open-source di lavori derivati -- Ŕ stato l'aspetto della licenza Copyleft pi¨ controverso (e, potenzialmente quello con pi¨ successo).

Procedimento open-source

L'organizzazione dei procedimenti di sviluppo dei sofware commerciali ruota attorno ad obbiettivi economici. Comunque, poichŔ i soldi spesso non sono la motivazione (primaria) dietro il software open-source, capire la natura della minaccia posta in essere richiede una profonda conoscenza del procedimento e degli stimoli dei team di sviluppo open-source.

In altre parole, per capire come competere con OSS, dobbiamo avere come bersaglio un procedimento pi¨ che una societÓ.

{ Questa Ŕ una precisazione molto importante, che vorrei fosse sfuggita a Microsoft. La vera battaglia non Ŕ NT contro Linux, o Microsoft contro Red Hat/Caldera/S.u.S.E. -- Ŕ sviluppo a sorgente chiusa contro sviluppo a sorgente aperta. La cattedrale contro il bazaar.

Ci˛ si applica anche al contrario, ed Ŕ per questo che il punto non Ŕ colpire Microsoft qua Microsoft -- Microsoft Ŕ il sintomo, non la malattia. Vorrei che molti pi¨ hackers di Linux lo capissero.

A livello pratico, significa che dobbiamo aspettarci che la macchina propagandistica di Microsoft si indirizzi contro il procedimento e la cultura open-source, pi¨ che contro competitori specifici. }

Gruppi di sviluppo open-source

Alcune delle caratteristiche chiave dei gruppi OSS spinti da Internet:

Coordinazione dello sviluppo di OSS

Comunicazione -- in scala Internet

Il coordinamento di un team OSS dipende molto dalle forme di collaborazione proprie di Internet. I metodi tipici sfruttano l'intera gamma delle tecnologie di collaborazione in Internet:

I progetti OSS della dimensione di Linux e Apache sono fattibili solo se, per affrontare un problema, viene messo assieme un gruppo sufficientemente grande di sviluppatori altamente esperti. Di conseguenza, c'Ŕ una correlazione diretta tra la dimensione del progetto che OSS pu˛ affrontare e la crescita di Internet.

Direzione comune

Oltre al mezzo di comunicazione, un'altra serie di fattori coordinano implicitamente la direzione del gruppo.

Obbiettivi comuni

Gli obbiettivi comuni sono equivalenti ad asserzioni evocative che pervadono il processo decisionale comune per l'intero gruppo di sviluppo. Un' unica, chiara direttiva (ad es. "ricreare UNIX") ha per il gruppo un potere comunicativo e di coinvolgimento maggiore di direttive multiple ed inafferrabili (ad es. "fare un buon sistema operativo").

Precedenti comuni

I precedenti sono potenzialmente il fattore pi¨ importante per spiegare la rapida e coesa crescita di enormi progetti OSS come il Linux Operating System. PoichŔ gli appartenenti all'intera comunitÓ Linux condividono anni di esperienza nel trattare con molte altre forme di UNIX, essi sono facilmente in grado di distinguere -- in modo non-confrontativo -- cosa ha funzionato e cosa no.

Non c'erano discussioni riguardo la sintassi dei comandi da usare negli editor di testo -- tutti usavano giÓ "vi" e gli sviluppatori semplicemente si spartivano pezzi di command namespace da sviluppare.

Avere una capacitÓ di comprensione 20:20 data dall'esperienza storica, fornisce una struttura forte ed implicita. In organizzazioni pi¨ lungimiranti, questa struttura Ŕ data da un leader forte ed utopista.

{ Ad una prima occhiata, si pu˛ leggere semplicemente come un (Bill naso marrone) commento fatto da qualcuno che si aspetta che Gates legga il memorandum -- si pu˛ quasi vedere l'autore genuflettersi davanti ad un'icona dell'Intrepido Capo.

Pi¨ generalmente, ci˛ fa pensare ad una seria e potenzialmente spiegabile sottovalutazione della capacitÓ da parte della comunitÓ di esprimere i propri leaders utopisti. Non abbiamo ottenuto Emacs o Perl o il World Wide Web partendo dalla ``comprensione 20:20'' -- nŔ Ŕ corretto vedere il seppur relativamente conservativo design del kernel di Linux come un modo di guardare indietro nel ricreare modelli passati.

Di conseguenza, ci˛ suggerisce che la risposta Microsoft all'open-source possa poggiarsi sul piede sbagliato nell'enfatizzare l'innovazione sia per come agiamo che nel modo in cui spieghiamo ci˛ che facciamo al resto del mondo. }

Bagaglio di conoscenze comuni

NatBro mette in evidenza che il bisogno di una serie di conoscenze comuni ed accettate Ŕ un pre-requisito per lo sviluppo di OSS. Questo punto Ŕ legato strettamente al fenomeno dei precedenti in comune. Dalla sua email:

Un attributo chiave Ŕ il bagaglio comune di conoscenze su UNIX/gnu che OSS trasmette e rinforza. Io penso che l'intero procedimento non funzionerebbe se la barriera d'accesso fosse molto pi¨ alta di quella che Ŕ...un programmatore UNIX con modesta esperienza pu˛ accrescere le sue conoscenze facendo grandi cose con Linux e con molti altri prodotti OSS. Per dirla in un altro modo -- per uno sviluppatore in ambiente OSS non Ŕ troppo difficile cavarsi uno sfizio, perchŔ le cose sono costruite in modo molto simile l'una all'altra, corrette nello stesso modo, ecc.

Mentre le esperienze precedenti stabiliscono l'identitÓ dell'obbiettivo finale, l'avere un bagaglio comune di conoscenze spiega il numero di persone necessarie affinchŔ il procedimento arrivi a conclusione.

La cattedrale e il bazaar

Un documento molto influente di un sostenitore di open-source -- Eric Raymond -- venne pubblicato per la prima volta nel maggio 1997 (http://www.redhat.com/redhat/cathedral-bazaar/). Lo scritto di Raymond Ŕ stato espressamente citato dal (futuro) CTO di Netscape Eric Hahn come spiegazione per la loro decisione di distribuire il codice sorgente del browser.

Raymond sezion˛ il suo progetto OSS allo scopo di ottenerne delle regole pratiche che potessero essere sfruttate in futuro per altri progetti OSS. Alcune delle regole di Raymond includono:

Ogni buon lavoro inizia dalla soddisfazione di uno sfizio personale dello sviluppatore

Questo riassume uno degli stimoli base degli sviluppatori nel procedimento OSS -- risolvere un problema corrente a cui si Ŕ trovato di fronte un singolo sviluppatore -- ci˛ ha permesso a OSS di elaborare progetti complessi senza avere un costante feedback dalla struttura di marketing / sostegno.

I bravi programmatori sanno cosa scrivere. Quelli molto bravi sanno cosa riscrivere (e riusare).

Raymond sostiene che gli sviluppatori sono pi¨ portati al riuso del codice in un procedimento rigorosamente a sorgente aperta piuttosto che in un ambiente di sviluppo pi¨ tradizionale perchŔ Ŕ sempre garantito loro l'accesso all'intera sorgente per tutto il tempo.

Una sorgente aperta ampiamente disponibile riduce i costi di ricerca per trovare un particolare pezzetto di codice.

``Metti in conto che scarterai molte case; in qualsiasi caso lo farai.''

Citazione da Fred Brooks, ``The Mythical Man-Month'', capitolo 11. PoichŔ i team di sviluppo di OSS sono estremamente sparsi, molti dei maggiori sottocomponenti in Linux avevano numerosi prototipi iniziali cui seguiva la selezione e la rifinitura di un singolo disegno da parte di Linus.

Trattare i propri utenti come co-sviluppatori Ŕ la via meno difficile per avere un rapido miglioramento di codice ed una correzione efficiente.

Raymond si fa promotore di un supporto importante e di una notevole documentazione per gli sviluppatori dei progetti OSS allo scopo di massimizzarne il profitto.

Il materiale riguardanete il codice Ŕ citato come un'area che viene trascurata dagli sviluppatori commerciali e che potrebbe costituire un errore fatale per OSS.

Fare uscire presto. Fare uscire spesso. E ascoltare i propri clienti.

Questa Ŕ una regola classica del manuale Microsoft. I sostenitori OSS noteranno comunque che il loro ciclo release-feedback Ŕ potenzialmente molto pi¨ veloce di quello dei software commerciali.

{ Questa Ŕ una affermazione interessante ed arrogante, come se pensassero che io sia stato in qualche modo ispirato dalla distribuzione Microsoft di soli binary.

Ma ci˛ fa pensare anche a qualcos'altro -- che anche se l'autore comprende intellettualmente l'importanza della distribuzione del codice sorgente, non riesce ad afferrare a pieno la potenza vera della diffusione del codice sorgente. Forse vivere con le convinzioni Microsoft rende ci˛ impossibile. }

Data una base grande abbastanza di beta-tester e co-sviluppatori, quasi ogni problema viene definito velocemente e la sua sistemazione risulta ovvia per qualcuno.

Questo Ŕ probabilmente il cuore dell'intuizione di Raymond nel procedimento OSS. Ha parafrasato questa regola come "la correzione dei bug Ŕ parallelizzabile". Segue un'analisi pi¨ approfondita.

{ Beh, aveva comunque quel diritto. }

Sviluppo parallelo

Una volta che una struttura componente Ŕ stata costituita (ad es. chiave di API & strutture definite), progetti OSS come Linux utilizzano molteplici piccoli gruppi di individui che risolvono indipendentemente problemi particolari.

PoichŔ gli sviluppatori lo fanno generalmente per hobby, avere capacitÓ di `investire' in molteplici e competenti sforzi non costituisce un problema, e i progetti OSS si avvantaggiano della capacitÓ di cogliere i perfezionamenti potenzialmente migliori tra i molti prodotti.

Da notare che ci˛ dipende molto da:

Correzione parallela dei bug

Il cuore della questione sostenuta da Eric Raymond Ŕ che a differenza di altri aspetti dello sviluppo di software, la correzione dei bug del codice Ŕ un'attivitÓ la cui efficienza migliora in modo quasi lineare con il numero degli individui impegnati nel progetto. I costi di gestione o coordinazione per la correzione di un pezzo di codice a sorgente aperta sono pochi o nulli -- questa Ŕ la `rottura' chiave nelle regole di Brooks' per OSS.

Raymond include la descrizione di Linus Torvald del procedimento di correzione Linux:

La mia formulazione originale diceva che ogni problema ``Ŕ chiaro per qualcuno''. Linus commentava dicendo che chi capisce e sistema il problema non deve essere necessariamente e neanche solitamente colui che l'ha definito per primo. ``Qualcuno trova il problema,'' diceva, ``e qualcun'altro lo comprende. E continuo dicendo che trovarlo Ŕ la sfida pi¨ grande.'' Ma il punto Ŕ che entrambe le cose tendono ad avvenire velocemente

Messa in un altro modo:

``La correzione dei bug Ŕ parallelizzabile''. Jeff [Dutky <dutky@wam.umd.edu] osserva che sebbene la correzione richieda la comunicazione tra correttori e un qualche sviluppatore che coordina, la correzione stessa non richiede una coordinazione effettiva tra correttori. Quindi non diviene preda della complessitÓ e dei costi di gestione che rendono difficile l'aumento di sviluppatori.

Un vantaggio della correzione parallela Ŕ che i bug e la loro sistemazione vengono trovati / propagati molto pi¨ velocemente che nei procedimenti tradizionali. Per esempio, quando l'attacco dell'IP di TearDrop fu per la prima volta postato in rete, dopo meno di 24 ore la comunitÓ Linux aveva una correzione funzionante e disponibile da scaricare.

"Correzione impulsiva"

Un'estensione alla correzione parallela che aggiungerei alle ipotesi di Raymond Ŕ la "correzione impulsiva". Nel caso dell'OS di Linux, all'atto di installare l'OS Ŕ implicito l'atto di installare l'ambiente di correzione/sviluppo. Di conseguenza Ŕ molto probabile che se un particolare utente/sviluppatore si imbatte in un bug di un componente di un altro individuo -- e specialmente se questo bug Ŕ "superficiale" -- quell'utente pu˛ rapidamente rattoppare il codice, e tramite le tecnologie di collaborazione di Internet, propagare questa pezza molto velocemente fino al mantenitore del codice.

Detta in un altro modo, i procedimenti OSS hanno una barriera d'accesso al procedimento di correzione molto bassa dovuta alla comune metodologia di sviluppo/correzione derivata dagli strumenti GNU.

Risoluzione dei conflitti

Ogni grande procedimento di sviluppo va incontro a conflitti che devono essere risolti. Spesso la soluzione Ŕ una decisione arbitraria allo scopo di far progredire il progetto. Nei team commerciali, la struttura gerarchica + revisione delle prestazioni risolve questo problema -- come fanno i team OSS a risolverlo?

Nel caso di Linux, Linus Torvalds Ŕ l'indiscusso `leader' del progetto. Egli ha delegato ampie componenti (ad es. networking, device drivers, ecc.) a parecchi suoi fidati "luogotenenti' che a loro volta delegano de-facto ad un gruppetto di "tenutari d'area" (ad es. LAN drivers).

Altre organizzazioni sono descritte da Eric Raymond: (http://earthspace.net/~esr/writings/homesteading/homesteading-15.html):

Alcuni progetti molto grandi lasciano completamente da parte il modello del ' generoso dittatore'. Un modo per farlo Ŕ riunire i co-sviluppatori in un comitato deliberativo (come in Apache). Un altro Ŕ la dittatura a rotazione, in cui il controllo viene passato da un membro ad un altro all'interno di un circolo di co-sviluppatori anziani (gli sviluppatori Perl si organizzano in questo modo).

 

Motivazioni

Questa sezione fornisce una panoramica di alcune delle ragioni chiave cercate dagli sviluppatori OSS per sviluppare i progetti OSS.

Risolvere il problema a portata di mano

E' di fatto la riformulazione della prima regola pratica di Raymond -- "Ogni buon lavoro inizia dalla soddisfazione di un personale sfizio dello sviluppatore".

Molti progetti OSS -- come Apache -- sono iniziati con un piccolo gruppo di sviluppatori assieme per risolvere un problema contingente a portata di mano. Miglioramenti successivi del codice spesso sorgono da individui che applicano il codice ai loro programmi (ad es. scoprendo che non c'Ŕ un driver per un NIC particolare ecc.)

Didattica

Il kernel di Linux crebbe all'interno di un progetto di didattica all'UniversitÓ di Helsinki. In modo simile, molti dei componenti dei sistemi di Linux / GNU (X windows GUI, shell utilities, clustering, networking, ecc.) furono estesi da persone all'interno di istituzioni educative.

{ Questo viene dallo stesso autore che pi¨ avanti sul fatto che la marmaglia di Linux avrÓ difficoltÓ ad assorbire nuove idee!. }

Gratificazione dell'ego

La pi¨ eterea, e forse la pi¨ profonda delle motivazioni presenti nella comunitÓ di sviluppatori OSS Ŕ la pura gratificazione dell'ego.

In "The Cathedral and the Bazaar", Eric S. Raymond cita:

La ``funzione utile'' che gli hackers di Linux massimizzano non Ŕ quella economica classica, ma Ŕ la soddisfazione del proprio ego e l'intangibilitÓ della propria reputazione nei confronti degli altri hackers.

E, naturalmente, "tu non sei un hacker finchŔ qualcun altro non ti chiama hacker"

Occupare la Noosphere

Un secondo documento pubblicato da Raymond -- "Homesteading on the Noosphere" (http://sagan.earthspace.net/~esr/writings/homesteading/), parla della differenza tra uno scambio motivato economicamente (ad es. sviluppo di software commerciali in cambio di denaro) e uno "scambio gratuito" (ad es. OSS per la gloria).

"Homesteading" Ŕ l'acquisizione della proprietÓ ottenuta dal fatto di essere il primo a `scoprirla' o dall'essere stato l'ultimo ad apportarne un significativo contributo. La "Noosphere" Ŕ definita vagamente come lo "spazio di tutto il lavoro". Quindi, sostiene Raymond, la motivazione di un hacker di Linux Ŕ rivendicare l'occupazione di un'area pi¨ vasta possibile all'interno del corpo di lavoro. In altre parole, accreditarsi per il pezzo pi¨ grande del premio.

{ Questa Ŕ una lettura sottile ma significativamente fasulla. Essa introduce una nozione di "dimensione" territoriale che non c'Ŕ da nessuna parte nella mia teoria. Pu˛ essere un errore personale dell'autore, ma il mio sospetto Ŕ che ci˛ rifletta la cultura ossessivamente-competitiva di Microsoft. }

Da "Homesteading on the Noosphere":

L'abbondanza rende i rapporti di comando difficili da sostenere e le relazioni di scambio un gioco senza scopo. Nelle culture dello scambio gratuito, lo status sociale Ŕ determinato non da ci˛ che controlli ma da ci˛ che dai via.

...

Per cui, da questo punto di vista, Ŕ del tutto chiaro che la societÓ degli hackers open-source Ŕ in effetti inserita nella cultura dello scambio gratuito. All'interno di essa non c'Ŕ nessuna grave scarsitÓ del 'necessario per sopravvivere' -- spazio disco, network bandwidth, computing power. Il software Ŕ condiviso liberamente. Questa abbondanza crea una situazione in cui l'unico modo disponibile per misurare il successo Ŕ dato dalla reputazione tra persone dello stesso livello.

Pi¨ succintamente (http://www.techweb.com/internet/profile/eraymond/interview):

SIMS: Quindi la scarsitÓ che cercavate era la scarsitÓ di attenzione e riconoscimento?
RAYMOND: E' esattamente questo.

Altruismo

Questa Ŕ una motivazione controversa e sono portato a credere che ad un certo livello, l'Altruismo `degeneri' in una forma di Gratificazione dell'Ego avanzata da Raymond.

Una motivazione minore che, in parte, deriva dall'altruismo, Ŕ colpire Microsoft.

{ Che ammissione affascinante, specie se viene da un Microservo! Naturalmente, non analizza il perchŔ questa connessione esista; potrebbe arrivare a colpire troppo vicino a casa... }

Biforcazione del codice

Il pericolo chiave in qualsiasi grande team di sviluppatori -- esacerbato in particolar modo nel caso del procedimento caotico di un team di sviluppatori su scala Internet -- Ŕ il rischio di biforcazione del codice.

La biforcazione del codice avviene quando, oltre al normale tira-e-molla di un progetto di sviluppo, si evolvono molteplici, inconsistenti versioni del codice base.

In campo commerciale, per esempio, la gestione forte ed unica del codice base di Windows NT Ŕ considerata come uno dei suoi pi¨ grandi vantaggi rispetto al codice base 'biforcato' che si trova nelle implementazioni UNIX (SCO, Solaris, IRIX, HP-UX, ecc.).

Biforcazione in OSS -- BSD Unix

Nello spazio OSS , BSD Unix Ŕ l'esempio migliore di codice biforcato. Il BDS UNIX iniziale era un tentativo della University of California, Berkeley, di creare una versione, libera da diritti, del sistema operativo UNIX a scopo di insegnamento. Comunque, Berkeley pose severe restrizioni all'uso non accademico del codice base.

{ La storia dello sdoppiamento di BSD fatta dall'autore Ŕ totalmente sbagliata. }

Allo scopo di creare una versione completamente free di BSD UNIX, un team ad hoc (ma chiuso) di sviluppatori cre˛ FreeBSD. Altri sviluppatori in disaccordo per un motivo o per l'altro con il team del FreeBSD frammentarono l'OS per creare altre varianti (OpenBSD, NetBSD, BSDI).

Ci sono due fattori dominanti che portano alla biforcazione dell'albero BSD:

Entrambe queste motivazioni creano una situazione in cui gli sviluppatori possono forzare una biforcazione nel codice e ricevere diritti (monetari, o a livello di ego) a spese della collettivitÓ BDS.

(Mancanza di) biforcazione in Linux

A differenza dell'esempio BDS, il codice del kernel di Linux non ha biforcazioni. Alcune delle ragioni per cui l'integritÓ del codice base di Linux Ŕ stata preservata includono:

Linus Torvalds Ŕ una celebritÓ nel mondo Linux, e le sue decisioni sono considerate definitive. A differenza di BSD, dove non esiste una simile celebritÓ come leader.

Linus Ŕ considerato dal team di sviluppo un onesto e ragionevole manager del codice, e la sua reputazione all'interno della comunitÓ Linux Ŕ molto forte. Comunque, Linus non Ŕ coinvolto in ogni decisione. Spesso, dei sottogruppi risolvono le proprie -- spesso grandi -- diversitÓ tra di loro ed evitano la biforcazione del codice.

Diversamente dalla partecipazione chiusa di BSD, chiunque pu˛ contribuire a Linux, e il proprio "status" -- e di conseguenza la possibilitÓ di 'occupare' un pezzo di Linux pi¨ grande -- Ŕ misurato sulla dimensione dei precedenti contributi.

Indirettamente ci˛ presenta un ulteriore disincentivazione della biforcazione del codice. Non c'Ŕ praticamente nessun meccanismo credibile per cui il codice base minoritario e biforcato possa essere in grado di sostenere il tasso di innovazione del codice Linux originario.

PoichŔ i derivati di Linux DEVONO essere disponibili attraverso degli accessi liberi, il guadagno a lungo termine per una minoranza con un albero Linux biforcato diminuisce.

Le motivazioni dell'Ego spingono gli sviluppatori OSS a piantare il pi¨ paletti possibile nella pi¨ grande Noosphere possibile. La biforcazione del codice base fa inevitabilmente restringere lo spazio di realizzazione al nuovo albero del codice per qualsiasi sviluppatore successivo.

Punti di forza dell'open-source

Quali sono i maggiori punti di forza dei prodotti OSS per i quali Microsoft si deve preoccupare?

Attributi esponenziali di OSS

Come il nostro Operating System business, l'ecosistema OSS ha vari attributi esponenziali:

L'unica grande costrizione che ogni progetto OSS deve affrontare Ŕ trovare abbastanza sviluppatori interessati a dedicare del tempo da contribuire al progetto. Internet Ŕ stato fondamentale per mettere assieme abbastanza persone per un progetto di Operating System. E, pi¨ importante ancora, il motore di crescita per questi progetti Ŕ la crescita del campo d'azione di Internet. Il miglioramento delle tecnologie di collaborazione lubrificano in modo diretto il motore OSS.

Per dirla in un altro modo, la crescita di Internet permetterÓ l'esistenza di progetti OSS sempre pi¨ grandi e renderÓ fattibili progetti OSS in software "pi¨ piccoli".

Come i software commerciali, i singoli progetti OSS pi¨ fattibili in molte categorie possono, nel lungo periodo, uccidere i progetti OSS concorrenti e 'acquisire' il loro valore IQ. Per esempio, Linux sta uccidendo BSD UNIX e ha assorbito la maggior parte delle sue idee di base (cosý come le idee negli UNIXes commerciali). Questo aspetto conferisce un enorme vantaggio al primo che arriva in un particolare progetto

Pi¨ grande Ŕ il progetto OSS, maggiore Ŕ il prestigio associato all'aver contributo alla sua Noosphere con grandi componenti di alta qualitÓ. Questo fenomeno contribuisce di rimando alla natura del "chi vince prende tutto" del procedimento OSS in un dato segmento.

Pi¨ grande Ŕ il progetto, pi¨ sviluppo/collaudo/correzione riceve il suo codice. Maggiore Ŕ la correzione, pi¨ gente si dispone a farla.

CredibilitÓ nel lungo periodo

I binaries possono morire, ma la sorgente di codice vivrÓ per sempre

Una delle implicazioni pi¨ interessanti della fattibilitÓ dell'ecosistema OSS Ŕ la credibilitÓ nel lungo periodo.

Definizione della credibilitÓ nel lungo periodo

La credibilitÓ nel lungo periodo esiste quando non c'Ŕ possibilitÓ di essere esclusi dal commercio in tempi brevi. Questo obbliga a un cambiamento su come i competitori si rapportano a te.

Per esempio, le Airbus Industries incamerarono una iniziale credibilitÓ a lungo termine grazie all'appoggio esplicito del governo. Di conseguenza, quando fa un'offerta per una linea aerea, la Boeing sarÓ pi¨ portata ad accettare un risultato non-economico nel breve periodo quando gareggia per un appalto contro la Lockeed che quando lo fa contro la Airbus.

Applicato liberamente al linguaggio dell'industria del software, un prodotto/procedimento Ŕ credibile nel lungo periodo se le tattiche FUD non possono essere usate per contrastarlo.

OSS Ŕ credibile nel lungo periodo

I sistemi OSS sono considerati credibili perchŔ il codice sorgente Ŕ disponibile potenzialmente da milioni di posti e individui.

{ Qui siamo nel cuore del modo di vedere Microsoft. Io capisco che la reazione tipica dell'hacker rispetto a questo modo di pensare sia di trovarla nauseante, ma esso riflette una sorta di crudeltÓ strumentale riguardo gli usi negativi del marketing che abbiamo bisogno di imparare per riuscire a tenerle testa.

La cosa realmente interessante di queste due affermazione Ŕ che Microsoft dovrebbe smettere con le tattiche FUD contro di noi.

Molti di noi si sono fatti l'idea che sia l'azione legale antitrust del DOJ (Department of Justice N.d.T.) a trattenere la Microsoft dall'estrarre le pistole del FUD. Ma se Sua Altezza Gates (His Gatesness nel testo originale hehe N.d.T.) fa sua questa parte del memorandum, Microsoft pu˛ pensare di dover sviluppare una risposta pi¨ sostanziale perchŔ FUD non funzionerÓ.

Ci˛ pu˛ significare novitÓ sia buone che cattive. La novitÓ buona Ŕ che Microsoft potrebbe smettere l'offensiva nel marketing, un'arma che nel passato Ŕ stata molto pi¨ potente della sua tecnologia distintamente inferiore. La novitÓ cattiva Ŕ che, nei nostri confronti, smettere potrebbe essere effettivamente la strategia migliore; non sprecherebbero pi¨ energia e potrebbero in effetti elaborare una risposta efficace. }

La probabilitÓ che Apache cessi di esistere Ŕ enormemente pi¨ bassa della probabilitÓ che WordPerfect, per esempio, scompaia. La scomparsa di Apache non Ŕ legata alla scomparsa dei binaries (che sono affetti da cambi nell'acquisizione, ecc.) ma bensý dalla scomparsa del codice sorgente e delle conoscenze di base.

Detta in un altro modo, gli utenti sanno che Apache sarÓ ancora in giro fra 5 anni -- ammesso che ci sia un minimo di interesse sostanziale da parte della sua comunitÓ di utenti/sviluppatori.

Un cliente Apache, parlando della ragione logica che l'ha spinto a far girare il suo sito e-commerce su un OSS afferm˛ che l'ha fatto "perchŔ Ŕ a sorgente aperta, e posso afidarlo ad uno o due sviluppatori e provvedere al mantenimento per conto mio illimitatamente. "

La mancanza di biforcazione del codice aumenta la credibilitÓ sul lungo periodo

Il GPL e la sua avversione alla biforcazione del codice rassicura i clienti sul fatto che non stanno prendendo un 'vicolo cieco' in evoluzione con l'acquisto di una particolare versione di Linux.

Il "vicolo cieco in evoluzione" Ŕ il centro della questione del software FUD.

{ Molto vero -- e c'Ŕ un'altra ommissione accecante qui. Se l'autore fosse stato veramente onesto, avrebbe notato che i sostenitori di OSS sono ben intenzionati a rigirare la questione e usarla per colpire Microsoft a morte.

Per stessa ammissione dell'autore, OSS Ŕ a prova di proiettile da questo punto di vista. D'altra parte, la complessitÓ sempre maggiore e lo slittamento programmato dell'appena rinominato ``Windows 2000'' fa pensare che esso sia un vicolo cieco in evoluzione.

L'autore non arriva a sottolineare ci˛. Ma noi lo dobbiamo fare. }

Correzione parallela

Linux e altri difensori dell'OSS stanno portando ragioni via via sempre pi¨ credibili sul fatto che il software OSS Ŕ solido almeno quanto -- se non pi¨ -- le alternative commerciali. Internet fornisce una vetrina ideale ed ad alta visibilitÓ per il mondo OSS.

{ Siamo un manipolo di appassionati, molti di noi non sono pagati e siamo quasi tutti a part-time, contro una macchina propagandistica multimilionaria guidata da alcuni fra i migliori specialisti nel marketing tecnologico.

E gli appassionati stanno ``portando via via ragioni sempre pi¨ credibili''. Per ammissione della stessa Microsoft, stiamo effettivamente vincendo.

CŔ forse qui un messaggio riguardo ai prodotti in questione? }

In particolare, organizzazioni pi¨ grandi e pi¨ sagge, che si appoggiano ad OSS prr operazioni di business (ad es. ISPs) sono confortate dal fatto che possono potenzialmente sistemare un bug indipendentemente dalla scheda del fornitore (per esempio, UUNET fu in grado di ottenere, compilare, e applicare la correzione contro un attacco di teardrop alle loro macchine di Linuz entro 24 ore dal primo attacco pubblico)

Sviluppo parallelo

Detta in un altro modo, "le risorse per gli sviluppatori sono essenzialmente libere in OSS". PoichŔ il pool di potenziali sviluppatori Ŕ enorme, Ŕ economicamente possibile cercare multiple soluzioni/versioni ad un problema e scegliere la soluzione migliore alla fine.

Per esempio, lo stack di Linux TCP/IP fu probabilmente riscritto 3 volte. L'assemblaggio di componenti del codice in particolare Ŕ stato costantemente perfezionato e messo a punto.

OSS = `perfetta' evangelizzazione / documentazione API

L'evangelizzazione / educazione degli sviluppatori dell'OSS di API consiste fondalmentalmente nel fornire allo sviluppatore il codice fondamentale. Dove l'evangelizzazione di API in un modello a codice si basa fondalmentalmente sulla fiducia, l'evangelizzazione OSS di API lascia allo sviluppatore la possibilitÓ di agire di testa sua.

NatBro e Ckindel sottolineano qui una una spaccatura nelle capacitÓ dello sviluppatore. Dove lo "sviluppatore appassionato" Ŕ confortato dalla evangelizzazione OSS, sviluppatori alle prime armi/intermedi --la massa della comunitÓ degli sviluppatori -- preferiscono il modello di fiducia + credibilitÓ organizzativa (ad es. "Microsoft dice che API X adotta questo modo")

{ Se sia vero che la maggioranza degli sviluppatori preferisce o no il modelle `trust' Ŕ una questione estremamente interessante.

La mia esperienza ventennale mi fa pensare di no; in generale, gli sviluppatori preferiscono il codice anche quando i loro boss non-tecnici sono ingenui abbastanza da preferire il `trust'. Microsoft, ovviamente, vuole credere che la sua `credibilitÓ organizzativa' conti -- Scorgo un qualche pensiero illusorio in questo punto.

D'altra parte potrebbero anche avere ragione. Noi, nella comunitÓ open-source, non possiamo permetterci di abbandonare questa possibilitÓ. Penso che possiamo affrontarla sviluppando una documentazione di alta qualitÓ. In questo modo, la `fiducia' nel nome degli autori (o in editori con buona reputazione quali O'Reilly o Addison-Wesley) pu˛ sostituire il `fiducia' in una organizzazzione API-defining.) }

Tasso di uscita

I progetti OSS fortemente componentizzati sono in grado di far uscire sottocomponenti non appena lo sviluppatore ha finito il suo codice. Di conseguenza, i progetti OSS vengono revisionati velocemente e frequentemente.

Punti deboli di open-source

I punti deboli nei progetti OSS si possono suddividere in 3 capitoli fondamentali:

Costi di gestione

Il principale blocco per i progetti OSS Ŕ l'aver a che fare con la crescita esponenziale dei costi di gestione proporzionalmente all'accrescimento in termini di tasso di innovazione e dimensione. Ci˛ implica un limite al tasso di innovazione cui un progetto OSS si pu˛ sottoporre.

Iniziare un progetto OSS Ŕ difficile

Da Eric Raymond:

E' del tutto chiaro che non si pu˛ codificare in stile bazaar partendo da zero. Si pu˛ testare, correggere, migliorare in stile bazaar, ma sarebbe molto difficile dare origine ad un progetto seguendo il modello bazaar. Linus non ci ha provato. Neanch'io. La nascente comunitÓ di sviluppatori ha bisogno di avere qualcosa da far girare e da testare.

L'argomentazione di Raymond pu˛ essere estesa alla difficoltÓ di far partire/mantenere un progetto se non ci sono chiari precedenti/obbiettivi (o troppi obbiettivi) per il progetto.

CredibilitÓ del bazaar

Ovviamente, ci sono molti pi¨ frammenti di codice sorgente in Internet di quante siano le comunitÓ OSS. Cosa differenzia i "codici sorgente morti" da un florido bazaar?

Un articolo (http://www.mibsoftware.com/bazdev/0003.htm) ci dÓ i seguenti criteri di credibilitÓ :

"....pensare in termini di un numero ristretto al minimo di partecipanti Ŕ fuorviante. Fetchmail e Linux hanno un numero enorme di beta testers *ora*, ma ovviamente entrambi ne avevano molto pochi all'inizio.

Ci˛ che entrambi i progetti avevano era una manciata di persone entusiaste e una promessa plausibile. La promessa era in parte tecnica (questo codice diventerÓ meraviglioso con poco sforzo) e in parte sociologica (se ti unisci al nostro gruppo, ti divertirai come ci stiamo divertendo noi). Quindi ci˛ di cui ha bisogno un bazaar per svilupparsi Ŕ il credere che esisterÓ il bazaar completamente sviluppato!"

Sono dell'opinione che alcuni dei criteri chiave necessari affinchŔ un bazaar sia credibile includono:

Sviluppo post-paritÓ

Descrivendo questo problema a JimAll, egli forný la perfetta analogia dell'"andare dietro ai fanalini di coda". Il modo pi¨ facile per ottenere un comportamento coordinato da una banda vasta e semi-organizzata Ŕ indirizzarla verso un bersaglio conosciuto. Avere dei fanalini di coda dona concretezza ad una visione sfuocata. In situazioni come questa, avere dei fanalini di coda da seguire Ŕ una delega per avere una forte leadership centrale.

Naturalmente, una volta che questo implicito principio organizzativo non Ŕ pi¨ disponibile (una volta che il progetto ha raggiunto la "paritÓ" con lo stato-dell'-arte), il livello di management necessario per spingersi verso nuove frontiere diventa imponente.

{ Nonsense. Nel mondo open-source, tutto ci˛ di cui si ha bisogno Ŕ una persona con una buona idea.

Parte dello scopo dei open-source Ŕ abbassare le barriere che ritardano l'innovazione. Abbiamo provato per esperienza che il 'management imponente' decantato dall'autore Ŕ una delle peggiori tra queste barriere.

Nel mondo open-source, gli innovatori provano qualsiasi cosa, e l'unico test avviene se gli utenti sperimentano volontariamente l'innovazione e gli piace una volta sperimentata. Internet facilita questo processo, e le convenzioni di cooperazione della comunitÓ open-source hanno il proposito specifico di promuoverlo.

La terza alternativa ad ``andare dietro ai fanalini di coda'' o ``forte leadership centrale'' (e pi¨ efficace di ambedue) Ŕ una anarchia creativa in evoluzione dove vi siano mille leaders e diecimila seguaci collegati da una rete di revisioni tra pari e soggetti al fuoco di fila dei controlli reali.

Microsoft non pu˛ battere ci˛. Io non credo neanche che possa realmente capirlo, non con il cuore. }

Questo Ŕ forse l'ostacolo pi¨ interessante da affrontare per la comunitÓ Linux ora che hanno conseguito la paritÓ sotto molti aspetti con lo stato dell'arte di UNIX.

{ La comunitÓ Linux non solo ha saltato quest'ostacolo, ma l'ha totalmente demolito. Questo fatto sta alla base del vantaggio a lungo termine dell'open-source rispetto allo sviluppo della closed-source. }

Lavoro poco sexy

Un'altra cosa interessante da osservare nel prossimo futuro di OSS Ŕ quanto bene il team Ŕ in grado di affrontare il lavoro "poco sexy" necessario per dar vita a un prodotto di categoria commerciale.

Nel terreno dei sistemi operativi, ci˛ include piccole ma essenziali funzioni quali power management, sospensione/ripresa, infrastrutture di management, accuratezze UI, approfondito supporto Unicode, ecc.

per Apache, ci˛ pu˛ voler dire funzionalitÓ tipo wizards per amministratori principianti.

Lavoro architettonico/integrativo

Il lavoro integrativo attraverso i moduli Ŕ il maggior costo in cui si imbattono i team OSS. Un memo email di Nathan Myrhvold del maggio 98, evidenzia che tra tutti gli aspetti presenti nello sviluppo di software, il lavoro di integrazione Ŕ quello pi¨ soggetto alle leggi di Brook.

Fino ad ora, Linux ha grandemente beneficiato del modello integrativo / componentistico portato avanti dai precedenti UNIX. Inoltre, l'organizzazzione di Apache fu semplificata dalle semplici e tolleranti specifiche del protocollo HTTP e dello UNIX server application design.

Innovazioni future che richiedono dei cambiamenti al nucleo del modello architettonico/integrativo diventeranno incredibilmente difficili da assorbire per il gruppo OSS perchŔ fa perdere simultaneamente di valore ai loro precedenti e al loro bagaglio di esperienza.

{ Questa previsione fa il paio con la
precedente asserzione dell'autore per cui lo sviluppo open-source si basa in modo pericoloso su progetti precedenti e guarda inevitabilmente al passato. Questa Ŕ miopia -- sembra che cose come Python, Beowulf, e Squeak (per nominare solo tre tra le centinaia di progetti innovativi) non sono percepiti dal suo radar.

Possiamo solo sperare che Microsoft continui a crederla cosý, perchŔ ostacolerebbe la loro risposta. Molto dipenderÓ su come interpreteranno innovazioni come (per esempio) la SMPizzazzione del kernel di Linux.

E' interessante notare come l'autore contraddica se stesso su questo punto. }

}

Questioni sul procedimento

Questi sono punti deboli intrinsechi nella metodologia progetto/risposta di OSS.

Costi iterativi

Una delle chiavi del procedimento OSS Ŕ nell'avere molte pi¨ iterazioni del software commerciale (Linux era conosciuto per il fatto di revisionare il suo kernel pi¨ di una volta al giorno). Comunque, i clienti commerciali ci dicono che vogliono meno revisioni, non di pi¨.

{ Mi chiedo come cambierebbe questa risposta se le revisioni Microsoft non fossero cosý costose?

Questo Ŕ il motivo per cui esistono i distributori commerciali di Linux -- per mediare tra un procedimento a rapida evoluzione e i clienti che non vogliono seguire ogni spostamento. Il kernel pu˛ essere revisionato una volta al giorno, ma Red Hat lo revisiona solo una volta ogni sei mesi. }

"Non-expert" Feedback

L'OS di Linux non Ŕ sviluppato per gli utenti finali, ma bensý per altri hackers. In modo simile, il web server Apache Ŕ implicitamente rivolto alla gran parte degli operatori dei siti, non ai server intranet dipartimentali.

La linea chiave qui Ŕ che poichŔ OSS non ha un esplicito rapporto marketing / customer, la "lista dei desideri" -- e di conseguenza lo sviluppo di certe funzioni -- Ŕ dominata dagli utenti con pi¨ conoscenze tecniche.

Una cosa che i gruppi di sviluppo alla MSFT hanno imparato pi¨ e pi¨ volte Ŕ che la facilitÓ d'uso, l'intuitivitÓ UI, ecc. devono essere costruite partendo dalla base del prodotto e non possono essere aggiunte in un secondo momento.

{ Questo richiede un commento -- poichŔ ci˛ Ŕ giusto in teoria, ma Ŕ incredibilmente falso nella pratica Microsoft. La falsitÓ implica una spiegabile debolezza nella implicita strategia (per Microsoft) di enfatizzare UI.

Ci sono due modi per costruire "fin dalla base" un prodotto facile da usare. Uno (il modo Microsoft) Ŕ di progettare applicazioni monolitiche che sono definite e dominate dai loro UI. Questo tende a generare ``Windowsitis'' -- mostruositÓ rigide, sferraglianti, inclini ai bug, con una superficie patinata ed un interno vuoto..

Programmi costruiti in questo modo sembrano user-friendly a prima vista, ma finiscono per diventare nel lungo periodo una voragine che inghiotte tempo ed energia. Essi possono essere sostenuti solo da un bombardamento pubblicitario a tappeto, il cui scopo principale Ŕ illudere gli utenti facendogli credere che (a) i bug sono delle caratteristiche o che (b) tutti i bug sono in realtÓ degli stupidi sbagli dell'utente, o che (c) tutti i bugs saranno aboliti con il prossimo upgrade. Questo approccio Ŕ fondalmentalmente spezzato.

L'altro modo Ŕ quello Unix/Internet/Web, che consiste nel separare il motore (che fa il lavoro) dall'UI (che fa l'ispezione ed il controllo). Questo approccio richiede che il motore e UI comunichino usando un protocollo ben definito. E' esemplificato dalle coppie browser/server -- il motore si specializza nell'essere un motore, e l'UI si specializza nell'essere un UI.

Con questo secondo approccio la complessitÓ globale scende e l'affidabilitÓ cresce. Inoltre, l'interfaccia Ŕ pi¨ facile da evolvere/migliorare/personalizzare, proprio perchŔ non Ŕ strettamente accoppiata al motore. E' anche possibile avere intefacce multiple accordate a diversi tipi di audiences.

Per finire, questa architettura conduce ad applicazioni che sono enterprise-ready -- che possono essere usate o amministrate lontanamente dal server. Questo approccio funziona -- ed Ŕ il modo naturale per la comunitÓ open-source di contrastare Microsoft.

Il punto chiave qui Ŕ che se Microsoft vuole dare battaglia alla comunitÓ open-source sull'UI, lasciamola fare -- perchŔ possiamo vincere anche questa battaglia, lottando a nostro modo. Possono fare dei monoliti Windows sempre pi¨ elaborati che si saldano a chiazze alla consolle delle applicazioni-server. Noi vinceremo se faremo delle applicazioni pulite che facciano leva su Internet e sulla Rete e facciano UI che si possano evolvere ed essere pluggable/unpluggable a scelta dell'utente.

Da notare, comunque, che la nostra vittoria dipende dall'esistenza di protocolli ben definiti (come HTTP) per la comunicazione tra UI e motori. E' per questo che ci˛ che l'affermazione che si trova pi¨ avanti nel memorandum riguardo la ``de-standardizzazione dei protocolli'' Ŕ cosý sinistra. Dobbiamo stare in guardia contro questo. }

La tendenza interessante da osservare qui saranno le conseguenze che avranno fornitori commerciali di OSS (come RedHat in campo Linux, C2Net in campo Apache) sul ciclo feedback.

CredibilitÓ organizzativa

Come pu˛ OSS fornire il servizio che l'acquirente si aspetta dai fornitori di software?

Modello di assistenza

L'assistenza al prodotto Ŕ la prima questione che assilla eventuali acquirenti di pacchetti OSS ed Ŕ la prima caratteristica dei redistributori commerciali.

Comunque, la stragrande maggioranza dei progetti OSS Ŕ assistita dagli sviluppatori dei rispettivi componenti. Aumentare proporzionalmente questa infrastruttura di supporto al livello che ci si aspetta per i prodotti commerciali sarÓ una sfida importante. Ci sono differenze enormi tra gli utenti e gli sviluppatori in IIS vs. Apache.

{ La vaghezza di quest'ultima frase Ŕ significativa. Se l'autore avesse continuato, avrebbe dovuto riconoscere che Apache sta massacrando IIS sul mercato (la quota di Apache Ŕ del 54% e sta salendo; quella di IIS Ŕ attorno al 14% e sta precipitando).

Ci˛ avrebbe dovuto portare a scegliere tra alternative sgradevoli (per Microsoft). Pu˛ essere che che i canali informali di supporto al cliente di Apache e la sua `credibilitÓ organizzativa' producano in realtÓ risultati migliori di quelli che Microsoft pu˛ offrire. Se ci˛ Ŕ vero, allora Ŕ difficile in via di principio spiegare perchŔ la stessa cosa non possa essere vera per gli altri progetti OSS.

L'alternativa -- che Apache Ŕ cosý buono che non ha bisogno di molta assistenza o `credibilitÓ organizzativa' -- Ŕ anche peggiore. Significherebbe che tutti i costosi battaglioni di assistenza e marketing schierati da Microsoft sono stati solo un gigantesco investimento sbagliato, come demolire i condomini staliniani quarant'anni pi¨ tardi.(?)

Queste due spiegazioni possibili implicano strategie distinte ma parallele per i sostenitori di open-source. Una Ŕ di costruire dei software che siano cosý buoni da non aver semplicemente bisogno di molta assistenza (ma faremmo cosý in ogni caso, e in genere l'abbiamo fatto). L'altra Ŕ di intensificare ci˛ che giÓ stiamo facendo con il supporto tramite mailing lists, newsgroups, FAQs, e altri canali informali ma estremamente efficaci. }

Nel breve-medio periodo, questo fattore da solo relegherÓ i prodotti OSS sullo scaffale pi¨ alto dell'insieme degli utenti.

Strategic Futures

Un problema eccelso che affliggerÓ l'utente con l'adozione in vasta scala dei progetti OSS Ŕ la mancanza di una direzione strategica nel ciclo di sviluppo OSS. Mentre i miglioramenti fatti sui bug di un prodotto OSS sono molto credibili, le funzioni future non hanno uno sviluppo garantito da impegni organizzativi.

{ No. Nella comunitÓ open-source, i nuovi aspetti di un prodotto sono il frutto dell'esplorazione individuale di nuovi territori da parte degli hackers. E ci˛ non si pu˛ certamente disprezzare. Internet e il Web furono costruiti in questo modo -- non grazie ad `impegni organizzativi', ma perchŔ qualcuno da qualche parte ha pensato ``Hey -- questa cosa potrebbe essere carina...''.

Forse Ŕ una fortuna per noi che la `credibilitÓ organizzativa' occupi uno spazio cosý grande nella visione del mondo di Microsoft. Il tempo e l'energia che impiegano preoccupandosi di questo aspetto che considerano un prerequisito sono risorse che non impiegheranno in azioni che potrebbero essere effettivamente contro di noi. }

Che significato ha per la comunitÓ Linux "registrarsi" per aiutare a costruire il Corporate Digital Nervous System? Come pu˛ Linux garantire una compatibilitÓ retroattiva con applicazioni scritte da precedenti API? A chi fai causa se la prossima versione di Linux non mantiene ci˛ che ha promesso? Come farÓ Linux a fare delle alleanze strategiche con qualche altra entitÓ?

{ La questione della compatibilitÓ retroattiva Ŕ carinamente ironica, considerato che non ho mai sentito parlare di un programma che girasse su tutti i DOS, Windows 3.1, Windows 95, Windows 98, ed NT 4.0 senza cambiamenti.

Qui l'autore Ŕ stato superato dagli eventi. Dovrebbe chiedere agli amichetti di Microsoft dentro ad Intel chi ha comprato una quota di minoranza di Red Hat meno di due mesi dopo che questo memorandum Ŕ stato scritto. }

Modelli di commercio open-source

Negli ultimi due anni, OSS ha avuto un altro cambiamento con l'emergere di ditte che vendono il software OSS, e, cosa pi¨ importante, ingaggiando sviluppatori a tempo pieno per migliorare il codice base. Qual'Ŕ il modello commerciale che giustifica queste assunzioni?

In molti casi, le risposte a queste domande sono simili a "perchŔ mai dovrei sottoporre il mio protocol/app/API ad un corpo standard?"

Servizi secondari

Il venditore di OSS-ware provvede alla vendita, assistenza ed integrazione al cliente. In effetti, ci˛ trasforma il venditore di OSS-ware da produttore di pacchetti di articoli a fornitore di servizi.

Articoli civetta -- Accesso al mercato

Il modello commerciale degli articoli civetta (prodotti venduti sottocosto) di OSS pu˛ essere utilizzato per due scopi:

Molti dei nuovi partecipanti OSS -- in particolare quelli nel campo degli Operating Systems -- vedono l'investimento nello sviluppo di prodotti OSS uno strategico "prodotto civetta" contro Microsoft.

Distributori Linux, quali RedHat, Caldera, e altri, hanno la precisa volontÓ di investire in sviluppatori a tempo pieno che producano per la comunitÓ OSS. Finanziando simultaneamente questi sforzi, danno vita implicitamente ad una collusione con l'intento di ottenere maggiori ricavi a breve termine facendo crescere il mercato Linux invece di competere direttamente l'uno contro l'altro.

Un esempio indiretto Ŕ l'impiego da parte della O'Reilly & Associates di Larry Wall -- "leader" e sviluppatore a tempo pieno di PERL. L'editore #1 dei manuali PERL Ŕ, naturalmente, la O'Reilly & Associates.

Nel breve periodo, specialmente quando il progetto OSS Ŕ in piena curva acendente, tali investimenti generano ROI positivi. A lungo termine, le motivazioni ROI possono portare questi sviluppatori a diventare proprietari delle estensioni pi¨ che a far uscire OSS.

Standardizzazione dei fornitori a valle

E' legato strettamente al modello commerciale dei prodotti civetta. Invece di cercare di ottenere dei guadagni marrginali facendo crescere il mercato in modo massiccio, questi negozi aumentano i loro ricavi essendo parte di una catena standardizzata di fornitori a valle.

Attualmente i migliori esempi di questo sono i piccoli venditori di server quali Whistle Communications, e Cobalt Micro che stanno rispettivamente investendo nello sviluppo di SAMBA e Linux.

Sia Whistle che Cobalt basano le loro entrate dalla quantitÓ di volume hardware. Di conseguenza, investire in OSS permette loro di evitare il mercato dei PC dove deve essere pagata una "tassa" ai venditori di OS (il prezzo al dettaglio di NT Server Ŕ di $800, mentre l'obbiettivo di Cobalt MSRP Ŕ attorno ai $1000).

I primi sviluppatori Apache furono assunti con cash-strapped ISPs e ICPs.

Un altro, pi¨ recente esempio, Ŕ l'accordo tra IBM e Apache. Dichiarando il server HTTP una merce, IBM spera di far convergere i ricavi nei servizi applicativi tecnicamente pi¨ arcani che raccoglie con la sua distribuzione di Apache (cosý come la speranza di raggiungere l'enorme quota di mercato di Apache).

Primo fautore -- Costruisci ora, $$ pi¨ avanti

Una delle qualitÓ esponenziali di OSS -- i progetti di successo OSS inghiottono quelli con meno successo nello stesso campo -- implica un modello di commercio con prelazione, in cui investendo direttamente in OSS oggi, si svuotano/eliminano i progetti competitivi futuri -- specialmente se il progetto richiede un'evangelizzazione API. Questo equivale a determinare un vantaggio in OSS al primo che prende l'iniziativa.

Inoltre, i vantaggi dati dalla scala di sviluppo, dal tasso di iterazione, e dall'affidabilitÓ sono dei doni del cielo per coloro che iniziano e che non possono permettersi un grande staff interno di sviluppo.

Esempi di avviamenti in questo campo includono SendMail.com (che fa una versione commercialmente sostenuta del sendmail mail transfer agent) e C2Net (che fa un Apache commerciale e criptato).

Da notare che non Ŕ stato osservato nessun caso di successo di uno che si avvii e che abbia dato origine ad un progetto OSS. In entrambi questi casi, i progetti OSS esistevano prima dell'avviamento.

Sun Microsystems ha recentemente annunciato che il suo progetto "JINI" sarÓ fornito di OSS tramite modulo e pu˛ rappresentare una applicazione della dottrina di prelazione.

Linux

Nelle prossime sezioni saranno analizzati i pi¨ notevoli progetti OSS inclusi Linux, Apache, ed ora anche Netscape's OSS browser.

Un secondo memorandum intitolato "Linux OS Competitive Analysis" fornisce una visione approfondita dell'OS di Linux. Qui, do un riassunto delle mie conclusioni su Linux.

Che cos'Ŕ?

Linux (pronunciato "LYNN-ucks") Ŕ l'OS open-source #1 come quota di mercato su Internet. Linux deriva da 25+ anni di studio sull'operating system di UNIX.

Funzioni principali:

Linux Ŕ un vero, credibile OS + procedimento di sviluppo

Come altri prodotti Open Source Software (OSS), il vero punto chiave di Linux non Ŕ la versione statica del prodotto ma bensý il procedimento che ci sta attorno. Questo procedimento conferisce credibilitÓ e un'aria di sicurezza-futura agli investimenti degli acquirenti Linux.

{ Tuto vero. Io stesso non avrei saputo dirlo meglio :-). }

Linux Ŕ un pericolo a breve/medio termine nel campo dei server

La minaccia principale che Microsoft deve affrontare nei confronti di Linux Ŕ diretta contro NT Server.

Il punto di forza di Linux nei confronti del server NT (e di altri UNIXes) Ŕ dato da diversi fattori chiave:

Linux Ŕ improbabile che sia una minaccia nei desktop

E' improbabile che Linux sia una minaccia nel medio-lungo termine nei desktop per varie ragioni:

Colpire Linux

Oltre ad attaccare in generale i punti deboli dei progetti OSS (ad es. costi integrativi / architettonici), alcuni attacchi specifici su Linux sono:

Tutte le edizioni standard dei prodotti per NT vs. Sun si applicano a Linux.

La homebase di Linux Ŕ attualmente l' infrastruttura della rete e del server dei prodotti. Piegando la funzionalitÓ estesa (per esempio Storage+ nei sistemi di archivio, DAV/POD per la rete) negli odierni servizi dei prodotti, alziamo la sbarra & cambiamo le regole del gioco.

{ Qui, come nel precedente commento su come pu˛ vincere Linux, iniziamo a vedere il profilo reale di una strategia Microsoft emergere dalle nebbie del corporatese. E non Ŕ gradevole; in effetti, Ŕ brutto abbastanza da essere appropriato al fatto che si sta avvicinando la mezzanotte di Halloween nel momento in cui scrivo.

Ci˛ a cui mira l'autore non Ŕ nient'altro che cercare di rovesciare l'intera infrastruttura " network e server del prodotto" (featuring TCP/IP, SMTP, HTTP, POP3, IMAP, NFS, e altri standard aperti) nell'uso di protocolli che, anche se possono avere gli stessi nomi, sono stati in realtÓ trasformati in congegni di controllo-del-cliente-e-del-mercato per Microsoft (questo Ŕ ci˛ che l'autore vuol dire in realtÓ quando esorta i Microservi ad "alzare la sbarra & cambiare le regole del gioco").

Il `aggiungere le funzionalitÓ estese' qui Ŕ un eufemismo per introdurre estensioni nonstandard (o interi protocolli alternativi) che siano in seguito messi prepotentemente sul mercato come standard, anche se sono chiusi, non documentati, o specificati solo fino al punto da creare una illusione di apertura. L'intento Ŕ di fare dei nuovi protocolli una lista di verifica per compratori ingenui, e rendere simultaneamente quasi impossibile per una terza parte scrivere qualcosa di simbiotico per i programmi Microsoft. (E chiunque ci riesca viene comperato.)

Questo gioco si chiama ``abbraccia e allargati''. Abbiamo giÓ visto Microsoft fare questo gioco, e sono molto bravi. Quando funziona, Microsoft vince un monopolio blindato. Gli acquirenti perdono.

(Questa strategia di inquinamento-degli-standard Ŕ perfettamente in linea con gli sforzi di Microsoft di corrompere Java e rompere il marchio Java.)

I sostenitori di open-source possono ribattere sottolineando esattamente come e perchŔ il cliente ci perde (competitivitÓ ridotta, costi maggiori, minore affidabilitÓ, opportunitÓ perse). I sostenitori di open-source possono anche contrapporre gli aspetti positivi -- cioŔ, come open-source e standard aperti aumentino la competizione fra venditori, facciano diminuire i costi, migliorino l'affidabilitÓ, e creino opportunitÓ.

Ancora una volta, come Microsoft ammette pi¨ sopra nel memorandum, Internet Ŕ figlio del nostro manifesto. La migliore controffensiva da parte nostra contro abbraccia-e-allargati Ŕ di sottolineare che Microsoft sta tentando di serrare Internet. }

Netscape

Nel tentativo di rinnovare la sua credibilitÓ nel campo dei browser, Netscape ha di recente fatto uscire e sta tentando di creare una comunitÓ OSS attorno al codice sorgente del suo Mozilla.

Organizzazione & licenze

Il modello organizzativo e delle licenze di Netscape Ŕ liberamente basato su quello della comunitÓ Linux & GPL con poche differenze. Primo, Mozilla e Netscape Communicator sono due codebases con gli ingegneri di Netscape che provvedono alla sincronizzazione.

A differenza di un completo GPL, Netscape si riserva il diritto finale di rifiutare / obbligare a delle modifiche all'interno del codice base di Mozilla e gli ingegneri di Netscape sono nominati "Direttori d'area" di grandi componenti (per ora).

Punti di forza

Capitalizzare i sentimenti anti-Microsoft nella comunitÓ OSS

In relazione ad altri progetti OSS, Mozilla Ŕ considerato essere come uno dei pi¨ diretti attacchi a breve termine al sistema Microsoft. Questo fattore da solo Ŕ probabilmente il fattore chiave che galvanizza lo stimolo degli sviluppatori verso il codice base di Mozilla.

Nuova credibilitÓ

La disponibilitÓ del codice sorgente di Mozilla ha migliorato di poco la credibilitÓ di Netscape nel campo dei browser. Come sottolinea BharatS in http://ie/specs/Mozilla/default.htm:

"Facendo uscire il loro codice essi hanno garantito che non spariranno mai completamente dall'orizzonte nel modo in cui Wordstar Ŕ scomparsa. I browsers Mozilla sopravviveranno bene nei prossimi 10 anni, anche se la loro base di utenza si restringe. "

Cavarsi un grande sfizio

Il browser Ŕ largamente usato / diffuso. Di conseguenza, il gruppo di persone che possono essere intenzionate a risolvere "un problema corrente a portata di mano" e/o sistemare un bug pu˛ essere vasto.

Punti deboli

Sviluppo post paritario

Mozilla Ŕ giÓ vicino ad essere pari a IE4/5. Di conseguenza, non c'Ŕ alcun esempio da seguire che possa aiutare e implicitamente coordinare il team di sviluppo.

Netscape ha assegnato ad alcuni dei sui migliori sviluppatori il compito a tempo pieno di gestire il codice base di Mozilla e sarÓ interessante vedere quanto (e se) questo potrÓ aiutare la capacitÓ di Mozilla di spingersi in nuovi campi.

Piccola Noosphere

Un punto debole interessante Ŕ la rimanente dimensione della "Noosphere" per i browser OSS.

    1. Il browser per sŔ stesso Ŕ essenzialmente finito.
    2. Non c'Ŕ pi¨ alcun grande segmento di alto profilo del browser puro che debba essere sviluppato. In altre parole, Netscape ha giÓ risolto l'80% dei problemi interessanti. La gratificazione dell'ego Ŕ poca /nulla nel correggere / sistemare il rimanente 20% del codice di Netscape.

    3. L'interesse commerciale di Netscape fa restringere l'effetto dei contributi della Noosphere.

La gestione di Linus Torvalds del codice base di Linux Ŕ diretta plausibilmente verso la creazione del miglior Linux possibile. Netscape, al contrario, si riserva espressamente il diritto di prendere delle decisioni gestionali sul codice basandosi sugli interessi commerciali / economici. Invece di creare un prodotto importante, il codice dello sviluppatore Ŕ sottomesso alla quotazione di Borsa di Netscape.

Costo di integrazione

Potenzialmente il maggior ostacolo allo sforzo di Mozilla Ŕ il livello di integrazione che gli acquirenti si aspettano dalle caratteristiche di un browser. Come affermato prima, l'integrazione sviluppo / collaudo NON Ŕ una attivitÓ parallelizzabile e quindi Ŕ danneggiata dal procedimento OSS.

In particolare, molto del nuovo lavoro per IE5+ non consiste solamente nell'integrare i componenti col browser ma continuare l'integrazione all'interno dell'OS. E sarÓ particolarmente spiacevole doverci competere.

Previsioni

La tesi quindi Ŕ che, a differenza dei progetti Linux e Apache che, per ora, hanno grande successo, gli sforzi di Netscape per Mozilla farÓ:

Tenendo presente che il codice sorgente Ŕ stato fatto uscire solo poco tempo fa (aprile '98), c'Ŕ giÓ la prova del calo di interesse per Mozilla. Una prova estremamente NON-SCIENTIFICA si pu˛ trovare nel declino del volume delle mailing list fra le mailing list di Mozilla da aprile a giugno.

Mozilla Mailing List

Aprile 1998

Giugno 1998

% decrescita

Funzioni desiderate

1073

450

58%

Sviluppo UI

285

76

73%

Discussione generale

1862

687

63%

Specchi interni delle mailing list di Mozilla possono essere trovate a http://egg.Microsoft.com/wilma/lists

Apache

Cronologia

Parafrasato da http://www.apache.org/ABOUT_APACHE.html

Nel febbraio del 1995, il server pi¨ popolare sul Web era il dominio pubblico HTTP daemon sviluppato da NCSA, University of Illinois, Urbana-Champaign. Comunque, lo sviluppo di quel httpd era in fase di stallo dalla metÓ del 1994, e molti webmasters avevano provveduto a sviluppare le proprie estensioni e sistemato bug, e avevano bisogno di una distribuzione comune. Un piccolo gruppo di questi webmasters, contattati privatamente tramite e-mail, si misero assieme con lo scopo di coordinare i loro cambiamenti (nella forma di "pezze"). Per la fine di febbraio del '95, otto contributori base formarono la fondazione dell'Apache Group. Nell'aprile del 1995, Apache 0.6.2 fu fatto uscire.

Nel maggio-giugno 1995, una nuova architettura server (chiamata in codice Shambhala) fu sviluppata, e includeva una struttura modulare ed API per una migliore estensibilitÓ, allocazione della memoria pull-based, e un modello di procedimento anti-biforcazione. Il gruppo fece il cambio verso il nuovo server base in luglio e aggiunse le caratteristiche da 0.7.x, che risultarono in Apache 0.8.8 (e nei suoi confratelli) in agosto.

A meno di iun anno dalla formazione del gruppo, il server Apache pass˛ la httpd di NCSA httpd come il server #1 in Internet.

Organizzazione

Il gruppo di sviluppo Apache consiste in circa 19 membri di base pi¨ centinaia di amministratori di siti web sparsi nel mondo che in un modo o nell'altro hanno sottoposto un rapporto / pezza sui bug. I dati sui bug di Apache si possono trovare a: http://bugs.apache.org/index.

Una descrizione sulla gestione del codice e sulle procedure di soluzione dei conflitti seguite dal team di Apache si trovano a http://www.apache.org:

Leadership:

C'Ŕ un gruppo base di contributori (informalmente chiamato il "nucleo") che fu formato dai fondatori del progetto ed Ŕ aumentato di tanto in tanto quando dei membri del gruppo hanno nominato dei contributori di rilievo e gli altri membri del nucleo hanno accettato.

Soluzione delle dispute:

Cambiamenti di codice sono proposti sulla mailing list e generalmente votati dai membri attivi --- tre +1 (voti affermativi) e no -1 (astenuti, o veti) sono necessari per promuovere un cambio di codice durante un ciclo di uscita

Punti di forza

Quote di mercato!

Apache ha oggi di gran lunga la quota #1 di web site su Internet. Fare la parte del leone sul mercato dÓ un enorme potere di controllo sull'evoluzione del mercato.

In particolare, la quota di mercato di Apache nel campo dei web server presenta i seguenti ostacoli competitivi:

Supporto terzi

Il numero di strumenti / moduli / plug-ins disponibili per Apache sono aumentati ad un tasso crescente.

Punti deboli

Prestazioni

Nel breve periodo, IIS batte sonoramente Apache su SPECweb. Andando avanti, quando IIS si sposta nel kernel e si avvantaggia di una integrazione pi¨ profonda con NT, ci si aspetta che questo orientamento si incrementi ulteriormente.

Apache, al contrario, Ŕ gravato dalla richiesta di creare un codice portabile per tutti i suoi ambienti OSS.

ComplessitÓ del protocollo HTTP & servizi applicativi

Parte del motivo per cui Apache Ŕ riuscito a trovare un punto d'appoggio e decollare Ŕ dato dalla semplicitÓ del protocollo HTTP. A mano a mano che nuove caratteristiche vengono stratificate sopra al modesto server ( per es. supporto alle transazioni multi-server, POD, ecc.) sarÓ interessante vedere come farÓ il team Apache a stare al passo.

Il supporto ASP, per esempio, Ŕ un driver chiave per IIS nei corporate intranets.

IBM & Apache

Recentemente, IBM ha annunciato il supporto al codice base di Apache nelle applicazioni server del suo WebSphere. Il risultato reale dell'entusiamo della stampa non Ŕ ancora chiaro, comunque:

Altri progetti OSS

Alcuni altri progetti OSS:

Risposta Microsoft

In generale, devono essere inserite molte pi¨ riflessioni/discussioni nella risposta Microsoft al fenomeno OSS. L'obbiettivo di questo documento Ŕ didattico e di analisi sul procedimento OSS, di conseguenza in questa sezione, offro solo una lista molto superficiale di opzioni e preoccupazioni.

VulnerabilitÓ del prodotto

Dove Ŕ pi¨ probabile che Microsoft senta il "pizzicotto" dei progetti OSS nel prossimo futuro?

Server vs. Client

Il server Ŕ molto pi¨ vulnerabile ai prodotti OSS del client. Le ragioni di ci˛ includono:

Accapparrarsi i benefici OSS -- Socializzazione degli sviluppatori

La capacitÓ del procedimento OSS di radunare e sfruttare l'IQ collettivo di migliaia di individui attraverso Internet Ŕ semplicemente stupefacente. E, cosa pi¨ rilevante, l'evangelizzazione di OSS aumenta proporzionalmente alle dimensioni di Internet in modo molto pi¨ veloce di quanto facciano i nostri sforzi di evangelizzazione.

{ Ovvero, Microsoft sta per essere superata sia per le capacitÓ intellettuali che per quelle commerciali da Open Source -- e lo sa! }

Come pu˛ fare Microsoft ad accapparrarsi parte delle esuberanti capacitÓ intellettuali degli sviluppatori che sono puntati sui prodotti OSS?

Alcune idee di partenza includono:

Accapparrarsi i benefici OSS -- procedimenti interni Microsoft

Cosa pu˛ imparare Microsoft dall'esempio OSS? Pi¨ specificatamente: come possiamo fare per ricreare internamente l'ambiente di sviluppo OSS? Diversi revisori di questo documento hanno costantemente sottolineato che internamente, noi dobbiamo vedere idealmente Microsoft come una comunitÓ OSS, ma per varie ragioni non lo Ŕ:

"Uno sviluppatore in Microsoft che lavori sull'OS non pu˛ cavarsi uno sfizio che ha con Exel, nŔ uno sviluppatore di Exel pu˛ cavarsi il suo sfizio con l'OS -- gli ci vorrebero mesi per immaginare come costruire & correggere & installare, e probabilmente non potrebbe comunque ottenere accesso a sorgenti adeguate"

"" Le persone devono lavorare alle loro parti indipendentemente dal resto , cosý le astrazioni interne fra i componenti sono ben documentate e ben esposte/esportare e anche pi¨ robuste perchÚ non sanno come saranno chiamate. Il sistema di sviluppo Linux si Ŕ evoluto in ci˛ concedendo a pi¨ parti di partecipare senza causare il numero enorme di edizioni di integrazione perchÚ la robustezza Ŕ presente ad ogni livello. Questa Ŕ una grande cosa, di lunga durata, per la stabilitÓ generale, e si vede. " "

Il trucco, naturalmente, Ŕ di accapparrarsi questi benefici senza incorrere nei costi dei procedimenti OSS. Questi costi sono il tipico motivo per cui si ersero tali barriere in primo luogo:

Estendere i benefici OSS -- Infrastruttura del servizio

Sostenere una comunitÓ di piattaforma & sviluppo richiede una grande infrastruttura di servizio che OSS non pu˛ fornire. Questa include PDC's, MSDN, ADCU, ISVs, IHVs, ecc.

L'equivalente "MSDN" delle comunitÓ OSS, naturalmente, Ŕ una libera confederazione di siti web con docs API di varia qualitÓ. MS ha l'opportunitÓ di sfruttare realmente il web per l'evangelizzazione degli sviluppatori.

Attutire gli attacchi di OSS

In generale, Microsoft pu˛ vincere attaccando i punti deboli dei progetti OSS.

De-standardizzare protocolli & applicazioni

I progetti OSS sono stati in grado di conquistare un punto d'appoggio in molte applicazioni server grazie al grande vantaggio dato da protocolli altamente standardizzati e semplici. Estendendo questi protocolli e sviluppandone di nuovi, possiamo respingere l'accesso dei progetti OSS nel mercato.

David Stutz fa un'osservazione molto buona: nel competere con il livello di integrazione dei desktop Microsoft, "i protocolli standardizzati diventano a tutti gli effetti mezzi di integrazione" per progetti OSS. Una gran quantitÓ di IQ viene spesa in gruppi di lavoro IETF che stanno creando velocemente il modello architettonico di integrazione per questi progetti OSS.

{ CioŔ, i protocolli aperti devono essere messi sotto chiave e l'IETF deve essere schiacciato allo scopo di ``de-standardizzare protocolli & applicazioni'' e fermare il software open-source.

Ancora una volta, la migliore risposta dei sostenitori di open-source sta nel sottolineare agli utenti che quando le cose sono ``de-standardizzate'', i venditori ci guadagnano e i clienti ci perdono. }

Alcuni esempi di iniziative Microsoft che stanno estendendo i protocolli standardizzati includono:

Costringere l'integrazione -- specialmente nel server

L'aumento dei server specializzati Ŕ una minaccia particolarmente spaventosa e potente che affligge direttamente il flusso delle nostre entrate. Una delle chiavi per combattere questa minaccia sta nella creazione di scenari integrativi che siano utili sulla piattaforma server. David Stutz precisa:

La questione base qui Ŕ che chi ha le migliori tecnologie e procedure di integrazione orientate verso la rete vincerÓ nel business standard dei server. C'Ŕ una convergenza di sistemi connessi, connettivitÓ mobile, e di diffusione dei protocolli di rete che farÓ esplodere il numero dei server (specialmente "server specializzati"??). Il cliente di prodotti ad uso generale dÓ un giro d'affari in cui vale la pena essere presenti - sarÓ schiacciato dai server di prodotti specifici?

CredibilitÓ organizzativa

Altri link interessanti

Ringraziamenti

Molte persone hanno fornito dati, riletture, interessanti email, e analisi sia su questo documento che sull'analisi di Linux:

Nat Brown

Jim Allchin

Charlie Kindel

Ben Slivka

Josh Cohen

George Spix

David Stutz

Stephanie Ferguson

Jackie Erickson

Michael Nelson

Dwight Krossa

David D'Souza

David Treadwell

David Gunter

Oshoma Momoh

Alex Hopman

Jeffrey Robertson

Sankar Koundinya

Alex Sutton

Bernard Aboba

 

Cronologia della revisione

Data

Revisione

Commenti

8/03/98

0.95

 

8/10/98

0.97

Inizio della revisione

Aggiunti i commenti di JoshCo

8/11/98

1.00

Alcune correzioni, stampate copie per la revisione di PaulMa