Spying on the Vegies

I have a security cam at my place in NZ. The best part of it… it has audio so I can listen to the birds in the morning from wherever I am 🙂 Second best part…I can spy on my vegies, make sure they are growing well and don’t need water etc 🙂

20181211114324-654

Standby for vegie close up!

ajaj

All looks good… Basil is a little wilty, but what do expect? I am 15,000 km away after all. I can also spy on Richard who is putting some cool steps on my deck 🙂

20181211114516-376

2018

So… it’s been a bit of a year. I was pretty busy looking back. I think I spent about 9 months on the road. I did some surfing. Bought a fridge. Plus some other stuff… so…. looking back….

The year started with a yet-to-be formed PubSweet community. PubSweet is the underlying ‘open infrastructure’ piece of the puzzle that enables folks to build any kind of publishing workflow on top of it. It is used for books, micropubs, content aggregation, journals… a lot. But at the beginning of this year there was one org building on top of it – Coko. Now, we have 9 publishing organisations building on it and 13 or so platforms in play. All that in one year… can you imagine. It is phenomenal growth. The best thing is the feeling in the community is awesome. As Geoff Builder recently said at a Coko meet “I can’t say enough how amazing it is that you aren’t killing each other”… very true.

This kind of growth and goodwill didn’t happen over night. I’ve been involved in many open source projects where there is no noticeable growth at all over many years. In fact, it was by watching these projects and trying and failing myself a number of times that I learned how to make this work. I had a plan from the start and strategised this growth. There are a few key parts…  First… the proposition is transparent. It’s a no bullshit kinda thing. You can’t buy your way in, you can only be part of this community if you play nice. You must be upfront and work in good faith. If not, then we don’t want you. So it’s transparent, we require transparency, but it is required. If you aren’t transparent then see you later.

Another critical piece was to develop processes for consensus. We have a number of workgroups that have helped with this. We also have an RFC process and 3 meetings in person a year where more difficult stuff can be meted out. It works very well. It is all also, by design. You must intentionally design such stuff and I spent a lot of time working through these scenarios in my own head. It takes time because each community has its own character. You want to make sure you have the right resonance with your strategies and sometimes I need to ponder this stuff a lot, let it sit and then bring it about. Also necessary is to have leadership. I provide a lot of that but I also strategised very explicitly for Jure to be the central pin for the PubSweet community. He is an awesome leader of the PubSweet clan but also it must be noted that this doesn’t ‘just happen’. Jure and I spent a lot of time talking through these things, working out what sort of tone we needed, how to best enable people to feel they could be part of this while curating it so it’s not a free for all. Jure has really risen to the challenge and IMHO stands as a case study of good community leadership.

Andrew Smeall from Hindawi and Paul Shannon from eLife have been early leaders in this community. To have such goodwill and leadership from folks like Andrew and Paul is really amazing. They have been in boots ‘n all from the beginning and never blinked. They are heart n soul and mainstay keepers of the PubSweet community ‘way’. I feel very privileged to work with them.

Also at the beginning of the year, Editoria was alive but no books were being put through. We have since changed that with at least three scholarly publishers using it in production as well as Book Sprints using it (recently used in a World Wild Life Fund Book Sprint). We got there also by careful strategy. Alison McGonagle-O’Connell has been out there presenting, demo-ing, and explaining Editoria to all comers. Alison is a joy to work with and I admire her can-do immensely. She’s a tough cookie and now the wizard of Editoria. Alison has brought people closer to Editoria which peaked this year with a Editoria community event. We got about 35 people there and I facilitated the process (after designing the event loosely based on the PubSweet events). Critical was a newly designed Feature Proposal process. I had to design it so that publishers with no in house dev resources could ‘take ownership’ of the product and also so that publishers, rather than technicians, could write the proposals. We received 36 proposals in 2 weeks from 6 publishing orgs. Amazing. There is now a 3-month roadmap in play because of this.

xpub-collabra and perhaps micropubs will go through similar process transitions next year.

paged.js is also flourishing. I started the project with Shuttleworth funding in Feb and now it is integrated into Editoria and it has already been used for several books. It is also growing quite quickly as a community, some of this is ‘auto growth’ – growth that just occurs with no assist – and some of it is from the efforts of the paged.js crew – Fred Chasen, Julie Blanc and Julien Taquet. Julien in particular is proving to be a very good community leader in this area. They are an amazing crew doing amazing work. I don’t suffer from FOMO (fear of missing out) but I really regretted not being able to go to the paged.js workshops in Paris and Brussels in November. They looked amazing.

Then there is Wax…. the editor is growing fast. We had to rebuild it because the libs we were using were not supported and slow growing. But Christos knuckled down and got it done.. amazing. It is currently a one person endeavor but watch this space as I have plans for community growth around it next year.

XSweet, the XSLT docx-to-HTML converter is also going great guns. V2.0 with math support out in the next weeks. This more or less completes all the things we need form it and the lib will flick into a maintenance mode.

Then there is Workflow Sprints. The process I designed for helping publishers work though their workflow woes. It takes 1 day per org/workflow and has proven to be extremely effective. I’m now training facilitators to do this as it is proving popular and I can’t do them all next year if it comes down to that. Coko is also able to generate revenue from it which is cool.

Then there are design sessions which I still facilitate for various products including Editoria, xpub-collabra, and micropubs. All interesting projects and the design sessions are fun and sooooo effective. Who said publishers couldn’t design their own solutions? Not me…

Also this year I have been peripheral to the Book Sprints team. I gave up direct involvement when I got my Shuttleworth Fellowship. Thankfully Barbara was there to take the helm and has done an amazing job. We have had a couple of meetings this year and it has been awesome. We broke 1m NZ this year for the first time…amazing. Many people still don’t think it’s a real thing 😉

Also from Book Sprints we get many requests from people who love what we do but want ‘not a Book Sprint’…ie they have some other format/media/context etc they want to think about. So this year I have also founded SprintLabs to act as a bucket to put these experiments in… more on this in the new year.

Also this year I finished my Shuttleworth Fellowship having reached the 3 year maximum and became an alum. That was quite a moment. Strange thing is, I feel more a Shuttleworth Fellow now than I ever have 🙂

Needless to say my journey is unconventional. All this stuff is stuff people told me wasn’t possible. All of it. Book in 5 days, impossible! You can’t use browsers to typeset books! Headless modular publishing CMS – impossible! Publishing platforms are an intractable problem! You guys will never be able to build community, it just won’t work!

Yeah yeah. Fuckem.

And there was a lot of other stuff this year too. But honestly, where do I get the time? Where do I get the time to surf? I have no idea. One of the tricks though that I have learned is to trust the people you delegate stuff to. Create an environment for them to succeed and let them go. For the most part I just need to talk things through with them and help keep them and everything on course. They also have to go with my rather counter-intuitive, emergent, way of problem solving and doing things. If they can’t then it doesn’t work out, if they can then we do great things. Which means, of course, lots of travel is needed and talking to people. I am a great believer in remote teams but I am not a believer in remote-ness. If that makes sense. You gotta be close to people so they can trust you and you trust them when you aren’t there. Its for this reason some of our meetings happen on beaches 🙂

It is what it is. It’s been a huge year.

Still, got to make a surfboard this week and 2 Workflow Sprints to go (in the US)… no matter, I’ll be here in no time…

Feet up mate, Koutu
Feet up mate, Koutu

Intractable?

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.

0e7a0485

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.

094a8844

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.