Description
I write as Chair of ProgHist Ltd with an update on the work to develop our infrastructure. Apologies for the long message. I've tried to be as brief as I can but I hope you appreciate this is a complex and important topic.
As you will be aware, last year we secured funds from Jisc and the Corporation for Digital Scholarship to gather community needs, to turn those into requirements, and to use that work as a basis for making a decision about how best to transition to a new publishing infrastructure. These funds were secured on the basis that our current infrastructure, whilst well loved by many in our community, is no longer fit for purpose: it is built on a static-site generator (Jekyll) that is no longer in active development and the complexity of our site has resulted in build times (7-8 mins) that both discourage us from using it as a platform to develop DH skills (which it was earlier in the project) and slow down our editorial work.
Many of you participated in requirements gathering. Thank you for doing so, and to Anisa for co-coordinating both the requirements gathering and synthesis. The resulting report and recommendations based on this work can be found here
2025_01-ph-tech-phase-1-requirements-recommendations.pdf.
Over the last month or so this has been boiled down to the following requirements:
- Our infrastructure needs simplified navigation, crisper typography, advanced search, the ability to facilitate offline use, and structured article metadata for harvesting by aggregators.
- Our Publishing Manager should coordinate future site development (drawing on recommendations in the Technical Infrastructure Renewal Phase 1 Report) in the form of community development sprints.
- A new technical infrastructure is needed for our site.
On 3., two options have emerged. The first is building a new custom site using a modern static-site generator, such as Hugo. This gives us maximum flexibility for development and customisation, and will mean retaining our existing publishing workflows (submission, peer-review, etc) but also introduces risk to continuation of service without mutualising development expertise across our editorial community. The second is moving to an existing publishing platform, such as Janeway. This gives us less flexibility for development and customisation (though much more than Janeway did when last evaluated 4-5 years ago) and would shift our workflows closer to a 'normal' journal, but with the benefit of uptime, plugins, security etc being taken care for us and a secure foundation on which to build our infrastructure as digital research/humanities evolves.
Anisa and I have evaluated the options and are leaning towards recommending Janeway. The costs here would be small compared with our running costs (publishing staff, specialist translators/copyeditors, services such as netlify, etc, though of course Janeway wouldn't replace investments in things like publishing staff and specialist translators/copyeditors, we'd still need them), and in return we'd get access to support transitioning our back catalogue to a new infrastructure, a partner committed to championing open infrastructure and diamond OA publishing, and a development platform (built in django/python) that provides our community with opportunities to contribute to a shared open infrastructure, both for the benefit of our community and for the benefit of all Janeway users.
Based on benchmarking against the way we operate right now, Janeway can more or less accommodate all our publishing needs (e.g. quirks we have around article difficulty and types of contributor role), with a few areas needing more discussion (principally, modification of articles). Moving to Janeway would also significantly change our publishing workflows, but it would not require a change to the values that underpin those workflows: open, efficient, documented, scalable, accessible, and sustainable publishing in and for the digital humanities.
After so many years finessing how we work, any change would be a big change. In turn this would require significant investment in time and energy to manage and make happen (the remaining Jisc and Corporation for Digital Scholarship funds would be invested here to mitigate impact on editorial teams). But I hope you all agree that something has to be done, that stasis isn't a viable option. Whilst Anisa and I are leaning towards Janeway, no decision has been made and your views are vital. What I would like to know from you now is how this proposal lands with you, the questions you have, and the questions you anticipate will arise. From there, Anisa and I can build a picture of community sentiment and use that as a basis for putting forward a formal recommendation.
FAQ
Based on initial feedback and questions, I provide some additional notes and points of detail below:
Do we have an estimated cost for importing the back-catalogue?
Based on an initial conversation with Janeway, support for that would be included. We should also be able to arrange for a test instance to be created with a handful for articles, so we can see the import before make any decision.
Has anyone reviewed their current capabilities against PH requirements?
Yes. I have a list of PH requirements that I went through with a member of the Janeway team. Only versioning/modification came up as a slight mismatch between our way of working and Janeway as an architecture. That said, they have versioning in their pre-print server architecture, so we should be able to reuse that. I got the strong sense from speaking to the Janeway team that if partners have development needs that broader communities will benefit from, they get added to the roadmap. For example, Janeway are implementing CRediT at the moment in a way that means contributor roles not in that taxonomy, which we’d need, can be implemented. And - to reiterate the point - as Janeway is a development platform (built in django/python)l, as things come up that we need, Janeway provides opportunities for our community to contribute to an open community infrastructure, both for our benefit and the benefit of all Janeway users (rather than just directing that effort at our own infrastructure).
Will Janeway count PH as a single title or one per language? Will a cost-per-title change PH future planning?
Subject to negotiation, we will be one publisher with four journals. We have aligned values with Janeway (some of you may have seen Open Journals Collective launch this week, which is spearheaded by the same people), share some supporters with OLH, and have a professional publishing staff that would handle author, editor, and peer reviewer relations (which is in contrast to how Janeway typically work with 'just' journals), which taken together means I'm hopeful we can have a sensible conversation about price. I will be clear in those conversations that we have ambitions to host more language journals that publish under the PH banner, but that that has been limited by our existing infrastructure rather than ambition.
Have we investigated about financial sustainability with Janeway?
We would of course ask and investigate this before any decision is made or contract signed. My understanding is that Janeway is intimately connected to Open Library of Humanities. OLH has over 300 geographically dispersed supporters, who invest in their work in a way comparable to our IPPs.
How would moving to a publishing platform (rather than building our own) change PH's identity as a "brand"? Will this mean that we are just a publisher of journals rather than a project?
We’d need to pay attention to this if we moved to a journal-centric technical infrastructure like Janeway. We are a project and a community not 'just' a publisher of journals. Moving to a service like Janeway will not mean removing and/or replacing our wonderful staff. They will still have plenty to do and we will continue to employ them so long as we have the IPP/financial backing to do so. Freeing our staff time from technical troubleshooting will, I hope, give us more capacity to build, maintain, and support our community of editors, authors, peer reviewers, translators, copyeditors, maintainers, etc. This - IMO - is a better investment in the DH community than time spent on technical troubleshooting.
What would happen to our publications if/when Programming Historian is no longer active? What happens if we run out of money to pay Janeway for a hosted service?
I will ask, though note that Janeway is open source so can be self-published if needed. In this scenario we revert back to an entirely volunteer run organisation. At present, this is a worst case scenario. This scenario is, of course, something that the Trustees of ProgHist Ltd - the publisher that underpins PH - are working hard to avoid: nobody wants to lose our wonderful staff. And we welcome ideas and suggestions from all members of the community on income sources and partnerships that can sustain our work.
In an important sense, this infrastructure proposal is also about sustaining our future: the scenario that keeps me up at night is that the site breaks in some way, it goes down or we can't publish any edits/changes/lessons, we don't have the technical capability to get it back up (because we've largely stopped developing the site we built for reasons described above), our supporters stop investing in us because we are no longer able to publish, and then we are no longer able to pay our staff. Janeway (it seems) takes that risk away, even if it adds the risk of having some bills to pay for a hosted service. But if we can’t pay that bill, then a lot would have already gone wrong.
Are there examples of Janeway websites we could look at?
Yes. The best way to find examples is to browse their news feed, which is hosted on Open Library of Humanities. For example, UCL and Leiden have made substantial investments in moving their journals to Janeway.