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: