Attenzione : questa è una traduzione non ufficiale del documento hacking di Havoc Pennington, l’originale si trova qui.
Questo documento è stato scritto nel Dicembre del 1999
Molti programmatori vogliono attivarsi su un progetto di software libero, ma non sono abbastanza sicuri su come funzionino le cose. Questa pagina è una collezione informale di “regole non scritte e intese” per le persone che vorrebbero proporsi volontariamente. Ne ho imparata qualcuna commettendo gli errori, e ancora violo i miei stessi suggerimenti qualche volta; queste sono solo linee guida grezze. altre persone ne faranno uscire differenti insiemi.
Non iniziare a lanciare il tuo progetto. Molte persone vogliono scrivere software libero, così la prima cosa che fanno è abbozzare del codice, renderlo GPL senza pensarci tanto, e rilasciare la versione 0.0.1 alpha. Sebbene sia divertente e possibilmente istruttivo, ciò è totalmente inproduttivo. Ecco perchè:
- E’ più istruttivo leggere e imparare dal codice delle altre persone aggiungendo piccole funzionalità qua e là, o riparare qualche bug. Molti progetti hanno un bug tracker; per esempio, per il progetto Gnome c’è bugs.gnome.org, Debian ha lo stesso sistema, ecc. Trova qualche bug nel tracker, e riparalo. O aggiungi una funzionalità che volevi.
- Ovviamente, è ancora più utile ripulire il codice esistente rispetto ad avviare in solitaria un progetto che non sarà mai finito.
- Quasi certamente, qualcun altro sta già lavorando su qualsiasi cosa tu voglia scrivere; è meglio finire un progetto che avere due progetti non finiti. Ti garantisco che il 95% dei progetti di software libero svaniscono nell’oblio prima di diventare utili. Dal punto di vista di istruirti, e anche dal punto di vista di diventare famoso e potersene vantare, avrai bisogno di persone che ti aiutino a raggiungere quel 5% di progetti di successo.
- Se non hai sbirciato e non hai partecipato a un progetto di software libero, non saprai come vengono fatte le cose e passerai dei brutti momenti provandoci da solo.
Nonostante tutto ciò che è stato detto, se hai una idea interessante e pensi che sarebbe divertente hackerarci un po’, in ogni caso fallo. Tutti noi l’abbiamo fatto. Qualcuno di questi progetti vanno davvero da qualche parte. E se hai un po’ di esperienza nell’hacking e c’è un’applicativo interessante su cui nessuno sta lavorando, provaci.
Programma, programma, programma. Se inizi un progetto, la cosa più importante è programmare. Devi programmare abbastanza da rendere l’applicazione utile principalmente da solo; questo può voler dire mesi o anni di lavoro solitario, finchè qualche anima decida di auitarti con la tua applicazione invece di iniziare la propria. Devi rilasciare spesso, riparare i bug velocemente, e generalmente mantenere il tutto divertente. Quando si passa alla pratica, scrivere un’applicazione libera è un enorme ammontare di lavoro. Se stai programmando da solo, metti in conto almeno 10-20 ore alla settimana di lavoro. Certamente puoi contribuire a progetti esistenti con meno ore. And schedule those 10-20 hours every week, for the forseeable future. Se non puoi permetterti così tanto tempo – non iniziare nemmeno il progetto. Se non puoi programmare, idem.
Sii Imprenditore di te stesso. Un sacco di persone scrivono le loro intenzioni di scrivere l’applicazione X, o annunciano la versione 0.0.1 alfa, e poi si arrendono quando non ottengono responso. Affrontala; non ci sarà più responso finchè non avrai utenti. E non ci saranno utenti finchè non scrivi codice. Quindi fai affidamento sulla tua determinazione.
Lo stesso fenomeno accade quando si chiede aiuto. Infine, se hai a che fare con un bug o un disfunzionamento o la carenza di documentazione, dovrai quasi certamente occupartene e sistemare la cosa da solo. Gli Hacker sono abbastanza buoni nell’aiutare principianti che non sanno da dove cominciare, ma prima o poi si aspetteranno che tu sia in grado di risolvere da solo i tuoi problemi.
Usa le mailing list. Se hai una domanda, ponila sulla ml. E’ in un certo modo maleducato mandare email private agli sviluppatori, a meno che non si sia sicuri che siano le sole persone che possano rispondere alla domanda. Se scrivi nella ML,
lasci che gli sviluppatori si condividano il compito di rispondere alle domande. (Se fai uso di email private, molto probabilmente scriverai allo sviluppatore sbagliato comunque, e finirai a non ottenere nessuna risposta perchè la persona a cui hai scritto non lo sa.)Le ML e la documentazione sono state fatte dagli sviluppatori per rendere il supporto a un grande numero di utenti fattibile. Ricorda che tutti sono volontari, e se ne hai bisogno una consulenza a pagamento è probabilmente disponibile.
Nessuno è obbligato. La gente spesso si aspetta che qualcuno sia impiegato in un progetto di software libero; o si aspettano di avere un compito, e di doverlo completare entro un certo tempo limite. Non funziona così. Non si può controllare quello su cui le altre persone lavorano, e nessuno ti dirà su cosa lavorare, sebbene ci sarà abbondanza di suggerimenti. Devi buttartici e far succedere qualcosa.
Coordinati con gli altri. Se impieghi 3 mesi scrivendo qualche nuova interessante funzionalità, e poi scopri che colui che mantiene il progetto odia l’idea e non accetterà la patch, o scopri che la tua patch non può essere applicata all’ultima versione in sviluppo, o scopri che qualcun altro ha fatto lo stesso lavoro, sarai infelice. Se stai pianificando di lavorare su qualcosa, scrivi una breve nota al maintainer di modo che lo sappiano. Molti maintainers saranno scettici – ricevono tante note e non vedono mai risultati! – ma lo terranno a mente e forse ti daranno qualche suggerimento.
Se diventi molto coinvolto in un progetto, una coordinazione migliore è possibile, solitamente usando una combinazione di email, CVS e IRC. CVS fa il suo bel compito di unire i cambiamenti quando la comunicazione viene meno.
Non c’è nessuna risposta alla domanda "quando verrà finita X?" o "la funzionalità X verrà implementata?" La risposta ad entrambe le domande è "quando e se qualcuno lo farà." Se quel qualcuno sei tu, allora conosci la risposta. Se quel qualcuno non sei tu, allora dovrai semplicemente aspettare e vedere. Non c’è nessun dirigente e nessuno per fare in modo che le cose accadano sicuramente.
I suggeritori non vanno bene. Un suggeritore sembra avere un flusso senza fine di idee brillanti sulle mailing list, ma o non programma mai, o non sa programmare. Se non sai programmare, allora non sai nemmeno come progettare del software. Puoi solo far danni.
Ci sono comunque un sacco di cose che i non-programmatori possono fare : bug report, richieste di funzionalità (finchè esse non siano ampiamente speculative e totalmente non relative al codice attuale), scrivere documenti, aiutare le altre persone con le domande da utente o di installazione, user group, amministrare i siti, amministrare i server, fare pacchetti per altre distribuzioni o sistemi operativi, ecc . Gli Hacker apprezzano il tuo interesse nel proprio lavoro, e la tua assistenza.
Sbirciare va bene. La tentazione di iscriversi a una Mailing List e iniziare a commentare su tutto è forte. Ma non diventare un suggeritore. Scrivi se hai esperienze rilevanti, sai come riprodurre il bug, hai esperienze speciali nell’area, conosci la risposta alla domanda. Altrimenti non scrivere. E’ anche una buona idea sbirciare per un po’ in un forum prima di iniziare a scrivere, solo per vedere qual’è il contesto.
Impara il copyright, i brevetti, le licenze, i marchi registrati, e così via. Devi essere un po’ avvocato per essere coinvolto nel software libero. Questo significa che hai la responsabilità di educarti. Tradizionalmente, un modo per imparare è guardare le stesse stanche flamewar che vanno avanti da settimane nel newsgroup gnu.misc.discuss. Un modo più veloce è leggere il sito del progetto GNU, in particolare la loro analisi della terminologia. Non scrivere a proposito di questioni legali se non le capisci. Ma dovresti capirle se hai intenzione di scrivere software e applicarvi una licenza.
Rispetta le volontà del maintainer del pacchetto. E’ sempre bene usare la stessa licenza, lo stesso stile di programmazione, ecc. del pacchetto di cui stai per inviare una patch. Se usi CVS, non fare il commit senza prima chiedere al mainteiner del pacchetto.
Usa l’opzione -u per fare il diff quando invii una patch. Un punto di minore importanza, ma quasi tutti preferiscono questo formato di patch.
Ricorda che tutti sono volontari. Trattali con il rispetto che meritano; lavorano solamente perchè si divertono. E’ piuttosto inadeguato trattare male qualcuno che ti sta dando qualcosa gratis.
Focalizza il tuo lavoro. Molti di noi hanno problemi a fare ciò, ma più ti focalizzi su un particolare compito e lo finisci, più roba utile realizzerai. Ho capito che devo scegliere piccoli compiti per avere successo. Altre persone sono meglio per i progetti a lungo termine. Organizza i tuoi sforzi per adattarli alla tua personalità. Cerca di finire i progetti, piuttosto che iniziarne 100 troppo ambiziosi.
Impara dalla comunità. E’ una buona idea tenersi aggiornati con siti di notizie, come LinuxToday, LWN o Slashdot e anche siti relativi al particolare progetto in cui sei coinvolto. (I tre che ho menzionato sono solo tre che mi capita di leggere.) Un buon libro sulla storia della comunità è chiamato Hackers, scritto da Steven Levy. Anche www.gnu.org ha un sacco di informazioni, e sbirciando sulle mailing list imparerai molto.
Sarai criticato. Come assodato, non importa ciò che fai o dici, qualcuno ti criticherà. E’ così che funziona Internet. Le persone che non hanno imparato questa lezione ancora si adirano e attaccano non appena accade; non farlo. Se sbirci nelle mailing list, imparerai presto quali persone hanno valide obiezioni e quali sono criticatori abituali. (Non che siano mutualmente esclusivi; qualcuno dei più produttivi hacker sono anche enormi criticatori.) Sviluppa una pellaccia, ne avrai bisogno.
Divertiti. L’Hacking è infine lavoro; è stare seduto da solo e lavorare sodo al codice o alla documentazione. Ma ci sono molte occasioni di socializzare, alle conferenze, su IRC, via email. Anche programmare è speranzosamente divertente per la maggior parte del tempo. Quindi, goditela. Questo è parte del concetto. Non prendere questo documento, o ogni regola , troppo seriamente.
Link: I pensieri di Eric Raymond su questo argomento sono qui; il suo HOWTO descrive come unirsi alla “cultura hacker.” Sebbene la cultura non sia davvero necessaria per partecipare nei progetti di software libero, IMO. Finchè seguirai il modo di lavorare della comunità non dovrai interessarti agli aspetti sociali (a meno che tu voglia farlo). Advogato (l’alter ego di Raph Levien) ha anche lui un suo saggio, qui. Dopo aver letto tutti questi consigli, come dice RMS, felice hacking!