Il dedalo della collaborazione

Supponiamo di aver studiato a fondo un linguaggio di programmazione, anche due, anche tre o come me che, per forza o per diletto, conosco ad alto livello la grammatica di almeno 4-5 linguaggi (C/C++, Java, Python e Scheme). Supponiamo che abbiamo consumato la nostra ragione e la nostra tastiera in esempi e piccoli progetti personali.

Adesso siamo pronti. Pronti per affacciarci nel meraviglioso mondo dell’Open Source! Dove chiunque può collaborare al progetto che più lo aggrada oppure può inserire il loro piccolo progetto all’interno del mare di progetti liberi e aperti alla collaborazione globale!

O no?

Beh non proprio. O meglio… funziona così almeno in teoria. La pratica, d’altro canto, è una specie di incubo.

PROGETTO PERSONALE O COLLABORAZIONE?

Non c’è nulla di più stimolante ed istruttivo che programmare in gruppo. Il gruppo diminuisce il carico di lavoro, velocizza l’apprendimento di librerie e triplica le idee. Sfortunatamente formare un gruppo solido necessita di parecchia fatica.

Il primo dubbio per il novello collaboratore è: porto avanti un mio innovativo progetto o collaboro ad un progetto già esistente? Il problema dei progetti personali è che raramente sono innovativi e non sempre si ha un idea carina in testa. Quindi perché aggiungere, ad esempio, un player audio nel campo già saturo dei player audio?

Partecipiamo ad un progetto allora! Scegliamone uno nel marasma dei progetti esistenti, leggiamo alcune piccole faq e ci scarichiamo anche i sorgenti. Poi il nulla.

Si perché conoscere un linguaggio, anche nelle sue formule più arcane, non ci da nessuna mano per affrontare un progetto vero e proprio, allo stesso modo di come saper usare somma, sottrazione, moltiplicazione e divisione non ci rende automaticamente matematici esperti. Ogni progetto, infatti, usa le sue librerie, a volte tali librerie sono “personalizzate”, sono strutturate in modi particolare, etc.. etc… con il risultato che il novello collaboratore rimarrà per minuti a fissare il codice sorgente con la faccia a punto interrogativo perenne. Finché desiste.

I punti critici qui sono due: scarsa conoscenza delle librerie specifiche e scarsa documentazione del codice. Il primo è inevitabile, nessuno può conoscere tutte le librerie esistenti (siano esse le OpenGL, o l’interfacciamento a gstreamer o a Xine o qualunque altra cosa vi venga in mente) e spesso un progetto di media complessità ne utilizza anche due-tre insieme. Il secondo invece è dovuto da una scarsa apertura degli sviluppatori del progetto.

Progetti piccoli sono solitamente scarsamente documentati mentre progetti grandi sono (per le loro natura di “grandi”) estremamente documentati (ma anche poco alla portata del novello collaboratore). Tenete presente poi che per documentazione non intendo la semplice lista delle API ma qualcosa di più alto: come sono organizzati i moduli, quale modulo fa cosa, quale sono le convenzioni utilizzate nella stesura del codice (e poi magari anche qualche bozza di diagramma delle classi non sarebbe male).

Questo fa parte della difficoltà di accesso a progetti esterni. Manca, purtroppo, un meccanismo che accompagni e guidi i collaboratori all’interno del codice.

RESTO SOLO IO!

A questo punto, a meno che non si è stati estremamente fortunati, si deve ripartire da soli. Ma cosa fare da soli? In teoria qualunque cosa, in pratica solo roba semplice. Questo perché non si può scendere in campo a cercare collaboratori e per avere speranze di recuperarne qualcuno che non faccia solo presenza, bisogna avere almeno un qualcosa di funzionante e se il progetto è troppo complesso quel “qualcosa di funzionante” potrebbe non arrivare mai.

D’altro canto un progetto troppo semplice spesso è banale e non attira l’interesse della comunità. Esiste una soglia di “massa critica” per i progetti open source dopo la quale il progetto cresce esponenzialmente e sotto la quale il progetto si spegne. Raggiungere tale soglia è quasi sempre un impresa titanica.

CONCLUSIONI

Esiste quindi una specie di selezione naturale? Solo i migliori vanno avanti? Si, in un certo senso si ma la mia visione è completamente differente. Io credo che ci sia un enorme mare di potenziale non sfruttato della comunità, di persone che hanno difficoltà a partire ma che con i meccanismi giusti potrebbero dare molto. Eppure rimangono la, parcheggiati per anni, inattivi. Un mare di “forza” che è inutilizzato a causa di spigoli che bisognerebbe smussare.

Non do soluzioni perché al momento non ne ho. Però vorrei far riflettere su questo e magari sensibilizzare di più chi un suo progetto attivo ce l’ha già.

Categorized: News

6 comments on “Il dedalo della collaborazione

  1. Eh… purtroppo è vero. Il tutto è reso ancora più difficile dalla distanza. Mi sono buttato in qualche progettino (tutti estremamente semplici e più che altro autodidattici)…poi magari il tempo scarseggia, la massa critica di utenti interessati non viene raggiunta e tutto rimane sospeso.

    Purtroppo per i progetti già attivi le barriere all’ingresso ci sono e sono molte. Credo che oltre che sbatterci la testa non ci si possa fare molto. Quello che però possiamo fare è tenere sempre ben presente questi problemi quando iniziamo un nuovo progetto.

    • KDE di carino proponeva dei “corsi” chiamati klassroom in cui programmatori di KDE esperti istruivano le nuove reclute. Questo è un meccanismo molto simpatico che grandi progetti potrebbero adottare.

  2. Tieni presente che secondo me alcune volte si hanno delle belle idee che però non possono essere applicate a progetti già presenti oppure non possono essere inserite in progetti più grandi poichè potrebbero essere non notate per via della “dispersione” che i grandi software hanno….

    Ci dovrebbero essere i presupposti sia per collaborare che per non farlo….

    • Ovvio. Se uno ha “l’idea rivoluzionaria” è più facile che la porti avanti da se piuttosto che cercare di forzarla all’interno di progetti già maturi.

    • Credo sia un pensiero diffuso. Se io con una laurea in ingegneria informatica e 5 linguaggi alle spalle faccio fatica a entrare nel meccanismo immagino chi si avvicini alla programmazione in modo “amatoriale”!