Der er en grund til, at softwareudviklere lever i forkant af en ujævnt distribueret fremtid: Deres arbejdsprodukter har altid været digitale artefakter, og siden begyndelsen af netværk er deres arbejdsprocesser blevet forbundet.
De værktøjer, der gør det muligt for softwareudviklere at arbejde, og de kulturer, der omgiver brugen af disse værktøjer, har tendens til at finde vej ind i mainstream. I bakspejlet synes det åbenlyst, at e-mail og instant messaging - begge brugt af udviklere før nogen anden - ville have nået masserne. Disse kommunikationsformer var relevante for alle.
Det er mindre indlysende, at Git, værktøjet opfundet til at koordinere udviklingen af Linux-kernen, og GitHub, den værktøjsbaserede kultur, der omgiver den, vil være lige så relevant. De fleste mennesker slynger ikke kode til livets ophold. Men da arbejdsprodukter og processer i ethvert erhverv i stigende grad digitaliseres, vil mange af os henvende sig til værktøjer designet til at koordinere vores arbejde med delte digitale artefakter. Derfor finder Git og GitHub sig vej til arbejdsgange, der producerer andre artefakter end eller ud over kode.
Som rapporteret i Wired, ReadWrite og andre steder bruges GitHub til at styre den fælles udvikling af opskrifter, musikpartiturer, bøger, skrifttyper, juridiske dokumenter, lektioner og tutorials og datasæt. I betragtning af den berygtede kompleksitet af Git, hvordan er dette muligt?
En af årsagerne er, at GitHub gradvist har eksponeret flere af de underliggende Git-funktioner i sin webgrænseflade. En anden er fremkomsten af webapplikationer, der bruger GitHub som en platform. Så er der den kulturelle faktor: GitHub inkorporerer en bestemt måde at arbejde sammen på. Dave Winer beskriver det med sætningen "fortæl dit arbejde." Jeg har brugt "observerbart arbejde." Den responsive organisations bevægelse fejrer "gennemsigtighed over privatlivets fred." For GitHubs regeringsevangelist, Ben Balter, er det "åbent samarbejde."
Blogindlægget, hvor Ben Balter foreslår, at udtrykket ikke blev offentliggjort, da jeg læste det. Men da bloggen er hostet på et offentligt GitHub-arkiv, kunne jeg ikke kun læse indlægget i kladde, men også følge diskussionen med inviterede korrekturlæsere og observere, hvordan denne diskussion påvirkede kladden. Et arkiv behøver naturligvis ikke være åbent for offentligheden - men enhver organisation skal have sine interne processer til at udnytte denne stil med åbent samarbejde. Ifølge Brian Doll, vicepræsident for strategi for GitHub, gør et stigende antal virksomheder netop det.
Det siges ofte i dag, at hvert firma er et softwarefirma. Det er sandt på en abstrakt måde, hvis du definerer intellektuel ejendom som software. Men det gælder også bogstaveligt talt for mange virksomheder, hvis værdi er inkorporeret i software, de udvikler internt.
Det var altid ønskeligt at udvide deltagelsen i denne udvikling ud over de traditionelle discipliner kode, test, QA og dokumentation. Men hvis det bidrag, du kan yde, var baseret på din forståelse af forretningen eller kunden, kunne du ikke engagere dig direkte.
"Det er sindssygt," siger Brian Doll. "Hvis du er en bank, bruger de formuesstyringsværktøjer, dine medarbejdere og dine kunder bruger er produktet, hvordan kan disse mennesker ikke have en direkte hånd til at forbedre det? "Med GitHub kan enhver interessent blive en førsteklasses deltager. I stedet for at skrive e-mails, der kredser om registreringssystemet, kan de sende pull-anmodninger og diskutere relaterede spørgsmål direkte i det system.
Tæmme Git-udyret
Git, den decentrale versionskontrolmotor under GitHubs emhætte, fungerer på måder, der overrasker ikke kun ikke-programmerere, men også programmører, der kommer til det fra centraliserede systemer.
I disse systemer er det en stor ting at oprette en gren inden for et arkiv for at udforske en alternativ version af et sæt artefakter. I Git er en gren en let konstruktion, en illusion skabt ved at flytte markører i stedet for data. I et konventionelt system ville det være utænkeligt dyrt at oprette en gren for at ændre et enkelt ord i et dokument. Git gør denne manøvre trivielt billig. GitHub kan integrere det i en arbejdsgang - pull-anmodningen - der indkapsler diskussion af ændringen og binder den til dokumentets ændringshistorik.
Gits protean-kapacitet har gjort det til et laboratorium for workflowinnovation, og de mange tilgange, der er kommet frem, præsenterer endnu et lag af kompleksitet. Mekanikken ved forgrening og fletning er vanskelig nok, men der er også forskellige tankegang om hvornår og hvordan man forgrener og fusionerer. Alt dette er udfordrende for programmører og langt ud over de fleste andre. Hvordan kan du tæmme dette udyr, så ikke-tekniske interessenter kan deltage?
GitHubs svar: Forbedre hjemmesiden til kerneaktiviteter. En advokat, der ønsker at ændre et ord i et juridisk dokument, behøver ikke bruge den skræmmende Git-klient; hun kan redigere filen i browseren. Denne handling starter en pull-anmodning workflow, der automatiserer oprettelsen af en filial dedikeret til den foreslåede ændring. GitHubbers kan lide at sige, at "der er kun en måde at ændre noget på." Ingen er forpligtet til at følge den gyldne regel, men det følger en vej med mindst modstand.
Som et resultat kan alle i et GitHub-aktiveret firma let vedtage denne bedste praksis. "I stedet for at rykke ved vandkøleren, fordi softwaren er forfærdelig," siger Brian Doll, "har du en måde at ændre den på." Dette engagement kan også omfatte kunder.
At ændre GitHub i sig selv er en anden sag. "Kort tid efter at blive ansat der," siger Greg Wilson, grundlægger af Software Carpentry-projektet, "der er ingen måde for mig at rette op på, hvordan GitHub administrerer tilladelser, tillade en bruger at fremstille flere gafler af en repo eller noget andet."
Uanset hvor GitHub-interaktion er aktiveret, fungerer ændringsmekanismen dog på samme måde, uanset om bidraget til en ændring er kode eller dokumentation eller juridisk rådgivning eller forretningsperspektiv eller kundefeedback.
Værdien af den delte konvention, uden tvivl GitHubs vigtigste innovation, forstærkes af andre konventioner importeret fra sociale medier. På Twitter kan du for eksempel henlede en anden Twitter-brugeres opmærksomhed ved at nævne deres brugernavn. Denne @mention-teknik fungerer i GitHub for enkeltpersoner og for hold.
Der er også GitHub Pages, en tjeneste, der er vært for websteder oven på GitHub-arkiver. Det foretrækkes af tekniske bloggere, der er fortrolige med Git og villige til at installere (og bruge lokalt) en Ruby-baseret webstedsgenerator kaldet Jekyll. Men som andre har opdaget, behøver du ikke installere Jekyll. Det er muligt at administrere et GitHub Pages-websted udelukkende i browseren og nyde fordelene ved versionshistorik og problemdiskussion.
