So, this is in part a bit of a brain dump as I intend to write something along the lines of this post for the Coko site.
Kotahi is the forthcoming publishing platform that we have now in a 1.0 alpha release. Kotahi is, by the way, a Maori word meaning ‘unity’ and we asked local iwi in northland (NZ) if we could use the name and they were happy for us to do so.
Coko has wanted a journal system for a long time. We started developing one in collaboration with the Collabra Psychology journal. But we were pretty understaffed to take it on and we needed folks on Editoria. That, and the fact that Hindawi had started their wonderful Phenom platform for journals meant we didn’t feel such a need to follow the project through at that time. eLife had also started Libero which was another journal system built on PubSweet. So why bother when so many good folks were on top of the problem? So we paused the effort.
So..why restart recently? Well, eLife have gone through a reshuffle and they aren’t focusing so much on Libero right now. That, plus Hindawi have a beautiful system (Phenom) but it has a lot of Hindawi business logic built in. If you want to use Phenom then you need to dig a lot of that code out. Not out of the question if you have the resources and certainly worth checking out if you do have the resources…but it feels like there is a gap now in the market for a modern, easily deployable, system.
That is why we restarted Kotahi. We already had a lot of stuff done so getting it across the line was an easy call to make. We had a little surplus too that we could spend on it, as we have no funding to build Kotahi. Not many funders are interested in supporting journal systems. So, we just decided to get on with it.
We have, as it happens, benefited alot from the wisdom accrued since we paused the dev. We have in the meantime built a micropublications system that is in production for the micropublication.org project. And also, we have seen inside many other workflows in a hands-on manner. My work with Workflow Sprints (a one day facilitated event to improve a publishers workflow) has allowed me to be a very privileged witness to many many workflows and use cases from journals, to preprints, micropublications, content aggregation, collaborative authoring of non-linear narratives, open access book production, OER textbook production and more…
From those sessions I have come to believe that there is very little difference in many of these workflows. There is, to speak directly, very little difference between a micropublications workflow, a journal workflow, and a preprint workflow.
I made a little slideshow about this here
The main point are the following slides showing a very lightweight breakdown of the three types of workflow..starting with Journals…the following is a very high birds-eye view of a typical journal workflow.
There is a gap between revise and publish that is covered by production. However, many journals currently have this managed by external vendors so in a way it is ‘outside’ a typical workflow. However, Kotahi will address this…more on this later…for now micropubs…
If you look at the difference in *workflow* between a journal and a micropub there isn’t much to speak of. Given that there is no strict category for what a micropub actually is, from my experience talking to, and working with, micropubs folks, the point they are eager on is that (from a workflow perspective) the process is ‘lighter’. The article might have a reviewer, or handling staff might know enough just to pass the content straight through. A revision might take place but since the articles are smaller than journal articles, the revision is mostly something of a ‘touch up’ rather than a radical revision. If they do review something it is done fast and with minimal reviewers. Maybe one for most cases.
So the main difference really is the ‘slightly lighter’ version of the same workflow Journals have… this may be hard for some micropubs people to stomach because, from my experience, they might see what they do as a radical departure from journals – possibly they may see micropubs as a necessary radical intervention and re-think because journals are too slow, leave important data on the cutting room floor, and manuscript publishing doesn’t account for the interesting (and long) journey of related findings researchers make along the way to a full manuscript for journals…
But, lets face it…. there is a difference between a ‘rethink’ of what kinds of things are worth publishing and the workflow associated with the publishing. Micropubs are a radical rethink of the former, but not yet on the later. That means, for all intents and purposes, we can consider journal workflows and micropub workflows to be more or less the same. That should actually be exciting for micropubs folks rather than deflating as it means you could very easily sit the two side by side in the same publishing channel … cross linking micropubs to manuscripts etc… achieving the progressive publishing, step by step to a full manuscript, that is part of the micropub movements narrative.
That is not to say I am defending the idea of manuscripts as a means of communicating research 🙂 I’m not… I’m relating usecases I see in the world right now and their associated workflows.
One last point about micropubs…unlike preprints and journals, the publishable content doesn’t look like a typical journal manuscript. The content, in fact, could be anything…it could be a gitlab repo, or a link to a jupyter/binder instance, or a link to stenci.la reproducible docs, or an abstract, or an image with some explanation… this is probably where micropubs deviate further from journals and preprints. The difference is in the content type, not really the workflow…so if you design a system that can work with ‘smaller’ articles, or different shaped articles, or even just with links to external resources as a publishable asset….well…then you have something…
So…what of preprints… well they aren’t that much different either. Basically, reviewing falls off the cliff…but not completely…. preprints have checks…some are automated, some are manual, before the stuff is pushed through. So, the process really is the same but ‘lighter’ again…
You can argue with me about this 🙂 I’d welcome it. But I don’t see the difference. As I say in the above slide deck, the difference in workflows between these 3 workflow is minimal, but configurable.
What I mean by that, is that it is easy to build a system that encapsulates any of these 3 workflows within the same system. It is also pretty simple to build a system that can deal with different content types, be they links, journal articles, abstracts-only or whatever…that isn’t so hard…One platform, if designed well, can do all 3 use cases.
That is what we have done with Kotathi.
If you would like to know more… email me. We are doing demos soon and also putting out the word for folks to join the effort.
