Category: Open Source publishing

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.

 

 

 

Whooohoooooooo!

Hindawi launches its Journal system today built on Coko PubSweet tech!!!

This week, Hindawi is releasing a new peer review system that will debut on Bioinorganic Chemistry and Applications. The new platform is open source, developed as part of Hindawi’s collaboration with the Collaborative Knowledge Foundation (Coko). This release is a first step towards a network of open publishing infrastructure that Hindawi, Coko, and collaborating organisations will develop and share with the research community.

https://about.hindawi.com/blog/hindawi-launches-new-open-source-peer-review-system/

This is major news for the Coko Community.

Intro to the Command Line

Many years ago when I was experimenting with Book Sprints I suggested to the Free Software Foundation that we do a Book Sprint at the LibrePlanet meeting in Boston (2009). The idea was to make a book introducing people to the command line. I asked Andy Oram (friend and editor at O’Reilly) if he would help me put it together and so we announced it and both turned up at the event to make it happen.

The Book Sprint was meant to be an opt-in. So ‘anyone’ who was at the event could come in and write the book. Of course ‘everyone’ wanted instead to go to the presentations! So we had almost no one from the event attend…it felt very lonely for a bit…

Then, a few people turned up online and because they couldn’t participate with the conference they wanted to be part of LibrePlanet and contribute to the book. It was an astonishing thing. More and more people turned up. I remember going to bed on the first night (it was a 2 day Book Sprint) and feeling like all was not lost, waking up the next day and a whole lot more of the book was done. It was amazing.

There were some fantastic contributions and we coordinated it all through online chat (I think it was IRC but can’t remember). I remember in particular having a really lovely chat with one participant – I think their name was ‘Freaky Clown’ but I can’t remember for sure. I remember a sense of solidarity and peer-ness when talking to them about the book and the process. There were a lot of things that made that process special.

Anyways…we produced the book in 2 days and it is quite an amazing work.

introduction-to-the-command-line

It was on offer from FLOSS Manuals (still there – http://write.flossmanuals.net/command-line/introduction/), but more interestingly the Free Software Foundation offered it for sale – https://shop.fsf.org/books-docs/introduction-command-line

The cool thing about that was (apart from the FSF publishing it which was already pretty cool) that they used their own cover art etc and made it their own… freedom in action.

Apparently the book has been very successful – its used as a textbook, has been reviewed a lot, and seems to get a lot of use – but imagine my surprise when I saw in the LibrePlanet meet of 2018 this program item:

Introduction to the Command Line brainstorming session

We’re updating the popular 150-page Introduction to the Command Line. What do you think should be in the new edition? We’ll be discussing content and process for updating this important work.

A product of a partnership between the FSF and Floss Manuals, this book gives new computer users a gentle, beginner’s window onto Bash, vim, a few scripting languages, and other key tools offered on the Unix/GNU command line. A lot has happened since the book was released in 2009. We want to include new developments without substantially increasing the length of the book.

Pretty cool! Andy hosted the session and I hope it went well… very nice to think these crazy things you are a part of become something and take on a life of their own….

I even found the only image I know of taken at the event (by me) when (on the second day) some folks took pity on us sitting by ourselves and came in and contributed…Andy on far left.

introcommandline-about-sprint-en

I also found this old blog I did on the FSF site –https://www.fsf.org/blogs/community/introduction-to-the-command-line

What is xPub?

So, there are a lot of product names at Coko – PubSweet, Editoria, XSweet, INK, xPub etc etc etc… so becoming tricky to track, but I wanted it seems there are quite a few people interested in xPub right now.

xPub is not really a product as such, it’s more a group of products – each of which relates to Journal workflows. The names for each product indicyae those relationships: xpub-collabra, xpub-elife, xpub-faraday (Hindawi) and xpub-epmc

Each of these is a platform, so yip, you read it right – there are actually no less than 4 journal platforms being developed in the Coko community, not including the Micropublications platforms (of which there are two – one developed with Wormbase, and the other with the Organisation for Human Brain Mapping).

So, right from the get go our ‘offer’ is not standard. We don’t offer one platform to rule them all – there are many journal platforms in production. All of these are built on top of PubSweet… PubSweet is a kind of ‘headless’ publishing platform….it’s more or less the backend brains in that it is a kind of framework that ‘thinks like a publishing system’ but has not determined a workflow for you. So, each of the xpub-* platforms are actually publishing platforms built to meet a specific workflow and built on top of PubSweet…

Here is a crappy diagram (drawn in haste) to get the basic idea across:

ya

In the above, you see a PubSweet platform (eg. xpub-elife). PubSweet itself is the whole app – it sort of ‘encapsulates’ everything. Really though, you get the PubSweet core and then extend it with front-end components to meet your workflow needs. A typical front-end component might be a login screen, or a dash, a submission info page, a reviewer form etc.

You can also extend PubSweet on the back end as well (eg to enable integration with external services etc). The following is a more accurate but slightly techy architectural overview (you can skip this image and the following paragraph if you want to avoid the slightly techie part of this article).

ps2

In case you are wondering – everything is written in Javascript. Why did we choose JS? It was a deliberate choice to go with a language that was prolific. Almost every dev around these days needs to know some Javascript (it’s the most popular language by far on Github), this makes finding a developer to work on your project is as easy as we could possibly make it. JS is also a phenomenal language these days. Fast, sophisticated and more than capable of supporting large-scale publishing requirements. I mean, if it’s good enough for Paypal, Netflix, Linkedin, Uber and ebay, then it is good enough for you.

So each PubSweet platform has its own collection of front and back end components to meet the workflow of someone’s dreams… the idea is that to achieve the platform of your dreams you can reuse what others have already built and then just build what isn’t already available. In a sense, you can ‘assemble’ your platform from existing parts.

c1e22edf10cd018c9d1a697c29fbd891

The nice thing about this is that each of the organisations building Journal platforms are sharing the following:

  1. the same back end/framework (PubSweet)
  2. various front (and back) end components
  3. lessons learned…

Each organisation has a vision of their ideal Journal workflow. They then design and build this on top of PubSweet, but as they do, they build various components (either page-based components such as a dashboard, or smaller UI components we call atoms and molecules) and they share these components with everyone. Hence, you should check the list of components before you start building in case the component you need already exists.

We have various agreed-upon ways to build and share components (see this as an example). These best practices are continuously evolving but you can read some of the latest discussions about this approach here – https://gitlab.coko.foundation/pubsweet/pubsweet/issues/408

Of course, all code is reusable in the Coko community because it’s all open source. The best practices are there to make the code easy to reuse.

All agreements as per above are made by consensus by the community. It is actually a pretty snappy process – don’t believe every crappy thing you read about how open source is built. Open source community processes can be elegant and fast, and the resulting code can beautiful. Coko is a good example of this – a community of professionals collaborating together to make fantastic open source software.

dsc01017

So… back to the xPub story. To make these decisions on how to share components etc, we have regular meetings with various workgroups (we keep the numbers in each group small so we can move fast), and we also have quite a few in-person meetings. Not only do we have PubSweet community meetings where all of these organisations meet, but we have various get-togethers on various topics if required. For example, we met in Cambridge recently to discuss Libero (the eLife delivery product), before that EBI there was an onboarding session in Athens, next month we have a special designers workgroup in-person meet, anbd so on. All this helps us keep in contact with each other, which helps build trust, but also turns out to lift energy levels and boost production. These meetings are fun.

dsc01022

Also at these meetings, we learn from each other. One of the big problems in this sector, and one of the reasons people ask ‘why are publishing platforms so hard to build?‘ (after a number of high profile failures), is that there has not been a focused effort to share experiences on how to build publishing platforms. So, that is what we are doing – at each meeting we talk about what we have learned, how we are thinking about things, and show each other what we have done. The last meeting, for example, each xPub platform gave a deep dive to everyone in the group in a process known as speed geeking (it wasn’t so speedy as each table had 25-30 mins to go through their platform).

dsc00903

dsc00944

So, xPub isn’t a single platform, it’s more the community that is building journal platforms on top of PubSweet and sharing learnings and components. It is a very cool thing.

As a community, we also produced a book entitled ‘PubSweet – how to build a publishing platform’. You can get this for free here – https://coko.foundation/books/

I can also send you a print copy (they look great!) if you send me a postal address.

dsc00851

The book covers many things – a whole lot of technical documentation for how to build and share components etc, as well as some information about to think about workflow and how to map this into a PubSweet system. Personally, I don’t think the technology is very hard when it comes to building platforms – we knew what we wanted from the beginning with PubSweet and went about and built it (not to downplay the extraordinary job Jure Triglav has done in leading this effort). But the real hard stuff is actually thinking about workflow – not many publishing orgs have had the opportunity to think about designing their workflow to meet exactly what they want (rather than shoe-horning it into an existing system), and so we have had to beat this track for other to follow. It has been quite a journey but the book pretty effectively outlines how to think about workflow (which of course is a process that can be accelerated using Workflow Sprints which is a process I designed to facilitate a publisher to design their own workflow and PubSweet platform in one day).

0e7a0345

In that book you can see some high level ‘architectures’ of each of the xPub platforms such as the following (xpub-collabora):

02-adam-workflow-v3

Or this (xpub-epmc):

ebi

So, you might be asking…. at what stage of development  are each of these platforms? … I’ll leave it to each of the teams to say exactly, but it has been shocking to see how fast things have come along. I mean, the xPub community only really got together for the first time mid-last year, and building started for most late last year and early this year. It looks like we will have a lot of platforms landing by the end of this year. In this sector that is lightning fast. EBI are particularly impressive – they started two months ago and are almost ready to go – if it weren’t for the fact we are all replacing the under-the-hood data model we designed together at the last PubSweet meet, they would be good to go already. They can achieve such speed because they are reusing a lot of the components that the other teams built before them (and because EBI are just very good 🙂 ).

I can speak a little more about xpub-collabra since that is the platform Coko is building for and with the Collabra Psychology Journal. It’s looking pretty nice. We have some work tidying up the UI, replacing the data model and a few other things, but it’s looking rather good. We are also putting some time into making it a generic platform since the Collabra workflow follows a fairly ‘plain vanilla’ model. So we are building in some management interfaces and various bits and pieces to make it more widely useful – for example, Giannis just built in a Submission Info builder – enabling a Journal admin to build their own submission forms. It requires some hand-holding to use right now, but we’ll shape it to be very usable by your general journal adminy-type. We also have to integrate ORCID and DOIs, extend the range of submission file types etc… but it’s pretty close.

Below is a video showing xpub-collabra in action. It is a a version from some months ago, but you can see the workflow pretty well in this demo.

I think most of the xpub community is going to offer their new platforms to the market in various ways. This will be interesting as there are very different approaches at play. Hindawi, for example, is looking to make their platform a multi-tenant platform, eLife will put JATS at the centre of the workflow etc… So look for more news on that also. For our part, Coko will offer xPub through a partnership with a hosting provider – probably with the same organisations we will work with for Editoria hosting services. Since everything we do is open source, we will also be supplying all the Docker, Helm and Kubernetes scripts so that you can set up your own commercial hosting service if that is your cup of tea (or you can extend your offering should you already be a hosting provider). Coko is pretty close to getting our first hosting partnership set up, so look for news of that soon!

One last thing – because of the modular nature of any platform built on top of PubSweet, it is possible to take any of the xPub platforms and customise it to meet your needs. No need to start building from zero. Additionally, the modularity means you can extend the systems with your own interesting new innovation – finally a place for innovation to call home in the publishing platform world….

So… there is a lot going on in the xPub world….we look quite different to the rest of the market because we are not building one platform – we have instead focused on building a community to support the development of multiple platform solutions for journal workflows. You can pick and choose which one you want, or build something else, reusing as much of the other systems as you can to reduce your development costs (we also spend a lot of time onboarding new folks and supporting them as much as we can).

But it’s not just about improving the game today – supporting the optimisation of workflows is one part of what we are trying to do, the other is to support future innovations.

If you want to know more, feel free to jump into the Coko community channel and chat – https://mattermost.coko.foundation

Come and join the party. We are happy to support you and happy to learn from you…. not-for-profit or commercial we don’t care, build a better journal platform on PubSweet than the rest of us and we’d be happy!  We are in it for the mission – come to talk to us! no preciousness here 🙂

Great Post by Arthur Attwell

Arthur Attwell is a friend and I’ve also been a fan of his work for a very long time (ever since his amazing work with Paperright  https://story.paperight.com/author/arthurattwell/ ). He just posted an awesome post on Paged Media about his new project – Fire and Lion – and their paged media workflow…

Book production with CSS Paged Media at Fire and Lion

PagedMedia Initiative

PagedMedia.org is launching a new community-led development at MIT Press on January 9, 2018. The project will develop a suite of Javascripts to paginate HTML/CSS in the browser, and to apply PagedMedia controls to paginated content for the purposes of exporting print-ready or display- friendly, PDFs from the browser.

This will be an Open Source initiative, appropriately licensed with the MIT license.

The January meeting will be the first meeting of the project and attending will be:

  • Adam Hyde (Coko/PagedMedia.org/Shuttleworth Fellow)
  • Dave Cramer (Hachette/PagedMedia.org/W3C Publishing Work Group)
  • Nellie McKesson (Hederis/W3C PWG)
  • Terry Ehling (MIT Press)
  • Erich van Rijn (University of California Press)
  • Kathi Flectcher (OpenStax/Shuttleworth Fellow)
  • Hugh McGuire (PressBooks/W3C PWG)
  • Arthur Attwell (Fire and Lion/Shuttleworth Fellow)
  • Tzviya Siegman (Wiley/W3C PWG)
  • Travis Rich (pubpub)
  • Fred Chasen (PagedMedia.org/Future Press/W3C PWG)
  • Julie Blanc (PagedMedia.org)
  • Phil Schatz (OpenStax)
  • Julien Taquet (Coko/PagedMedia.org)
  • Ned Zimmerman (PressBooks)
  • Carly Strasser (Coko)
  • Wendell Piez

For further information please contact: adam@coko.foundation

PagedMedia.org is funded by the Shuttleworth Foundation.

Also posted here – https://www.pagedmedia.org/paged-media-open-source-initiative/

Aperta Halted

A part of my personal history is a platform called Aperta which was previously called Tahi. It was a PLoS project and I was hired to design and build it. I quit when the PLoS Board decided to close the repositories, effectively making it a closed project. The repos remained closed, and as far as I know, are still closed today. Ironically after I left, they renamed the project ‘Aperta’ – Italian for ‘open’. A really silly marketing move to reassure everyone that despite what they may have heard, the project was still open…that was perhaps true, albeit (ironically and literally) in name only.

Now, it seems, the platform dev has been halted. Feels good to me. From what I heard (and I didn’t hear much), PLoS didn’t take the project in a good technical direction and generated a significant amount of bad faith and market confusion while trying to develop it behind closed doors.

To quote the new CEO Allison Mudditt (who I respect very much, Coko worked with Alison when she was at UCP):

Part of this initiative will involve changes around the workflow system – Aperta™ – we set out to develop several years ago with the goal to streamline manuscript submission and handling. At the time we began, there was very little available that would create the end-to-end workflow we envisioned as the key to opening research on multiple fronts. But the development process has proved more challenging than expected and as a result, we’ve made the difficult decision to halt development of Aperta. This will enable us to more sharply focus on internal processes that can have more immediate benefit for the communities we serve and the authors who choose to publish with us. The progress made with Aperta will not be wasted effort: we are currently exploring how to best leverage its unique strengths and capabilities to support core PLOS priorities like preprints and innovation in peer review. This will be part of our planning for 2018.

http://blogs.plos.org/plos/2017/12/ceo-letter-to-the-community-mudditt/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+plos%2FBlog+%28Blogs+-+PLOS%29

I hope that PLoS releases the technologies that have been developed for Aperta (there was a lot more than just the submission system) into the open… with both open repositories and open licenses AND, more importantly, an open heart. Collaboration and openness is more to do with how people are than what open license they choose and several of the practices, including asking potential collaborators to sign Non-Disclosure Agreements (NDAs) before getting a demo of the system, were ridiculous and ungenerous.

Having said that, it would be awesome to see all that work released into the open, in open repos with open licenses, and no more blurring of the word ‘open’. Afterall the systems developed that included Tahi were all paid for by researchers. The PLoS Article Processing Charges fuels PLoS and they committed some of this revenue to the development of Tahi. When I was there, no external funding was secured for developing the system. Pedro Mendes made a good point in response to the announcement:

ha

There is some merit to this, but I do applaud PLoS for being adventurous, and if it had worked then the result would have been APCs could be lowered, not just for PLoS, but for any Journal out there reliant on expensive and dysfunctional Manuscript Submission Systems. Allison also notes this in a discussion below the post mentioned above:

…the original idea was that Aperta would allow us to eliminate or speed up the slowest steps between a finished work and its publication in order to reduce the cost of our publishing services

That is true, and it was an admirable goal. However, whatever the journey was between then and now, the project should have always have been out in the open as a public asset. Open for science, open for access, open for source, open for all – and the fact researchers paid for it but it was turned into closed project mid-flight is reprehensible and in the end it worked against PLoS, in particular, it severely weakened PLoS claims to supporting all things open. What a mess.

But, it can’t be ignored that Tahi is about 5 years old now, which is old in software years. A entire generation of technologies that are better suited to solving these problems has arisen in that time. The system is now not much more than a still (just) relevant but outdated approach. That is the risk you take when you develop things behind closed doors. By the time you release it (or don’t in this case), it is out of date. That said, it would still be good to release it, but there are better technologies and approaches out there now.

So I look on with interest to see what will happen next.  I sincerely hope PLoS can return to cutting a path through publishing and exploring and enabling a viable Open Access model that others can follow. With Allison at the helm I am betting things are going to take a much needed turn for the better, not just with this project, but on all counts.

As for me, I learned a lot from designing Aperta (I prefer to call it Tahi). The design process was an introduction to scientific journal publishing for me. I learned a great deal. Tahi gave me, at the time, an unencumbered dream time to imagine something new. It had a lot of interesting innovative approaches and if I had stayed with the project it would have ended up close to where PubSweet is now as I wanted to completely decouple the ‘spaces’ (a concept important to Tahi). It would not have been as good as PubSweet at doing this as a complete ‘decouple’ really has to be imagined from the start, and isn’t as clean if retrofitted. Still, the system would have been a lot more flexible and reusable.

But that wasn’t to be. Don’t get me wrong – I don’t think Tahi was the perfect platform, but it was a pretty good starting point with some significant innovations. At the time, I was looking forward to shaping Tahi with use and to mature it into an excellent system. The good news is, the next platform you design is always better.  I took a lot of what I learned (I have now been involved in instigating around a dozen publishing systems) to my next development, and worked hard to re-conceptualise a new system that avoided some of the mistakes I made with Tahi, and took some of the good parts a whole lot further. That new project is PubSweet and it is looking awesome, and leverages modern technologies and approaches to the max – mainly thanks to the bunch of amazing folks working on it within the Coko team (particularly Jure Triglav) and also now, increasingly, from the collaborators we work with (at this stage mainly eLife, YLD, Hindawi and ThinSlices). Also a huge thanks to the Shuttleworth for backing me, especially because it was at a time (I had just quit PLoS) when it was very much needed. Their backing meant Coko was possible, and consequently, PubSweet and everything else we have done.

Anyways… it was past time PLoS moved on too from Aperta and congratulations to Allison for making the right call, especially given that it would have been a difficult one given the cultural forces at play inside of PLoS.