Partecipando al Linux Day di quest’anno, mentre il pubblico si sorbiva con calma le mie slide, ha potuto osservare anche la mia esibizione in un “cazziatone” di proporzioni bibliche verso le aziende che pubblicizzano il loro fare open source, mentre in realtà la community che ribolle e si smuove non viene gestita da nessuno, e non ha poi molto modo di interagire con la compagnia; c’è una barriera vetrosa e impalpabile, in molti casi, la quale isola il contesto aziendale dalle meccaniche aperte e che fa sì molte volte che il lavoro della comunità relativa ad un progetto portato avanti da un’azienda (quindi company-driven) venga male integrato, male interpretato, gettato, sprecato.
Concorderete con me che non è modo, questo, di far sentire tale un contributor il quale con i suoi consigli, il suo codice, ed in prima battuta il suo tempo, risorsa che nella società attuale non basta mai, sta prendendo parte nei processi decisionali del proprio prodotto, e lo sta arricchendo del suo particolare e personale bagaglio di conoscenza. Per questo motivo quello che ricordo con molto piacere a chiunque mi chieda consigli su come far crescere un’applicazione, un programma, un prodotto qualsiasi dal punto di vista della community, che per vedere un’esplosione rigogliosa da questo punto di vista bisogna stimolare, e prendersi cura delle persone. In che modo? Ce n’è uno solo: attraverso delle persone, pagate, all’interno dell’azienda, che abbiano tra le attività indicate nel proprio mansionario pure quella di coordinare, anche in maniera blanda, il lavoro fatto dai contributori esterni, e di raccogliere i feedback, e di abbozzare molto lievemente l’integrazione di feature mal progettate all’interno del progetto iniziale.
Abbiamo quindi una sola via da intraprendere, per far si che il nostro prodotto open source goda di un’ottima reputazione presso le persone che lo sviluppano dall’esterno: in primo luogo, condurre un assessment preliminare sui costi (mensili e/o annuali) portati dall’aprire il nostro sviluppo al pubblico. Oltre il mansionario sopra elencato, conviene tenere in conto nella nostra analisi arbitraria anche un monte ore supplementare per gli ingegneri del software; questo monte ore/uomo andrà applicato in maniera cumulativa e il massimo che questo numero può raggiungere sarà funzione di quanto vorremo “stare a sentire” la community.
In secondo luogo, quando avremo sbrigato la burocrazia, dovremo mettere in atto il nostro documento preliminare: è consigliato l’uso della metodologia agile in azienda, nonché l’integrazione di domande nei nostri meeting periodici per capire se quello che stiamo facendo sta funzionando, quale appeal ha il prodotto, e quanto è interessante il ciclo di sviluppo per chi è all’esterno. Annualmente, ci troveremo davanti al bilancio, e potremo decidere se mantenere le cose come stanno, o se correggere la rotta rivedendo i piani a fronte di un ritorno di investimento troppo basso. Starà a noi quindi la decisione di continuare con un reparto a workflow costante, se dedicare altro personale alle “cortesie per gli ospiti”, oppure effettuare dei tagli nello specifico riallocando le risorse di cui disponiamo su altri compiti, interni al ciclo di vita del prodotto e all’azienda.
Alessio Biancalana | @dottorblaster
Open source for companies: treat your community well
Sometimes companies approach the open source community the wrong way, believing that the ROI will be big even with a minimum effort.
Are people really so easiliy deceived, or does the perception of how much a company believes to its own product matter, along with a working flow in which the community is heavily integrated?
Participating at today's Linux Day, as the public calmly read my slides also had the opportunity to observe my exhibition in a biblical proportion scolding of those companies who advertise their open source, while in reality the community that is in turmoil isn't managed by anyone, and doesn't have any way to interact with the company itself; there's a transparent, impalpable barrier, in many cases, which isolates the company context from the open mechanics, which makes the work of the community on a project carried on by the company (company driven) is badly integrated, understood, wasted.
You will probably agree with me on the fact that this is not the way to make a contributor feel, someone that with advice and code and time, resource that is so scarce in our current society, is taking part in the decisional processes of his product, and is enriching it with his particular and personal knowledge. This is the reason why I remind anyone who asks advice on how to make an app, a program, or any product grow from the point of view of the community, that in order to see a growth explosion you must stimulate and take care of people. How? There's only one way: thanks to a few paid people inside the company, that among their activities also have the role of coordinating - in a very bland way - the work done by external contributors, of gathering feedback, and design the integration of features that were ill projected inside the initial plan.
Alessio Biancalana | @dottorblaster