At the STM 2015 meeting in London in early December, I was a member of a panel that discussed the topic of “platform wars”: should publishers buy, build or partner? The panel was moderated by Freddie Quek, previously at Wiley and now a researcher at the Henley Business School. I represented the platform provider perspective; my colleagues on the panel were Christian Kohl — previously with DeGruyter and now working as a consultant — and James Walker — with IOPP, who has its own platform.
Freddie’s questions to the panel were thought-provoking — i.e., off the cuff answers were not advised! In this post and upcoming ones, I’m going to reprise Freddie’s questions, and my answers.
- What is your organisation doing with publishing platforms (current state) and why?
Over two decades we’ve done by my count four major platform revisions – you might even call it replacements – as both the technology industry and the publishing industry have driven opportunity and change. I highlight this because keeping up with these two independently evolving dimensions/drivers is part of the challenge for anyone who owns a platform, or invests in a platform. You can’t “invest and forget”.
Early on we saw that some scholarly publishers who built their own platforms did not treat them as continuous investment responsibilities. They would defer maintenance for 3-5 years, and then need a huge leap (and large funding) to catch up. As a technology company, HighWire would plan for those investments regularly and continuously.
In HighWire’s two most recent platform revisions, we’ve been able to build substantially with industry standards, with open source, and on general purpose platforms that others have built, such as Drupal and business intelligence tools.
Why? It lowers our investment both one-time and ongoing. It sharpens/formalizes the interfaces between layers, and it allows us to recruit and retain developers from a wider pool since we are using standard tools. On the downside, we’ve found that with greater supply of developers, there is also greater demand. So we are often working outside of Silicon Valley to source developers.
- With the rapid change in the business environment (economics, commoditized technology, competitive advantage, availability of vendors and technology solutions etc.), has the considerations for a publishing platform changed/or are different than in the past?
It definitely has changed. To some extent, a modern platform is a framework that allows you to plug in various components. And the “you” in this case might not be just the platform owner, but the customers who use the platform. We have had some experience with customers doing their own platform extensions using the Drupal framework as an integration point. It works, but requires sophisticated developers and coordination to do this “co-development” as we call it. The BMJ site’s front end is largely BMJ’s own code; the back end is HighWire’s. Similarly, some of the components of the eLife site are implemented by eLife, and some by HighWire.
There are others who have platforms on offer that take advantage of the simplification that comes with Open Access assumptions – no ecommerce, no access control, no subscribers, no COUNTER reporting. Open Journal Systems are in this class.
And I think it is only a matter of time before we see this applied in manuscript system platforms: PLOS has tahi, renamed Aperta; and a new group called Coko is working in this area also. There are others.
- If your organisation (or in your role advising publishers) decide what to do today with publishing platforms, will your answer be the same? What criteria will you use?
I can recall two decades ago how some composition companies and SGML consultants were selling scholarly societies on the need to have their own SGML DTD, because their journals were “special”. And it was undoubtedly true to some extent that individual journals were special! But did they need their own dictionary and language to support that?
It reminds me of how three decades ago, when I was managing IT infrastructure for Stanford University, we looked at whether we should buy or build. Stanford had its own payroll system, its own accounting system, its own fundraising system, and its own student records system. Some of these were easy decisions: payroll and accounting were clearly not unique (in fact, you could say that treating these as unique led to specific problems). But the debate on fundraising (which Stanford has unique approaches to, and is very good at) and student systems (to support unique academic programs) took a lot longer to resolve. But today all those functions operate on packaged software.
Today I think the same happens in hosting and (to a much lesser extent) manuscript management platforms. For the most part, journals aren’t unique in their core hosting requirements, but individual journals and publishers are innovators in specific areas – e.g., linking data, visualizing data, supporting conversation, alerting — and HighWire’s approach is to enable these leaders to experiment and innovate on top of the core hosting platform.
For manuscript management, there is a lot more to be considered about experimentation. There is a lot going on now in this area (more so than in hosting, perhaps), as journals focus more on the author and reviewer experience. HighWire recognized this when we built our BenchPress manuscript management system: it supports fully customized workflows by journal.
The criteria I think would be to
- decide if you must have control to fulfill your business or mission imperatives (perhaps differentiation, perhaps speed of innovation);
- at what level that control has to be at;
- whether an existing platform can support that level of control;
- whether you can afford the ongoing maintenance;
- and whether you have the technology management to accomplish this in or out of house.
Many societies have to make similar decisions when they are considering whether to self publish, or to contract for publishing services. Societies know they require editorial independence. But beyond the decision on what papers to accept and reject (and what editors to hire), what must they have? And if they feel they need a customized hosted journal site, or manuscript management system, which contract publishers can support that?
More of the panel’s questions will be covered in Parts 2 and 3:
- More generally, should publishers still be building platforms?
- Isn’t platform just a commodity these days?
- Is the “Feature race” still on or is it well and truly over?
- Is it essential for competitive advantage?
- Should publishers not collaborate more or partner with others like FaceBook/Google that have better nous, technology, platform?
- Should publishers not focused more on its core competence around creating and driving discoverability and usage of content?
- Assuming yes to previous question, what kinds of problems have you either solved, or identified that need to be solved by publishers?
- Why are publishers not solving common problems together for industry and their customers/users? E.g. access to content (example I have is in the last 3 years, from working with other publishers and vendors, ship a lot of content/data to each other in the most inefficient way) – is there a better way?
- What suggestions you have on how publishers can solve these common problems?
- Are there other more important things publishers should do/focus on?
- Looking into the next 10-20 years, what can you see for the future of publishing, publishing platforms, and content? How will the next generation platform or content look like?
- Plus a “bonus” question that Freddie tossed at the panel just as we ran out of time!
Latest news and blog articles
HighWire partners with Rievent to embed CME learning content within journal articles