The first week of December is an important week in the scholarly publishing calendar in the UK. As well as STM Week (#STMWeek), which includes a series of linked all-day seminars along with a committee and working group meetings, there are multiple community, vendor and industry events. It’s a good opportunity to look back on the year and take stock.

Collaboration between otherwise fierce competitors

Cooperation and collaboration was high on the agenda during #STMWeek. The opening keynote of the Standards and Tools seminar (#STMStandTools), given by Bill Kasdorf (@BillKasdorf) of Kasdorf and Associates set the tone.

In his talk, Bill discussed a number of joint ventures between publishers and other stakeholders, particularly around technology solutions. Starting with the Joint Roadmap for Open Scholarly Tools (JROST), he went on to cite Metadata 2020, Scholix, OpenAire, Blockchain for Peer Review, RA21, Manuscript Exchange Common Approach (MECA) and the Collaborative Knowledge Foundation (Coko) among other ventures as examples “collaboration between otherwise fierce competitors”.

Man harvesting a cocoa bean
Harvesting a cocoa bean is only the start.

We could debate the relative merits of these separate initiatives and many are doing so, but the idea of a shared infrastructure is a compelling one. After all, so much of what publishers do as baseline services are extremely similar. The Oldenburgian principles of registration, dissemination, certification and archiving that underpin the academic record rely on a series of workflow tools and processes like peer-review, content management, and typesetting that will increasingly be seen as the price of entry to the market, and not the place to differentiate. This is doubly true in a future where content may become largely free.

The day after the Standards and Tools Day, I headed over to the #AllThingsCoko meeting. Perhaps the strongest example of an attempt to build shared infrastructure, Coko are building an open source collection of modular publishing tools that can be bolted together to form a loosely coupled architecture. What’s more, it’s open source so in principle, anybody can use it. The early adopters of the approach include Hindawi, eLife, UC Press, Europe PMC, and; a research community pioneering micropublication.

With each new development partner contributing to the codebase, the barrier to entry for new partners should come down. Having said that, there is an acknowledged problem that for many publishers, who may not have sufficient technical expertise, implementing an open source solution isn’t exactly easy. There is still technical work to do to customize, add specific user experience features, and integrate into existing technical systems. At the meeting, Kristen Ratan, Co-founder of Coko, spoke about the need to add a service layer over the top of the open source base, to enable publishers to innovate and differentiate. In other words, to be the RedHat to Coko’s Linux, or in less technical terms, the UPS or FedEX to the public road network.

I spoke with Kristen while writing this piece, and she put it like this:

“The key to changing the platform landscape is to create a many-to-many relationship between technologies and service providers so that new service offerings can be spun up quickly to meet evolving needs… We need to break the vendor lock-in that is driving up costs and inhibiting innovation.”

Indeed, at All things Coko there were several were several well-known publishing service providers taking an interest in providing that service layer, so it’s worth keep an eye out for partnership announcements over the coming months.

A new technology strategy for scholarly publishing?

I’m sure that many readers will stop at this point and wonder whether anything is truly different here. Aren’t there already companies that provide platforms to publishers that don’t have the capability or resources to build their own? Isn’t this what Highwire, Atypon, Silverchair, and others have been doing for years? Don’t they also have user meetings and drive innovation based on the business problems that publishers tell them about?

The use of open source does make a difference. As Adam Hyde points out in his guest post on the Kitchen from September, by making the underlying code base open and therefore free to experiment and innovate with, a community of developers and service companies can be built around the technology. By separating the infrastructure from the service layers, it’s possible to lower the barriers to entry and reduce friction in competition among service providers. While the same thing can be done with proprietary technology, incentives around the lifetime value of customers tends to drive towards vertical integration, which can limit choice and raise costs.

Coko aren’t the first to use open source technology in scholarly publishing, Open Journal Systems and Alfresco are both examples of successful open source publishing solutions, but those technologies sit in a specific place in the publishing value chain.

What Coko are also doing that’s interesting is using highly modular architecture. The old choice was to create either small disparate systems that don’t talk to each other, or one big system that was intended to do everything for everybody but did nothing well. With modern architecture and development techniques, like APIs and microservices, that has become a false dichotomy. Modern techniques allow the creation of individual functional components with well-defined points of integration that can then be bolted together as needed. This approach can be extended to the feature level, as they have done at Coko, so that individual implementations can be built quickly from pre-written libraries. The process is sometimes compared to building with Lego. When done well, the approach is highly flexible, as well as being far more maintainable, because changes to one component or feature don’t affect others in unpredictable ways.

So can Coko create that network of service providers, so that their open source technology becomes widely adopted? That’s a good question. In part, it’ll depend on whether their modular architectural approach will bring enough flexibility and be easy enough to build on to meet the needs of a diverse range of publishers. The work with is promising, as it shows that Coko can be used for novel publication forms, but what about older publishers with legacy technology or data issues? How can Coko help publishers struggling with GDPR issues or compliance with Plan S?

Whether we’re talking about Crossref, MECA, Coko, or Scholix, the technology approach is important, but is perhaps more predictable than the human factor. After talking about collaboration for many years, perhaps the industry is finally ready to really embrace it and be less proprietary about the things that we all do in pretty much the same way. Time will tell if any of the current endeavors, Coko included, will be just one more interesting initiative, or the movement that changes the way we think about our infrastructure.

Phill Jones

Phill Jones

Phill Jones is a co-founder of MoreBrains Consulting Cooperative. MoreBrains works in open science, research infrastructure and publishing. As part of the MoreBrains team, Phill supports a diverse range of clients from funders to communities of practice, on a broad range of strategic and operational challenges. He's worked in a variety of senior and governance roles in editorial, outreach, scientometrics, product and technology at such places as JoVE, Digital Science, and Emerald. In a former life, he was a cross-disciplinary research scientist at the UK Atomic Energy Authority and Harvard Medical School.


26 Thoughts on "All Things Coko: A Step Towards a True Shared Infrastructure for Scholarly Communication?"

Coko is open source but not in a useful way. You can see the elife version or the hindawi version of their journal manager, but there’s no base version that I can deploy to my server.

What these developers need to understand is that 95% of academic fields that need open source journal manager and publishing support are not computer science. Philosophers don’t necessarily know javascript. Psychologists didn’t get taught PHP. Open Journal Systems has the advantage here, insofar as its deployment is about as complicated as WordPress. But yes, it does have a particular “place in the value chain”, the PKP/OJS forums are like a tech support center for predatory publishers.

So to me, Coko is just another provider of effectively closed solutions. It’s a bit like how Android is open source, but because the actual open source component doesn’t work without all of closed commercial components, it’s not really free software.

As noted in the post, software alone is not enough. Unless you’re a big enough publisher that you can hire your own team of internal developers to customize, install, maintain, and update the software, you’re right — it’s no different than a closed commercial component. The real breakthrough would be service companies built around using the software, “the RedHat to Coko’s Linux, or in less technical terms, the UPS or FedEX to the public road network.”

Sure, services are very helpful, but an actually usable open software product is a great place to start. Take Between the Species for example, its Wikipedia page describes how back in the 1980s the editors used to manually type pages and cut them out with scissors. Even with its humble origins, it’s a legitimate scholarly publication for animal rights people (and is online now).

Coko is more like RedHat than Linux. Linux has both free and proprietary distributions (even Android is linux-based). I can get Ubuntu or CentOS for free. Or I can choose RedHat. But what I don’t need to do, is reverse-engineer Linux before I can install it.

If Coko were really a public road, it would be more like WordPress. Anyone can download and install WordPress. The open source version is free and functional. And if you want a hosted solution you can buy that. If you want more customization and support you can buy that too. [Disclosure: I don’t have any stake in wordpress, I don’t even use it.]

I think there’s limited benefit to beating up this analogy too much, but if I understand your point of view correctly, you don’t like the fact that it would require a level of technical skill to make use of Coko currently.

I think you might be asking for a little bit much a little bit soon. Bear in mind that Ubuntu and CentOs are both distributions of Linux. Somebody had to take the kernel, bundle it with a shell and package management and distribute it. Some organizations are community-led projects that do that for free, others are commercial companies that charge money for it.

The point of my post is that Coko is currently that foundational layer, the equivalent of that Linux kernel. Expecting it to be a turnkey solution for a non-technical user is, in my opinion, asking too much at this stage. The ecosystem needs time and encouragement to mature.

Hi Phill – You’re right, I was asking too much too soon. I was expecting something equivalent to OJS.

What bugged me about Coko is that that they appeared to be releasing their code to maximize the amount of work I would need to do before I could start using it. By releasing only client-specific customizations they ensured that anyone who wanted to use their software would have to jump through hoops, hopefully buying a service package to go with it. But I now think that it probably just appears this way because they are still working on their software and it’s not yet ready for production.

I also wonder – if a service provider ecosystem didn’t appear for OJS, why would it appear for Coko? OJS is also liberally licensed using GPL2 – you can sell a customized and enhanced version of OJS. But I can’t think of any organizations that are selling a customized OJS service. Perhaps this is a licensing issue, but then the MIT license on Coko’s software would make it more vulnerable to being a “reinvention of the proprietary model” because there’s no obligation for Coko service providers to make their customized versions open source. Publishers concerned about vendor lock-in would be safest going with the GPL2-licensed OJS because it protects them from proprietary customizations.

Journal Starter, that’s the question I ask in the penultimate paragraph of my post.

“So can Coko create that network of service providers, so that their open source technology becomes widely adopted?

I don’t know if OJS did anything to try to promote the use of its open-source technology by service providers or not. Are service providers needed for OJS? The building of that community of providers seems central to Coko’s strategy, as they’re trying to create shared infratsrtucre, not just free software.

Thanks, that’s a very important perspective. I can see as a small publisher without your own technology function, you might look at a Github repository and wonder ‘what on earth am I going to do with that?’ You’re right that you need somebody to help you deploy, customize, configure and maintain it. Very often, the companies that provide those services do add proprietary layers over the top of the open source codebase, which can create its own version of vendor lock-in.

That said, the creation of that open source base reduces the barriers to entry for service providers, which can create much more competition.

Your comparison to Android is a good one here. By creating that deep open source codebase, Android fostered innovation among smartphone manufacturers and enabled innovation that challenged Apple and drove the industry forward and created entry-level options for consumers. It’s also worth noting that you can get free distributions of Android, as well as Linux operating systems.

The question is, how might something similar work for publishers. As David mentions, the key is the network of service providers that compete effectively at various levels and price points in the industry. Perhaps, there’s even a way to create a ‘free’ distribution through some kind of co-operative, grant or endowment mechanism. Since the codebase is free, it can be used by any type of organization, the business model is up to the service provider themselves.

Journal Starter, I would be happy to chat as it seems you seem to be confused about what open source is. Which is ok, part of what we do in Coko is help educate folks about open source. So I’ll try and respond to your points, however you are using confusing language and conflating ideas so it is rather difficult to follow the argument but I’ll give it a go…

First you say there is no ‘base version’ (by that I guess you mean ‘install-able’ versions) you can deploy to your server, which implies you have technical skills. If so there are detailed instructions online on how to install ‘base versions’.

Then you say you that Journals need support. We totally agree. Which is why 3 service providers were at the event described above (as Phill mentions in the article). When these folks or others (we are in many of these conversations) come online you’ll have all the service you want, no installation or tech skills needed.

Lastly, there are no closed source components required to run any of the products coming out of the Coko community. So I have no idea what you mean when you say “open source component doesn’t work without all of closed commercial components,”.

I think, in general, you are confusing commercial services with licenses. To help disambiguate this you may wish to read the article Phill refers to that I wrote for SK to help understand the difference –

As a side note, sorry you chose to remain anonymous. However, I’d be happy to chat and go through what a open source license is and the difference between this and service provision. should you wish to email me directly. Also – David, you are also making these same conflations, Open source + service provision does not equal ‘closed commercial component’.

Sorry if I wasn’t clear. The point I was making was that open source code without any services or support is just as unusable for most publishers (other than the biggest houses) than the proprietary solutions that they can’t afford. Open source code is just the start of things (and the right start), but for many who don’t have the means to be their own development and support service, more is needed, and the big benefits won’t be seen until those services are available, built around open source tools.

Hi Adam – the closed components was a reference to Android – which doesn’t work very well without commercial involvement from Google.

I understand that Coko is open source. Your code is open. It’s there on Github and linked from your webpage. I can see it. You apply an MIT license so I can reuse it. But by only providing journal/publisher-specific implementations of your platform, you’ve managed to set the technical skills bar high enough that people (like myself) who don’t have a lot of web development training or experience can use it.

There’s no ‘xpub’ repository. There’s only xpub-elifesciences, xpub-hindawi, xpub-collabra, xpub-epmc. So your software is open but because it’s not installable without client-specific customizations, I can’t do anything with it.

Journals have different needs. Today, I just want software I can use. Later, I might need more services and customizations. If you want to capture my business later, you’ve missed out because I couldn’t install your software today.

First of all, the Android comparison is absurd. There is *no proprietary components* necessary to run Coko products.

If you wish to argue that you need services to run Coko products, that is quite a different argument. Make that argument and find a better analogy.

As for services, as stated there are hosting services in the wings. You won’t have to wait much longer and you can also have this. You all seemed to be saying ‘you need services’ and we reply ‘yes we know’. We have made that point several times and outlined what we are doing about it. Instead the reply from each of you is ‘ah, services is like android’. Which is where you conflate proprietary components with services. As a result the arguments you are making are hopelessly confused and circular as you refuse to understand that open source + service provision (which is what you seem to be asking for) is something we agree is needed AND it is not the same thing as ‘proprietary components’. Please learn to disambiguate these issues.

Phil, your argument in particular is really confused. What do you mean by ‘create some kind of free distribution’. It is all free. They are all usable platforms. Take whichever one you like.

As for not being able to install the software Journal Starter, please jump into the Coko channel. We help people with this every day. We are more than happy to help you.

I’m not going to reply any more, this is getting circular. I will however make the offer to do a workshop on Open Source for SK chefs and its community. It seems it is necessary.

Wow. Journal Starter never said Coko had proprietary components – they said Android had proprietary components on top of its open source base. They even acknowledged Coko released open source MIT-licensed code. But they made the analogy because they could only find repositories with customized versions of xpub. Because they would need to undo the customizations before they could use the software, it meant that xpub was unusable-to-them (presumably for lack of resources). If this was incorrect, all you would have needed to do was post the URL for the uncustomized xpub repository instead accusing everyone of not understanding open source.

If this kind of condescending reply is how Coko responds to people having difficulty with its software, then I guess that’s why Open Journal Systems runs something like 10,000 journals and Coko’s software doesn’t.

Hi Adam,

Based on your comment above, I get the impression that you feel somewhat attacked by the discussion here. I’m very sorry if that’s the way that it appears to you. The comments that I and David have made have both been supportive of Coko’s approach.

I hope that you haven’t taken my sympathetic approach to discussing Journal Starters concerns as support for their position, I don’t agree with their position but I do respect that they have a viewpoint.

My take on the whole Android comparison is that it’s a reaction to the fact that Coko is not a turnkey platform solution. Personally, I think that expecting it to be is asking a bit much, as the ecosystem is still evolving. As you say, we all acknowledge the need for some sort of layer on top of the modular infrastructure that Coko has created. Of the two chefs that have posted in this comment thread, neither have criticized Coko for that. That’s just where things stand at the minute, and that’s fine.

I know that all of Coko’s offerings are free and open source and that it’s possible for people to deploy them themselves, apologies if that was unclear.

In my response to Journal Starter, I floated an idea of a free distribution. What I mean by that, is a sort of turnkey or near-turnkey solution. I recently saw another innovative platform solution (I won’t name them here because I’m unsure how confidential that work still is). Their codebase is not open source, but what they have an interesting approach to reduce the barrier to entry for configuring the workflow. That is, it’s intended to require no coding skills to customize. There’s no need to go down this particular rabbit hole as it’s just a thought, but I was just wondering whether there was a place in the market for a free or nearly free product, based on Coko, that could be used by small society publishers and library publishers with minimal technical capacity and minimal funds for service provision.

My honest opinion is that the approach that Coko is taking to its architecture is solid, it’s the correct first step, but in many respects, the technology part is going to be the easy bit.

Most publishers do not operate a developer rich environment and often have trouble even implementing standard packages for basic services like subscription management. Without the basic developer skills or having on board a senior developer any system open source or not can be difficult to implement. Changing platforms or implementing manuscript tracking systems is challenging even to some of the large publishers. Software development or implementation is not for the faint of heart.
Publishers have a very good set of skills, but software development is not one of them.

That’s right Dan, and that’s the challenge that we’re essentially all wrestling with here.

The model that’s being suggested is that Coko have created an open source codebase that service providers can then use to provide a platform and support services around it. That means that each new provider in the space doesn’t have to reinvent the wheel. That reduces barriers to entry, creates a more competitive marketplace and thereby reduces costs while driving innovation. In principle, because so much of this new ecosystem would be shared technology, it’s possible that platform transitions from one provider to another might be easier, again reducing friction and increasing competition among vendors.

Just want to chime in to say a couple of things that may be useful to some. 🙂

First, anyone who just wants to check out xPub – no gitlab, no installing anything, just give us a shout. I can walk you through. I’d be delighted to! From there, if you want to ‘bang’ on it a bit, give it a go, you can ask us for a beta hosted version. Happy to supply that and training/ follow up to. This is how to start getting involved with the journals community. You can also talk to eLife, Hindawi, EBI..

Next, is just a reminder that excellent service providers are preparing to enter the space, giving real-world options to journals/ publishers without technical expertise, deep dev resource or deep pockets. Publishers decide which service provider they like or trust the most (maybe choose one with whom they already work with in other capacities), and which offering best suits their workflows. Worried this sounds like a reinvention of the proprietary model? Maybe so, but if you can always leave with your data and your code because this is baked in to the service provider certification with Coko, then it’s actually much more control for the publisher, who inevitably will have more choices once the ‘pain of switching’ is no longer a ‘thing.’

If you want to unpack any of this more, and together, let’s set up time to chat.

It would be good for both Adam and Alison to explicitly disclose their roles with CoKo and Editoria/CoKo respectively when first chiming in.

If you have vanilla xPub code and it’s not public, is that really open source?

That link takes me to the version of xPub for Collabra.

References to the collabra journal and its website are built into the code.

Yes, that’s the repository I referred to as xpub-collabra earlier. The URL doesn’t say Collabra, but the first line of the description says it’s for Collabra.

If you follow the link from xpub-collabra to the journal, it looks very much like an Ubiquity Press journal – you can tell from the layout, color scheme, font and the Ubiquity Partner Network logo. Ubiquity Press uses Open Journal Systems for its back-end. You wouldn’t know it if you publish with them because it’s very heavily customized, but they have an agreement with PKP to contribute back to the OJS code base.

I guess that means xPub isn’t ready for deployment yet.

Excellent point! As you point out accurately, Adam and I both work for Coko. 🙂 Sorry for forgetting to disclose this very important information. And many thanks for reminding!

Are there also people who make themselves known and have arguments against the Coko approach? I’d be interested in a balanced view, knowing where people are coming from, understanding pros and cons. By the way, I attended the meeting in London and was inspired by the open and constructive dialogue.

> Are there also people who make themselves known and have arguments against the Coko approach?

I work as a developer for the Public Knowledge Project which builds OJS. I do not have arguments against Coko’s approach. From what I know, they are building a good technical foundation and we collaborate with them on critical infrastructure projects like Texture, which will be a huge step forward for the production of JATS-XML for our community. Shared infrastructure is a good thing. Many parallel, overlapping efforts are also a good thing.

But I will try to put these architectural questions about modularity into perspective for non-technical readers. Modularity in software is all about how you break up a complex machine into its component parts. All of the open-source platforms I am familiar with (OJS, Coko’s Pubsweet, Janeway) pursue modularity in different ways.

Successful modularity in software is usually determined by how easy it is to tailor the software for a particular business case, how reliably the software handles all these different configurations, and how much (or little) maintenance work is required to keep it all going.

So how can a non-technical observer evaluate a platform’s modularity? You can’t, not really, not unless you have the resources to pay a technical advocate to do a thorough review for your particular business case.

That’s why, for all but the largest publishers, a services layer is so important. Yes, you can pull OJS off-the-shelf and get it running almost as easily as WordPress. But, like WordPress, there’s a lot more to running a successful enterprise.

Take the Scholarly Kitchen for example. It runs on WordPress. But I can see that it is hosted by WPEngine, a managed hosting service dedicated to the platform. That means they’re paying a premium for special hosting that knows how to keep a WordPress instance up and running smoothly. Their theme is a custom theme built by a service provider, Alfresco Software, who were likely also responsible for testing, acquiring and developing all of the modular components the site uses. (WordPress calls them plugins, and I can identify five just by looking at the source code of this page.) Most of these plugins help improve Scholarly Kitchen’s ranking in search results, prompt users to share content on social media, and improve the appearance when they are shared in social media. I’d bet good money that Scholarly Kitchen is also running one or more plugins that manage their publishing workflow, since WordPress doesn’t do much of this out-of-the-box. If a technical fault occurs in one of the modules, they’ll need a service provider to work that out.

(I haven’t hacked anything. All of this information is publicly available to anyone who knows where to look.)

Using a shared, modular infrastructure like WordPress meant that the Scholarly Kitchen only had to pay for the work it took to adapt the system to their needs. But it doesn’t mean it was free, and they still have to pay to keep it running.

Encapsulating those costs is what a good service provider will do. They should be able to tell you just how much you can tailor a platform based on your budget, whether that’s $1,000, $10,000 or $100,000.

But a services layer doesn’t need to restrict itself to a commercial ecosystem. Coko is building its platform through close partnerships with particular publishers, a model that the Janeway platform is also pursuing with the Open Library of Humanities. Likewise, many of OJS’s most successful service providers are collaboratively-funded national service providers (SciELO, Érudit,,, etc) who are in turn closely involved in the ongoing development of the platform.

All this is to say that a services layer — commercial or otherwise — is not a gatekeeper to shared, modular, open infrastructure, but instead is a kind of collective labour, bringing to an open-source project financial and technical resources that reinforce the right incentives: namely, to keep a platform modular and adaptable enough that it can continue serving a diverse set of users.

But none of us are on the brink of solving scholarly publishing, and you lot aren’t going to agree on what that should look like any time soon. There’s no one best platform, only one that suits your needs (or doesn’t) in the here and now. What makes open modularity exciting is that it lets us keep experimenting. To do that, though, is going to require technical and financial resources that advocate for your particular vision.

Despite our difference with PKP business practices, the key advantage that OJS has compare with any other open source JMS out there is the collaboration.With over 10,000 users worldwide and solid growth rate, OJS has established itself unequivocally to be the number one brand name for open source JMS. Coko, Janeway, and no other competitor would be able to surpass OJS in the long run without massive expenditure.

Comments are closed.