FutureCSD@CSCW2012

Il workshop The Future of Collaborative Software Development, parte di CSCW 2012, è terminato da poco. Le aspettative non sono state deluse. Più di trenta partecipanti molto attivi nelle discussioni.
Ho sentito presentazioni molto interessanti su GitHub (Coding for an Audience: Transparency and Collaborative Behavior in a Social Coding Environment), StackOverflow (Programming in a Socially Networked World: The Evolution of the Social Programmer) e Collabode, un prototipo di editing collaborativo del codice alla Google Docs (Collabode: Collaborate on the Code).
Ho assistito all’uso di Google Docs per la redazione collaborativa real-time delle note del meeting. Google Docs ha retto la concorrenza alla grande. Lo trovo una buona soluzione per motivare i partecipanti a seguire le discussioni senza distrazioni.
Ho avuto una lunga bibliografia sul trust da una gentile ricercatrice di Irvine.
Mi rimangono da rileggere le note sulle research questions, i commenti delle sessioni e alcuni riferimenti annotati. Ora però c’è la cena con i partecipanti al workshop.

Google Summer of Code 2010

…a proposito di idee innovative 🙂 il GSoC è un programma che ha da una parte lo scopo di supportare il miglioramento di progetti open source e dall’altra di supportare gli sviluppatori permettendo loro di emergere e di migliorarsi (e guadagnare qualcosa 🙂 ).
Google seleziona un insieme di organizzazioni che sono quasi sempre le stesse. L’elenco per il 2010 verrà pubblicato il 18 Marzo.
Gli sviluppatori che vogliono partecipare poi, dovranno richiedere di lavorare su una delle idee di miglioramento proposte su un progetto OS di una delle organizzazioni, a scelta (anche più di una ma è consigliabile concentrare la proprio richiesta su una sola in quanto non è banale riuscire a convincere chi legge ad accettare la propria proposta) oppure inoltrare una personale proposta di miglioramento (che è sempre apprezzato).
La timeline completa la trovate sul sito ufficiale del GSoC 2010.
Vi consiglio di scegliere un’organizzazione già da subito tra quelle partecipanti lo scorso anno, perchè prendendo contatti con le rispettive community il prima possibile, aumentano le chance di essere accettati per il GSoC.

Nel caso in cui il progetto eventualmente realizzato per il GSoC sia attinente alle tematiche affrontate nel corso di Sistemi per la Collaborazione in Rete (laurea specialistica/magistrale), il prof. Lanubile (come già accaduto in passato) è disponibile ad accettarlo come progetto d’esame oppure di tesi.
Un esempio di organizzazione i cui relativi progetti possono certamente essere accettati è Hackystat (non a caso fondato dal Collaborative Software Development Laboratory dell’Università delle Hawaii).

Consiglio a chiunque di partecipare perchè è una delle rarissime occasioni di essere coinvolti in progetti open source, sentirsi parte di una comunità, “collaborare” realmente a distanza con tutor e altri sviluppatori, imparare etc sfruttando magari il tutto anche in ambito universitario! oltre all’ovvia influenza sul curriculum 🙂 e sul portafogli (si viene pagati $4500 in più riprese a seconda che si superino con successo le varie deadlines) potrebbero interessarvi le mie personali considerazioni alla fine della mia esperienza, ma troverete moltissimi blog post su esperienze di altri se cercate un po’in giro.

Se volete contribuire a diffondere la notizia scaricate il volantino ufficiale in italiano 😉

P.S.
il volantino se non sbaglio è stato tradotto in italiano proprio da Pasquale Minervini (studente del dib) che ha partecipato anche lui al GSoC 2009.

Google Wave

Google Wave è la nuova creatura di Google e credo farà parlare di sè nei prossimi mesi. Se avesse successo potrebbe finire per sostituire l’email, e quindi Gmail (non facile), nonché Google Docs stesso.
Gli autori sono gli stessi che hanno creato Google Maps e questo dovrebbe bastare per non prenderli sottogamba.
Se volete saperne di più leggete il post sul blog di Google. Guardando la presentazione di Lars Rasmussen, sono rimasto impressionato dal modo con cui è possibile visualizzare i contributi dei diversi autori di un documento condiviso.
Come nella tradizione di Google, Wave è sia un prodotto open source che una piattaforma estendibile mediante API, per consentire i mashup. Come nella tradizione di Internet, Wave è anche un protocollo basato su XMPP, per far sì che chiunque possa costruire un client o un server senza che rimangano isolati dal resto della rete.

PS. Ringrazio Gaetano Salierno per aver segnalato il video di Google Wave

Information overload

Un report segnalato su CIO Insight

As much as e-mail, instant messages, blogs and their brethren technologies have helped knowledge workers better collaborate, interruptions and duplications derived from these forms of digital communication and content are overwhelming workers to the point of distraction.
…
The addition of new collaboration layers force the technologies into untenable competitive positions, with phone calls, e-mails, instant messaging and blog-reading all vying for workers’ time.
…
However, Basex proposed several steps to mitigate information overload.
…
For all communication, Basex wants to remind workers to be as explicit as possible because their readers are not mind readers. While the statement may seem like an obvious mantra, it is also easily forgotten.

Basex also urged users to choose the proper communication medium at the proper time. The researchers suggested instant messaging is better than the phone when multiple parties need to be on and do the talking, or there are a number of many-to-many conversations taking place.

L’ultimo punto mi risuona come un mantra quando partecipo a una conference call con 8-10 persone. Questa settimana me ne sono toccate due.

Frederick Brooks, Jr. at OOPSLA 2007

Ultimo reportage da OOSPLA, con un po’ di ritardo per non pesare troppo sui lettori.
Collaboration and Telecollaboration in Design

Frederick P. Brooks, Jr. (University of North Carolina at Chapel Hill)
Qualcuno osa chìedere chi è Fred Brooks? Questa volta vi accontento.

Brooks distilled the successes and failures of the development of Operating System/360 in The Mythical Man-Month: Essays in Software Engineering, (1975, 20th Anniversary Edition, 1995). He further examined software engineering in a 1986 paper, No Silver Bullet. He is a member of the National Academy of Engineering, the National Academy of Science, and the American Academy of Arts and Sciences. He has received the ACM A.M. Turing Award, the IEEE John von Neumann Medal, the IEEE Computer Society’s McDowell and Computer Pioneer Awards, the ACM Allen Newell and Distinguished Service Awards, the AFIPS Harry Goode Award, and an honorary Doctor of Technical Science from the Swiss Federal Institute of Technology

Il design engineering, a differenza dell’arte, è un lavoro di team. Perché? Ci sono aspetti sempre più sofisticati anche nei prodotti più semplici. Tuttavia i grandi progetti di ingegneria sono ancora oggi il lavoro di una, al più due menti. Si ha così l’integrità concettuale.
Brooks mostra una tabella con a sinistra linguaggi e sistemi disegnati da una sola persona e a destra quelli disegnati da un processo di gruppo. Solo i primi hanno il loro fan club.
Il problema è: come ottenere integrità concettuale con il team design. Il design non può essere il prodotto di una negoziazione. Ci vuole un chief designer e per grandi sistemi un chief architect. Anche l’interfaccia utente richiede un solo user-interface designer (es. Google). Per preservare l’integrità concettuale le assunzioni devono essere documentate:

“better to be wrong than silent or vague”

Brooks cita The Cathedral and the Bazaar con Unix costruito da gruppi diversi e l’early bug detection come risultato dell’enorme scala del testing. La posizione di Brooks è che il modello del bazaar è basato sul gift e funziona quando gli sviluppatori sono i clienti stessi: conoscono così i requisiti in base alla loro esperienza personale. Costruireste mai un sistema di controllo del traffico aereo? Attenzione alle generalizzazioni errate, quindi.
Ma quando la collaborazione aiuta? Aiuta nel caso dell’esplorazione concettuale (alternative radicali, brainstorming) ma non nel conceptual design né nel detailed design. E il pair programming? E nei design review? I review sono collettivi, il design no. Il design è un processo prevalentemente per il singolo individiuo mentre il review è un processo di gruppo condotto in modo iterativo.
Il messaggio che Brooks vuole trasmettere è:

Low tech often suffice

I documenti condivisi sono il fattore più importante. Poi la voce. Quando unsare la videoconference?

  • When issues vital to one or more players
  • When people are insecure
  • When interviewing strangers
  • When organization or national cultures are very different

Freb Brooks conclude dicendo che cI sono pochi studi di telecollaboration in design.

Jonathan Grudin at WikiSym 2007

Incoraggiato dai numerosi commenti pervenuti sul post precedente, pubblico un nuovo resoconto sul talk del padre del CSCW.

Jonathan Grudin, Microsoft Research
Living Without Parental Controls

This is by far the most interesting, dynamic period in the quarter century I’ve worked on collaboration technologies, and there is every reason to believe the pace will pick up. We can ignore history without being doomed to repeat it, because there is no going back. But there have been trends that suggest what we might watch out for. Ignoring the admonition that “he who lives by the crystal ball soon learns to eat ground glass,” I’ll describe observations, research, and product innovation that suggest opportunities and challenges swirling toward and around us. Central to the changes is the generation growing up with wikis, weblogs, tagging, map mashups, messaging, multiplayer games, and other social software.
Bio
Jonathan Grudin is a Principal Researcher in the Microsoft Adaptive Systems and Interaction group. His involvement in HCI began shortly before the first CHI conference and his involvement with collaboration technologies shortly before the first CSCW conference. His research at Microsoft has included studies of streaming media, privacy and sharing, early use of emerging technologies in organizations, and the impact of technologies on the gulf between policies and practice.

Un commento interessante è stato che gli MMORPG sono un esempio di ambiente in cui i team virtuali non si incontrano nemmeno all’inizio ma comunque funzionano bene. Sarebbero da studiare.
Ha citato il lavoro di McGrath (1991) per spiegare perchè il groupware che funziona negli esperimenti di lab poi sul mercato non ha grande successo: gli esperimenti misurano solo le performance della funzione di produzione ma non gli altri aspetti della collaborazione di gruppo.

Gran talk. Ha concluso dicendo che il supporto ai piccolo gruppi, quando arriverà e funzionerà bene, darà origine a delle killer apps.