Come definire un programma open source

Completato

In questa unità vengono illustrate le considerazioni principali da tenere presenti per definire un programma open source.

Che cosa significa "open source"?

Un programma open source implica di più dell'accesso pubblico a una codebase. Richiede anche di aprire un progetto live a cui possa partecipare chiunque voglia essere coinvolto. Se eseguito correttamente per un progetto appropriato, un programma open source può contribuire a migliorare notevolmente la qualità del prodotto.

Uno dei motivi principali per cui le aziende creano progetti open source è il desiderio di coinvolgere la community. I progetti più popolari ricevono contributi significativi e gratuiti dalla community.

Non si tratta necessariamente di altruismo. Le persone e le organizzazioni utilizzano i progetti perché vi vedono un vantaggio per sé o per l'azienda. Quando il progetto non soddisfa le esigenze o le aspettative, altri utenti hanno la possibilità di risolvere i bug o di aggiungere funzionalità. Invece di conservare questi miglioramenti in fork privati, sono spinti a contribuire a tali modifiche nel repository di origine in modo che diventino parte della baseline del progetto. Questo ciclo virtuoso di miglioramento è il motivo per cui molte aziende producono software usando il modello open source.

Obiettivi del modello open source

In breve, la partecipazione al software open source prevede tre dimensioni:

• Utenti finali, che studiano o usano i repository di altri.
• Collaboratori, che sono attivamente coinvolti nel miglioramento dei repository di altri.
• Produttori, che creano e gestiscono i propri repository aperti ad altri.

Perché le organizzazioni possano valutare attentamente ciò che possono ottenere da ogni dimensione, è opportuno che facciano il punto della situazione attuale. Ogni dimensione comprende cinque livelli di processo.

• Ad hoc, senza processi in corso. Il successo dipende dalle singole attività.
• Gestito, con un processo parzialmente documentato. Il successo dipende dalla disciplina.
• Definito, con un processo documentato, standardizzato e integrato. Il successo dipende dall'automazione.
• Misurato, che è un processo gestito con tecniche quantitative. Il successo dipende dalla misurazione delle metriche rispetto agli obiettivi aziendali.
• Ottimizzato, con un processo che viene migliorato in modo continuo e affidabile tramite modifiche sia incrementali che innovative. Il successo dipende dalla riduzione del rischio di una modifica.

Per comprendere meglio la situazione attuale della propria organizzazione, vedere Open-source self assessments (Autovalutazioni relative al modello open source).

Che cosa rendere disponibile come open source?

Molti progetti non sono destinati ad avere successo come open source. Anche se i criteri possono essere diversi a seconda degli obiettivi e del livello di processo dell'azienda, di seguito sono riportati alcuni criteri che è consigliabile considerare prima di rendere disponibile un progetto come open source:

• Il progetto contiene una proprietà intellettuale che si vuole proteggere? In tal caso, il codice sorgente perderebbe valore una volta reso disponibile come open source. Non rendere disponibili come open source questi tipi di progetti, a meno che non si ritenga che i vantaggi siano superiori ai rischi.

• Lo stato del progetto è stabile e la qualità del codice è buona? Il progetto da cui iniziare non deve essere perfetto, ma se è in pessime condizioni, i potenziali collaboratori potrebbero rinunciare.

• Il progetto è utile per chi non fa parte dell'azienda? In caso contrario, è probabile che nessuno voglia partecipare.

• Le persone che non fanno parte dell'azienda sono in grado di contribuire? Devono avere accesso a tutte le dipendenze del progetto, ai processi di compilazione e a qualsiasi altro elemento necessario per eseguire il progetto. Se non possono avviarlo, non possono contribuire.

• Il team ha la larghezza di banda necessaria per supportare un programma open source? Se non è pronto, allora è meglio aspettare. Se si rende disponibile come open source un progetto senza supportarlo, si potrebbe perdere la possibilità di creare una community solidale.

Queste domande sono solo alcune delle considerazioni più comuni. Potrebbero esserci altri problemi aziendali o di conformità da tenere in considerazione.

Progettazione di un programma open source

L'esecuzione di un programma open source è simile all'esecuzione di un programma InnerSource, ma a livello pubblico. Di conseguenza, sono necessarie alcune considerazioni aggiuntive.

Definizione delle aspettative della community

File come README.md e CONTRIBUTING.md sono ancora più importanti perché vengono esposti a utenti che non conoscono il contesto aziendale. Devono essere valutati dal punto di vista di un utente esterno all'azienda perché risultino chiari a chiunque.

Anche il codice di comportamento è un importante criterio da divulgare. Lo standard prevede l'aggiunta di un file CODE_OF_CONDUCT.md alla radice del repository, per spiegare il comportamento previsto per i partecipanti alla community. Più gruppi dell'organizzazione devono esaminare questo documento, incluso il team legale. Fortunatamente sono disponibili molti codici di comportamento standard da cui poter iniziare. Molti progetti usano questi codici senza alcuna modifica. Per altre informazioni, vedere la guida ai codici di comportamento open source.

Formazione dei dipendenti per la gestione di un repository

I dipendenti potrebbero non avere esperienza nella gestione della community open source. Per aiutarli, è consigliabile che l'azienda metta a disposizione un set di guide che illustrino tutti gli aspetti principali da conoscere prima di iniziare. Queste guide devono essere pubblicate in un repository interno o in un portale accessibile solo ai dipendenti della società e devono essere riviste regolarmente. Le guide seguenti sono alcune delle più importanti:

• Una guida ai progetti da rendere disponibili come open source che fornisca un framework per decidere se un progetto candidato debba essere reso o meno disponibile come open source. Questa guida può essere strutturata come diagramma di flusso, set di domande o elenco di considerazioni.

• Un elenco di controllo per la configurazione che includa tutti gli elementi di lavoro che un team deve completare prima e dopo l'avvio di un progetto open source. Questo elenco deve includere la necessità di ottenere l'approvazione a rendere disponibile come open source il progetto, le revisioni del codice per assicurarsi che i dati sensibili vengano rimossi prima che il progetto venga pubblicato, un marchio o una ricerca dei progetti open source per assicurarsi che non esista un conflitto di denominazione e così via.

• Un elenco contatti con le persone più importanti dell'organizzazione che potrebbe essere necessario contattare qualora fosse necessario il supporto diretto dei gestori. Questo elenco deve includere le persone responsabili della sicurezza del software, della sicurezza del sito, degli aspetti legali, delle pubbliche relazioni e così via.

• Un collegamento a un repository di base che possa essere clonato come riferimento. Deve contenere un file README di esempio, la licenza, il codice di comportamento, la guida per i contributi ed eventuali altri file di supporto che ogni progetto open source dell'azienda dovrà includere. Non deve contenere nulla di cui potrebbe essere eseguito accidentalmente il push al pubblico.

• Una guida per il gestore che illustri le responsabilità di chi ha il compito di mantenere integro il repository. Queste responsabilità includono la necessità di mantenere aggiornata la documentazione del repository, di assicurare che i problemi e le richieste pull abbiano in modo tempestivo l'attenzione degli utenti preposti e così via.

• Una guida alle comunicazioni che offra ai gestori del repository le linee guida relative agli argomenti che non si vuole includere nei file pubblici come README.md, CONTRIBUTING.md o CODE_OF_CONDUCT.md. Può trattarsi di argomenti aziendali sensibili, ad esempio il divieto di parlare dei concorrenti, o di argomenti più generali relativi alla gestione, ad esempio come riconoscere in modo corretto i principali collaboratori.

• Una serie di domande frequenti interne con le risposte approvate alle domande più comuni. Questo elenco è particolarmente utile se esistono sfumature legali relative agli argomenti di cui l'azienda può parlare quando gestisce un programma open source.

• Criteri per le licenze in cui dovranno essere elencate le licenze approvate o rifiutate dall'ufficio legale per l'utilizzo o il contributo al modello open source.