“This month, a second Hindawi journal will move onto the Phenom Review system, our new peer review platform built entirely open source. Phenom
Review is part of Hindawi’s collaboration with Coko utilizing their open source PubSweet framework. […] The migration of our remaining 230 journals is expected to be completed early in the new year.”
Tag: Hindawi
Publishing Platforms built with PubSweet
I get asked a lot how many platforms are there built on top of PubSweet. It can be quite difficult to understand this by looking at the Coko website. So here goes (we might add to the below and put it on the Coko site).
Hindawi
Hindawi is currently considering names for the journal platform it currently has in production, plus they are building more than one platform. First up is their journal platform, currently in production for their first journal. It is a low volume journal, with 20 submissions so far and 1 article which has gone through the entire process and been accepted for publication.
Hindawi are looking to make the platform multi-tenanted – which is a often misused/misunderstood phrase, but essentially it points to a strategy for adapting the software so that one organisation can run multiple journals from the same (singular) install/instance. Hindawi then will be going live with the second journal in the near future. They are leading the charge in the Coko community on this multi-tenanted approach and we continue to learn a lot from this amazing team of folks.
On top of this Hindawi are building a QA platform on top of PubSweet. All of which is open source and available to whoever wants it. They went live within a year of beginning to build. Notably the first to go into production with a PubSweet Journal platform.
After gaining this experience (building their first PubSweet Journal platform) they scaled their team up to 18 people working on different PubSweet developments.
eLife
eLife have a special issue where they wish to replace their current platform – EJP – but in phases. So they have been working closely with the EJP team to replace the workflow step by step. The first step has been to replace the submission workflow. Now 60% of all submissions go through their PubSweet submission component and then the article is transitioned into EJP via an EJP API (recently built). The content is transferred between the two systems using a MECA bundle, representing the first time MECA has been used in the world in a live use case. The MECA component is, of course, is open source and available to anyone building a PubSweet platform. They went live with the submission app in just over a year of beginning to build.
eLife is building out their entire workflow as a series of inter-connected PubSweet apps. This means you can grab one part of their system and integrate it in your workflow. Its an interesting strategy.
The cool thing about the Coko community is that we have a variety of approaches to similar problems so it will be interesting to see how attractive the multiple app proposition is to others. They will name each standalone app with the prefix Libero (eg Libero Publisher, Libero Review etc). All is open source.
It has to be noted that EJP’s position is a very enlightened one and fantastic to see a forward-looking vendor working with a Coko community member. I am sure this is going to work out in their favor going forward. I think the number of folks working on these platform components for eLife is maybe 6-10 … will ask Paul and check.
EBI
Lead by the very awesome Audrey Hamelers, the EBI (European Bioinformatics Institute) platform is going live in May with their system. They are intending to flick the switch and go from 0 to 100. The platform looks awesome and it is essentially a multiple source post-publish QA system for content aggregation (pushing to EPMC). It supports manual input through a submission wizard as well as batch FTP upload/submission. Although built specifically for their workflow it is conceivable the platform could be used for any workflow requiring post acceptance/production QA.
They have done some cool stuff with annotations using Nick Stennings Annotator, to QA XML. They are also using XSweet for docx to HTML conversion and a whole lot of other interesting tech. EBI have built this extremely quickly, with most of it done in a couple of months. Other priorities got in the way and they had to pause for a few months, but even so, if they go live in May it will be done in under a year from starting. I think they have a small dev team of about 3-5.
EBI has most of the Coko community meets. Awesome folks. All open source.
Editoria
Editoria is developed by the Coko team. A fully fledged post-acquisition book production workflow. It was developed with the University of California Press and the Californian Digital Library. Editoria is now used in production by UCP, ATLA, Punctum Books and Book Sprints. There is a fledgling but healthy community evolving around the product as well as a forthcoming hosting vendor agreement (tba). All open source. Editoria has a small team of (currently) 2 devs working on the core Editoria platform, however much more horsepower is added when you consider dev done on CSS stylesheets, paged.js, XSweet (docx to HTML conversion) and Wax (editor). So really the team is more like 6.
Micropublications
The wonderful wormbase crew commissioned the Coko team to develop a micropublications platform for their micropublications.org project. It follows a simple micropubs workflow which has been designed and built to allow for its re-purposing by any micropubs use case. When it gets down to it however the line between a journal workflow and a micropubs workflow (even tho micropubs is a broadly used and misused term) is a little imaginary. The two look very similar, the real difference is the scope of material submitted and the intention to process it quickly. This platform could probably also be used for journal submissions.
It has been in active dev for a year. Unsure when we will go live, it will probably be a progressively live situation with the initial switch being thrown sometime this year. All open source. Currently one (extremely productive) Coko dev.
Aperture
Another micropubs platform, dev just just begun with one person. It is a platform built for the Organisation of Human Brain Mapping. Awesome folks. I did a workflow sprint with them last year. Cool people and this will be a cool platform. Most interesting is their desire to publish living entities eg Jupyter Notebooks. Super interesting. All open source.
Pre-Review
Built by the pre-review folks and most specifically by Coko friend Rik Smith Unna. Great chap. This is a pre-print review system built to replace their current system that was built ontop of Authorea. All open source. One current dev (Rik).
Digital Science
A new addition – their innovations team is building a very interesting awards system. That in itself isn’t so exciting but their idea is to build a system with configurable workflows. You model a workflow, export, and then the PubSweet app is automatically compiled to suit. Very ambitious and very speculative. A lot to be learned from this and the good thing is that it is all open source and the DS folks are great to work with. Looking forward to see how this evolves. I think there is one developer currently working on this.
Xpub-Collabra
Xpub-collabra is a journal platform the Coko dev team have developed with Dan Morgan from the Collabra Psychology journal. We have put one year dev into it but with just one developer working on it. I’ve decided to pause dev for a little while so we can accelerate other efforts. Our platform dev team is small and we need to maximise resources, and as eLife and Hindawi have Journal offerings in the mix, we have less urgency to develop this platform at the moment. Though we aren’t abandoning it …stay tuned. (One interesting avenue is to collaborate with orgs with dev resources to finish this off – if that sounds like you, give me a call).
And…
There are a number of projects in the wind. A pre-acquistion monograph workflow, emergency medicines workflow and some other stuff. Plenty going on…consider this though… although PubSweet has been in development for 3 years, we only started building the community a year ago. Already 9 platforms are being built, covering a variety of fascinating usecases and 3 of which are now in production, 2 of which started building less than a year ago… needless to say, watch this space.
The Awesome eLife
Today eLife went live with their new submission wizard built on PubSweet… this following the introduction of Hindawi’s journal system, also built on PubSweet, in December… makes for an awesome couple of months! 🙂
Coko and Open Source
We’ve tried to build software for other people before, but it wasn’t until we worked with the Coko Foundation that we realised how important a “community-first” approach is. The benefits from the conversations, before any code is even written, is obvious when you start writing and even more obvious when you see the quality of the finished product.
– Paul Shannon, Head of Technology, Elife
Paul Shannon is a great advocate for the way we work in the Coko community. eLife was one of the first to see the potential in the way we work, and I remember clearly sitting in a pub talking to Paul about it with Kristen. He was enthusiastic and genuinely supportive when we explained in straight forward terms that we were trying to establish *real* collaboration and not collaboration in name only which is unfortunately so often the case.
We work closely with Paul and the eLife team, as well as the Hindawi team, and in many cases we are each extending the others team. That is what close collaboration is all about. As Paul states:
I love the pleasant surprise when one of your collaborators solves a problem for you, or when you find a problem you thought was just unique to you being discussed elsewhere. For us, the main benefit is knowing that what we’re building is useful to others and is solving the important problems – things get built more quickly and more correctly which reduces the burden on everyone.
This is very true. In a community when you share the burden of a problem you have the luxury of bringing in a bunch of active minds who have a desire to solve the same thing but are not on your payroll. So, you can leverage expertise in areas that your team doesn’t necessarily have. Software development in publishing these days covers a huge scope – everything from workflow, to file formats, OAuth, to containerised deployments and much more. Its hard for any one team to have that scope of expertise. But we have so far found, even with our relatively small foundational group, that we have always been able to find someone in our community that knows a lot about any given problem space.
So, extending your own team and being able to reach out to others with specific expertise is a huge advantage of working in the Coko community. But it doesn’t stop there. It is often the case that someone will be able to improve on your approach to a specific problem, and sometimes it is also true that someone in the community will offer to build it since they have the same need.
This leads to, as Paul says, things getting built more ‘quickly and correctly’. I absolutely agree, as does Andrew Smeall of Hindawi who also collaborates with us:
[Coko] have marshalled a diverse group of publishers towards a shared goal. Together, we’ve implemented a radically open process of constructive collaboration, where each member benefits from the strengths of the others. The result has been rapid progress towards an elegant, maintainable product.
– Andrew Smeall, Head of Strategic Products, Hindawi
This is awesome stuff. Imagine not having to solve all the problems of building a publishing system by yourself?
Of course there is a cost to this. To communicate this I sometimes use the phrase ‘The cost of collaboration is conversation”. This is very true. In order to benefit from collaboration in an open source project, you have to be communicative. We have several mechanisms to help with this, the mattermost chat channel is one. If you visit the Coko GitLab (where the code is stored) you will also find it is very active with conversations in the commits and the issues (eg https://gitlab.coko.foundation/XSweet/XSweet/issues/106) . We also have a lightweight RFC process (eg https://gitlab.coko.foundation/pubsweet/pubsweet/issues/341), and we also have smaller WorkGroups for developers and designers. These WorkGroups consist of one person per collaborating organisation each meeting and is facilitated by Coko. This keeps the group small and the conversation focused, lowering the overhead for all.
The result of all this is that we can keep the overhead low, and produce better products than if we were working alone. We can also produce them faster, learning from each other as we go. As Andrew also says:
An improvement for one becomes an improvement for all. Individual communities can focus on core areas of expertise — peer review, hosting, discovery — knowing that their innovations will improve the entire system. The result is more creativity, a more diverse set of solutions, and, ultimately, faster progress.
There is a secondary benefit too… communities are in themselves motivating, as Paul Shannon says:
Having other people build components to solve the problems you are facing is a great benefit of a common infrastructure, but also knowing that what you’re building is useful to more than just your team really adds energy and purpose to our teams of developers and designers.
All in all, its hard to argue against this kind of value in collaboration. I’m not currently seeing any downside except (for me) lots of travel! But thats in my DNA now, so I can handle it….would be good though if there was better surf in London and Athens…
We will add more organisations to the mix as we go…some announcements coming shortly. But here too we are being careful. Its important that we add the right orgs, ones that have a willingness to put in as well as take out…we don’t want to host parasites… this ecosystem can only work if there is close communication and a dedication to working together. This requires trust and good faith and if an org enters this tight community with the intention of free riding they will soon find out they are not welcome. For this to work for you, you need also to work for it. It is not a one way street. If you can accept that and get into the right mode, you will benefit greatly AND you will have a great time… communities are also fun when done right and so far our community meets are super fascinating and filled with awesome folks. It is an honor and a joy to hang out with them and solve problems together.
One of the additional benefits, which I touch on above, is learning from each other. In the last community meet, we had a few weeks ago in London each of the three foundational orgs – Coko, eLife, Hindawi – presented where they were with their journal platforms built on top of PubSweet. Each had taken slightly different paths to solve similar problems. There was much overlap of course, but where I learned the most was where someone had tackled the same problem slightly differently…this was really the first time this had occurred in our community and it was tremendously exciting.
As it happens, there seem to be quite a few orgs wanting to jump into the community. So, from here, it is all about scaling gracefully. We will work out processes to manage and maintain this good faith and good will as we grow. The foundations are there, now it’s all about the mechanics of growth…
Getting Design and User Experience Right in Open Source
So, I’ve thought about Open Source and design… I’ve even written some articles on opensource.com (https://opensource.com/users/adam-hyde) about the subject, and created a methodology for bringing the use-case specialist (user) into the center of the process, along with designers and everyone else…
I’ve also brought this subject up a number of times in Shuttleworth Foundation meetings and received some invaluable advice and insights from fellow Fellows and Shuttleworth staff… many of whom have heard my whacky ideas several times over now and are still patiently listening and offering advice! Forever grateful to y’all… especially Helen, Sean, Arthur, and Andrew for ideas and feedback.
But what I didn’t expect, is that I’d be part of a wider community where these ideas could form the basis of the culture. This is what I saw happen this week in London as part of the PubSweet Global meet Coko hosted (& I facilitated).
There were about 25 of us coming together to discuss all things PubSweet with particular emphasis on building Journals. Present were many folks from eLife, Hindawi, Ubiquity, and Coko. We got to the topic of ‘Technical Council’ and I tabled the idea that we need some kind of process in place so that all stakeholders feel they are getting a say in, and are being heard, the future of PubSweet – since it is their technology too.
When I tabled the idea that we need some form of technical council, Catriona MacCallum, who I used to work with at PLOS, asked the very salient question – and what about the users?
I’m very grateful to Catriona for that question as it gave me the opportunity to open up the concept and talk about how there are very few communities in open source that treat software development as anything other than just a technical problem, and further that we should take this opportunity to experiment in making this community strong on solving ‘user needs’ and design… it was a great discussion and I’m also grateful to eLife’s head of product – Giuliano Maciocci – for having a strong voice in favor of this and really stepping into, what looks to be, an emergent leadership role with regard to design in the community.
As a result, we formed a Dev Council and a Design Council. These are oversight/communication groups of 5 people each. So, they don’t ‘govern’ but the choice by the community to form these two groups is a testament to how seriously the community is to making beautiful products that solve real problems in publishing for real people…
All in all, a pretty fantastic 3 days.
Great article on open source for open science
From Paul Peters, CEO for Hindawi, a great article on open source and open science/open access.
Rare in the scholarly publishing scene to find someone that understands the value of open source as clearly as is articulated here.