Det er en grunn til at programvareutviklere lever i forkant av en ujevnt fordelt fremtid: Arbeidsproduktene deres har alltid vært digitale gjenstander, og siden nettverkets begynnelse har deres arbeidsprosesser blitt koblet sammen.
Verktøyene som gjør det mulig for programvareutviklere å jobbe og kulturene som omgir bruken av disse verktøyene, har en tendens til å finne veien inn i det vanlige. I ettertid virker det åpenbart at e-post og direktemeldinger - begge brukt av utviklere før noen andre - ville ha nådd massene. Disse kommunikasjonsmåtene var relevante for alle.
Det er mindre åpenbart at Git, verktøyet oppfunnet for å koordinere utviklingen av Linux-kjernen, og GitHub, den verktøybaserte kulturen som omgir den, vil være like relevant. De fleste slenger ikke kode for å leve. Men ettersom arbeidsproduktene og prosessene i hvert yrke i økende grad digitaliseres, vil mange av oss trekke til verktøy designet for å koordinere arbeidet vårt med delte digitale gjenstander. Derfor finner Git og GitHub seg inn i arbeidsflyter som produserer andre gjenstander enn eller i tillegg til kode.
Som rapportert i Wired, ReadWrite og andre steder, brukes GitHub til å administrere samarbeidsutvikling av oppskrifter, musikalske partiturer, bøker, skrifttyper, juridiske dokumenter, leksjoner og opplæringsprogrammer og datasett. Gitt den beryktede kompleksiteten til Git, hvordan er dette mulig?
En årsak er at GitHub gradvis har eksponert flere av de underliggende Git-mulighetene i webgrensesnittet. En annen er fremveksten av webapplikasjoner som bruker GitHub som en plattform. Så er det den kulturelle faktoren: GitHub legemliggjør en bestemt måte å samarbeide på. Dave Winer beskriver det med uttrykket "fortell arbeidet ditt." Jeg har brukt "observerbart arbeid." Den responsive organisasjonsbevegelsen feirer "åpenhet om personvern." For GitHubs regjeringsevangelist, Ben Balter, er det "åpent samarbeid."
Blogginnlegget der Ben Balter foreslår at ordet ikke ble publisert da jeg leste det. Men siden bloggen er vert på et offentlig GitHub-arkiv, kunne jeg ikke bare lese innlegget i utkast, men også følge diskusjonen med inviterte korrekturlesere og observere hvordan diskusjonen påvirket utkastet. Et depot trenger selvfølgelig ikke å være åpent for publikum - men enhver organisasjon bør ønske at sine interne prosesser skal utnytte denne stilen med åpent samarbeid. I følge Brian Doll, visepresident for strategi for GitHub, gjør et økende antall selskaper akkurat det.
Det blir ofte sagt i dag at hvert selskap er et programvareselskap. Det stemmer på en abstrakt måte hvis du definerer immateriell eiendom som programvare. Men det er også bokstavelig talt sant for mange selskaper hvis verdi er nedfelt i programvare de utvikler internt.
Det var alltid ønskelig å utvide deltakelsen i den utviklingen utover de tradisjonelle fagområdene kode, test, kvalitetssikring og dokumentasjon. Men hvis bidraget du kan gi var basert på din forståelse av virksomheten eller kunden, kunne du ikke engasjere deg direkte.
"Det er sinnssykt," sier Brian Doll. "Hvis du er en bank, bruker formuesforvaltningsverktøyene dine ansatte og kundene dine er produktet, hvordan kan disse menneskene ikke ha en direkte hånd i å forbedre det? "Med GitHub kan hver interessent bli en førsteklasses deltaker. I stedet for å skrive e-postmeldinger som går i bane rundt registreringssystemet, kan de sende trekkforespørsler og diskutere relaterte spørsmål direkte i det systemet.
Taming Git-dyret
Git, den desentraliserte versjonskontrollmotoren under GitHubs hette, fungerer på måter som overrasker ikke bare ikke-programmerere, men også programmerere som kommer til det fra sentraliserte systemer.
I disse systemene er det en stor sak å opprette en gren i et depot for å utforske en alternativ versjon av et sett med gjenstander. I Git er en gren en lett konstruksjon, en illusjon skapt ved å flytte pekere i stedet for data. I et konvensjonelt system vil det være utenkelig dyrt å lage en gren for å endre et enkelt ord i et dokument. Git gjør den manøveren trivielt billig. GitHub kan bygge den inn i en arbeidsflyt - pull-forespørselen - som innkapsler diskusjonen om endringen og knytter den til dokumentets endringshistorikk.
Gits protean-evner har gjort det til et laboratorium for arbeidsflytinnovasjon, og de mange tilnærmingene som har dukket opp presenterer et nytt lag av kompleksitet. Mekanikken ved forgrening og sammenslåing er vanskelig nok, men det er også forskjellige tankegang om når og hvordan man skal forgrene og slå seg sammen. Alt dette er utfordrende for programmerere og langt utover de fleste andre. Hvordan kan du temme dette dyret slik at ikke-tekniske interessenter kan delta?
GitHubs svar: Forbedre nettstedet for kjerneaktiviteter. En advokat som ønsker å endre ett ord i et juridisk dokument, trenger ikke bruke den skumle Git-klienten; hun kan redigere filen i nettleseren. Denne handlingen starter en arbeidsflyt med forespørsel som automatiserer etableringen av en filial dedikert til den foreslåtte endringen. GitHubbers liker å si at "det er bare en måte å endre noe på." Ingen er pålagt å følge den gyldne regelen, men å gjøre det følger en vei med minst motstand.
Som et resultat kan alle i et GitHub-aktivert selskap enkelt vedta denne beste fremgangsmåten. "I stedet for å rype mot vannkjøleren fordi programvaren er forferdelig," sier Brian Doll, "har du en måte å endre den på." Dette engasjementet kan også omfatte kunder.
Å endre GitHub i seg selv er en annen sak. "Det er kort tid å bli ansatt der," sier Greg Wilson, grunnlegger av Software Carpentry-prosjektet, "det er ingen måte for meg å fikse hvordan GitHub administrerer tillatelser, tillate en bruker å lage flere gafler av en repo eller noe annet."
Uansett hvor GitHub-interaksjon er aktivert, fungerer endringsmekanismen på samme måte, uansett om bidraget til en endring er kode eller dokumentasjon eller juridisk rådgivning eller forretningsperspektiv eller tilbakemelding fra kunder.
Verdien av den delte konvensjonen, uten tvil GitHubs viktigste innovasjon, forsterkes av andre konvensjoner importert fra sosiale medier. På Twitter kan du for eksempel trekke oppmerksomheten til en annen Twitter-bruker ved å nevne brukernavnet. Denne @mention-teknikken fungerer i GitHub for enkeltpersoner og for team.
Det er også GitHub Pages, en tjeneste som er vert for nettsteder på toppen av GitHub-arkiver. Det favoriseres av tekniske bloggere som er kjent med Git og villige til å installere (og bruke lokalt) en Ruby-basert nettstedsgenerator som heter Jekyll. Men som andre har oppdaget, trenger du ikke å installere Jekyll. Det er mulig å administrere et GitHub Pages-nettsted helt i nettleseren og nyte fordelene med versjonshistorikk og problemdiskusjon.
