Vinod Valloppillil (VinodV)

Aug 11, 1998 -- v1.00

Microsoft Confidential

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.

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.

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.

L'ampia categoria di licenze include:

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:

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

Fondazione Free Software / Progetto GNU

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).

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

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à.

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. }

Alcune delle caratteristiche chiave dei gruppi OSS spinti da Internet:

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.

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. }

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:

La cattedrale e il bazaar

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

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

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

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

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

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.

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:

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:

Messa in un altro modo:

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.

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):

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.

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:

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.

Da "Homesteading on the Noosphere":

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.

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.

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:

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

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

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.

OSS è credibile nel lungo periodo

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

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.

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.

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)

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.

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.

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.) }

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.

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

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:

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?

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.

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.

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.

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

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ù.

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. }

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.

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.

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.

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

Strategic Futures

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?"

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.

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

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).

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.

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.

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:

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.

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:

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

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

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.

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.

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à

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.

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.

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.

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

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

Leadership:

Soluzione delle dispute:

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.

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.

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:

Alcuni altri progetti OSS:

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.

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:

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.

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

Alcune idee di partenza includono:

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 è:

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:

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.

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.

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:

Credibilità organizzativa

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