Home / General Kitchen / All Things Coko: A Step Towards a True Shared Infrastructure for Scholarly Communication?

All Things Coko: A Step Towards a True Shared Infrastructure for Scholarly Communication?

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 Micropublication.org; 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 Micropublication.org 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.




Source link

If You Like This Post Please Share This......

About josan

Leave a Reply

Your email address will not be published. Required fields are marked *

*