Comunità VS azienda: chi deve guidare il progetto?

Spesso durante la gestione di un progetto si commette l’errore di dare troppo respiro alla propria comunità, complice il desiderio di veder fiorire una serie di contributi, magari categorizzabili e ordinabili. Il problema che sorge nel costruire un approccio al business open di questo tipo è che necessariamente si ha bisogno di alcune strutture di controllo, come abbiamo visto nell’articolo precedente, ma anche di “controllori”. La questione fondamentale quindi si pone nei termini in cui possa essere meglio lasciar prendere le redini del tutto alla comunità, oppure se possa essere auspicabile dotare il proprio progetto di una forte parte aziendale.

Per ognuna delle due scelte si hanno pro e contro: non è possibile stabilire a priori se uno scenario sia auspicabile rispetto a quello concorrente; sono semplicemente due strategie diverse da applicare con business, ecosistemi e soprattutto obiettivi diversi.

Company-driven: le redini in mano all’azienda

In generale per un’azienda, non importa di quale dimensione, che sia alle prime armi con la lama a doppio taglio del business open source, può essere consigliabile un approccio company-driven, ossia quello in cui la compagnia mantiene saldamente le redini dei suoi prodotti e dei suoi processi di sviluppo, accettando contributi esterni fortemente vagliati all’interno dell’azienda e che siano aderenti a degli standard stretti, imposti dall’alto, che non consentano, quindi, la traformazione di un prodotto o di una parte di esso in qualcosa di più articolato senza avere delle specifiche autorizzazioni. Il pregio di questo tipo di tecnica è che i contributi vengono tenuti maggiormente sotto controllo, vengono impartite delle istruzioni precise e i contributori avranno la sensazione di trovarsi in uno schema ben delineato, organizzato.
Può sembrare che non ci siano punti di scontro con gli utenti, ma non è così: sistematicamente alcuni contributori avranno infatti l’impressione di vivere la propria esperienza in una gabbia dorata, ed alcuni sicuramente resteranno delusi dal fatto che i contributi siano filtrati in maniera così forte.

È quindi essenziale curare la relazione con la propria community affinchè vengano smussati i punti di eccessivo attrito con la logica obbligatoriamente aziendale di un approccio di questo tipo.

Community-driven: la comunità come organo di decisioni

La comunità delusa potrebbe trovarsi a demandare un approccio maggiormente comunitario: ma che succede quando un intero progetto è a conduzione comunitaria? Non è assolutamente facile affidare una soluzione ad una comunità lasciando che vengano gestiti tutti gli aspetti dello sviluppo senza un coordinamento di tipo aziendale e, se vogliamo, utilitaristico. Guardiamo ai fatti: andrebbe lontano un progetto senza qualcuno alla guida che lo strutturi in maniera sensata e non abbia anche qualche pretesa? Il pregio di un sistema community-driven è la totale assenza di controllo da parte di un’azienda, e quindi la totale libertà anche di figure come i project manager di poter gestire il proprio contributo senza essere vincolati ad alcun business plan. Un’azienda però che voglia ricavare qualcosa dal progetto può essere messa in seria difficoltà dalla mancanza di organizzazione che in casi estremi può essere presente con un approccio simile.

Certo, comunità molto attive possono permettersi con un grande afflusso di contributi di lasciare che l’azienda stia nella bambagia consegnando un prodotto supportabile per anni grazie allo sforzo di volontari che contemporaneamente ne beneficiano in infrastrutture di stampo più “casalingo”, tuttavia quanto può essere sano per un’azienda poggiare il proprio business solamente su una comunità, facendone tutt’al più parte senza poter impartire alcuna direttiva?

Azienda e community: un approccio ibrido

Pur esistendo casi di studio di successo e casi analoghi di fallimento critico di progetti open source per entrambe le due soluzioni progettuali, ciò che è consigliabile è adottare un approccio misto: una compagnia a capo del tutto, che tuttavia permetta ampio respiro alla comunità. Per progetti piccoli, la questione è facilmente gestibile. Per progetti grandi invece, il merito della cosa va affrontato con qualcuno che sia fortemente preparato all’impatto con le persone, come un community manager magari anche abbastanza navigato.

Quello che emerge quindi è che più che adottare nella propria strategia di business una strada e seguirla in maniera strettamente aderente a quello che ci si è preposti, è bene mescolare queste due macrocategorie perchè non vengano sollevate obiezioni e i contributori si sentano sempre “coccolati”, liberi di poter apportare le modifiche che loro vogliono sempre nel rispetto di regole che non li facciano sentire solo delle scimmie al lavoro per una azienda, magari gratis.