Le sfide del modello open source

Per sua natura il sistema di sviluppo open source pone delle sfide peculiari sconosciute all’ambiente di sviluppo tradizionale; prima di affrontare dunque gli strumenti di design e organizzazione del lavoro che sono nati per risolvere queste problematiche diamone una breve panoramica.

Difficile integrazione del software

Quella dell’integrazione del software è in realtà una vecchia sfida che viene enormemente amplificata nell’ambito FOSS. Per integrare le nuove feature sviluppate in un software stabile diversi modelli avevano costruito le proprie pratiche:

• Nel modello a cascata l’integrazione era una fase circoscritta e a sé stante.
• A tale struttura molto rigida si contrappone lo schema innovativo Stabilize & Synchronize nato in ambiente Microsoft: durante il giorno gli sviluppatori lavorano sul proprio pezzo di codice in cui sono responsabili, e di notte il software viene ricompilato da zero. La mattina dopo, si avevano dunque due possibilità:
  • la compilazione falliva, il responsabile veniva trovato e “punito”;
  • la compilazione aveva successo, il software integrato è quindi nella “versione migliore possibile” (questa versione migliore non è per forza una versione stabile).
• In XP l’integrazione veniva eseguita più volte al giorno in modo esclusivo: un solo sviluppatore alla volta poteva integrare il proprio lavoro sull’unica macchina di integrazione disponibile; questo permetteva di individuare facilmente eventuali problemi di integrazione e risolverli con rapidità.

Ma come organizzare l’integrazione nel mondo open-source? Per sua natura, in questo ambito l’integrazione viene eseguita continuamente e senza coordinazione a priori (questo anche perchè il team è sparso): è anarchia totale, con lo svantaggio che da un giorno all’altro una enorme parte della codebase potrebbe cambiare in quanto un singolo sviluppatore potrebbe integrare mesi e mesi di lavoro in un’unica botta. Vedremo più avanti che strumenti si sono costruiti per contenere tale problematica.

Sfaldamento del team

Nell’open source nascono inoltre problemi riguardanti la gestione del team. Occorre decidere:

• come comunicare
• come tenersi uniti
• come coordinarsi
• come ottenere nuove collaborazioni

Per comunicare si utilizza di solito internet: si potrebbe dire che senza internet non potrebbe esistere il concetto stesso di open source. In particolare si utilizzano spesso dei forum per organizzare il lavoro, in modo da tenere la community unita e rispondere dubbi ai nuovi utenti.

Per quanto riguarda il coordinamento del lavoro approfondiremo nelle prossime lezioni vari strumenti per la sincronizzazione del lavoro e di versioning per codice (come git). Per quanto riguarda le documentazioni inizialmente venivano sfruttate le wiki, anche se ora sono poco utilizzate (github e gitlab ad esempio le supportano ancora) in favore di siti compilati contenenti la documentazione del software. Questi siti sono chiamati Pages e per crearli vengono sfruttati tool basati su markdown (anche in questo caso può essere utilizzato git per fare versioning della documentazione).

Deve poi essere facile, addirittura banale, poter compilare il codice e ricreare l’ambiente di sviluppo omogeneo per tutti; si utilizzano quindi strumenti di automatizzazione delle build (come i Makefile) in modo che chiunque voglia partecipare possa farlo indipendentemente dalla propria configurazione software e hardware.

È infine importante educare i reporter dei bug e avere un sistema per organizzare per le segnalazioni di errori: il sistema dovrebbe essere accessibile a tutti in modo da evitare segnalazioni duplicate e consentire una facile organizzazione delle stesse. Vedremo più avanti come anche una segnalazione d’errore avrà il suo “ciclo di vita”.