Non è questo il luogo più adatto per descrivere nei particolari i vari modelli di sviluppo del software, tuttavia può essere utile descrivere alcuni degli aspetti peculiari del mondo Open Source; tenendo comunque presente che gli aspetti qui presentati non sono insiti nel software libero, sebbene trovino il loro compimento l'uno nell'altro. Infatti le licenze libere non vietano ad una persona (o gruppo) di effettuare autonomamente tutto lo sviluppo di un programma e quindi rilasciarne le versioni definitive (complete di sorgenti) e d'altro canto alcune aziende stanno facendo tentativi di applicare alcuni aspetti di questo modello ai loro prodotti proprietari.
La prima caratteristica dello sviluppo Open Source, indicata appunto dalla frase del titolo (rilascia prima, rilascia frequentemente), è il fatto di cominciare a rendere pubblico il proprio progetto fin dall'inizio, addirittura prima che sia funzionante, e quindi continuare a rilasciare nuove versioni ogni volta che vengono effettuate modifiche o corretti bug.
In questo modo la comunità degli sviluppatori può seguire da vicino l'evoluzione del programma e collaborare attivamente senza rischiare di ripetere lavoro già fatto da altri.
Collegato al punto precedente, è un aspetto che può lasciare perplesso chi è abituato al mondo del software proprietario, ovvero i numeri di versione dei programmi open source. Nel primo caso i programmi vengono rilasciati come prodotto finito, dunque con un numero di versione ``intero'' o con un nome, al più accompagnati da indicazioni poco visibili su eventuali patch già applicate; nell'open source al contrario tutte le versioni intermedie sono ben visibili.
Un'altra differenza è che nel software proprietario la data di uscita di un prodotto è frequentemente determinata da motivi di marketing, per cui vengono rilasciate come definitive delle versioni ancora in fase di sviluppo.2.6Al contrario nel software libero un programma prende un numero di versione ``intero'' solo quando tutte le caratteristiche previste sono implementate e funzionanti (a meno ovviamente di bug particolarmente nascosti); per questo motivo chiunque abbia bisogno di un programma per scopi non critici2.7può tranquillamente utilizzare una versione ``beta'' o ``release candidate'' senza timore di malfunzionamenti peggiori di quelli delle release ``definitive'' di numerosi produttori di software proprietario.
Generalmente i numeri di versione di un programma open source seguono lo schema seguente.
Per il kernel linux, ad esempio, i middle number dispari vengono usati per indicare le versioni di sviluppo, mentre quelli pari vengono assegnati alle versioni stabili; così fino a poco tempo fa erano mantenute le versioni stabili 2.0, 2.2 e 2.4, mentre lo sviluppo avveniva nelle versioni 2.5, che all'inizio del 2004 è stata giudicata abbastanza stabile da dare vita alla 2.6.
Quando un programma è sviluppato da un numero elevato di persone, come è ad esempio il caso di molti progetti open source, è ovviamente necessario coordinare i loro sforzi, in modo tale da ottenere un prodotto omogeneo; frequentemente di questo compito si occupano coloro che hanno dato inizio al progetto e possono farlo prevalentemente in due modi: o tendono ad accettare qualsiasi contributo, controllando semplicemente che funzioni ed integrandolo il più possibile con il resto del progetto, rischiando però di perdere in omogeneità, oppure si possono comportare da ``dittatori illuminati'' facendo una rigida selezione dei contributi ricevuti ed aggiungendo solo ciò del quale sono effettivamente convinti; questo non è contrario allo spirito del software libero, in quanto chi non fosse soddisfatto della gesitione ``ufficiale'' può realizzare, distribuire e mantenere patch per aggiungere le proprie varianti al progetto.
In casi estremi, è possibile che degli sviluppatori, insoddisfatti della gestione ufficiale del progetto, decidano di effettuare una fork, ovvero di far nascere un nuovo progetto basato sul codice originale al momento della fork, ma gestito in modo differente; tale rischio è insito nella natura stessa dell'open source e comporta sicuramente degli svantaggi dal punto di vista dell'``ottimizzazione delle risorse'', ma è necessario per preservare la libertà dei programmi e può offrire comunque delle opportunità dal punto di vista della specializzazione dei programmi e della loro varietà.
Tra i non addetti ai lavori potrebbero sorgere dei legittimi dubbi sulla sicurezza del software open source e sulla possibilità che la conoscenza del codice sorgente venga utilizzata per scopi maliziosi, ed in particolare per realizzare versioni modificate dei programmi con comportamenti illeciti, per aggirare eventuali protezioni (autentificazioni e simili) presenti nei programmi conoscendone il funzionamento e per trovare e sfruttare eventuali errori. In realtà questi aspetti non costituiscono un serio problema per la sicurezza di un sistema, come mostrerò in seguito, e si può anzi dire che il modello di sviluppo open source offre degli strumenti per realizzare programmi più sicuri dei corrispettivi ``closed''. Ovviamente ciò non significa che ogni programma open source sia sicuro, tuttavia questo modello di sviluppo, unito ad una consapevolezza del problema in fase di progettazone e sviluppo può aiutare notevolmente la riduzione dei problemi di sicurezza nei programmi.
Questo è un rischio effettivamente presente: esistono numerose versioni modificate in modo malevolo di programmi open source, e soprattutto dei programmi piu' importanti del sistema, tuttavia:
Ci si potrebbe comunque chiedere se la conoscenza del sistema di comunicazione tra client e server non possa comportare dei rischi, tuttavia bisogna ricordare che la maggior parte dei programmi, sia open che closed, fanno uso di protocolli standard, le cui specifiche sono liberamente disponibili sugli RFC, per cui la conoscenza di un'implementazione (a meno di bug) non rende più o meno semplice l'attacco al protocollo.
Comunque per avere accesso da remoto ad un computer è necessario che sullo stesso ci sia un programma che ascolta richieste di connessione su una determinata porta e fornisce tale accesso: i programmi attualmente utilizzati (sempre a meno di bug o cattive configurazioni) o forniscono un accesso estremamente ridotto e quindi privo di pericoli, oppure prevedono l' autentificazione di chi ha effettuato la richiesta di connessione (spesso ma non sempre un nome utente e password).
Per poter avere accesso al computer aggirando tale controllo ci possono essere diversi modi: venire a conoscenza di una coppia nome utente - password valide, sfruttare un bug del programma, oppure, e questo è il caso in questione, sostituire il programma in questione con una versione modificata che permetta di aggirare i controlli, ma per poterlo fare è necessario o avere gia' accesso (con sufficienti diritti) alla macchina, oppure ``avere accesso all'amministratore'' e convincerlo in qualche modo ad installare il programma (ma un amministratore accorto evita di cadere in simili trappole e si assicura che gli utenti non possano installare programmi potenzialmente pericolosi).
In ogni caso se il server2.8 è sicuro non è (dovrebbe essere) possibile aggirarne le protezioni mediante un client2.9 modificato, e comunque in molti casi il client ``normale'' non serve neanche per effettuare l'attacco.
Rimane la possibilità di servirsi del codice sorgente per trovare eventuali bug presenti nei programmi e sfruttarli: in questo caso il problema è che trovare questi errori tramite la sola lettura del codice è praticamente impossibile: l'unico modo efficace per trovare i bug è utilizzare il programma, sia nel modo ``normale'' che provando a dargli degli input errati o ``strani'' e controllare che la risposta del programma sia corretta. Questo è uno dei motivi per cui il software open source viene rilasciato fin dalle prime fasi dello sviluppo e il motivo per cui il software closed viene dato a dei beta tester prima del rilascio ufficiale.
Da questo punto di vista la differenza tra i due modelli sta nel fatto che nel caso dell'open source ci sono più tempo e frequentemente più persone a disposizione per la ricerca dei bug, e nel momento in cui una persona segnala il bug ed il metodo per sfruttarlo (exploit) c'è chi cerca subito di correggerlo e rilascia la correzione quanto prima possibile, o comunque nel frattempo descrive un workaround, ovvero un modo per aggirare il problema impedendo l'utilizzo dell'exploit trovato. Chi sviluppa software ``closed'', al contrario, cerca frequentemente di ostacolare la diffusione di notizie sui bug trovati, sperando di impedirne lo sfruttamento, solo che in questo modo una persona malintenzionata non si farà scrupoli nell'andare a cercare informazioni in modi poco legali, mentre un amministratore onesto non potrà trovare quelle informazioni (exploit e workaround) che lo aiuterebbero a ridurre i danni nell'attesa che l'errore venga corretto; tra l'altro nel caso proprietario è frequente che vengano rilasciate patch ``cumulative'' per correggere diversi errori, magari anche dopo mesi dalla loro scoperta.
Uno dei vantaggi del software open source sta nel fatto che, se anche l'autore originale non potesse o non volesse più mantenere il suo programma, chiunque sia interessato alla cosa può prendere il suo posto e continuare lo sviluppo. Questo non vuol dire che i programmi open source siano eterni, ma semplicemente che le loro sorti dipendono esclusivamente dal numero di persone ad essi interessate, quindi indirettamente dalla qualità del prodotto, e non da fattori esterni come la mancanza di tempo di una persona o il fallimento di una azienda.