Lato Social: creazione di una community e logiche di condivisione

4.2.1 Un passo imprescindibile

Dopo aver ampiamente parlato dell'integrazione delle consolidate realtà dierenti di PEUDOM, segue ora il successivo passo nell'ottica dello sviluppo di un am- biente collaborativo. Giunti a questo punto, si ha a disposizione una piattaforma per la gestione e lo sviluppo di mashup, una piattaforma accessibile liberamente tramite browser da utenti dierenti. In una simile situazione, però, risulta ancora prematuro parlare di collaborazione. Certo, ora più utenti hanno la possibilità di sfruttare l'applicazione Web per creare delle proprie composizioni e anche propri servizi e componenti, ma, tuttavia, ancora gli utenti non hanno modo di col- laborare tra loro. Questo non è dovuto tanto alla mancanza di mezzi comuni per collaborare, mezzi che ovviamente sono comunque da implementare, ma al- la mancanza di una base comune sulla quale poter concentrare gli sforzi della propria collaborazione. È quindi chiaro come non sia possibile dedicarsi alla col- laborazione senza prima avere la possibilità di lavorare su uno stesso progetto, sia esso un mashup o un servizio. La condivisione appare quindi come un necessario antecedente della collaborazione. In questo senso sia la possibilità per gli utenti di scambiare idee e pareri, sia la possibilità di operare su uno stesso PIS sem- brano essere necessarie. E' quindi importante, per prima cosa, pensare a quali siano i requisiti e modellare quali siano le dinamiche di condivisione più oppor- tune. Gli utenti devono avere la possibilità di associarsi tra loro? Oppure la sola condivisione puntuale con specici utenti risulta suciente? Come i modi della condivisione dovono essere declinati per aderire al meglio al contesto dei mashup? Ma anche, quali scelte operare in base alle soluzioni e agli emergenti standard de facto dei più aermati social network e delle più rinomate Web application? Si cerca di rispondere a questi interrogativi nel prossimo paragrafo.

4.2.2 I modi della condivisione

In questo paragrafo si cerca in primo luogo di presentare le soluzioni scelte per im- plementare la condivisione, si tenta poi in seconda battuta di motivare il proprio approccio attraverso un confronto, nel quale le soluzioni scelte da social media e applicazioni Web interpretino la parte del contraddittorio.

La scelta fatta a questo riguardo è la possibilità per gli utenti di aggregarsi in gruppi. Si è scelto di partire nell'implementazione da un tale concetto per svariati motivi, che combinano l'ecacia del risultato nale ad una maggiore semplici- tà di realizzazione. Riettendo circa le possibili scelte di sviluppo, due sono le principali possibilità: quella di creare una qualche entità che si ispiri al concetto di gruppo, oppure quella di optare per una condivisione puntuale tra utenti, che non necessiti di una tale struttura di supporto. La scelta della seconda soluzione

4.2 Lato Social: creazione di una community e logiche di condivisione51 sembrerebbe più conveniente, in quanto alternativa semplice e diretta, la quale permette anche di non dover regolare ulteriori dinamiche di relazione (quelle re- lative ai gruppi). Una simile decisione solleva in realtà alcune criticità. Infatti una condivisione in cui un utente debba esplicitamente elencare i soggetti inte- ressati - condivisione puntuale - presuppone che si sia in possesso di un qualche identicativo che permetta agli utenti di referenziarsi tra loro e che esista sostan- zialmente una relazione pregressa tra gli utenti, sviluppata oine o tramite altri mezzi. Infatti la conoscenza, ad esempio dello username o dell'indirizzo email di un individuo, da sola non permette di conoscere tale individuo, ma bensì consen- te solo di identicarlo in maniera univoca all'interno della piattaforma. Queste informazioni non permettono di far comprendere con chi si stia eettivamente condividendo qualcosa, a meno dell'esistenza di un rapporto pregresso tra le par- ti. Inoltre è del tutto razionale uno scenario in cui un generico utente desideri un particolare servizio, componente o composizione, ma allo stesso tempo non abbia la possibilità di raggiungere un tale scopo, non avendo modo di comprendere a chi rivolgersi per completare il proprio compito. Una semplice lista degli utenti registrati all'interno della piattaforma continua ad essere di poco aiuto; allo stes- so tempo però sarebbe consigliabile rivolgesi ad un numero quanto maggiore di utenti, così da aumentare le probabilità di una sperata risposta aermativa.

A questo punto si rende necessaria una nuova considerazione: la condivisione di tipo puntuale è la più consona solo in determinati ambiti applicativi, oppure sotto alcune speciche condizioni. Infatti sia in un ipotetico ambito lavorativo, così come in un ambito di relazioni amicali o di conoscenza, l'esistenza di relazioni oine in unione alla presenza di una determinata struttura sociale rendono molto più ecace la capacità di un generico utente di scegliere con chi condividere i propri le o di richiederne la condivisione. Infatti in una realtà lavorativa è possibile sostenere che esista sempre, associata ad ogni gura, un rispettivo ruolo, grazie al quale sia possibile discriminare le conoscenze, le capacità e le competenze di un preciso individuo. Allo stesso modo in una rete di amici o conoscenti non viene meno la capacità di identicare e contestualizzare la persona che è associata ad un particolare prolo utente; lo stesso vale anche nel caso di una conoscenza superciale o indiretta.

Lo scenario applicativo di PEUDOM è però dierente: data la generalità del- l'approccio seguito, non è possibile ritenere ancora valide le supposizioni descritte in precedenza. Certo alcuni utenti potrebbero già conoscersi, oppure conoscersi tramite l'utilizzo della applicazione, ma questo rientra in un caso particolare e non può essere preso come esempio generale. Giunti a questo punto, ancora una volta, le possibili soluzioni sono molteplici: una idea potrebbe essere quella di mantenere una condivisione puntale, a patto però di creare un spazio liberamen- te consultabile in cui ogni utente specichi non solo le informazioni rilevanti prese dai propri dati anagraci, ma anche i propri interessi, le proprie capacità, aspi- razioni ecc. Insomma, orire la possibilità di contestualizzare un utente in base a dei contenuti personali permetterebbe almeno ad un utente generico di classi-

care e valutare i proli degli altri utenti. Questo approccio è lo stesso adottato anche da Facebook: la pagina personale dell'utente permette di vericarne l'i- dentità, almeno quella supposta, e comprendere nel caso specico se richiedere o meno l'amicizia a quel preciso utente. Si ricorda che in questo caso però si è già a conoscenza del nome del soggetto ed in realtà le informazioni personali, foto del prolo compresa, servono solo a togliere d'impaccio in caso di omonimia. Una tale scelta non sembra quindi adeguata per PEUDOM. La condivisione all'interno della piattaforma è infatti orientata ai contenuti e non tanto alla persona: è infat- ti ragionevole supporre che, ad un utente interessato in un determinato ambito, non interessi tanto conoscere la persona che condivida una specica composizio- ne, quanto avere la possibilità di usare quella stessa composizione a prescindere da chi sia il suo autore.

Un approccio ibrido molto interessante è quello adottato in Google+ nelle cerchie: in questo caso, pur permanendo la necessità di una conoscenza diretta o indiretta tra gli utenti, è possibile condividere con degli speciali gruppi, creati dall'utente in base alle realtà associative in cui vive (es. familiari, amici, colleghi di lavoro). Una simile suddivisione in gruppi è stato introdotta anche da Face- book. Sebbene una simile dinamica non coincida ancora con quella di PEUDOM, allo stesso tempo permette di comprendere le potenzialità dei gruppi.

Questo permette di orientare l'oggetto della condivisione verso un determina- to gruppo di interesse, formato da utenti che, a prescindere dalla loro identità, sono caratterizzati da fattori comuni. Per quale motivo si è scelto di partire dal- l'implementazione di dinamiche di gruppo all'interno della nuova piattaforma? L'idea fondamentale è quella di associare ogni gruppo ad una determinata area di interesse. In questo modo ogni utente può regolarsi in base all'area di inuenza di ogni gruppo: ricercare un servizio, un componente o una composizione diventa più immediato. Infatti non è più necessaria una interazione diretta tra gli utenti che, iscrivendosi ad un gruppo, potranno automaticamente usufruire dei prodotti degli altri utenti. La conoscenza tra due utenti non è più necessaria, sia nel caso in cui io desideri condividere o sia alla ricerca di qualcosa. In questo modo l'u- tente nisce per autoselezionarsi alla condivisione e verso la condivisione di ciò che più gli interessa.

Una ulteriore alternativa è quella di rinunciare ai gruppi e di mantenere di fatto solo una suddivisione in categorie di interesse, seguendo il modello sfruttato ad esempio dall'Ubuntu Software Center, Apple Store e Google Play. Questa soluzione applicata a PEUDOM avrebbe lo svantaggio di condividere ogni risorsa con tutti gli utenti; si renderebbe quindi necessaria l'integrazione con una diversa dinamica, qualora un utente desideri restringere la condivisione ad un gruppo limitato di utenti.

Per tutte queste ragioni, nonostante l'ultimo modello descritto appaia essere il più completo, si è scelto di partire da una implementazione più semplice che ruota attorno al solo concetto di gruppo, riservandosi di migliorarne la caratte- rizzazione tramite l'organizzazione in categorie di interesse in una fase successiva

4.2 Lato Social: creazione di una community e logiche di condivisione53 dello sviluppo. Inoltre, alla luce della larga diusione delle logiche di condivi- sione puntuale, si è deciso di integrare anche queste dinamiche, trasversali e non contrastanti con le logiche di gruppo.

4.2.3 Le dinamiche di gruppo e di condivisione

Lo scopo di questo paragrafo è quello di stabilire, in forza delle speculazioni circa i modi della condivisione, quali debbano essere nello specico le dinami- che da implementare in PEUDOM. È possibile condividere il proprio lavoro o con un gruppo, oppure con un preciso insieme di utenti, da elencarsi in fase di condivisione a partire da una lista, comprendente tutti gli utenti registrati alla piattaforma. Non vi sono particolari restrizioni nella creazione di un gruppo: ogni utente può liberamente creare e/o aggregarsi ai gruppi che desidera. Esistono tue tipi dierenti di gruppi, quelli pubblici e quelli privati:

Gruppi pubblici: realizzano il desiderio di creare dei gruppi di riferimento al- l'interno di una particolare categoria di interesse. La partecipazione è del tutto libera e l'utente ha la possibilità di sfogliare quali siano i gruppi pubblici disponibili su PEUDOM.

Gruppi privati: si congurano come una cerchia ristretta di persone. Al con- trario dei primi, è possibile accedere a questi gruppi solo tramite invito diretto del proprietario, non sono inoltre visibili all'interno della lista dei gruppi pubblici.

La ragione dei gruppi privati è quella di permettere la creazione di piccole cerchie personali: queste infatti possono essere necessarie qualora ad esempio si condi- vida un servizio o un componente realizzato tramite l'utilizzo di dati sensibili oppure tramite l'uso di una chiave personale, collegata ad uno specico servizio a pagamento (con limiti di costo o frequenza ad esempio sul numero di interro- gazioni al servizio tramite API). Un gruppo privato permette di selezionare un gruppo ben limitato di collaboratori: solo loro saranno invitati ad unirsi al grup- po. Certo, all'utente rimane la scelta se accettare o meno l'invito, così come può decidere di lasciare il gruppo in ogni momento. Il controllo centralizzato nelle mani del creatore del gruppo impedisce però che il numero dei suoi partecipanti aumenti in modo indiscriminato. Si garantisce inoltre anche al creatore di poter abbandonare un gruppo (in questo caso il discorso vale a maggiore ragione per un gruppo pubblico), a patto che questo scelga un utente che prenda il suo posto. Per quanto la condivisione puntuale e la condivisione con un gruppo privato possano sembrare identiche, esistono alcune dierenze. Infatti mentre il primo tipo meglio si adatta ad una condivisione monodirezionale, occasionale e ad hoc, il secondo meglio rispetta la necessità di una condivisione multidirezionale, es- sibile e a medio/lungo termine. Solo all'interno di un gruppo gli utenti hanno la

possibilità di condividere senza sforzo all'interno di stesso spazio; la collaborazio- ne può vertere su un numero non limitato di le, aggiunti di volta in volta da un qualsiasi utente iscritto, senza la necessità di specicare ogni volta i destinata- ri. Al contrario l'altra condivisione è per natura circostanziale e limitata ad un singolo le, utile soprattutto per una collaborazione più rapida e mirata.

In ultima istanza restano da esplicitare quali sono gli oggetti della condivisione e come si immagina di sfruttare l'infrastruttura descritta precedentemente. Gli oggetti, o le, designati sono i tre elementi fondamentali che ruotano attorno alla creazione di un mashup: Servizio, Componente e Composizione. L'idea è quella di sviluppare, all'interno della piattaforma, un ambiente dedicato, all'interno del quale ogni utente possa gestire, organizzati per tipo, i propri le. In questa particolare sezione l'utente deve avere la possibilità di distinguere quali siano i le personali e quali invece siano condivisi. Inoltre per quelli, che tra questi ultimi sono di proprietà dell'utente in questione, si prevede di garantire maggiori possibilità di gestione, al ne di abilitare la condivisione, ranarne i meccanismi in previsione di una più ecace collaborazione, gestire gli utenti ai quali il le è visibile oppure revocare la condivisione.

Tra queste opzioni quella che crea maggiore perplessità è la possibilità di ri- muovere un oggetto dalla condivisione. La rimozione di una composizione non è di per sé problematica, al meno dal punto di vista dello sviluppo delle dinamiche di condivisione. Il vero problema è quando si sceglie di rimuovere un servizio o un componente. Considerando individualmente questi due oggetti, ancora non si è in grado di comprendere una importante criticità. Infatti, solo considerando le due entità nel loro ruolo di elementi essenziali per la realizzazione di compo- nenti/composizioni, è possibile comprendere come un approccio non ponderato possa essere rischioso.

La creazione di una composizione avviene progressivamente tramite l'uso di uno o più componenti, a loro volta concretizzati sfruttando un determinato servi- zio. Nel caso in cui si rimuovesse un servizio o un componente si andrebbe di fatto ad invalidare l'utilizzo di un determinato componente o composizione all'interno del quale si faceva uso del soggetto eliminato (Figura 4.2). L'utente potrebbe ritrovarsi ad utilizzare componenti o composizioni creati prima della data della rimozione, dovendo in questo caso constatare il loro stato di oggetto malfunzio- nante o danneggiato. Allo stesso modo è necessario garantire che la possibilità di rimozione dallo sharing sia possibile: un utente potrebbe aver condiviso il le sbagliato, oppure potrebbe aver errato nello scegliere il meccanismo di condivi- sione. Allo stesso tempo, oltre a motivi prettamente legati all'utente, esistono ragioni legate ai service provider: un eventuale cambio delle API, la rimozione o la modica del servizio oerto, la scadenza di una chiave di registrazione o la necessità di contribuire economicamente per continuare ad usare il servizio so- no tutte eventualità indipendenti da PEUDOM che vanno di fatto ad alterare il funzionamento di servizi, componenti e composizioni, ma che sono allo stesso tempo connaturali nella denizione di mashup. In questo caso però la possibilità