Github logo

We recently decided to move all of our public-facing documentation to Github—including this blog. It is a puzzling decision, at first glance. Why turn to a Microsoft-owned code repository to store and share materials related to scholarly publishing? One answer is that it isn’t about Github per se—we are, instead, choosing the underling, open-source Git system that Github and other Git-based services use. We could, for example, move our repositories to a self-hosted GitLab installation—our long-term goal, in fact. But for now it’s Github that’s hosting our Git-tracked stuff.

There’s a lot of strange terminology in that first paragraph, at least for non-programmers like us. So here’s the quickest of primers, with a link to a more detailed explanation. Git was created by Linus Torvalds, the same Finnish programmer who develops the Linux operation system “kernel.” Git is an open-source system for tracking changes to software code. Multiple coders can make and propose changes to an application, with every version—and the differences between them—automatically tracked. So Git is just an especially popular version-control system that Github, as a web-based commercial service, relies on.

Though designed for software code, Github can be used for non-code files and projects too. And if your project is public and openly licensed—as all of’s “repositories” are—Github is free. (As a 510(c)3 nonprofit like, you can obtain an account that includes private repositories too; we haven’t bothered, since we intend to use Github for openly licensed material shared back to the community.)

As the use of “repository” has already suggested, Git and Github have their own arcane (and confusing) terminology. The language takes some getting used to, for sure—terms like “commit”, “pull”, and “diff” seem designed to confound outsiders. But mastering the language, and the basic functions, is worth it.

Which brings us to the benefits. Github allows scholarly publishers like to share materials—reference files, workflows, published works—to others in the community, with clear, open licensing. The service is great for tracking updates over time—useful to us, as a kind of time machine, but also to community members looking to understand the evolution of, say, a policy document or even the gestation of a scholarly work. Hosting materials on Github entails an operational transparency that we embrace as a mission-driven principle. And, thanks to Github, folks outside the formal organization can contribute to our work, through a commenting system (called “issues”) and more formal suggested changes (called “pull requests”). They can even copy any of our repositories, to adapt for their own (openly licensed) purposes (a “fork,” in Git language).

There is much more to say about how Git and Github work. We recommend this video introduction narrated by Jon Tennant as part of the Open Science MOOC project he is spearheading (which, fittingly, is hosted on Github). In fact, it was the indefatigable Tennant, through the MOOC and other projects, who has convinced us that Github and Git are useful services for an open-access publisher like

We have created four repositories that, for now, are mostly empty:

  • replicateus – a home for the plain-text versions of these posts and the eventual book-length summary
  • organization – the place where all of our operating documents—across editorial, visibility, and operational domains—will live (excluding certain financial and personnel records)
  • singles – a directory to collect files related to specific non-serial works, published or in-progress
  • serials – the home for documents related to serial publications

We will be moving documents over, and otherwise building out these repositories over time.