There's a reason why software developers live at the leading edges of an unevenly distributed future: Their work products have always been digital artifacts, and since the dawn of networks, their work processes have been connected.
The tools that enable software developers to work and the cultures that surround the use of those tools tend to find their way into the mainstream. It seems obvious, in retrospect, that email and instant messaging -- both used by developers before anybody else -- would have reached the masses. Those modes of communication were relevant to everyone.
It's less obvious that Git, the tool invented to coordinate the development of the Linux kernel, and GitHub, the tool-based culture that surrounds it, will be as widely relevant. Most people don't sling code for a living. But as the work products and processes of every profession are increasingly digitized, many of us will gravitate to tools designed to coordinate our work on shared digital artifacts. That's why Git and GitHub are finding their way into workflows that produce artifacts other than, or in addition to, code.
As reported in Wired, ReadWrite, and elsewhere, GitHub is used to manage the collaborative development of recipes, musical scores, books, fonts, legal documents, lessons and tutorials, and data sets. Given the infamous complexity of Git, how is this possible?
One reason is that GitHub has gradually exposed more of the underlying Git capabilities in its Web interface. Another is the emergence of Web applications that use GitHub as a platform. Then there's the cultural factor: GitHub embodies a particular way of working together. Dave Winer describes it with the phrase "narrate your work." I've used "observable work." The Responsive Organization movement celebrates "transparency over privacy." For GitHub's government evangelist, Ben Balter, it's "open collaboration."
The blog post in which Ben Balter proposes that term was unpublished when I read it. But since the blog is hosted on a public GitHub repository I could not only read the post in draft form but also follow the discussion with invited reviewers and observe how that discussion influenced the draft. A repository, of course, need not be open to the public -- but every organization should want its internal processes to leverage this style of open collaboration. According to Brian Doll, vice president of strategy for GitHub, a growing number of companies are doing exactly that.
It's often said nowadays that every company is a software company. That's true in an abstract way, if you define intellectual property as software. But it's also literally true for many companies whose value is embodied in software they develop internally.
It was always desirable to expand participation in that development beyond the traditional disciplines of code, test, QA, and documentation. But if the contribution you can make was based on your understanding of the business or of the customer, you couldn't engage directly.
"That's insane," says Brian Doll. "If you're a bank, the wealth management tools your employees and your customers use are the product, how can those people not have a direct hand in improving it?" With GitHub, every stakeholder can become a first-class participant. Rather than writing emails that orbit the system of record, they can send pull requests and discuss related issues directly in that system.
Taming the Git beast
Git, the decentralized version control engine under GitHub's hood, works in ways that surprise not only nonprogrammers but also programmers who come to it from centralized systems.
In those systems it's a big deal to create a branch within a repository, in order to explore an alternative version of a set of artifacts. In Git a branch is a lightweight construct, an illusion created by moving pointers instead of data. In a conventional system it would be unthinkably costly to create a branch to change a single word in a document. Git makes that maneuver trivially cheap. GitHub can embed it in a workflow -- the pull request -- that encapsulates discussion of the change and ties it to the document's change history.
Git's protean capabilities have made it a laboratory for workflow innovation, and the many approaches that have emerged present another layer of complexity. The mechanics of branching and merging are tricky enough, but there are also various schools of thought about when and how to branch and merge. All this is challenging for programmers and way beyond most others. How can you tame this beast so that nontechnical stakeholders can participate?
GitHub's answer: Enhance the website for core activities. A lawyer who wants to change one word in a legal document needn't use the scary Git client; she can edit the file in the browser. That action will kick off a pull-request workflow that automates the creation of a branch dedicated to the proposed change. GitHubbers like to say that "there's only one way to change something." Nobody is required to adhere to that golden rule, but doing so follows a path of least resistance.
As a result, everyone in a GitHub-enabled company can easily adopt this best practice. "Instead of grousing at the water cooler because the software is terrible," says Brian Doll, "you have a way to change it." Everyone can use the same mechanism, whether a contribution to that change is code or documentation or legal advice or business perspective or customer feedback.
The value of that shared convention, arguably GitHub's most important innovation, is enhanced by other conventions imported from social media. On Twitter, for example, you can draw the attention of another Twitter user by mentioning their username. This @mention technique works in GitHub for individuals and for teams.
There's also GitHub Pages, a service that hosts websites on top of GitHub repositories. It's favored by technical bloggers who are familiar with Git and willing to install (and use locally) a Ruby-based site generator called Jekyll. But as others have discovered, you don't have to install Jekyll. It's possible to manage a GitHub Pages site entirely in the browser and enjoy the benefits of version history and issue discussion.