FORSETI BLOG. Readcast. Ottobre 2013 Speciale Linux Day.

Transcript

1 FORSETI BLOG Readcast Ottobre 2013 Speciale Linux Day

2 Indice di Denis Turrina 3

3 Forseti Blog - Ottobre di Denis Turrina Denis Turrina Dottore in Sicurezza dei Sistemi e delle Reti Informatiche, Dottore Magistrale in Sicurezza Informatica; entrambe le lauree sono state conseguite presso il Dipartimento di Tecnologie dell Informazione (DTI) dell Università degli Studi di Milano, polo di Crema. Attualmente è dipendente della Consoft Sistemi S.p.A. presso la filiale di Milano. Gli interessi principali, oltre alla sicurezza in sé, sono il mondo Open Source, il diritto d autore e le problematiche legate alla privacy. Parafrasando Eric S. Raymond, ogni buon lavoro di sviluppo software inizia da un bisogno dell autore. Ho notato che, per quanto banale, spesso sia necessario un supporto semplice e immediato per l aggregazione di punteggi, siano essi i voti dati da una giuria a dei concorrenti o i propri voti universitari. La prima soluzione è indubbiamente l uso di un foglio di calcolo, ma c è bisogno di un software solitamente pesante per farlo funzionare. Ciò non si adatta bene ai tablet, uno strumento con funzionalità simili ad un computer (almeno nelle applicazioni base) ma con una portabilità straordinaria. Il bisogno in questione è quindi un applicazione che consenta di aggregare i vari punteggi rapidamente, con un interfaccia touch-friendly, al contrario dei fogli di calcolo (pensati per essere usati con la tastiera). Ho deciso di iniziare nel modo più corretto possibile: non scrivere codice di getto, ma partire da una lista dei requisiti il più possibile completa, con la coscienza che non saranno tutti immediatamente implementati. Il passo successivo è stato compiere una lunga serie di scelte: quale licenza applicare al codice, posto che l intenzione è avviare un progetto Open Source? Chi coinvolgere nel progetto, tra le persone che conosco? Quali altre figure sono necessarie? Dove mettere il codice in modo che sia pubblicamente accessibile? Poiché si tratta del mio primo progetto Open Source, ho cercato informazioni da qualcuno che ne sapesse più di me... come l autore di un libro. (Curiosamente, all interno del libro si invita proprio a cercare il sostegno e l aiuto di qualcuno che sia più esperto, quindi mi sono trovato sulla strada giusta.) La scelta, non troppo ampia in verità, è ricaduta su Producing Open Source Software di Karl Fogel. L autore è uno degli sviluppatori di Subversion, un software per il controllo delle versioni (uno dei due più usati, insieme a Git) open source. Ho così individuato i principali punti di attenzione, da tenere in considerazione quando ci si affaccia nel mondo open source in un ruolo così delicato come il project manager. L ordine di seguito presentato è volutamente diverso da quello del libro. Inoltre, non è indicato quali siano state le mie scelte: si tratta di considerare una serie di variabili spesso personali, mentre in questo articolo vorrei solo presentare il mio percorso. Comunicazione È essenziale comunicare nel modo corretto, perché la Community è composta da persone con diverse conoscenze, diversi caratteri e perciò diversa sensibilità in merito alle parole usate. Scrivere un non è come parlare faccia a faccia: una sfumatura nella voce, un sorriso, uno sguardo può far capire che si sta scherzando, o che si sta riprendendo una persona in tono bonario. Le stesse parole scritte su un messaggio di posta elettronica possono essere più facilmente travisate: il tono bonario può sembrare un attacco diretto, un consiglio può sembrare un imposizione. Le persone si Denis Turrina

4 4 Forseti Blog - Ottobre 2013 offendono facilmente, soprattutto quelle sensibili, e i programmatori sono molto sensibili... specie per ciò che riguarda il proprio lavoro. Oltre ad usare le parole giuste, è importanto avere una moltitudine di canali a disposizione: le non sono sufficienti, anzi, per motivi di privacy è opportuno utilizzare le mailing list. È consigliato anche avere un canale IRC per chat in tempo reale con gli utenti. Un sito Web, invece, aiuta a dare visibilità per il progetto e costituisce un single point of contact, cioè un luogo (virtuale) a cui chiunque può accedere e in cui si possono trovare tutte le informazioni necessarie. Risorse Oltre ai già citati sito web, mailing list e canale IRC, bisogna avere un repository su cui mantenere il codice sorgente e un issue tracker, che permette di tracciare la storia sia dei bug, che inevitabilmente verranno introdotti nell applicazione, che la richiesta di nuove funzionalità. In tal senso, esistono software che possono essere installati su un server di proprietà lo stesso che può ospitare il sito web e le mailing list. Tuttavia, si ottiene una buona visibilità anche affidandosi a quei servizi che propongono soluzioni chiavi in mano già pronte e collaudate, anche gratuitamente come (citando le tre più note) GitHub, SourceForge e Google Code. Ci sono poi le risorse umane: i programmatori, ovviamente, ma anche i tester, persone che possano (e vogliano, si tratta pur sempre di open source) curare i manuali utente e la documentazione, e gli utenti. Ogni utente deve essere trattato come se fosse un collaboratore, quindi è importante che anch essi si sentano coinvolti e possano fare le proprie richieste in modo semplice non tutti gli utenti sono programmatori. Dal privato al pubblico Quando si vuole rendere pubblico un progetto, è fondamentale passare attraverso due punti: la licenza e l annuncio. La licenza dipende strettamente dalla natura del progetto e dalla volontà dell autore. Ci sono licenze Open Source più o meno stringenti, più o meno intercompatibili e retrocompatibili, più o meno specifiche per la tipologia di progetto (ad esempio, la GNU Affero GPL è particolarmente indicata per software che funzionino attraverso la rete). È opportuno utilizzare licenze note, in quanto gli sviluppatori si muoveranno in un ambiente a loro familiare, evitando di aggiungere clausole che, in mancanza di supporto legale, probabilmente creeranno solo confusione. È importante anche prestare attenzione al contesto legale (ad esempio, la possibilità di porre brevetti sul software) delle nazioni in cui il software è sviluppato, cosa che le licenze classiche spesso già considerano. Il secondo aspetto è l annuncio: il maggior numero di persone possibile deve essere a conoscenza dell esistenza del software Open Source, e di come sia possibile collaborare. Questo punto diventerà importantissimo anche in fasi successive, quando il software sarà abbastanza maturo da prevedere nuove release. Per questo motivo, utilizzare le soluzioni già esistenti per il proprio repository è utile: chi programma software Open Source conosce già quegli ambienti, e sa come interagire con gli altri autori al loro interno. Ci sono molte altre problematiche da affrontare prima e durante la vita di un progetto Open Source. Tuttavia, questi punti devono essere necessariamente tenuti in considerazione prima di iniziare, perché hanno un impatto importante sul futuro del nostro progetto. Infine, è importante ricordare che nelle Community Open Source sono presenti persone molto esperte, che possono essere di grande aiuto anche nella futura gestione del progetto: in questo caso, a titolo personale, mi sento di consigliare a chi volesse intraprendere questa avventura una notevole dose di umiltà. Denis Turrina

5

6 Associazione FORSETI via Camillo Benso Conte di Cavour, VARESE (VA) CC BY: $\ Documento rilasciato con licenza Creative Commons BY-NC