Scholarly publishing loves intractable problems. Building publishing platforms is often argued to be such a thing.

I think there’s a reasonable amount of skepticism here toward any claims to have solved what has been, for decades, an intractable set of problems. We’ve watched Wiley pour (estimated) tens of millions of dollars into building a platform, only to give up and purchase Atypon. We’ve watched Elsevier pour similar (estimated) amounts of money into building Evise, only to give up and purchase Aries. We’ve watched PLOS pour similar (estimated) amounts of money into building Aperta, only to give up and sign on with Aries.

David is talking to a belief in the scholarly publishing sector that publishing workflow platforms are an intractable problem. And yet, so the belief goes, Aries and others, have apparently ‘solved’ this problem.

Well, intractable problems aren’t ones that have been previously solved. So whats going on with this argument?

I’m guessing there is a lot of unspoken stuff embedded in this position. For example, I think that some take the ‘intractable problem’ line because they are feeling threatened. Pure and simple. Threatened by the current wave of interest and optimism around open source solutions in this sector. You can see this defensiveness at play in some articles and comments on Scholarly Kitchen. It’s not too hard to spot.

But all that aside, why not just take the argument on face value. What of this apparent intractableness? Let start by admitting, Aries and other systems, have not ‘solved’ publishing workflow. None of the publishers I know that use these systems celebrate them. So maybe it is true…publishing platforms are trying to solve an intractable set of problems…since no one has solved it yet…hoho…

Well, I’d say the reality is this:

  1. Existing platforms are trying to solve complex publishing workflow problems
  2. publishing workflow is not complex

Sum the two up and its easy to see that existing publishing platforms are trying to solve the wrong problems. They are trying to solve a complex set of problems when the actual problem is actually pretty simple. This kind of defective problem-solution context has too nasty outcomes:

  1. bad solutions – when you make a problem unnecessarily complex you design an unnecessarily complex solution. An unnecessarily complex solution is another way of saying a bad solution.
  2. a broken solution culture – bad solutions confuse the people you are trying to help. If the solution becomes mainstream it results, in turn, in a dysfunctional, and self perpetuating, circle of dependency between ‘vendor’ and ‘user’ – where the ‘unduly complex problem and resulting solution’ become the normative conceptualization of ‘how things are’.. Solve a problem badly and people will want you to solve it badly for a long time. That’s culture for you.

So, the big problem really is… what is the problem we are trying solve?

Workflow, in a word. Workflow is what we are trying to solve. How to get a paper from submission to publication. All the processes that occur in between those two points is what I refer to as workflow. What needs to be done, by who, and when. Thats the crux of it – this is what workflow is, that is what publishing platforms are trying to solve.

Perhaps it’s best to start there – to understand the workflow problem so we can design the best solution for it.

You can already see that when we take this view on the problem that designing good publishing platforms already feels a little more in reach. The problem space is not solved by some kind of complex magic performed by software developers. The problem is solved by first having a good understanding of workflow. Who does what and when. That’s it. Not too tricky to get your head around.

So how do we understand workflow? Well despite my philosophy degree, I’m not always a theorist, I’m also a pragmatist. The best way to understand what a publishing workflow is, is not to come up with some handy abstractions (although I’ve also done this), it is to ask a publisher.

I do this all the time. I travel to publishers and get all the folks involved in the publishing workflow in to a room and then ask them to go through it step by step.


When all these folks are in the same room, I simply ask the group to step me through the workflow process starting at step one – author logs in to the submission system – right through to publication. I ask each step to be described in the format  – who does what. The ‘when’ is looked after by the order of steps.

There are usually a few circular steps, revisions and so forth, but it can all be captured in this simple process. It takes maybe 1.5 hours or so. At the end we have a complete picture of their workflow.

Now… if you were to design a system to capture the workflow as it is described at this point you would have a bad solution. Why? Because of this broken solutions culture I spoke about above. Current publishing platforms solve the problems badly and so we currently have bad workflows.

To avoid making overly complex, bad, solutions we need to first look at better understanding the problem. Can we look at a current workflow and reduce its complexity without losing anything? Thats the first step.

How do we do this? Well… the pragmatist enters the room again…. With the same group of people we can simply ask them to walk through an ideal workflow. I do the same thing… ask them to start with step one – author logs in to a submission system – and then walk through an ideal process step by step.


What happens? Well, you would be surprised. In a few hours the same group has radically simplified their workflow without losing anything. It is, in effect, a lovely kind of lossless compression (I used to do a lot of streaming, and lossless compression is the holy grail!).

Recently, for example, I did this process with a publisher and reduced the steps from 41 to about 9. This is not uncommon.

So… as to intractable problems… imagine designing a system to encapsulate 41 steps. Now imagine designing one to solve 9.

Its not difficult to design a system for 9 steps. In fact, it’s pretty easy.

This is at the heart of the ‘intractable problem’ blah blah. Its just blah blah motivated by a lot of self interest, woolly thinking and a broken solutions culture. We have become trapped by these ideas as a sector. At the same time, publishing is itching to find a better way… however, we have (as David says) looked to see the solution as being software. The solution is not software, the solution is that we need to understand workflow better. If we can do that we can make better solutions.

PubSweet meet #5

Friday I facilitated a PubSweet meeting at the lovely new eLife offices in Cambridge, UK. We do this every 4 months to work through shared technical issues. The community is going really well, in this meeting we had 3 new projects represented. These are all projects building on top of PubSweet, which makes a total of 13 publishing platforms (that we know of). Incredible. Even more incredible was that we only started the PubSweet community a year ago and now 9 orgs in total are building on PubSweet… amazing….

Anyways… it was a great day. Possibly too short. We’ll do a 2 dayer (as is usual) next time (March-ish).


Another day, another dollar? pound? euro? I don’t know what…

Another day in London. I Kicked off an Update Sprint for the PubSweet book at the Hindawi offices, met with 3 service providers curious about Coko, and then an evening facilitating a micropublications design session with the folks

Daniela from Micropublications also kindly sent me pics (at the bottom) she took so my mama could see that I actually do work for a living…

dsc02692 dsc02693 dsc02696 dsc02699 dsc02701 dsc02707 dsc02708 dsc02713 dsc02715 dsc02719

What’s in a Name?

What’s in a name? I say a lot! … actually, I am plagiarizing here… These are lyrics from a reggae band I used to manage back in the day. D-riser. I managed them for about 5 minutes, but in that 5 minutes I did manage to get enough $ for them to release their first album. They were a cool band and I didn’t deserve to manage them. They were far too good.

D-riser sang a lot about Maori rights and disenfranchisement in Aotearoa, otherwise known as New Zealand. Infact, they sang exactly about this issue – the naming of things. Naming is, after all, inherently connected to identity. So why use a European name for a place that was first found and named by Maori? The Europeans knew why, it’s part of the colonialist playbook.

So… zoom forward a few hundred years, and I am asking myself my own questions about identity. Specifically, what is in the name ‘Book Sprint’?

Well, what is a Book Sprint? On a raw level I guess it represents a methodology I created. It took many years of hard work, sleeping on sofas and being literally homeless. Not in the sleep-on-the-streets sense, but in the traveling nomad sense. During this period I was trying to work out how to make this Book Sprint idea work when no one could tell me how and in fact I don’t think there was really anyone that thought it was possible. Make a book in a week? Ridiculous! So, needless to say, there was no revenue from this, as yet, non-thing. I had to prove its value the hard way. So it was, and so it is. It took a long time and now I am very proud of this product of my own stubborness.

Now Book Sprints is a company. It has an amazing team that does amazing work. It has an amazing CEO – Barbara. How we managed to find each other as kindred work spirits I never cease to be thankful for. But that’s also true for all the team. Amazing people.

Book Sprints does amazing work. We produce books in 3-5 days. From nothing. We do it for all comers – activists, academics, corporates, NGOS … the works. We never fail. Never. Astonishing really. If you have never facilitated a Book Sprint, you would not know how hard it is. We face challenges in every event from extremely difficult personalities, to groups that want a book on something they know nothing about. But we facilitate through it every time. 100% success.

So, what’s the connection between a reggae band and Book Sprints… you might well ask. Well, its about the naming of things. Names are important. The name Book Sprints is important, it is the thing that identifies 10 years of working out how to get a group of people from zero to a great book in 3-5 days. It represents 10 years of championing collaboration in the face of enormous skepticism and proving that people working together make better books than those that don’t. Of the power of collaboration and a very special style of facilitation. It represents us. How we are now an expert team doing very specialised work. Book Sprints represents us, our journey and what we have achieved.

So, it is sometimes difficult when I see others, who most often already know about us, use the name Book Sprints to represent themselves. Most often these activities result in failure. It is frustrating. I have talked to people before that have told me they have done a Book Sprint and that it was a failure. Book Sprints suck, its a terrible idea, I will never do it again. Except, I have never met these people before. We did not work with them. They failed because they worked with people that had not had the same journey as us and yet claimed they knew as much as us, were as good at it as us.

We have also had people come talk to us representing themselves as interested in doing a Book Sprint with us. We share a lot of information with them generously. And in some circumstances they have then gone out there and tried to do what we do under the name Book Sprint. In one case they copied our logo, our text on the website, and made a brochure which looks all the world like us, except not us.

The same has also happened with some academics that write about Book Sprints. We have talked to and generously shared a lot of information with them. They then write about Book Sprints as if they invented the idea with no reference to us. That is kinda shameful for an academic.

I’ve even had someone misrepresent themselves as a journalist to interview me, only to discover they were not a journalist. They were just trying to find out as much as possible about how we do what we do. Why bother? I mean, they could have just asked.

It’s been hard to see that. It’s hard to generously share information in good faith when it is then used in bad faith. It sucks.

So, I have come to agree, once again, with D-riser that names are important. The name Book Sprints, as it represents us, is important. It presents us and the work we do. If you talk to us, Book Sprints, you know we can do what we say we can do because we have done it 150 times before without failure. We do not suck. We are extremely proud of what we can do. Book Sprints is us, it is our identity.

So I have decided to trademark the name Book Sprints. I’m not a fan of any sort of Intellectual Property. It also sucks. But trademarks exist, in part, to help people like us maintain a strong identity. I am ok with that.

Our Trademark was approved a few weeks ago