GitHub per il resto di noi

C'è un motivo per cui gli sviluppatori di software vivono ai margini di un futuro distribuito in modo non uniforme: i loro prodotti di lavoro sono sempre stati artefatti digitali e, dagli albori delle reti, i loro processi di lavoro sono stati collegati.

Gli strumenti che consentono agli sviluppatori di software di lavorare e le culture che circondano l'uso di questi strumenti tendono a farsi strada nel mainstream. Sembra ovvio, in retrospettiva, che la posta elettronica e la messaggistica istantanea, entrambe utilizzate dagli sviluppatori prima di chiunque altro, avrebbero raggiunto le masse. Quelle modalità di comunicazione erano rilevanti per tutti.

È meno ovvio che Git, lo strumento inventato per coordinare lo sviluppo del kernel Linux, e GitHub, la cultura basata sugli strumenti che lo circonda, saranno altrettanto rilevanti. La maggior parte delle persone non imita il codice per vivere. Ma poiché i prodotti di lavoro ei processi di ogni professione sono sempre più digitalizzati, molti di noi graviteranno su strumenti progettati per coordinare il nostro lavoro su artefatti digitali condivisi. Ecco perché Git e GitHub stanno trovando la loro strada nei flussi di lavoro che producono artefatti diversi o in aggiunta al codice.

Come riportato in Wired, ReadWrite e altrove, GitHub viene utilizzato per gestire lo sviluppo collaborativo di ricette, spartiti musicali, libri, caratteri, documenti legali, lezioni ed esercitazioni e set di dati. Data la famigerata complessità di Git, com'è possibile?

Uno dei motivi è che GitHub ha gradualmente esposto più funzionalità di Git sottostanti nella sua interfaccia Web. Un altro è l'emergere di applicazioni Web che utilizzano GitHub come piattaforma. Poi c'è il fattore culturale: GitHub incarna un modo particolare di lavorare insieme. Dave Winer lo descrive con la frase "racconta il tuo lavoro". Ho usato "lavoro osservabile". Il movimento Responsive Organization celebra la "trasparenza sulla privacy". Per l'evangelista del governo di GitHub, Ben Balter, si tratta di "collaborazione aperta". 

Il post del blog in cui Ben Balter propone quel termine non era pubblicato quando l'ho letto. Ma poiché il blog è ospitato su un repository GitHub pubblico, non solo ho potuto leggere il post in forma di bozza, ma anche seguire la discussione con i revisori invitati e osservare come quella discussione ha influenzato la bozza. Un repository, ovviamente, non deve essere aperto al pubblico, ma ogni organizzazione dovrebbe desiderare che i suoi processi interni sfruttino questo stile di collaborazione aperta. Secondo Brian Doll, vice presidente della strategia di GitHub, un numero crescente di aziende sta facendo esattamente questo.

Al giorno d'oggi si dice spesso che ogni azienda è una società di software. Questo è vero in modo astratto, se definisci la proprietà intellettuale come software. Ma è anche letteralmente vero per molte aziende il cui valore è incorporato nel software che sviluppano internamente.

È sempre stato auspicabile espandere la partecipazione a tale sviluppo oltre le tradizionali discipline di codice, test, QA e documentazione. Ma se il contributo che puoi dare fosse basato sulla tua comprensione del business o del cliente, non potresti impegnarti direttamente.

"È pazzesco", dice Brian Doll. "Se sei una banca, gli strumenti di gestione patrimoniale utilizzati dai tuoi dipendenti e dai tuoi clienti sono il prodotto, come possono queste persone non avere una mano diretta nel migliorarlo?" Con GitHub, ogni stakeholder può diventare un partecipante di prima classe. Invece di scrivere e-mail che orbitano intorno al sistema di registrazione, possono inviare richieste pull e discutere questioni correlate direttamente in quel sistema. 

Domare la bestia Git

Git, il motore di controllo della versione decentralizzato sotto il cofano di GitHub, funziona in modi che sorprendono non solo i non programmatori, ma anche i programmatori che vi arrivano da sistemi centralizzati.

In questi sistemi è un grosso problema creare un ramo all'interno di un repository, al fine di esplorare una versione alternativa di un insieme di artefatti. In Git un ramo è un costrutto leggero, un'illusione creata spostando i puntatori invece dei dati. In un sistema convenzionale sarebbe impensabilmente costoso creare un ramo per cambiare una singola parola in un documento. Git rende quella manovra banalmente economica. GitHub può incorporarlo in un flusso di lavoro - la richiesta pull - che incapsula la discussione della modifica e la lega alla cronologia delle modifiche del documento.

Le capacità proteiche di Git l'hanno reso un laboratorio per l'innovazione del flusso di lavoro e i molti approcci che sono emersi presentano un altro livello di complessità. I meccanismi di ramificazione e fusione sono abbastanza complicati, ma ci sono anche varie scuole di pensiero su quando e come ramificarsi e fondersi. Tutto questo è impegnativo per i programmatori e va ben oltre la maggior parte degli altri. Come puoi domare questa bestia in modo che le parti interessate non tecniche possano partecipare?

La risposta di GitHub: Migliora il sito web per le attività principali. Un avvocato che vuole cambiare una parola in un documento legale non deve usare lo spaventoso client Git; può modificare il file nel browser. Quell'azione darà il via a un flusso di lavoro di richiesta pull che automatizza la creazione di un ramo dedicato alla modifica proposta. A GitHubbers piace dire che "c'è solo un modo per cambiare qualcosa". Nessuno è tenuto a seguire quella regola d'oro, ma così facendo segue un percorso di minor resistenza.

Di conseguenza, tutti in un'azienda abilitata per GitHub possono facilmente adottare questa best practice. "Invece di brontolare al refrigeratore d'acqua perché il software è terribile", dice Brian Doll, "hai un modo per cambiarlo". Questo coinvolgimento può estendersi anche ai clienti.

Cambiare GitHub stesso è un'altra questione. "A meno di essere assunto lì", afferma Greg Wilson, fondatore del progetto Software Carpentry, "non c'è modo per me di correggere il modo in cui GitHub gestisce le autorizzazioni, consentire a un utente di creare più fork di un repo o qualsiasi altra cosa".

Ovunque sia abilitata l'interazione in stile GitHub, il meccanismo di modifica funziona allo stesso modo, indipendentemente dal fatto che il contributo a una modifica sia codice o documentazione o consulenza legale o prospettiva aziendale o feedback dei clienti. 

Il valore di quella convenzione condivisa, probabilmente l'innovazione più importante di GitHub, è accresciuto da altre convenzioni importate dai social media. Su Twitter, ad esempio, puoi attirare l'attenzione di un altro utente di Twitter menzionando il suo nome utente. Questa tecnica @mention funziona in GitHub per gli individui e per i team.

C'è anche GitHub Pages, un servizio che ospita siti Web sopra i repository GitHub. È favorito dai blogger tecnici che hanno familiarità con Git e desiderano installare (e utilizzare localmente) un generatore di siti basato su Ruby chiamato Jekyll. Ma come altri hanno scoperto, non è necessario installare Jekyll. È possibile gestire un sito GitHub Pages interamente nel browser e godere dei vantaggi della cronologia delle versioni e della discussione dei problemi.