Bibliografia

La "Open Source Development with CVS" di Fogel è molto di più del suo sottotitolo. Per usare le parole dell'editore: "Open Source Development with CVS è uno dei primi libri disponibili che insegna lo sviluppo e l'implementazione di software Open Source". Include anche il miglior manuale introduttivo e testo di riferimento per CVS che abbia mai visto. Il libro era così ben fatto che mi ha spinto a scrivere questo HOWTO, perché il ruolo che esso cercava di esercitare mi era parso così importante e utile. Gli si dia un'occhiata, o lo si compri se possibile, se seriamente interessati a condurre un progetto di software libero.

Anche se tratta solo brevemente il software libero (e lo fa camminando in punta di piedi intorno alla questione software libero/open source, con l'uso della flaccida espressione "codice aperto", che solo un avvocato potrebbe coniare), il libro di Lessig è notevole. Scritto da un avvocato, parla di come la regolamentazione su Internet non sia esercitata con le leggi, ma con il codice stesso, e di come la natura del codice determinerà la natura delle libertà future. Oltre ad essere una lettura veloce e godibile, racconta un po' di storie carine, e spiega quanto c'e' bisogno di software libero, con molta più intensità di qualsiasi cosa abbia letto, a parte "Right to Read" di RMS.

Anche se devo dire per onestà che non sono più quel fan di ESR che ero in passato, questo libro si è dimostrato insostituibile nel portarmi dove sono oggi. Il saggio che dà il titolo al libro fa un buon lavoro nel tratteggiare il processo del software libero, e fa un lavoro sbalorditivo nell'argomentare a favore dello sviluppo di software libero/open source come direzione da prendere per avere del software migliore. Il resto del libro contiene altri articoli di ESR, articoli che per la maggior parte sono pubblicati sul suo sito: eppure, è una bella cosa da possedere in versione cartacea, ed è una cosa che ogni appassionato di software libero/open source dovrebbe leggere.

Poiché l'articolo ha un suo riassunto iniziale, ho pensato di inserirlo qui parola per parola:

Questo articolo esamina il più recente dei paradigmi - l'Organizzazione a rete virtuale - e si chiede se lavoratori della conoscenza dispersi geograficamente possano collaborare per un progetto senza alcuna pianificazione centralizzata. La coordinazione, la gestione ed il ruolo della conoscenza emergono come le aree centrali di interesse. Sono stati scelti come caso di analisi il Linux Project e il suo modello di sviluppo, e sono stati identificati i fattori critici di successo per questa struttura organizzativa. Lo studio prosegue con la formulazione di una struttura di massima che può essere applicata a tutti i tipi di lavoro decentrato virtuale, e trae la conclusione che la creazione di valore viene massimizzata quando c'è intensa interazione, e condivisione di informazioni senza inibizioni, tra l'organizzazione e la comunità che la circonda. Perciò, il potenziale successo o fallimento di questo paradigma organizzativo dipende dal grado di dedizione e coinvolgimento della comunità circostante.

Questo articolo è stato segnalato a me in quanto autore di questo HOWTO, e ne sono rimasto molto impressionato. È stato scritto da uno studente specializzando in management, e penso che l'articolo abbia centrato il bersaglio nel valutare il progetto Linux come esempio di un nuovo paradigma di gestione, un paradigma in cui vi porrete al centro, nel vostro ruolo di manutentori di un progetto di software libero.

Come sviluppatore che cerca di controllare un'applicazione, e di condurla al successo nel mondo del software libero, non sono sicuro di quanto sia utile la discussione di Dafermos, tuttavia fornisce sicuramente una giustificazione teorica al mio HOWTO: la gestione di progetti di software libero è un animale diverso dalla gestione di progetti di software proprietario. Se si è interessati alle modalità concettuali e teoriche in cui la gestione di progetti di software libero differisce da altri tipi di gestione, questo è un ottimo articolo da leggere. Se questo HOWTO risponde a dei "come?", Dafermos risponde a dei "perché?" (ben più difficili da sostenere), e fa davvero un buon lavoro.

Un articolo ben scritto, anche se penso che il titolo abbia confuso tanta gente, quanta il resto del saggio ne abbia aiutata. Offre una buona spiegazione di come progettare programmi che avranno successo, e che si conserveranno mantenibili crescendo.

In uno dei migliori articoli sull'argomento che abbia letto, Monty ricapitola alcuni dei punti principali cui ho accennato, compresi: avvio di un progetto, collaudo, documentazione, organizzazione e leadership di un team, e diversi altri argomenti. Per quanto l'articolo sia più dogmatico di quanto io cerchi di essere, penso sia un articolo importante, e l'ho trovato molto utile nello scrivere il presente HOWTO; in tutti i punti in cui ho attinto qualcosa da questo articolo, ho cercato di citarlo.

Ho molti problemi in sospeso con questo pezzo; per avere un buon punto di vista critico si consiglia di leggerlo [KRAWITZ] contemporaneamente all'articolo di Monty.

Ad una prima occhiata, l'HOWTO delle pratiche di rilascio scritto da ESR sembra avere molto in comune con questo documento; ad un esame più dettagliato, le differenze diventano evidenti, anche se i due restano strettamente imparentati. Il suo documento, letto in congiunzione con questo, darà al lettore un buon quadro di come lavorare alla gestione di un progetto. L'HOWTO di ESR entra un po' più nei dettagli su come scrivere, e in quali linguaggi scrivere, e tende a dare istruzioni e liste di controllo più specifiche ("chiamate questo file così, non così"), mentre il presente HOWTO tratta le cose in modo più astratto. Ci sono diverse sezioni molto simili. Questo HOWTO è anche molto più breve.

La mia citazione preferita dal suo HOWTO è: ""Gestire un progetto bene, quando tutti i partecipanti sono volontari, presenta alcune sfide molto particolari. Questo è un argomento troppo vasto per essere trattato in un HOWTO." Ah, davvero? Forse sto solo facendo un lavoro scadente.

Venugopalan fornisce uno dei migliori saggi sull'uso efficace di CVS in cui mi sono imbattuto. È scritto per gente che abbia già una buona conoscenza di CVS. Nel capitolo sui rami descrive quando e come creare dei rami, ma non dà informazioni su quali comandi CVS bisogna usare per farlo. Questo va bene (sono stati scritti altri HOWTO su CVS, più tecnici), ma i novellini di CVS dovranno passare del tempo sul manuale di riferimento di Fogel, prima di poter trovare questo di qualche utilità.

Venugopalan produce liste di controllo di cose da fare prima, dopo, e in prossimità dei rilasci. Vale sicuramente una lettura, poiché molte delle sue idee risparmieranno un sacco di mal di testa agli sviluppatori, per un lungo periodo di tempo.

Riferendosi principalmente alla pratica della programmazione (come fanno di solito la maggior parte degli articoli sull' argomento), l'articolo parla un po' della gestione dei progetti ("Usatela!"), e un pochino della comunicazione all'interno di un progetto di software libero.

Questo articolo accenna a quel dibattito sulla "scrittura di codice mantenibile" che ho cercato con ogni mezzo di evitare nel mio HOWTO. È uno dei migliori (e più diplomatici) articoli sull'argomento che abbia trovato.

Questo articolo mi ha reso felice, perché ha affrontato molti dei problemi che avevo riguardo l'articolo di Monty su LinuxProgramming. L'autore sostiene che Monty suggerisce semplicemente l'applicazione di tecniche di gestione dei progetti antiquate, per software proprietario, invece di cercare di elaborare qualcosa di nuovo. Ho trovato questo articolo estremamente ben meditato, e lo ritengo una lettura essenziale per ogni gestore di progetti di software libero.

Anche se l'articolo è poco più di una domanda, leggere le risposte a questa domanda fornite dai lettori di Advogato può essere d'aiuto. In molti modi, questo HOWTO costituisce la mia risposta alla domanda posta nell'articolo, ma ci sono altre risposte possibili, molte delle quali possono mettere in discussione quello che è scritto in questo HOWTO: vale la pena di dare un'occhiata.

Questo documento è stato scritto come risposta a un'altro articolo su Advogato. Anche se non riguarda la conduzione di un progetto, descrive alcuni modi per iniziare con lo sviluppo di software libero senza iniziare un progetto. Penso sia un articolo importante. Se si è interessati ad impegnarsi nel software libero, questo articolo dimostra alcuni dei modi in cui si può farlo senza iniziare veramente un progetto (cosa che, come spero questo HOWTO abbia mostrato, non va presa alla leggera).

Questo di Moorman è un articolo breve, ma apporta alcuni contributi utili. Il commento che ricorda agli sviluppatori di ringraziare i loro collaudatori ed utenti finali è preziosissimo, e spesso dimenticato.

Non avevo nemmeno una sezione, in questo HOWTO, su come scegliere il nome da dare al progetto, fino a che l'articolo di Leslie Orchard me lo ha ricordato: grazie a Leslie per aver scritto questo articolo!

In questo articolo, David Allen affronta lo schema di numerazione delle versioni "Major.Minor.Patch" nella sua interezza; è bene leggerlo mentre si legge la Sezione 2.4. L'articolo mi è piaciuto, e inoltre descrive alcuni dei progetti che ho citato nella mia discussione della numerazione delle versioni.