Niente caramelle dagli sconosciuti: strutturare un progetto open source

Molto spesso chi si approccia per la prima volta alle dinamiche di tipo open source rimane invischiato in approcci un po’ troppo company-oriented, con il risultato che il prodotto finale non risente del benefico influsso del feedback dell’utente. Abbiamo analizzato l’importanza di questo elemento nell’articolo precedente, e proprio riguardo questo c’è un ulteriore elemento di disquisizione: che succede cioè quando invece di dimostrare un po’ troppa “timidezza” nei confronti degli utenti, una compagnia dà troppo spago ai suoi contributori volontari?

Ovviamente non esiste una soglia specifica per un’analisi di questo tipo, e sta all’analista in questione mettere in gioco i propri paletti e stabilire con criterio quali contributi vadano ricercati ed accettati, frenando anche alla bisogna tutto il materiale che viene inviato di cui non si sente il bisogno, e che andrebbe anche ad infettare l’identità del prodotto, se c’è in gioco anche un discorso di brand identity. La conseguenza peggiore infatti di tutto questo è che si venga soverchiati, letteralmente, dalla propria community, e si possa essere costretti a delle maniere brusche per rimettere ciascuno al proprio posto, nel ruolo che gli compete. È necessario quindi un grosso lavoro a monte? Dipende dall’entità del progetto e dalla grandezza del coinvolgimento che ha la comunità nello stesso.

Vediamo quindi insieme come applicare dei controlli precisi per non dover essere sgradevoli in seguito rifiutando l’opulenza di correzioni e suggerimenti che una comunità legata a doppio filo al nostro ciclo di sviluppo può fornire.

Chi ha fatto cosa, quando, e a che ora: il changelog

Spesso uno strumento di cui viene sottovalutata l’importanza è il cosiddetto changelog, ovvero un file nel quale vengono tracciate tutte le modifiche fatte progressivamente ad un’opera come quella che potrebbe essere un software; in questa maniera chiunque ha accesso all’elenco dei cambiamenti e può vedere se il suo contributo in una determinata è ancora necessario. Un progetto senza un changelog pulito, o senza comunque delle tecnologie di tracciamento dei progressi fatti, rischia seriamente di venire subissato da contributi inutili e ridondanti; per la riuscita dell’open sourcing di un progetto, è utile massimizzare l’afflusso di contributi nelle aree dove c’è bisogno, e di questo parleremo in seguito.

Come dicevamo quindi, un changelog mantenuto regolarmente (o mezzi simili) può essere un buon punto di inizio per rinforzare la potenza di un team di contributori volontari con un modello di gestione a “blob”, ossia un po’ come capita.

Bugzilla! Ovvero cosa resta da fare

Dopo il “cosa è stato fatto”, che abbiamo affrontato parlando del changelog, rimane un punto fondamentale: cosa resta da fare? Cosa bisogna portare a compimento, preferibilmente in un tempo che non sia tendente ad infinito? Uno strumento carino che fornisce una utility di questo tipo è BugZilla: ci sono un sacco di progetti simili (tutti rigorosamente open source) atti a creare collaborazione tra i membri di uno o più team, tuttavia ho scelto BugZilla perchè mi sembra il più adatto, dato che viene utilizzato da tutti i principali progetti aperti in circolazione – come Linux, per fare un esempio. Vi dice niente questo nome?

Mettendo da parte l’incenso, BugZilla è un software che permette di tracciare i problemi che hanno gli utenti, e di attivare delle discussioni in merito a queste criticità: in questo modo per una comunità sarà molto più facile individuare la fonte del problema ed attivarsi per aggiustare il tutto; questo a prescindere dal fatto che il progetto sia guidato dalla community stessa, oppure con una forte componente aziendale dietro. Approcci di questo tipo permettono anche un secondo tipo di segnalazione, ovvero la “feature request”, una prassi abbastanza comune nei progetti aperti: un utente è libero di fare la propria proposta per una caratteristica aggiuntiva che a suo parere migliorerebbe l’opera di molto; se poi questa proposta verrà valutata positivamente da un numero sufficiente di persone, allora vorrà dire che varrà la pena di spenderci del tempo… almeno virtualmente. Può infatti capitare che ci siano feature request, diciamo, sconclusionate, le quali non meritano attenzione. Parleremo tra poco quindi anche di come rifiutare questo tipo di contributo.

Caramelle dagli sconosciuti: rifiutare un contributo

Mettiamo il caso che al nostro progetto di esempio sia arrivato un contributo che non serve, sia esso del codice che ripara una falla già “aggiustata” da qualcun altro, oppure una feature request duplicata o assurda. Può capitare che il contributore non abbia letto bene il changelog, o non abbia ricercato con sufficiente concentrazione sul BugZilla, e affrontare criticità di questo tipo nella maniera giusta può fare la differenza tra il fallimento e la vittoria nello sviluppo di una soluzione aperta.

E mentre l’effetto di una reazione un po’ scomposta da semplici membri della comunità può scivolare addosso, la mancanza di tatto da parte del project manager, peggio ancora se fa parte della stessa compagnia, può essere devastante: l’open source è fatto da persone, e come possono esserci bravi programmatori, buoni sistemisti e grandi coordinatori, si possono incontrare anche tante primedonne, e contributori che possono non vedere di buon occhio lo scarto del proprio lavoro. È opportuno rivolgersi a questi con tatto: se arriva un contributo che non serve, perchè l’obiettivo è stato già raggiunto da qualcun altro, si può comunque dedicare qualche secondo (o minuto) ad analizzarlo, e a vedere se può essere competitivo rispetto alla soluzione fornita da un altro membro della comunità; in caso negativo, è possibile semplicemente dire “no grazie” invece che “no” e basta. La comunità che prende parte al progetto è la nostra risorsa, e dobbiamo tenerci caro ogni suo membro il più possibile (ovviamente poi se c’è qualcuno che esce dai gangheri, lo si manda a quel paese tranquillamente, ma senza esagerare); rifiutare cortesemente, magari dire: “Grazie, ora come ora non serve questa patch, ma ci ragioneremo su” può decretare la vittoria della compagnia presso la mente delle persone, che vedranno un brand cortese e leale presso i propri contributor.

E per le feature request? Beh, stesso discorso, con un punto in più: nell’accettare consigli della comunità sul cosa fare piuttosto che sul come farlo, bisogna tenere presente che ci si espone a un pubblico che a buon bisogno ha una preparazione nettamente inferiore a quella dei dipendenti preparati per sfornare soluzioni leader nel settore: dobbiamo quindi escludere i contributori dal mettere bocca anche sulle feature? Ci sono casi in cui è opportuno farlo, ma per la maggioranza delle volte no; nonostante la preparazione a volte inferiore, privarsi del feedback comunitario riguardo le caratteristiche di un prodotto è sempre un male, poiché anche dalla mente meno elevata può essere prodotto, in un lampo di genio, quel non-so-ché il quale può rendere la tua soluzione vincente su tutte le altre.

Lesson learned? Lesson learned. Quando gli sconosciuti ti offrono delle caramelle, bisogna valutare se effettivamente servono. E nell’ecosistema open source esistono gli strumenti per farlo.