La storia dello sviluppo di

PostgreSQL  è il più evoluto database server Open Source. È un database Relazionale ad Oggetti (ORDBMS), ed è supportato da un gruppo di sviluppatori connessi via Internet.

PostgreSQL ebbe inizio come Ingres, sviluppato all'università di Berkeley in California (1977-1985). Il sorgente di Ingres fu preso e migliorato dalla Relational Technologies/Ingres Corporation che produsse i primi server database che ottennero successo commercialmente. (Ingres Corp. fu in seguito acquistata dalla Computer Associates).

Anche a Berkeley, Michael Stonebraker capeggiò un gruppo per sviluppare un database server chiamato Postgres (1986-1994). Il sorgente di Postgres è stato preso dalla Illustra e sviluppato come prodotto commerciale. (L'Illustra fu più tardi comprata da Informix e integrata nel Informix's Universal Server).

Due studenti laureati a Berkeley, Jolly Chen e Andrew Yu, aggiunsero l'interfaccia SQL al Postgres, e lo chiamarono Postgres95 (1994-1995). Essi lasciarono Berkeley, ma Jolly continuò ad aggiornare e supportare Postgres95, che ha ancora una mailing list attiva.

Nell'estate 1996, divenne chiaro che la domanda di un database server SQL con tecnologia Open Source era forte ed un team doveva essere formato per continuare lo sviluppo. Marc G. Fournier a Toronto (Canada) si offrì di ospitare la mailing list e approntò un server per ospitarne i sorgenti. Il migliaio di iscritti alla mailing list furono spostati sulla nuova list ed il server fu configurato, fornendo alle persone gli account per apportare le modifiche ai file sorgenti usando CVS.

Jolly Chen disse: "Questo progetto necessita di poche persone con molto tempo, non di molte persone con poco tempo." Con 250.000 linee di sorgente C, capimmo cosa intendeva. All'inizio c'erano quattro persone maggiormente impegnate: Marc, Thomas Lockhart da Pasadena, California, Vadim Mikheev da Krasnoyarsk, Russia, e me stesso. Noi tutti avevamo un lavoro full-time, così si lavoravamo al Postgres nel tempo libero. Certamente era una scommessa.

Il nostro primo obiettivo fu di esaminare la vecchia mailing list, valutare le pezze che erano state pubblicate per fissare i vari problemi. Il sistema era molto fragile allora, e non facilmente comprensibile. Durante i primi sei mesi di sviluppo, c'era paura che una toppa potesse intaccare tutto il sistema e noi saremmo stati incapaci di correggere il problema. Ci siamo rotti la testa su molti bug report nel tentativo di capire non solo che cosa era andato storto, ma anche come il sistema aveva eseguito molte funzioni.

Ereditammo un'enorme base di sistemi installati. Un tipico bug report era: "Quando agisco in questo modo, il sistema si interrompe ed esce." Noi avevamo una lunga lista di messaggi di questo tipo. Divenne chiaro che era necessario organizzarsi. Molti bug report richiedevano un lavoro significativo per essere risolti, e molti altri erano duplicati, così la nostra TODO list riportava tutte le query SQL che davano errori, e segnalandole agli utenti si ridussero le duplicazioni nei bug report.

Avevamo molti zelanti sviluppatori, ma la curva di apprendimento nel capire come il back-end lavorava era significativa. Molti sviluppatori vennero impiegati nei sorgenti di contorno, come le interfacce dei linguaggi o gli strumenti del database, dove era più semplice capire. Altri sviluppatori si focalizzarono su specifici problemi delle query cercando di localizzare le radici del problema. Era entusiasmante verificare che diversi bug erano risolti con una sola linea di sorgente C. Postgres si era sviluppato in ambiente accedemico e non era stato esposto al pieno spettro di query del mondo reale.

A quel tempo si era parlato di aggiungere delle caratteristiche, ma l'instabilità del sistema ci costringeva a focalizzarci sulla soluzione dei problemi esistenti. Cambiammo il nome da Postgres95 a PostgreSQL. Era solo una parola, ma evidenziava le nostre doti SQL. Iniziammo a distribuire i nostri sorgenti usando sup che permetteva alle persone di tenere aggiornata la copia dell'albero dei sorgenti, in seguito passammo a CVS remoto.

Le release avvenivano ogni 3-5 mesi. Questo tempo era impiegato da 2-3 mesi di sviluppo, un mese di beta testing, una release principale e qualche settimana per rilasciare una versione con i bug più seri corretti. Non abbiamo mai tentato uno scadenziario più serrato. Un database server non è un word processor o un gioco, dove tu puoi facilmente ricominciare se incontri un problema.
I Database sono multi utente, ed i dati utente sono memorizzati nei nostri server, così dobbiamo stare molto attenti nel rilasciare del software quanto più affidabile possibile.

Lo sviluppo di un codice sorgente di tali dimensioni e complessità non è idoneo a principianti. Abbiamo avuto difficoltà nel trovare sviluppatori interessati in un progetto che ha una curva di apprendimento così lunga. Comunque, l'atmosfera rilassata, la nostra attenzione a migliorare sia l'affidabilità sia le performace, alla fine ci hanno aiutato ad attrarre i talenti esperti che ci servivano.

Dare ai nostri sviluppatori la conoscenza che serviva loro per assisterci con PostgreSQL era chiaramente una priorità. Avevamo una TODO list che evidenziava cosa era necessario fare, ma 250.000 linee di codice facevano di ogni singola riga della TODO un progetto impegnativo. Realizzammo che la formazione di uno sviluppatore sarebbe stata più conveniente che aiutare i nuovi utenti ad iniziare.
Così decidemmo di scrivere un diagramma di flusso per i moduli del back-end, evidenziando gli scopi di ciascuno di essi.
Scrivemmo una FAQ per gli sviluppatori per fissare alcuni concetti legati alle domande più comuni legate allo sviluppo del programma.
Con questi documenti gli sviluppatori divennero produttivi più rapidamente.

Il sorgente ereditato da Berkeley era molto modulare, ma anche un po' marcio: alcuni sviluppatori a Berkeley non avevano capito come affrontare alcuni compiti.
Anche i loro stili di programmazione erano molto diversi.
Scrivemmo, quindi, un programma per uniformare l'indentazione ed il formato dei sorgenti C per avere almeno una consistenza di base. Scrivemmo uno script per trovare le funzioni che potevano essere definite come statiche e quali, invece, potevano essere tolte perchè non erano mai chiamate.

Questi due programmi erano lanciati proprio prima di ogni rilascio. Una tabella di controllo ci ricordava cosa era stato cambiato ad ogni rilascio. Appena guadagnata la conoscenza del codice, fummo in grado di eseguire più complesse correzioni e, simultaneamente, di inserire maggiori caratteristiche allo stesso PostgreSQL.

Iniziammo a riprogettare il codice meno strutturato. Ci muovemmo in modo che ogni nuova versione avesse nuove importanti caratteristiche, anziché semplicemente risolvere i problemi della versione precedente. Migliorammo la compatibilità con SQL, aggiungemmo le sub-select, migliorammo anche il locking e aggiungemmo anche le funzionalità SQL che ancora mancavano. Abbiamo aggiunto anche il supporto telefonico per coloro che ne hanno bisogno. I gruppi su Usenet iniziarono a farci conoscere.

L'anno precedente, abbiamo indagato su PostgreSQL ed abbiamo notato che molte persone stavano raccomandando altri database, anche se noi ci stavamo occupando sempre più rapidamente delle problematiche degli utenti. Un anno dopo, molte persone ci consigliavano ad utenti che avevano bisogno di supporto per le transazioni, query complesse, supporto SQL di tipo commerciale, tipi di dati complessi ed affidabilità. Altri database erano consigliati quando la velocità era il requisito principale. Questo chiaramente descriveva le nostre forze.

Il rilascio di PostgreSQL su RedHat come parte della loro distribuzione di Linux moltiplicò velocemente la nostra base d'utenti. Ora ogni nuova versione è essenzialmente un grosso passo avanti rispetto alla precedente. La versione più recente, la 6.5, segna la nostra totale padronanza sul sorgente ereditato da Berkeley.

Finalmente ogni modulo è stato compreso da almeno un membro del gruppo di sviluppo. Stiamo ora facilmente aggiungendo nuove carattistiche, grazie all'accresciuta esperienza ed al nostro team mondiale.

Come molti altri progetti open-source, non sappiamo quante persone stanno usando il nostro software, ma la funzionalità e la visibilità sono sensibilmente maggiori, lo vediamo anche dall'aumento del traffico sulle mailing list del PostgreSQL.