La maggior parte degli sviluppatori Open Source ha accolto quest'attenzione con molto favore: non solo per orgoglio, ma anche perché consente loro di giustificare di fronte a colleghi e dirigenze i loro sforzi (ora sempre più collegati ai loro compensi).

Questo pubblico nuovo, tuttavia, pone domande imbarazzanti:

• Si tratta davvero di un modo nuovo di creare software?
• Ognuno dei successi nel campo Open Source è un caso fortuito o esiste una metodologia replicabile?
• Perché mai destinare le mie risicate risorse finanziarie a un progetto in cui i miei concorrenti finirebbero per usare il mio stesso codice, e gratis?
• In che misura tutto questo modello di sviluppo si appoggia sulla figura dell'hacker della domenica o dello studente d'informatica che ha avuto la fortuna di combinare insieme i bit giusti per far funzionare qualcosa?

La mia idea è che il modello Open Source sia davvero un modello affidabile per la conduzione dello sviluppo software a scopi commerciali. Cercherò di esporre le condizioni preliminari per un progetto simile, a quali tipi di progetto questo modello si adatti e quali passi dovrebbe fare un'azienda per lanciare un progetto Open Source. Questo saggio vuole indirizzarsi alle società che rilasciano, vendono e supportano commercialmente software o alle società che usano certe parti software come componenti fondamentali nei loro processi di business.

È tutta una questione di piattaforme
Per quanto io sia un accanito fan dell'approccio Open Source allo sviluppo del software, ammetto senz'altro l'esistenza di situazioni in cui le parti in causa non vi troverebbero vantaggi. Il modello implica notevoli compromessi e il ritorno non è mai garantito. Un'analisi accurata vuole che ci si chieda quali siano gli obiettivi a lungo termine dell'azienda e quali i vantaggi competitivi di cui essa dispone oggi.

Esaminiamo per prima cosa le Application Programming Interfaces (API), le piattaforme e gli standard. Per la comodità di questo saggio riunirò nel termine generico "piattaforma" le API (come il server API di Apache per la costruzione di moduli personalizzati), i protocolli on-line come l'HTTP e le convenzioni dei sistemi operativi (quali il modo in cui Linux organizza i file di sistema, o quello in cui sono amministrati i server NT).

Win32, la raccolta di routine e risorse offerte e definite da Microsoft per tutti gli sviluppatori di applicazioni per Windows 95 e NT, è una piattaforma. Se volete scrivere un'applicazione eseguibile su Windows, dovete usare questa API. Se volete, come ha fatto una volta IBM con OS/2, scrivere un sistema operativo che possa eseguire programmi creati per MSWindows, dovrete implementare l'API Win32 nella sua interezza, perché è quella che le applicazioni Windows si aspettano di poter usare.

Allo stesso modo è una piattaforma la CGI, Common Gateway Interface. La specifica CGI permette agli sviluppatori di server Web di scrivere script e programmi che si eseguono al di sotto di un server Web. La CGI è una piattaforma assai più semplice di Win32, e di conseguenza in grado di fare molto meno, ma la sua esistenza è stata cruciale per il mercato dei server Web perché ha permesso agli sviluppatori di applicazioni di scrivere codice portabile, programmi eseguibili sotto qualunque server Web. Una differenza-chiave fra CGI e Win32, a parte alcuni ordini di magnitudine nella complessità, era che nessuno deteneva la proprietà della specifica CGI: essa era semplicemente qualcosa che i principali server Web implementavano per poter eseguire gli script CGI degli altri server. Solo dopo parecchi anni che la CGI era in uso si ritenne fosse il caso di stilarne una specifica informativa in forma di RFC (Request For Comments) presso la IETF (Internet Engineering Task Force).

Una piattaforma è quanto definisce un software nella sua essenza: qualunque software, sia esso un browser come Netscape oppure Apache. Le piattaforme permettono di costruire o di usare un pezzo di software sopra un altro e sono dunque essenziali non solo nello spazio Internet, dove piattaforme comuni come HTTP o TCP/IP hanno veramente favorito la crescita esplosiva di Internet, ma stanno diventando di valore sempre più essenziale nell'ambito di qualsiasi ambiente informatico, nel contesto server come in quello dell'utente finale.

Nel progetto Apache abbiamo avuto la fortuna di sviluppare molto per tempo un'API interna che ci consentisse di distinguere fra le funzionalità server fondamentali (gestione delle connessioni TCP, del processo-figlio e delle richieste HTTP di base) e quasi tutte le altre funzionalità di più alto livello, come il logging, un modulo per CGI, gli acclusi server-side, la configurazione di sicurezza, ecc. Un'API potente ci ha anche permesso di rinunciare ad altri pezzi ingombranti di funzionalità, come il mod_perl (un modulo Apache che include un interprete Perl in Apache) e il mod_serv (che implementa l'API dei servlet Java), e di formare gruppi di sviluppatori dedicati. Questo ha liberato il gruppo centrale di sviluppo dalla preoccupazione di costruire un "mostro" per supportare questi grandi sforzi, in aggiunta al dover mantenere e migliorare il nucleo del server.

Esistono strategie commerciali costruite sul modello di possesso delle piattaforme software. Tali strategie possono richiedere pagamenti per qualsiasi uso di queste piattaforme, sulla base di un'installazione software standard o secondo l'uso (pay-per-use) o magari secondo qualche altro modello. Qualche volta le piattaforme sono gravate da copyright; altre volte offuscate dalla mancanza di una descrizione scritta per l'uso pubblico; altre ancora sono evolute così velocemente, spesso per ragioni non tecniche, che chiunque altro tenti di fornire tali piattaforme non riesce a tenerne il passo e viene quindi percepito dal mercato come "superato", tecnicamente parlando, anche quando la programmazione non c'entra.

Un tale modello di strategia commerciale, potenzialmente vantaggioso nel breve termine per la società titolare della piattaforma, lavora contro gli interessi di tutte le altre aziende del settore e contro il livello generale di evoluzione tecnologica. I concorrenti, anche quando dispongano di tecnologia superiore, di migliori servizi o di costi più bassi, non possono sfruttare questi vantaggi perché non hanno accesso alla piattaforma. Il rovescio della medaglia è che i clienti possono diventare dipendenti da una piattaforma e, all'aumentare dei prezzi, trovarsi a dover scegliere se pagare un po' di più al momento per rimanere su quella piattaforma, o spendere molto per passare a una piattaforma diversa, che li farà risparmiare sul lungo periodo.

I computer e l'automazione sono oggi una componente talmente essenziale dell'attività quotidiana che un'impresa commerciale accorta non dovrebbe dipendere da un unico produttore per la fornitura di servizi essenziali. Poter scegliere il servizio significa non solo avere libertà di scelta: una scelta deve anche essere economicamente abbordabile. Il costo di un cambiamento di sistema è un aspetto importante in questa libertà di scelta. E questo costo può essere ridotto al minimo se cambiare software non significa dover cambiare piattaforma. È dunque sempre nell'interesse dei clienti pretendere che il software che usano sia basato su piattaforme non proprietarie.

È un concetto, questo, che a molti risulta difficile da visualizzare, perché l'economia classica (la legge della domanda e dell'offerta che si insegna a scuola) si basa sulla nozione che i prodotti in vendita abbiano un costo relativamente scalabile e che, per vendere dieci volte tanto un prodotto, il costo delle materie prime per un produttore aumenti, di norma, anche nell'ordine delle dieci volte. Nessuno avrebbe potuto prevedere la spettacolare economia di scala mostrata dal software, la mancanza quasi completa di ogni correlazione diretta fra la quantità di sforzo richiesta da un prodotto software e il numero di persone che possono comprarlo e usarlo.

Un corpus di riferimento per il software open source che implementi un protocollo di connessione o un'API è più importante, per la salute a lungo termine di quella piattaforma, anche di due o tre implementazioni indipendenti non-open source. Perché questo? Perché un'implementazione commerciale può in ogni momento venir comprata da un concorrente e rimossa dal mercato in quanto possibile alternativa, distruggendo quindi la nozione che lo standard è indipendente. Può anche servire come quadro di riferimento accademico per comparare implementazioni e comportamenti.

Esistono organizzazioni come la IETF e il W3C (World Wide Web Consortium) che si sforzano, con risultati generalmente eccellenti, di mantenere un forum di discussione per lo sviluppo di standard multiparte. Queste organizzazioni riescono, in complesso, nell'intento di produrre architetture d'alta qualità secondo le necessità di Internet. Tuttavia, il successo a lungo termine di un dato standard e la diffusione dello stesso ricadono fuori della loro giurisdizione. Esse non hanno alcun mezzo per costringere i gruppi membri a creare software che implementino i protocolli che loro definiscono con tanta precisione. L'unica soluzione, a volte, è dunque ricorrere a un corpus di riferimento che dimostri perché una certa implementazione sia corretta.

Per esempio, nel dicembre del 1996 AOL effettuò una lieve modifica nei server proxy usati dai suoi clienti per accedere ai siti Web. Questo "upgrade" non mancava di un piccolo risvolto politico molto intelligente: quando gli utenti di AOL accedevano a un sito Web che usasse un server Apache 1.2, che all'epoca aveva pochi mesi di vita e che implementava la nuova specifica HTTP/1, trovavano a dar loro il benvenuto il seguente messaggio, altamente informativo:

VERSIONE WEB NON SUPPORTATA

L'indirizzo Web richiesto non è disponibile in una versione supportata da AOL. Il problema è di pertinenza del sito Web, non di AOL. Il titolare di questo sito usa un linguaggio HTTP non supportato. Se ricevete spesso questo messaggio, potete impostare le vostre preferenze per la grafica Web su COMPRESSED alla keyword: PREFERENCES

Allarmato da questo "upgrade", il nucleo centrale di sviluppo di Apache dispose i carri in cerchio e analizzò la situazione. Una richiesta al team tecnico di AOL produsse la seguente delucidazione:

I nuovi server Web HTTP/1.1 stanno cominciando a generare risposte HTTP/1.1 a richieste HTTP/1.0, anziché generare solo risposte HTTP/1.0. Era nostra intenzione arginare questi errori perché non proliferassero e diventassero standard de facto, bloccandoli subito. Auspichiamo che gli autori di questi server Web modifichino il loro software affinché generi risposte HTTP/1.1 solo quando viene avanzata una richiesta HTTP/1.1.

Sfortunatamente, i progettisti di AOL stavano erroneamente presupponendo che le risposte HTTP/1.1 non fossero retrocompatibili con i client o i proxy HTTP/1.0. Lo sono, invece: HTTP è stato progettato per essere retrocompatibile con le versioni precedenti. Ma la specifica HTTP/1.1 è tanto complessa che una lettura non attenta e completa potesse indurre a credere che non fosse questo il caso, specialmente con il documento HTTP/1.1 circolante alla fine del 1996.

Così noi, sviluppatori Apache, dovemmo scegliere: fare dietro front e fornire risposte HTTP/1.0 a richieste HTTP/1.0, o seguire le specifiche. Roy Fielding, il "poliziotto HTTP" del gruppo, riuscì a mostrarci chiaramente che il comportamento del software era corretto e vantaggioso: ci sarebbero stati casi in cui i client HTTP/1.0 avrebbero desiderato aggiornarsi a una conversazione HTTP/1.1 dopo aver scoperto che un server supportava la versione 1.1. Era anche importante rendere noto ai server proxy che, anche se vedevano che la prima richiesta che passavano a un server d'origine era 1.0, il server d'origine poteva supportare anche l'1.1.

Si decise che avremmo puntato le pistole contro AOL e chiesto che correggessero il loro software. Sospettavamo che la risposta HTTP/1.1 fosse in realtà causa di un problema col loro software, probabilmente dovuto più all'imprecisione della loro programmazione che a un cattivo progetto del protocollo. Dietro la nostra decisione avevamo la scienza. Quello che più importava era che, a quel punto, Apache girava sul 40% del server Web presente sulla Rete e Apache 1.2 su una consistente porzione degli stessi. AOL dovette pertanto decidere se correggere i propri errori di programmazione o comunicare ai suoi utenti che circa il 20% o più dei siti Web su Internet sarebbero risultati inaccessibili attraverso i suoi proxy.

Il 26 dicembre 1996 pubblicammo una pagina Web esponendo la disputa nel dettaglio, e rendendone nota l'esistenza non solo ai nostri utenti ma a molti importanti organi d'informazione, quali C|Net e Wired, per giustificare le nostre azioni.

AOL decise di correggere il software. Più o meno nello stesso periodo annunciammo la disponibilità di una patch per i siti che volevano aggirare il problema di AOL finché questo non fosse stato risolto; una patch che degradava a HTTP/1.0 le risposte per AOL. Fummo chiari nel dire che questa sarebbe rimasta una patch non ufficiale e non supportata, e che non avrebbe costituito un setting di default nella distribuzione ufficiale.

Si sono verificati molti altri casi in cui produttori di software HTTP (fra gli altri Netscape e Microsoft) hanno rilevato problemi d'interoperabilità con Apache; in molti di questi casi si è imposta una scelta fra correggere il bug o rendere inutilizzabili molti siti. A volte un produttore implementava non correttamente il protocollo, ma conforme ai propri client e server, dando luogo a un'implementazione che funzionava a dovere sui prodotti, ma imperfettamente (a dir poco) su client e server realizzati da altri. La situazione è molto più subdola perfino di quella di AOL, poiché il bug potrà non apparire o non apparire significativo alla maggior parte degli utenti di questo software. Di qui, le ramificazioni a lungo termine di un simile bug (o la nascita di altri bug a complicare la situazione) possono passare inosservate finché non è troppo tardi.

Se non ci fosse un server Web di riferimento open source e diffusissimo come Apache, sarebbe del tutto comprensibile che queste leggere incompatibilità fossero cresciute l'una sull'altra e si fossero stratificate, nascoste sotto il biasimo reciproco o sotto trucchetti mentali da Jedi ("Non è riproducibile in laboratorio..."), e dove la risposta al problema: "non riesco a connettere il browser di X al server di Y" sarebbe stata semplicemente "beh, usa il client di Y e andrà tutto a posto". Al termine di questo processo ci saremmo ritrovati due o più World Wide Web, uno costruito sui server di X, l'altro sui server di Y, ciascuno funzionante solo con i client dei rispettivi produttori. Ci sono numerosi precedenti storici per questo tipo di attività anti-standard, una politica ("chiusura") codificata come pratica commerciale fondamentale da molte società di software.

Naturalmente, questo avrebbe significato la rovina per tutti gli altri soggetti in causa: fornitori di contenuti, fornitori di servizi, sviluppatori di software e chiunque dovesse usare l'HTTP per comunicare avrebbero dovuto mantenere la propria offerta su due distinti server. A dispetto della pressione degli utenti tecnici per "mettersi d'accordo", la pressione contraria del marketing a "innovare, differenziare, primeggiare nel settore, definire la piattaforma" avrebbe trattenuto entrambe le parti dal tentare di liberare i loro protocolli dagli obblighi del marchio proprietario.

Una situazione analoga la vediamo nel caso del JavaScript client-side. Tale era la differenza di comportamento fra i vari browser, e perfino fra diverse versioni beta dello stesso browser, che gli sviluppatori hanno dovuto creare un codice per riconoscere le diverse revisioni e assegnare loro comportamenti diversi: la cosa ha allungato in modo significativo i tempi di sviluppo delle pagine che adoperano il JavaScript. Si è dovuto pertanto attendere che il W3C prendesse una posizione ufficiale e gettasse le basi per un Document Object Model (DOM) perché si potesse vedere un tentativo autentico e serio di creare uno standard multiparte intorno al JavaScript.

Esistono forze naturali, nel mondo moderno degli affari, che spingono alla deviazione quando una specifica è implementata da un software chiuso. Anche un errore accidentale di lettura di una specifica comune può causare una deviazione, se non viene corretto all'istante.

Per questo dico che costruire servizi o prodotti fondandoli su piattaforme basate su standard è un bene per la stabilità dei processi di business. Il successo di Internet non ha mostrato solo come le piattaforme comuni contribuiscano a facilitare le comunicazioni, ma ha anche forzato le aziende a pensare di più a come creare valore in quanto viene comunicato, piuttosto che cercare di ricavare valore dalla rete in sé.

Analizzare gli obiettivi per un progetto open source
Quello che dovreste chiedervi, come società, è a che livello i vostri prodotti implementino una nuova piattaforma e fino a che punto è nel vostro interesse mantenere la proprietà di quella piattaforma. Quanto della vostra offerta di prodotti e servizi, quanto delle vostre entrate, si trova sopra o sotto quella piattaforma? Ecco qualcosa che potete probabilmente esprimere in cifre.

Poniamo che siate una azienda produttrice di database. Vendete un database che funziona su diversi sistemi operativi e, separatamente, anche pacchetti per l'amministrazione tramite interfaccia grafica, strumenti di sviluppo rapido, una libreria di procedure comuni a uso degli utenti, ecc. Fornite assistenza su base annua. Gli upgrade richiedono un nuovo acquisto. Offrite anche corsi. Infine, avete una squadra di consulenza consistente e in crescita che implementa il database per i clienti.

Supponiamo che il bilancio delle vostre entrate si presenti più o meno così:

• 40% - Vendite del software di database
• 15% - Assistenza
• 10% - Consulenza
• 10% - Strumenti di sviluppo rapido
• 10% - Strumenti di amministrazione grafici
• 10% - Librerie di procedure/applicazioni basate sul database
• 5% - Manuali/corsi

A prima vista, l'idea di distribuire gratuitamente il database suona assurda. Significherebbe buttar via il 40% delle vostre entrate. Se siete una società fortunata sarete in profitto, e se siete ancora più fortunati questo margine di profitto sarà forse del 20%. La rinuncia a quel 40% spazzerebbe via tutto.

Ciò, ovviamente, presupponendo che nessun altro fattore dell'equazione cambi. Ma ci sono invece buone probabilità, se giocate bene le vostre carte, che le cose cambino. I database non sono quel genere di applicazione che le aziende prendono da uno scaffale a CompUSA, infilano nel CD drive delle loro macchine e non ci pensano più. Tutte le altre voci d'entrata restano valide e necessarie, senza relazione con il prezzo dell'OS. Infatti, aumentare il prezzo di questi servizi aggiuntivi è adesso possibile più di un tempo, quando il costo del software divorava quasi per intero il prezzo che un consumatore pagava comprando un software di database.

Quindi, in parole povere, se la distribuzione a basso prezzo (o addirittura gratuita) del database portasse il database a raddoppiare la sua base di utenti, e se gli utenti fossero motivati quanto lo erano prima ad acquistare dalla vostra società consulenza, assistenza, strumenti di sviluppo, librerie eccetera, si vedrebbe un incremento del 20% nelle entrate complessive. La cosa più probabile è che al vostro software si avvicini quattro o cinque volte il numero dei clienti che già avevate e, mentre le entrate relative ad altri servizi diminuiranno, vuoi perchè molti utenti si accontenteranno della versione gratuita, vuoi perchè alcuni concorrenti offriranno i medesimi servizi per il vostro software, le entrate complessive della vostra azienda saranno quasi certamente aumentate, a patto però che gli introiti legati a tali servizi non diminuiscano eccessivamente.

Ancora, a seconda della licenza usata, potreste abbassare il costo di sviluppo del software. Vi capiterà di trovare clienti motivati che correggono da sé i bug, per esempio, e nuove innovazioni da parte di clienti che offrono il loro codice al progetto perché desiderano che venga mantenuto come parte standard della distribuzione complessiva. Nel complesso, i vostri costi di sviluppo dovrebbero diminuire.

È anche probabile che, data una miscela prodotto/servizi come quella sopra descritta, il rilascio gratuito del progetto non aiuterà i vostri concorrenti ad essere competitivi nei vostri spazi di reddito. Ci sono probabilmente già dei consulenti che compiono lavoro d'integrazione con i vostri strumenti; autori indipendenti di manuali; librerie di codice realizzati da altre aziende. La disponibilità del codice sorgente aiuterà marginalmente la concorrenza nel fornire assistenza al vostro codice, ma voi, in qualità di sviluppatori originali, avrete nel vostro marchio una risorsa nascosta contro la quale gli altri dovranno confrontarsi.

Va da sé che non sono tutte rose e fiori. Questo processo implica dei costi che sarà difficile legare direttamente alle entrate. Per esempio, il costo dell'infrastruttura a supporto di questo sforzo, pur poco significativo di per sé, può gravare sull'amministrazione del sistema e lo staff dell'assistenza. Calcolate anche il costo per le comunicazioni degli sviluppatori con altri sviluppatori esterni all'azienda e le spese generali extra per sviluppare il codice in modo pubblico. Un costo rilevante può essere rappresentato dalla preparazione del codice per un minuzioso esame da parte del pubblico. E dopo tutto questo lavoro, potrà capitare che non ci sia "richiesta di mercato" per il vostro prodotto come freeware. Il resto di questo saggio si propone di affrontare questi punti.

Valutazione della richiesta di mercato per un prodotto
Un'azienda può essere tentata di guardare all'Open Source come a un modo di salvare un certo progetto, di guadagnare notorietà o semplicemente di trovare un buon pretesto per abbandonare una categoria di prodotti. Nessuna di queste è una buona ragione per lanciare un progetto Open Source. Se una società intende perseguire questo modello seriamente, deve fare le sue ricerche per determinare con precisione che cosa il prodotto debba essere perché una strategia Open Source abbia successo.

Il primo passo è condurre un'analisi sulla competitività del mercato, per identificare sia i concorrenti commerciali che quelli freeware, non importa quanto piccoli siano. Fate molta attenzione a determinare esattamente quello che il vostro prodotto offre, suddividendo la vostra offerta in componenti, blocchi separabili che possano potenzialmente essere raccolti, venduti o resi Open Source uno per uno. Analogamente, non escludete combinazioni di freeware e software commerciale che offrano le stesse funzionalità.

Riprendiamo l'esempio del database, immaginando che il database del produttore si componga di fatto di tre elementi: un server SQL di base; un gestore del logging di backup/transaction; una libreria per sviluppatori. Un tale produttore dovrebbe paragonare l'offerta dei suoi prodotti non solo con quella dei giganti come Oracle e Sybase, non solo con quella dei concorrenti commerciali più piccoli ma in crescita, come Solid e Velocis, ma anche con database freeware come MySQL e Postgres. Tale analisi potrebbe portare alla conclusione che il server SQL di base dell'azienda non fornisca che poche funzioni in più rispetto a MySQL, e in un'area che non è mai stata considerata di vantaggio competitivo ma meramente una caratteristica necessaria a tenere il passo con gli altri produttori di database. Il gestore del logging di backup/transaction non ha rivali freeware e la libreria per sviluppatori è surclassata dalle utility Perl DBI, ma ha poca concorrenza nel comparto Java o C.

Quest'azienda potrebbe allora considerare le strategie seguenti:

1. Rimpiazzare il server SQL di base con MySQL, e quindi pacchettizzare le funzionalità del server SQL di base e il gestore del logging di backup/transaction, e vendere le librerie Java/C fornendo allo stesso tempo supporto alla libreria Perl gratuitamente. In questo modo si cavalcherebbe l'onda generata dal pacchetto MySQL e l'incredibile libreria di codice add-on e moduli plug-in disponibili per MySQL. Ciò vi permetterebbe anche di mantenere riservata ogni porzione di codice che abbiate ragione di ritenere possa avere brevetti o codice brevettabile, o che semplicemente vi paia buona abbastanza per rappresentare un vantaggio competitivo. Proponetevi dunque al mercato come un'azienda che può scalare MySQL per usi più ampi.
   
   
2. Assegnare a MySQL le "funzionalità extra" del server SQL di base e quindi riprogettare il gestore del logging di backup/transaction per venderlo come prodotto separato che funzioni su una varietà di database, sia pure con una preferenza per MySQL. Quest'ultimo ha una redditività minore, ma vi permette, come azienda, di concentrarsi sui propri obiettivi e di aumentare il numero dei propri clienti. Un prodotto del genere potrebbe anche essere più facile da supportare.
   
   
3. Prendete la strada opposta: mantenete una strategia di prodotto commerciale per il server SQL di base e per le librerie, ma fate del gestore del logging di backup/transaction un'utility generale open source per un'ampia gamma di database. Questo contribuirebbe a tagliare i costi di sviluppo per questa componente e generare un traino di mercato per il vostro database commerciale. Sottrarrebbe anche un vantaggio competitivo che alcuni vostri concorrenti potrebbero avere dall'open source (ma ne sottrarrebbe però anche a voi).
   
   Sono tutti approcci validi. Eccone un altro:
   
   
4. Rendete open source l'intero server di base come prodotto a sé, separato da MySQL o da Postgres o da qualunque altro pacchetto esistente, e fornite per esso assistenza a pagamento. Vendete lo strumento di backup/logging come software standard, non open source, ma offrite invece i sorgenti delle librerie di sviluppo per incoraggiare i nuovi utenti. Questa strategia comporta rischi maggiori, dal momento che pacchetti popolari come MySQL o Postgres sono di solito in circolazione da un bel po' di tempo ed è molto radicata negli sviluppatori l'avversione a cambiare un database, se quello che usano funziona bene. Per convincerli, dovreste riuscire a dimostrare un vantaggio significativo sui programmi comunemente usati. Il vostro prodotto dovrà essere decisamente più veloce, più flessibile, più facile da amministrare e da programmare oppure contenere funzioni tanto nuove da motivare gli utenti a provarlo. Dovrete anche spendere molto più tempo per suscitare interesse nel prodotto, e dovrete probabilmente anche trovare la maniera di distogliere i programmatori dai prodotti concorrenti.

Personalmente sconsiglierei quest'ultimo approccio nelle circostanze descritte, visto che MySQL parte davvero avvantaggiato, con moltissimi add-on e una base di utenti piuttosto ampia.

Tuttavia, di tanto in tanto un progetto open source marca il passo, o perché il team principale di sviluppo non sta sviluppando attivamente, o perché il software s'imbatte in problemi architetturali che gli impediscono di soddisfare richieste nuove, o semplicemente perché l'ambiente in cui una richiesta era nata s'inaridisce o cambia obiettivo. Quando ciò accade, e diventa chiaro che la gente è alla ricerca di alternative, c'è la possibilità d'introdurre un rimpiazzo che attirerà l'attenzione, anche se non rappresenterà immediatamente un progresso significativo dello stato delle cose.

L'analisi della domanda è essenziale poiché di solito è la domanda che crea nuovi progetti open source. Apache nacque quando un gruppo di webmaster, che si passavano l'un l'altro patch per il Web server NCSA, a un certo punto decisero che questa specie di scambio delle figurine era una pratica poco efficiente e soggetta a errori, e scelsero dunque di operare una distribuzione separata del server NCSA con le loro patch incorporate. Nessuno dei protagonisti di quei giorni lontani si trovò coinvolto perché voleva vendere un server commerciale con Apache come base, anche se si tratta certo di una ragione validissima.

L'analisi della domanda di mercato per un particolare progetto open source implica dunque che si frequentino le mailing list e i forum di discussione pertinenti, che si scandaglino gli archivi dei newsgroup, che chieda a clienti e concorrenti; solo allora sarà possibile stabilire realisticamente se esiste qualcuno disposto a contribuire allo sviluppo del vostro progetto.

Tornando agli albori di Apache: quelli fra noi che si scambiavano le patch, le mandavano anche alla NCSA, sperando che sarebbero state incorporate, o almeno che la loro esistenza venisse riconosciuta, per essere rassicurati sul fatto che avremmo potuto compiere l'upgrade senza problemi all'uscita della successiva release. Ma la NCSA aveva ricevuto un duro colpo quando i primi programmatori del server le erano stati portati via da Netscape; i programmatori rimasti non potevano far fronte all'inondazione di email. Costruirci il nostro server fu quindi un risultato dell'istinto di conservazione più che della volontà di creare il futuro grande server Web. È importante avere obiettivi contenuti quando si comincia, perché li si può raggiungere senza troppe difficoltà e non si deve dipendere dal fatto che il progetto arrivi a dominare il mercato per trarre qualche vantaggio dall'approccio.

La posizione dell'Open Source nello spettro del software
Per determinare a quali parti della vostra linea di prodotti, o a quali componenti di un dato prodotto, applicare il modello open source, può essere utile svolgere questo semplice esercizio. Cominciate col tracciare una linea che rappresenti uno spettro. A sinistra scrivete "Infrastrutturale", cioè il software che implementa le struttura di supporto e le piattaforme, giù fino al TCP/IP e al kernel e perfino all'hardware. A destra scrivete "Applicazioni per l'utente finale", cioè gli strumenti e le applicazioni che verranno usate dall'utente medio, non tecnico. Lungo questa linea disegnate dei punti rappresentanti, in termini relativi, le zone in cui ritenete si collochi ognuna delle componenti del vostro prodotto. Dall'esempio fatto sopra, i front-end GUI (a interfaccia grafica) e gli strumenti di amministrazione si troveranno all'estrema destra, mentre il codice che gestisce i backup sarà all'estrema sinistra. Le librerie di sviluppo saranno poco a destra del centro, le risorse SQL di base poco a sinistra. A questo punto potrete inserire i prodotti dei concorrenti, divisi anch'essi nelle loro componenti, usando, se siete veramente creativi, colori diversi per distinguere le offerte gratuite da quelle commerciali. Il risultato sarà molto probabilmente che l'offerta gratuita tenderà a raggrupparsi verso sinistra, quella commerciale verso destra.

Il software open source si è sempre posizionato più verso l'estremità infrastrutturale/ back-end dello spettro del software così rappresentato, e questo per diversi motivi:

• Le applicazioni per gli utenti finali sono difficili da scrivere, non solo perché il programmatore deve gestire un ambiente grafico a finestre in mutamento continuo, non standard e pieno di bug in ragione della sua stessa complessità, ma anche perché i programmatori, con qualche insigne eccezione, non sono di solito dei buoni progettisti di interfacce grafiche.
• Per tradizione, il software open source ha sempre dominato nelle porzioni di codice relative al networking e ai sistemi operativi.
• L'Open Source prospera dove i cambiamenti incrementali sono ricompensati; storicamente, questo significa sistemi back-end più che front-end.
• Molto del software open source fu scritto da progettisti per risolvere compiti che si presentavano loro durante lo sviluppo di software o servizi commerciali; il loro primo pubblico furono dunque altri progettisti.

Ecco perché vediamo consistenti offerte open source nell'ambito dei sistemi operativi e dei servizi di rete, e molto pochi, invece, nell'ambito delle applicazioni per desktop.

Non mancano certamente eccezioni. Esempio illustre è GIMP, o GNU Image Manipulation Program, un programma per X11 paragonabile per ricchezza di funzionalità a Photoshop di Adobe. È vero però che, in un certo senso, anche questo prodotto è uno strumento "infrastrutturale", una piattaforma, dal momento che deve il suo successo alla sua meravigliosa architettura a plug-in e alle dozzine e dozzine di plug-in che sono stati sviluppati e che permettono di importare ed esportare molti diversi formati di file e che implementano centinaia di effetti-filtro.

Date un'altra occhiata allo spettro che avete disegnato. A un certo punto, potete osservare la vostra offerta nel contesto di questi concorrenti e tracciare una linea verticale. Questa linea denota la separazione fra il vostro spazio Open Source e quello che decidete di mantenere proprietario. Questa stessa linea rappresenta la vostra vera piattaforma, la vostra interfaccia fra il codice pubblico che state cercando di affermare come standard, a sinistra, e il codice proprietario per il quale volete stimolare la domanda, a destra.

La natura aborre il vuoto
Qualunque software commerciale all'interno di un ambiente altrimenti completamente open source, è una forte motivazione a sviluppare da zero il software in un ambiente realmente "pubblico". Come avviene in natura, quando esiste una barriera commerciale tra due validi software open source, il desiderio di oltrepassare l'ostacolo porta a creare un "ponte" che li colleghi. Questo è vero perché ogni divario può essere colmato e superato a patto di disporre delle risorse necessarie; se questo divario è abbastanza piccolo perché la vostra azienda possa colmarlo ricorrendo al suo solo team di sviluppo, sarà probabilmente abbastanza piccolo perché venga colmato anche un gruppo di sviluppatori motivati.

Torniamo all'esempio del database: poniamo che decidiate di rendere pubblico il codice sorgente del vostro server SQL di base (o del codice avanzato che avete posto sopra MySQL), ma anche che abbiate deciso di guadagnare creando un driver commerciale, senza distribuirne i sorgenti, per collegare quel database a un server Web per creare contenuti dinamici. Avete stabilito che il database sarà l'elemento economicamente in perdita del prodotto, bilancerete aumentando i margini di guadagno sulla componente.

Dal momento che connettere database ai server Web è cosa assai comune e auspicabile, gli sviluppatori non potranno prescindere da voi oppure dovranno trovare un altro sistema per accedere al database dal sito Web. Ogni sviluppatore sarà motivato dall'idea di risparmiare il denaro che altrimenti dovrebbe pagarvi. Se un numero sufficiente di sviluppatori unisce le forze per ripagarsi del tempo impiegato per questo lavoro, o se capita che un solo capace sviluppatore non possa permettersi il plug-in ma voglia usare quel database, è possibile che un bel mattino, svegliandovi, troviate un concorrente open source alla vostra offerta commerciale, e ciò eliminerà completamente il vantaggio di possedere l'unica soluzione per quel compito.

Questa non è che una parte di un quadro più ampio: dipendere, per il proprio guadagno, da codice sorgente proprietario in prodotti strategici, è diventato un'impresa rischiosa. Se siete in grado di trarre profitto supportando la combinazione server Web + plug-in + database, o fornendo un'interfaccia per la gestione complessiva di quel sistema, sarete protetti contro sorprese di questo tipo.

Non tutto il software commerciale si presenta così vulnerabile: è una particolare caratteristica di quello che cerca di inserirsi in una nicchia direttamente fra due offerte open source consolidate. Collocare la vostra offerta commerciale come aggiunta al set corrente di offerte open source è una strategia più solida.

Lo regalo o me lo tengo?
In molte delle categorie software standard è presente software open source, specialmente in quelle rivolte ai server. Troviamo, ovviamente, sistemi operativi ma anche server Web, server di posta (SMTP, POP, IMAP), server di news (NNTP) e server DNS, linguaggi di programmazione (il collante dei contenuti dinamici sul Web), database, codice di networking di ogni sorta. Sui desktop abbiamo editor di testo come Emacs, Nedit e Jove, sistemi a finestre come Gnome e KDE, browser Web come Mozilla, e salvaschermo, calcolatrici, programmi di gestione di conti bancari, PIM, client di posta, strumenti di imaging... la lista potrebbe continuare. Non tutte le categorie hanno la loro killer application, tipo Apache o Bind, ma non sono davvero molte le nicchie commerciali che non dispongano, almeno dove non esista una nascente proposta alternativa open source. Questo è molto meno vero per la piattaforma Win32 di quanto non lo sia per Unix o Macintosh, soprattutto perché la cultura open source non ha adottato tale piattaforma in quanto non abbastanza "aperta" per costruirvi sopra seriamente.

C'è una ragione valida che consiglia di approfittare, quando un pacchetto open source in una categoria si sovrappone alla vostra potenziale offerta, donando il vostro codice aggiuntivo o altri miglioramenti al progetto esistente per mirare a un ritorno sotto forma di un codice complessivamente di miglior qualità, di una spinta nell'ambito marketing o dell'istituzione di una piattaforma comune. Nel valutare l'opportunità di una simile strategia bisogna fare attenzione ai termini della licenza:

• I termini della licenza per il pacchetto in questione sono compatibili con i vostri obiettivi a lungo termine?
• Potete aggiungere il vostro codice entro i limiti legali della licenza?
• La licenza dà incentivo sufficiente ai futuri sviluppatori? Se non lo fa, gli sviluppatori potrebbero venirvi incontro modificando la licenza?
• Il vostro contributo è di carattere abbastanza generale per interessare gli sviluppatori e gli utenti del progetto esistente? Se si limitano a implementare un'API nel vostro codice proprietario, probabilmente non verranno accettati.
• Se il vostro contributo è rilevante, potrete avere uno status pari a quello degli altri sviluppatori, in modo di poter applicare direttamente le correzioni ai bug e i miglioramenti che farete in seguito?
• Sono, gli altri sviluppatori, persone con cui potete realmente lavorare?
• Sono i vostri sviluppatori all'altezza di un lavoro in ambiente cooperativo?

Far contenti gli sviluppatori è probabilmente la sfida maggiore nel modello open source, una sfida che né l'impegno tecnologico né, a ben vedere, i soldi aiutano più di tanto a vincere. Ogni sviluppatore deve sentire di contribuire in modo positivo al progetto, deve sentirsi ascoltato; i suoi commenti sull'architettura e sulla progettazione devono essere valutati e rispettati, gli sforzi profusi nel codice ricompensati con l'integrazione nella distribuzione o, in caso contrario, con un rifiuto ottimamente argomentato.

Sbaglia chi dice: "Il modello open source funziona perché l'intera Internet diventa il vostro dipartimento di ricerca e sviluppo e la vostra assistenza". Di fatto, la quantità di sforzo disponibile per un dato set di compiti da parte di un programmatore di talento è di solito limitata. Così, è di solito nell'interesse di tutti se gli sforzi di sviluppo parallelo non s'intraprendono al solo scopo di evitare dispute semantiche fra sviluppatori. D'altra parte, si ha un'evoluzione più efficiente quando soluzioni alternative sono in gara per aggiudicarsi le risorse. Non sarà quindi un male avere due soluzioni in gioco nella medesima nicchia, se solo il talento in gioco pareggia la massa critica; una soluzione potrebbe contenere un'innovazione non contemplata nell'altra.

La concorrenza ha dato prova della sua utilità nel campo dei server SMTP. Il programma "Sendmail" di Eric Allman ha rappresentato a lungo lo standard per i "daemon" STMP presenti su ogni sistema operativo. Sono comparsi poi altri concorrenti open source, come Smail o Zmailer, ma il primo ad aver fatto veramente breccia sugli utenti è stato il pacchetto Qmail di Dan Bernstein. Quando Qmail si è presentato sulla scena, Sendmail aveva vent'anni e cominciava a dimostrarli; per giunta, non era progettato per l'Internet degli anni Novanta, in cui i buffer overflow e la caduta del servizio sono diventati comuni come i temporali a Seattle. Qmail era rivoluzionario sotto diversi aspetti: progetto del programma, amministrazione, perfino la definizione di "comportamento corretto" per un server SMTP. Un'evoluzione del genere sarebbe stata altamente improbabile per il pacchetto Sendmail di Allman, non perché Allman e i suoi non fossero bravi programmatori o perché mancassero contributi di terze parti: è semplicemente che, a volte, ci vuole uno stacco netto per provare qualcosa di veramente nuovo e vedere se funziona. Per ragioni simili, l'IBM ha sovvenzionato lo sviluppo del daemon SMTP "SecureMailer" di Weiste Venema, che nel momento in cui scrivo sembra destinato a una buona popolarità. Lo spazio dei daemon SMTP è abbastanza ben definito e importante da supportare più di un progetto open source; solo il tempo può dire quale sopravviverà.

Bootstrapping
È essenziale alla salute di un processo open source che esso abbia un sufficiente impulso iniziale per essere in grado di evolvere e rispondere a sfide nuove. Niente è statico nel mondo del software e ogni componente principale richiede una costante opera di aggiornamento e miglioramento. Una delle grandi attrattive commerciali di questo modello è che riduce la quantità di sviluppo di ogni parte in causa; ma, perché la teoria si traduca in fatti, servono altri sviluppatori attivi.

Nel cercare di determinare che domanda ci sia per il vostro progetto, vi sarete probabilmente imbattuti in un certo numero di altre società e individui abbastanza interessati da formare un nucleo base di sviluppatori. Una volta decisa una strategia, proponetela con determinazione anche maggiore a questo nucleo, magari avviando a questo scopo una semplice mailing list di discussione, in cui niente sia ancora inciso nel marmo. È molto facile che dal gruppo emergano idee significative per il successo del progetto e una lista delle risorse che potranno contribuirvi. Per i progetti più semplici basterà che il gruppo s'impegni a provare il vostro prodotto e a rimanere nella mailing list di sviluppo. Tuttavia, per progetti più impegnativi, sarebbe bene valutare le dimensioni totali di questa base di risorse.

Quanto segue è la mia idea delle risorse minime per un progetto di media complessità, quale potrebbe essere la creazione di un comune plug-in di scelta e acquisto (del tipo "carrello della spesa") per un server Web, o di un nuovo tipo di daemon di rete che implementi un semplice protocollo. È anche compresa una descrizione dei ruoli richiesti e della competenze necessarie a ciascuno.

• Ruolo 1: supporto dell'infrastruttura. Configura e mantiene gli alias della mailing list, il server Web, il server di codice CVS (Concurrent Versioning System), il database dei bug, ecc.
  
  Avvio: 100 ore.
  
  Manutenzione: 20 ore alla settimana.
  
  
• Ruolo 2: "capitano" del codice: sorveglia quanto consegnato, è totalmente responsabile della qualità del codice implementato. Integra patch fornite da terze parti, correggendo tutti i bug o le incompatibilità che possono contenere. Questi compiti sono indipendenti da qualunque altro lavoro di sviluppo di cui egli sia responsabile.
  
  Avvio: 40-200 ore (a seconda del tempo richiesto per la sistemazione del codice per l'uso pubblico!).
  
  Manutenzione: 20 ore alla settimana.
  
  
• Ruolo 3: manutenzione del database dei bug: non intende essere "assistenza" gratuita, ma è importante che il pubblico abbia una maniera organizzata per segnalare bug e problemi agli sviluppatori del server. In ambito gratuito, gli sviluppatori non sono ovviamente neanche tenuti a rispondere a tutta la posta ricevuta; dovrebbero tuttavia sforzarsi di rispondere almeno alle osservazioni più rilevanti. Il responsabile dell'aggiornamento del database dei bug dovrebbe costituire la prima linea del supporto, colui che esamina regolarmente tutte le segnalazioni, che seleziona quelle più interessanti da inviare agli sviluppatori.
  
  Avvio: il tempo necessario per padroneggiare il codice.
  
  Manutenzione: 10-15 ore alla settimana.
  
  
• Ruolo 4: aggiornamento della documentazione e del sito Web: è una posizione spesso lasciata vacante nei progetti open source, rimessa ai progettisti o a chi desidera ardentemente contribuire senza essere un programmatore di grido; ma più spesso, rimane scoperta. Ma se intendiamo fare sul serio, le risorse dedicate a far sì che gli utenti non tecnici capiscano e apprezzino gli strumenti che usano sono essenziali per diffonderne l'uso; aiutano a ridurre le segnalazioni di bug o a rispondervi, quando si tratta di semplici fraintendimenti, e incoraggia altri a impadronirsi del codice e quindi a dare il proprio contributo in futuro. Un documento che descriva ad alto livello l'architettura interna del software è essenziale, e quasi altrettanto lo è una documentazione che illustri le procedure principali o le classi entro il codice.
  
  Avvio: 60 ore (supponendo che la maggior parte del codice sia documentato).
  
  Manutenzione: 10 ore alla settimana.
  
  
• Entusiasta/zelota/evangelista/stratega: chi sappia dare propulsione al progetto trovando altri sviluppatori, spingendo particolari clienti potenziali a provarlo, scovando altre società possibili candidate all'adozione della nuova piattaforma, ecc. Non proprio un uomo di marketing o un venditore, perché deve lavorare a stretto contatto con la tecnologia: ma deve possedere la capacità di vedere chiaramente il ruolo del progetto in una prospettiva più ampia.
  
  Avvio: il tempo di conoscere il progetto.
  
  Manutenzione: 20 ore alla settimana.

  Ci ritroviamo dunque con cinque figure che equivalgono grosso modo a tre impiegati a tempo pieno. In realtà, alcuni di questi ruoli vengono gestiti da gruppi di persone che ne condividono la responsabilità, e alcuni progetti sopravvivono con meno di cinque ore alla settimana spese in media dai partecipanti-chiave, una volta superate le asperità delle prime release. Ma all'inizio del progetto è essenziale che gli sviluppatori gli dedichino lo stesso tempo e concentrazione che impiegherebbero se il progetto fosse una normale impresa di sviluppo di un'azienda.

  Questi cinque ruoli, inoltre, non coprono alcuna risorsa che potrebbe essere indirizzata a un nuovo sviluppo: si tratta di puro aggiornamento. In conclusione, se non trovate fra colleghi e partner risorse sufficienti per coprire queste basi, più sviluppatori extra per realizzare nuove fondamentali implementazioni (finché non farete nuovi reclutamenti), sarà forse il caso che riconsideriate il tutto.

  Quale licenza?
  Scegliere il tipo di licenza che meglio convenga al vostro progetto potrebbe rivelarsi un'impresa complessa e talvolta poco divertente, anche se potrà esserlo per il vostro ufficio legale. Esistono rapporti e siti Web molto dettagliati su quest'argomento; qui farò alcune considerazoni generali di carattere commerciale sulle varie licenze.

  Copyright di tipo BSD
  È il copyright usato da Apache e dai sistemi operativi basati su BSD (FreeBSD, OpenBSD, NetBSD) e si può riassumere così: "Ecco il codice, fateci quello che volete, non c'interessa; solo, se lo provate e lo vendete, datacene credito". Di solito il credito viene riscosso in diverse forme: sulla pubblicità, in un file README, nella documentazione cartacea, ecc. È stato obiettato che tale copyright potrebbe non essere scalabile, cioè: chi rilasciasse un software in bundle che includa 40 differenti moduli open source, tutti basati su BSD, dovrebbe fornire 40 differenti notizie di copyright. Nella pratica questo non è mai stato un problema, anzi è stato visto come una forza positiva per diffondere consapevolezza sull'uso del software Open Source.

  Da un punto di vista commerciale, questa licenza è la migliore quando s'interviene su di un progetto preesistente, perché non ci si deve preoccupare di licenze o di restrizioni sull'uso o la ridistribuzione futuri. È possibile miscelare e adattare questo software al vostro codice proprietario e rilasciare solo quello che ritenete possa essere utile al progetto e quindi, di riflesso, a voi. È uno dei motivi per cui l'abbiamo scelta per il gruppo Apache. A differenza di molti progetti software gratuiti, Apache fu avviato in gran parte da webmaster dell'ambito commerciale che cercavano un server Web migliore per le loro esigenze di business. È probabile che nessuno di noi mirasse a creare un server commerciale sopra Apache, ma nessuno sapeva che cosa il futuro avesse in serbo per noi, e limitare le nostre opzioni fin dall'inizio non sarebbe stato intelligente.

  Questo tipo di licenza è l'ideale per promuovere l'uso di un corpus di codice di riferimento che implementi un protocollo o un servizio comune. È un altro motivo della sua scelta per il gruppo Apache: molti di noi volevano che l'HTTP sopravvivesse e diventasse un vero standard multiparte, e non ci siamo minimamente preoccupati se Microsoft o Netscape avessero deciso di incorporare nei loro prodotti il nostro motore HTTP o qualunque altra componente del nostro codice, se solo ciò avesse contribuito all'intento di mantenere comune l'HTTP.

  Un tale grado di apertura presenta i suoi rischi. La licenza non fa riferimento ad alcun incentivo alle aziende perché diano in cambio le loro aggiunte al codice del progetto. Si sono in effetti dati casi in cui alcune aziende hanno sviluppato intorno al progetto delle tecnologie che ci sarebbe piaciuto vedere a loro volta offerte al progetto stesso. Ma se avessimo avuto una licenza che prescriveva che il codice aggiuntivo dovesse essere reso disponibile al progetto d'origine, si può pensare che quelle aggiunte non sarebbero nemmeno state fatte.

  Tutto questo per dire che, strategicamente parlando, il progetto deve mantenere una spinta sufficiente e che i partecipanti realizzano un valore maggiore contribuendo con il loro codice al progetto: perfino il codice che avrebbe avuto un valore se mantenuto proprietario. È un equilibrio complicato da mantenere, specialmente quando un'azienda decide di aumentare considerevolmente il codice scritto su un progetto derivativo, e comincia a dubitare se il possibile ritorno valga lo sforzo del contributo. Insomma, lavoriamo più di tutti gli altri messi insieme, perché dovremmo spartire? Chi scrive non ha la risposta a questa domanda. Quello che posso dire è che quell'azienda non ha probabilmente saputo trovare un modo più persuasivo per ispirare alle terze parti la voglia di contribuire per raggiungere gli obiettivi di progettazione più efficacemente.

  La licenza pubblica Mozilla
  La Mozilla Public License (MPL) è stata sviluppata dal team Mozilla di Netscape per l'impiego nei loro progetti. Quando fu rilasciata, era la prima licenza di tipo nuovo dopo molti anni e rispondeva davvero a molte questioni-chiave ignorate dalle licenze BSD o GNU. Nello spettro delle licenze software open source è adiacente alla licenza in stile BSD, con due differenze sostanziali:

  Essa prescrive che le modifiche alla "distribuzione" siano rilasciate sotto lo stesso copyright della MPL, il che la rende di nuovo disponibile al progetto. "Distribuzione" sono definiti i file così come vengono distribuiti nel codice sorgente; è importante perché consente a un'azienda di aggiungere un'interfaccia a una libreria di codice proprietario senza prescrivere che l'altra libreria di codice sia pure sottoposta alla MPL, ma solo l'interfaccia. In questo modo, il software può venir inserito, in grado variabile, entro un ambiente software commerciale.

  La licenza ha numerose clausole a protezione sia del progetto nella sua interezza sia dei suoi sviluppatori contro questioni di brevetto nel codice aggiunto che potrebbero insorgere. Prescrive che l'azienda o l'individuo che contribuisca con codice al progetto rinunci a ogni possibile pretesa a diritti di brevetto a cui il codice potrebbe dare adito.

  La seconda clausola è importantissima; al momento in cui scrivo, contiene anche un grave difetto.

  Preoccuparsi delle questioni di brevetto è Cosa Buona E Giusta. C'è sempre il rischio che, in perfetta buona fede, un'azienda offra codice a un progetto e poi, una volta che il codice sia stato completamente implementato, cerchi di reclamare il pagamento di una qualche concessione di brevetto per il suo uso. Una simile strategia commerciale, oltre a essere di pessimo gusto, è un vero passo falso dal punto di vista delle pubbliche relazioni, ma purtroppo non tutte le aziende arrivano a capirlo. La seconda clausola, dunque, previene il caso di qualcuno che fornisca di nascosto del codice ben sapendo che è brevettato e passibile di causare dei gran mal di testa a tutte le parti in causa.

  Questo non elimina naturalmente l'eventualità che qualcun altro sia titolare di un brevetto che possa far valere: non esiste strumento legale che forniscono questo tipo di protezione. Per la verità, io farei appello all'Ufficio Federale Brevetti e Commercio (U.S. Patent and Trade Office) perché se ne faccia carico: se ha l'autorità per definire certe idee e algoritmi come proprietà di un soggetto, dunque perché non gli si dovrebbe richiedere di fare l'opposto e di certificare come libero da brevetti il codice che ho presentato, garantendomi protezione da cause per violazione di brevetto?

  Come ho detto prima, tuttavia, la MPL vigente al dicembre 1998 presenta un difetto. In sostanza, la Sezione 2.2 prescrive (nella sua definizione di "Contributor

  Version") che chi da il contributo rinunci a reclamare brevetti su qualunque parte di Mozilla, non solo sul codice che ha fornito. Può non sembrare un difetto: sarebbe bello che una quantità di grandi aziende rinunciasse a ogni diritto sull'intero pacchetto.

  Purtroppo c'è una grande azienda che detiene uno dei più grandi portafogli di brevetti al mondo, che ha un grosso e specifico problema con questo cavillo. Non già perché voglia una volta o l'altra perseguire Mozilla e pretendere royalty, che sarebbe follia. La preoccupa il fatto che alcune parti di Mozilla implementano processi su cui essa detiene dei brevetti grazie ai quali incassa ogni anno moltissimi dollari: e se rinunciasse a far rispettare i brevetti sul codice di Mozilla, quelle altre aziende che pagano migliaia di dollari per quei brevetti, potrebbero semplicemente prendere da Mozilla il codice che li implementa e portarlo nei loro prodotti, eliminando la necessità di comprare la licenza del brevetto detenuto dalla succitata grande azienda. Questo non rappresenterebbe un problema se la Sezione 2.2 della MPL si riferisse semplicemente alle patch oggetto di contributo piuttosto che all'intero browser, quando si viene alla rinuncia ai diritti di brevetto.

  A parte questo cavillo, la MPL è una licenza straordinariamente solida. Prescrivere che le modifiche debbano tornare al "nucleo" significa che le correzioni di bug essenziali e i miglioramenti della portabilità rifluiranno nel progetto, mentre caratteristiche a valore aggiunto potranno sempre essere sviluppate da entità commerciali. Si tratta forse della licenza da preferire quando si sviluppano applicazioni per l'utente finale, nelle quali i brevetti possono più facilmente diventare un problema e più grande può essere l'impulso a ramificare il progetto. Per contro, la licenza BSD è forse più adatta a progetti destinati a essere "invisibili" o essenzialmente librerie di funzioni, quali un sistema operativo o un server Web.

  La Licenza Pubblica GNU
  La licenza GNU, che certamente non è concepita per l'ambito commerciale, presenta tuttavia elementi di un certo richiamo (che ci crediate o no) anche per i fini di business.

  Fondamentalmente, la GPL (General Public License) prescrive che gli incrementi, i derivati e perfino il codice che incorpora altro codice sotto GPL vengano rilasciati essi stessi come codice sorgente sotto GPL. Questo comportamento "virale" è stato ampiamente propagandato dagli apologeti dell'Open Source come un modo per assicurare che il codice che nasce free rimanga free: che non ci sia possibilità che un interesse commerciale possa deviare le versioni di sviluppo dal codice disponibile e impegnare risorse che non siano rese pubbliche. Agli occhi di chi licenzia il proprio software sotto GPL, sarebbe meglio non ricevere addirittura contributi che riceverne per poi non poterli usare liberamente. La cosa ha naturalmente un interesse speculativo, e si trovano sostenitori che dichiarano che Linux non sarebbe arrivato dov'è se non avesse avuto una GPL, perché la lusinga della deviazione per ragioni commerciali sarebbe stata troppo forte, impedendo di raggiungere la massa critica dello sforzo di sviluppo unificato.

  A prima vista, dunque, parrebbe che la GPL non possa coesistere felicemente con un fine commerciale collegato al software open source. I tradizionali modelli di guadagno attraverso l'aggiunta di valore al software non sono qui praticamente possibili. Tuttavia, la GPL potrebbe essere un mezzo efficacissimo per affermare una piattaforma che scoraggi perfino la creazione di piattaforme concorrenti, e per proteggere la rivendicazione di chi voglia essere conosciuto come il "primo" fornitore di prodotti e servizi residenti su questa piattaforma.

  Ne sono esempi Cygnus e GCC. Cygnus opera un sostanzioso blocco di modifiche ogni anno, portando GCC su diversi tipi di hardware e mantenendo quei porting. La grandissima parte di quel lavoro, secondo il dettato della GPL, va come contributo alla distribuzione di GCC che viene reso gratuitamente disponibile. Cygnus fa pagare lo sforzo insito nel porting e nell'aggiornamento, non il codice in sé. La storia di Cygnus e della sua leadership in questo ambito ne fanno l'azienda di riferimento quando ci si voglia accostare a questo tipo di servizio.

  Se un concorrente volesse cominciare a competere con Cygnus, sarebbe costretto a distribuire anch'esso le sue modifiche con licenza GPL: in altri termini, non c'è speranza che un concorrente possa trovare una nicchia tecnico commerciale che sia sfruttabile con la struttura GCC senza dare a Cygnus la stessa opportunità di approfittare anche di quella tecnologia. Cygnus ha creato una situazione in cui i concorrenti non possono competere sul piano della diversificazione tecnologica, a meno che non intendano spendere quantità ingenti di tempo e di denaro e usare una piattaforma completamente diversa da GCC.

  Un'altra maniera in cui si potrebbe usare la GPL per intenti commerciali è sotto forma "tecnologia sentinella", con una versione non-GPL dello stesso codice disponibile per la vendita. Per esempio, poniamo che abbiate un ottimo programma per criptare le connessioni TCP/IP su Internet. Non v'importa che venga usato in modo commerciale o meno: vostro interesse è che chi vuole incorporarlo in un prodotto o ridistribuirlo a pagamento vi paghi per l'autorizzazione a farlo. Se mettete il codice sotto una licenza GPL, questo secondo gruppo di utenti non potrà fare quello che vuole senza mettere per intero sotto GPL il suo prodotto, cosa che molti di loro non sarebbero propensi a fare. Ma se mantenete un ramo del vostro progetto separato, ossia non sotto GPL, potrete licenziare commercialmente il ramo separato di codice come meglio vi aggrada. Bisogna però fare molta attenzione e accertarsi che tutto il codice che vi è stato dato spontaneamente da terze parti sia disponibile per questa ramificazione non-gratuita; potete farlo dichiarando che solo voi (o vostri dipendenti) scriverete codice per questo progetto, oppure che (in aggiunta) otterrete da

  parte di tutti coloro che hanno contribuito al progetto il permesso esplicito di riversare qualunque loro contributo in una versione commerciale.

  Per alcune società questo è un modello commerciale sostenibile: un esempio è Transvirtual di Berkeley, che applica questo modello a una Java Virtual Machine leggera e a un progetto di libreria di classi. Si può obiettare che un alto numero di partecipanti a un progetto verrebbe respinto da un simile modello, e che le versioni GPL e non-GPL potrebbero divergere; a mia volta, obietto che se si trattano i partecipanti con lealtà, magari anche offrendo loro denaro o compensi d'altro tipo in cambio dei loro contributi (dopo tutto è in gioco il vostro interesse primario), questo modello potrebbe funzionare.

  L'ambito della licenza open source evolverà certamente nei prossimi anni quanto più diventerà chiaro che cosa funziona e che cosa no. La verità è che avete la libertà di inventarvi una licenza nuova, che descriva esattamente il punto dello spettro (delimitato da BSD a destra e da GPL a sinistra) in cui vorreste collocarla. Ricordatevi solo che quanto più grande sarà la libertà che accorderete a coloro che usano ed estendono il vostro codice, tanto più essi saranno incentivati a contribuirvi.

  Strumenti per il lancio di un progetto Open Source
  Nel Progetto Apache disponiamo di un eccellente set di strumenti disponibili e aggiornati per consentire l'ottimale funzionamento del nostro processo di sviluppo distribuito.

  Il più importante è il CVS, o Current Versioning System. Si tratta di una raccolta di programmi che implementano un "repository" di codice condiviso, aggiornando un database di modifiche, ciascuna delle quali porta un nome e una data. È estremamente valido per permettere a diverse persone di essere "autori" simultanei di un programma senza intralciarsi a vicenda. È utile anche nel processo di debugging, poiché si possono ripercorrere a ritroso le modifiche una per una, per scoprire dove esattamente si sia potuto introdurre un certo bug. Poiché sono disponibili client per tutte le principali piattaforme, funziona alla perfezione su linee commutate o attraverso connessioni a lunga distanza. Può anche essere protetto tramite tunneling su una connessione criptata che usi SSH.

  Il Progetto Apache usa il CVS non solo per tenere aggiornato il software ma anche il file "STATUS" in cui collochiamo tutte le principali questioni in discussione, ciascuna completa di commenti, opinioni e perfino voti. Lo usiamo anche per raccogliere i voti sulle decisioni prese dal gruppo, per tenere aggiornati i documenti del nostro sito Web, per gestire i documenti di sviluppo, ecc. In breve, è la risorsa e il software di gestione delle conoscenze del progetto. La sua semplicità può sembrare un inconveniente, il software in questo campo è di solito costoso e ricco di funzioni, ma la verità è che nel caso di CVS la semplicità è una gran virtù. Tutte le componenti del CVS sono gratuite, sia il server che i client.

  Altro elemento vitale per un progetto open source è una solida base di forum di discussione per sviluppatori e per utenti. Qui, la scelta del software è lasciata molto al caso: noi usiamo Majordomo, ma anche ezmlm, Smartlist o un altro qualsiasi programma sarebbe potuto andare ugualmente bene. Quello che conta è che ogni sforzo di sviluppo abbia la sua mailing list, così che gli sviluppatori possano selezionare da sé ciò che li interessa e restare ragionevolmente aggiornati sullo sviluppo. Sarà anche saggio creare per ogni progetto liste separate al quale il server CVS invia per email le modifiche che vengono operate nel suo "repository", per consentire una specie di controllo passivo delle modifiche fra colleghi. Questo modello è in effetti molto efficace per mantenere gli standard del codice e per scoprire bug. Può essere anche il caso di predisporre liste diverse per utenti e sviluppatori e magari perfino di distinguere fra tutti gli sviluppatori e un gruppo pilota, se il progetto è di ampio respiro. Infine, è importante che si rendano disponibili pubblicamente gli archivi delle liste, così che i nuovi utenti possano, tramite una ricerca, sapere se un certo problema sia già stato trattato, o come si sia risposto in passato a certe domande.

  Tener traccia di bug e di problemi è anche essenziale in un progetto ben condotto. Al Progetto Apache usiamo uno strumento GNU chiamato GNATS, che ci è stato molto utile in oltre 3000 segnalazioni di bug. Vi servirà uno strumento che permetta a diverse persone di rispondere alle segnalazioni di bug, di specializzarsi sui bug di una specifica componente del progetto e di leggere e rispondere via email alle segnalazioni, anziché solo tramite un modulo in una pagina Web. L'obiettivo principale per il database dei bug è di essere il più semplice e automatico possibile, sia per gli sviluppatori che rispondono alle segnalazioni di bug (perché è veramente un compito noioso) sia per ricercare se un certo bug sia già stato inserito. In sostanza, il database dei bug diventerà il vostro deposito di conoscenza aneddotica del progetto e delle sue capacità. Perché un certo comportamento è una caratteristica, non un bug? C'è qualcuno al lavoro su un problema segnalato? Ecco le domande a cui un buon database di bug dovrebbe cercare di rispondere.

  L'approccio open source non è una magia che funzioni per tutti i progetti di sviluppo software. Lanciare un progetto di successo richiede non solo le giuste condizioni ma anche un'enorme quantità di lavoro, perché esso prenda finalmente vita. In più di un senso voi, come sostenitori del nuovo progetto, dovrete agire come il dottor Frankenstein, ora miscelando sostanze chimiche, ora somministrando scosse elettriche, per portare il vostro mostro alla vita. Buona fortuna.