How to Open

Il modello di sviluppo opensource oramai domina buona parte del mondo software e, oltre alle ben note applicazioni che tutti usiamo, non di rado capita di imbattersi in piccoli ma utili progetti, intesi a risolvere una qualche esigenza specifica di una nicchia specifica, pubblicati da parte di qualcuno che vuole condividere il suo lavoro con altri. Eppure altrettanto spesso vediamo che vengono compiuti piccoli grandi errori di carattere operativo e metodologico, motivati forse da un troppo precipitoso entusiasmo nella pubblicazione del codice e dalla scarsa dimestichezza col modello stesso, che limitano il potenziale benefico di tali opere.

Tantissimi sono i progetti che si autodefiniscono “opensource”, quando poi sul sito si trova un archivio compresso con il codice sorgente e nulla più. Ma “opensource” non è solo “pubblicare il codice”, bensì svilupparlo e farlo crescere insieme. Per trasparenza e condivisione, ma soprattuto per il bene stesso del progetto: più è facile per una nuova persona avvicinarsi al suo sviluppo e più è facile coinvolgere sviluppatori che possano dare una mano, anche solo con un piccolo contributo occasionale.

Rinunciare ad adottare alcuni accorgimenti ed un metodo davvero “opensource” vuol dire non trarre nessun beneficio dalla propria scelta di aprire ad altri il codice, ma accollarsi tutti gli oneri. Questa è, purtroppo, una delle principali cause di estinzione di buona parte dei progetti in circolazione.

Questa pagina si rivolge a coloro che vogliono pubblicare un proprio nuovo software, o già lo già fatto ma senza badare molto alla forma, o che sviluppano e mantengono una applicazione freeware e vorrebbero renderla opensource, e vogliono non solo aprire il proprio lavoro ad altri ma giovare loro stessi degli impliciti benefici dell’opensource.

Strumenti e Opportunità

Ci sono numerosi strumenti che possono essere allestiti a contorno di un progetto di sviluppo software, per rendere più comodi ed efficaci i processi di pianificazione, sviluppo, testing, manutenzione e miglioramento del codice, e fortunatamente su Internet esistono numerosi servizi che li integrano affinché possano essere rapidamente ed efficacemente adottati.

Tra questi, citiamo:

  • Logo SourceForgeSourceForge: fino a qualche anno fa era il più noto e popolare, anche se opinabili scelte nella gestione del sito hanno fatto fuggire parte del suo pubblico. Risente soprattutto della mancanza di strumenti di collaborazione più immediati, adottati da altri;
  • Logo GitHubGitHub: ad oggi la piattaforma più utilizzata, che facilita molto la possibilità di terzi di inviare modifiche e correzioni al codice. Gratuito per i progetti opensource, a pagamento per progetti chiusi;
  • Logo GitLabGitLab: simile a GitHub, ma a sua volta sviluppato come progetto opensource. È possibile utilizzare gratuitamente il servizio online, o, se si ha tempo e capacità, installarne una istanza su un proprio server (e condividerla con altri).

Tutte queste piattaforma integrano una serie di strumenti estremamente utili, se non indispensabili, per agevolare lo sviluppo collaborativo ed abbassare il più possibile la soglia di accesso per aspiranti nuovi collaboratori. Più la soglia è bassa, più sarà facile il reclutamente spontaneo.


Il bug tracker (o issue tracker)

Laddove una mailing list o un forum sono canali comodi per fornire assistenza agli utenti del proprio software, la disponibilità di un bug tracker garantisce una assai più agevole e conveniente gestione delle segnalazioni. Utilizzando uno strumento ad-hoc si può tenere individuale traccia di ogni problema riscontrato, ma anche delle richieste di feature e delle funzionalità che si vogliono integrare in versioni future. Rendere pubbliche e facilmente consultabili tali informazioni non solo permette agli utenti di sapere come e quando un certo problema è stato risolto (o eventualmente di sollecitare una risoluzione, sintomo del fatto che il problema tocca più persone e forse merita una priorità più alta), ma facilita i nuovi potenziali collaboratori a capire rapidamente “cosa c’è da fare” e magari prendersi carico di un compito; in questo modo si possono intercettare occasionali contributi, magari modesti e mirati ma comunque benefici per la manutenzione e la stabilità del progetto a lungo termine.

Non temere di ricevere segnalazioni di errori e di lasciare che siano pubbliche sul bug tracker: un progetto che non riceve segnalazioni è un progetto che non usa nessuno e dunque poco appetibile. Il punto non è far sapere agli altri che esistono problemi (quale software non ne ha?), ma come questi problemi vengono gestiti. Anzi: incoraggiare a segnalare i problemi aiuta a farli emergere e a correggerli prima che vadano a discapito di qualcun altro.

Il repository

Pubblicare occasionalmente un archivio compresso con l’ultima versione aggiornata dell’applicazione è certo consigliabile, ma ancor più consigliabile è tenere il tutto su un repository, su cui risiede il codice “vivo” in fase di sviluppo, aggiornato ad ogni singola modifica effettuata. Il sistema più utilizzato oggi è GIT (integrato nelle tre piattaforme di cui sopra), consigliato per via di una serie di facilitazioni rispetto al suo predecessore (il sistema SVN).

Storicizzare ed esporre pubblicamente non solo le versione stabili ma anche ogni modifica che avviene tra una versione e l’altra è estremamente utile per una serie di fattori: permette di risalire facilmente a quando e come è stata apportata una modifica (la quale magari ha introdotto un bug), rappresenta una implicita copia di backup del proprio codice, permette a chi è esterno al progetto di vedere quanto frequentemente il codice viene effettivamente aggiornato (anche se tra una versione e l’altra passa un anno), e più di ogni altra cosa facilita l’inclusione di modifiche fatte da terzi evitando o comunque limitando il rischio di “conflitti” tra modifiche diverse fatte da persone diverse in tempi diversi (con tutti i grattacapi che ne derivano).

Abituati ad usare un repository anche se – almeno per ora! – sei da solo a lavorare sul progetto: per i motivi di cui sopra tenere sempre aggiornato il proprio repository comunica il fatto che il codice è vivo e mantenuto, anche se è passato qualche tempo dall’ultima versione stabile. Su Internet si trovano facilmente guide e tutorial per GIT, anche in italiano.


Utilizzare in parallelo un bug tracker ed un repository permette di tenere sempre aggiornati tutti – in primis coloro che si imbattono nel progetto per caso e lo reputano interessante e meritevole di supporto – in merito ai progressi fatti, e rende molto più immediato ad altri il poter contribuire con una patch.

Licenza

La licenza è a tutti gli effetti un contratto col quale l'autore del software dichiara cosa gli utenti possono o non possono fare. Non pensare che il software rilasciato con una licenza libera sia completamente fuori controllo: ciascuno deve rispettare delle regole, e se non lo fa è assolutamente lecito fargli mandare una lettera da un avvocato e procedere per vie legali per mancato ossequio del suddetto contratto.

Ci sono numerose licenze tra cui scegliere, ciascuna con un diverso grado di libertà concessa all'utente e con diversi requisiti, e alcune di queste non sono compatibili tra di loro. In linea di massima, è raccomandato:

  • non inventarsi nuove licenze, ma adottarne una già diffusa e popolare. Questo per evitare ulteriori frammentazioni, incompatibilità, ed ambiguità in caso di disputa legale. Ogni licenza ha diversi gradi di "personalizzazione" che permettono di intervenire puntualmente su alcuni fattori
  • GPLv3per il software destinato all'uso desktop o embedded è consigliata la GPLv3, che non solo garantisce le quattro libertà fondamentali del software libero agli utenti ma impone loro di garantirle anche ad altri cui loro stessi distribuiranno il software
  • per il software destinato all'uso web è consigliata la AGPLv3, molto simile alla GPLv3 (e con essa compatibile) ma che estende sia le quattro libertà che i vincoli sul copyright anche a chi accede al software online

Per essere completamente tutelati è necessario essere rigorosi nell'applicazione della licenza, ed evitare ogni ambiguità. È pertanto consigliato:

  • esplicitare nel readme file del progetto il copyright, ovvero nome e cognome della persona (oppure il nome dell'organizzazione) che detiene i diritti dell'opera. Nota bene: il concetto di copyright non è in conflitto con quello di licenza libera, anzi il copyright è esattamente lo strumento con cui l'autore del software dichiara di possederne la proprietà intellettuale e pertanto il diritto di applicarvi una licenza; senza copyright, non può esistere licenza
  • allegare al progetto un file license che contenga il testo integrale della licenza scelta
  • includere in cima ad ogni file sorgente un commento, una intestazione che riporti nuovamente il copyright, la licenza di riferimento, e qualche riferimento per approfondire. Gran parte delle licenze contengono suggerimenti a tal proposito, ad esempio la GPLv3 consiglia il seguente formato:
    [Nome e breve descrizione del programma]
    Copyright (C) [2017]  [Mario Rossi]
    
    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.
    
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see http://www.gnu.org/licenses/.
    
  • pressoché ogni licenza opensource implica di mantenere, in eventuali prodotti derivati, chiare e leggibili le informazioni sul copyright originale, benché il modo in cui queste informazioni vengono visualizzate può essere interpretabile. Per quanto riguarda GPLv3 e AGPLv3 è possibile specificare quella che viene considerata dall'autore una "Appropriata Nota Legale", ovvero il modo e la forma in cui si vuole che queste informazioni siano rese visibili; anche in questo caso, per buona misura è raccomandabile accompagnare questi dettagli ad ogni indicazione del copyright (nel readme file e nelle intestazioni dei file sorgente)

Consigli Vari

Ogni progetto che si rispetti ha un nome ed un logo. Non sottovalutare questi elementi, sono molto importanti per comunicare il tuo progetto. Su OpenClipArt trovi tanti begli elementi in grafica vettoriale, rilasciati in pubblico dominio, da usare per elaborare un tuo logo.

Dato un nome ed un logo è anche facile provvedere ad un sito web che spieghi in poche parole a cosa serve, dove di scarica, come si usa, ed i link agli strumenti di collaborazione di cui sopra. Non è difficile trovare su Internet templates HTML già pronti da personalizzare e pubblicare su uno spazio web.