Since as long as I can remember, which equates to sometime around early 2012, I’ve been incredibly fortunate to work with numerous smart, inspiring, and innovative editorial colleagues at the Programming Historian. Over the years, we’ve explicitly maintained an equitable workload, with everyone consciously advancing the project in accordance with their own interests when they had time. Recently, when it became clear that I wouldn’t be able to do my share amidst new projects and obligations, I knew I had to step away and make room for new eyes, new ideas, and new energy. Last Monday was my last official day on the team. [N.B: I’ve habitually used “we” and “our” throughout this post, and I’m not ready to edit those out just yet.]
After investing considerable time and energy over many years across many facets of the project—editing lessons, developing a GitHub infrastructure, crafting a transparent peer review process, endlessly revising documentation, enabling a multi-lingual site with Jekyll and GitHub Pages, and tackling various design challenges (all of these collaboratively with other editors, of course)—I’d like to think it’s only natural to have wondered: “What’s going to happen after I leave?” No one wants their work to go for naught, even as we recognize that’s sometimes the nature of project volunteerism. I’ve asked myself this question before, and the answer was always, “I’m not sure but I’m not ready to move on.” As the project has matured, over the last year especially, and with a new cohort of insanely talented editors recently joining the team, the answer clearly became: “The project is going to get seriously better.” It’s much easier to step away on those terms.
Nonetheless, I’ve been a bit introspective about moving on. While I’m pleased with my own contributions, I realized that I’m most impressed with what PH’s editors and contributors collectively have managed to accomplish over the last few years. While we all hear about the challenges—and not infrequently the failures—of digital project sustainability, I want to highlight what I think has been a tremendous sustainability success story of the Programming Historian. I’m not a sustainability expert, but I thought it would be useful to document (from a naive experiential perspective) what seem in retrospect a few key factors that have helped fuel the project’s success. [These of course are my own views and do not represent any official position of PH.]
GitHub (it’s not just for code anymore)
If you’re learning about scholarly publishing and you end up at GitHub, you’ll probably think you’re in the wrong place. Although designed to manage code more than serve as a scholarly publication platform, it’s worked remarkably well for the Programming Historian. This isn’t the place for details, but it’s been immensely helpful because it automatically versions our lessons and documentation, keeps track of our changes to them (including the peer review process itself) facilitates our website, and helps us manage a wide range of issues that need to be addressed. Everything is stored in plain text, so I’m confident everything will be as easily readable in a few decades as it will be in a few days. I wrote a little about this at Digital Commons some time ago, but of course we’ve continued to revise our processes (the latest submission process and its revision history is of course openly available). More recently, as we’ve debated how much our lessons should remain fixed publications or be updated as software versions change, all the strategies we’ve considered would be easily facilitated by the standard capabilities of GitHub (and Git, the version tracking system on which GitHub is based). While that kind of technical flexibility was a theoretical advantage of our initial move from WordPress to GitHub Pages about four years ago, it has proven a most practical one as well. It’s awfully nice when your technology stays out of the way.
One aspect of using a platform like GitHub that I have come to appreciate deeply over the years is how it functions independently of any particular editor or institution. The archive of our editorial discussions, debates, and decisions, bestows an autonomy and value upon the project far beyond our tutorials. And it does this not merely by virtue of its existence, but because of its visibility. I remained surprised at the amount of potentially tacit editorial knowledge that the team built over time. GitHub has made it easy to preserve that (and access it on the fly: “Did’t we talk about that before? Oh yeah, and here’s what we decided and why”). Crucially, it helps maintain continuity amidst personnel change. More importantly, that work/knowledge has become an integral part of the project itself, not simply an auxiliary apparatus to our more overt lessons. While discussions about hidden work in the digital humanities will go on for some time, I’m glad that the Programming Historian works to make visible important contributions (whether from editors or reviewers or anyone else) that don’t necessarily get reflected in by-lines.
Participant Investment and Freedom
As the project team has grown, some editorial specialization has been necessary to ensure required work (often not super fun work) gets done. Yet we largely resisted (sometimes against my own wishes, to be honest) slotting new editors into particular roles or jobs. This allowed editors considerable freedom to work on different aspects of the project, to move between them as they wished, and to write their own job description so to speak. To me, this has fostered an empowering sense of investment among editors, who have not merely volunteered their time to maintain the momentum of a pre-existing project; rather, they have deliberately guided the project according to individual and collective goals. As the project grows, how sustainable this practice truly is remains to be seen, but I do think it was instrumental in the early years. It also speaks to the importance of continually re-evaluating how an editorial team works, something I think we did rather well.
I think a somewhat obscure key to our sustainability has gone far beyond how we publish and maintain lessons in a technical capacity, particularly the way we have tried to embody our editorial and publishing values in our processes, documentation, and even infrastructure. This has encouraged editors (me certainly, but I think others would tend to agree) to feel like they are working toward larger goals than editing and publishing peer-reviewed tutorials (as valuable a service as we believe this to be in itself). For me, helping to implement and refine an open and collaborative (rather than strictly judgmental) peer review process has been, in my view, one of my most significant contributions to the project. Recognizing that some editorial projects have fundamentally different goals, I remain convinced that the Programming Historian stands as a model of what rigorous peer review and scholarly publication could become. When I found myself editing documentation, or immersed in mostly invisible work like abstracting Jekyll templates or formatting metadata, I was ultimately motivated by the goal of creating a more friendly, transparent, and incredibly productive, scholarly publishing environment.
Find People You Like to Argue With
One reason I wanted to join the team years ago was to work with like-minded folks interested in digital publishing and digital humanities pedagogy. Over the years, as people have come and gone from the team, I found myself working with people who had or developed distinctly different visions of the project than I held. To be sure, there’s a point at which this can create dysfunction or paralysis. Looking back, I consider this intellectual plurality (and by this I mean more than one might expect to be helpful) a tremendous asset. In the past I might have shied away from seeking collaborators unless we all more or less agreed upon a vision of what to do and how to do it. Today I see that divergence as essential to sustainability. While frustrating at times, it always prevented us from racing to an endpoint and then wondering if maybe we should have gone elsewhere instead. That surely would have been far more frustrating than our abundance of caution, extended debate, or existential reflection ever was.
I don’t mean to suggest the Programming Historian has solved all the challenges of sustainability, that it’s unique in its success, or that it’s blueprinted a digital publishing utopia. Some of our (potential) contributors may be a bit uncomfortable with GitHub (although that’s something we continually tried to mitigate). A growing editorial team has made internal coordination a bit more tricky than it used to be. There are numerous ongoing issues to resolve, and some are quite old because editors couldn’t quite agree on what to do (I have contributed immensely to this, I might add; no one ever accused me of being un-opinionated). And so on…
But one indisputable fact remains: the Programming Historian marches on. I wouldn’t say the project has a life of its own; it breathes through its many volunteers, whatever role they play (our total budget since I started has been $0). Yet the editorial team in its many configurations has cultivated a camaraderie, a community, a vision, an efficiency, and a project that stands not only to endure but to thrive for a long time. Reflecting on many years of Skype calls, philosophical debates, technical challenges, a giant AHA poster and flurries of GitHub issue commenting, it’s incredibly rewarding to see how these have funneled into the project’s stability, growth, and maturity amidst change. When I started in 2012, I wasn’t sure the project would be relevant in 2017, much less be accelerating as it is (just check out the deluge of upcoming lessons and the latest backend improvements).
I’m seriously humbled and proud to have been part of the team. While I should thank each past and present (and future?) editor individually for what they’ve taught me, that will happen elsewhere. But I absolutely must mention some longstanding colleagues, namely Bill Turkel (who launched the initial project and eventually invited me to help), and two editors I’ve worked with for many years, Adam Crymble (who’s anchored the project for its existence and pushed it in many new directions), and Caleb McDaniel (who facilitated so much of our WordPress to GitHub transition and subsequent development). Even the relatively new editors with whom I’ve worked with most closely, particularly Matthew Lincoln and Amanda Visconti, have made enormous contributions to PH and my own knowledge in a very short time.
Although I’ve discussed sustainability from an editorial perspective, it’s truly a community effort. I hope everyone who hasn’t visited the Programming Historian of late will check out the many recent lessons (maybe you’ll notice some new design features), jump into an editorial conversation (which are open on purpose!), write a lesson, or at least volunteer to help review one. No amount of engagement is too little, and you’ll work with some fantastic people along the way. I’ll dearly miss my regular conversations with the editors and contributors, but I can’t wait to see what they have in store for us.