Onto Journals…

We (at Coko) have been working with Collabra Psychology to develop a Manuscript Submission System with them. The cool thing is, we can re-use a lot of work that we put into Editoria since we built PubSweet with the notion of highly reusable components (on the frontend and backend)…

I find it so satisfying to see our ideas and hard work put into building systems with the ‘right level of abstraction’ paying off. We are pretty much putting together a cluster of tech that can be re-assembled to meet a huge variety of publishing workflows very quickly…

The platform is called ‘xpub’ for now and it’s looking pretty good. We were able to assemble a basic dashboard, submission page, and editor plus link it up to INK for MS Word -> HTML conversion in a matter of days. All still in early days but looking great.

Login page for our first Journal platform.
Login page for our first Journal platform.

You knew the day was coming … 🙂

The Glamour, the glamour

4am at Baltimore airport…yawn… I’ve never seen an airport so busy at this time of the morning…While in Baltimore, Kristen (co-Founder, Coko) and I had a really good meeting with the nice folks at Project MUSE. We are helping them with EPUB conversions using INK. I think it will lead to a community meeting soon as we are getting quite a bit of interest around it.

Now back to San Francisco. Hopefully I can snooze a little on the plane. Meet with UCP when back later in the morning to work through the list of items for development on Editoria. I’m really looking forward to this. Lots of good feedback from recent tests. I think we’ll also tweak the development process (Cabbage Tree Method) a little for this next phase and try user-dev-UX collaborative meetings facilitated online. It will be faster for picking up and fixing issues in the testing phase.

Coko and Communities

Kristen Ratan (co-Founder of Coko) and I have been pondering ‘the next phase’ of Coko. We have an organisation in place, with great people, and we have developed products (Editoria, and more coming soon) and frameworks (INK and PubSweet). Also, of course, we have developed the Cabbage Tree Method for facilitating ‘users’ (use-case specialists) to design their own products.

So…next up… community. It seems to me it is an interesting next phase which will require a lot of thinking about. The complexity comes from the fact that we have multiple primary stakeholders at play. A rough breakdown (note, each category is a complex ecosystem of diverse roles – all of which we still have to think through):

  1. PubSweet backend – this is a ‘headless CMS’ built for publishing workflows… however, it is a technical software whose primary community would be developers that commit to its continued development. Additionally, I would argue, its use-case is a whole lot broader than capital P Publishing… any organisation that wants to develop workflows for producing content (which is pretty much every organisation that exists) could benefit from this software. Publishers are just a tiny subset.
  2. INK – the web service for (primarily) managing file conversion pipelines. This is also a technical ‘backend’ whose primary community would be developers. INK’s use-case is also broader than ‘just’ publishers.
  3. INK Steps – INK processes files through steps which are small plugins. These can do anything from file conversion, to validation, content parsing etc…. the primary community for this is possibly more tightly connected to publishing requirements, but the builders of steps are more likely to be those involved on the production side of the workflow ie. file conversion experts, content miners etc
  4. XSweet – a very specific content conversion pipeline for producing HTML from docx. Primary community would be file conversion experts.
  5. Editoria – the monograph production platform. Primary community – Publishers but also interesting to any org that produces books.
  6. Journals – we are on our way to producing a Journal platform. The primary community for this is also publishing organisations…
  7. Ecosystem – we are building out an ecosystem of projects. So as much as possible we need to consider how we interact with and build community/collaboration with other open source/open access (etc) projects.

It is a complex stack..our job is to work out all parts of this stack, understand what they look like, and think through why they would want to be involved in a community, and how…

The beauty of small teams


I have been involved in setting up a team for the Collaborative Knowledge Foundation (Coko). We are about 12 all up now and spread around the globe. At our core we have :

Jure – Lead PubSweet Developer Slovenia
Richard – PubSweet Developer Kenya
Yannis – PubSweet Frontend Developer Athens
Christos – PubSweet Frontend Developer Athens
Charlie – INK Lead Developer New Zealand
Wendell – XSL-pro East Coast USA
Julien – UX-pro France
Henrik – Designer Netherlands
Juan – Sys Admin Nicaragua

and then we have myself, Kristen Ratan (co-Founder), and Alex (process manager) in San Francisco.

So… just looking at how development works… in the dev side of things we are pretty well distributed over the world and across a large variety of time zones, in fact, NZ, EU, USA is about as bad as it can get when setting up meetings at reasonable hours for all affected… so how do we manage to make this work?

Well, firstly we obviously rely on some remote tools. We all coalesce around Mattermost – an open source version of Slack (By the way, don’t use Slack – https://clearchat.com/blog/forget-applevsfbi-slack-gmail-have-backdoors/). This is a good avenue for remote chatting. We use it for both chit chat, y’know, hanging out and taking bullshit, and also work. Work mostly gets done on side channels, I wrote something about it here.

Okok..so that’s Mattermost. It’s a good tool but if we were just a bunch of people scattered around the world with a chat channel then it probably wouldn’t work as effectively.

So, I wanted to say something about creating space for people to operate and how remoteness can actually play into that rather nicely.

First of all, we are an organisation that likes people to like what they do. So we like to trust them and give them a bit of room to move. All people are creative and I believe all folks need challenges where they can exercise that creativity. Nothing new here – if you want to read more about this, with special reference to development teams, then read Peopleware (terrible title, great book – very old school… you can stop reading when they talk about optimum cubicle layouts, but the rest is awesome).

What I have found over the years is that responsible people work responsibly. So, I am assuming you work with some people like this 🙂 Otherwise return to zero and start again…. the thing about responsible people is that they like to get their head down into a flow and get on with it. They love hard problems and they love the trust given to them to solve these problems. But sure sure, this can happen in real space in a shared office…but…can it? I think there is an argument to made here that remote teams enable a more optimal working environment for this kind of team.

In our case, for example, we actually only have two people in the same place (not counting San Francisco). They are Yannis and Christos. Very nice chaps if you ever happen to be fortunate enough to meet them. Yannis and Christos work on developing the front-end components for the PubSweet publishing framework that Richard and Jure are building. We have an advantage here that we have carefully chosen to create a technical architecture that supports the autonomous development of front-end components which is separate to the backend that they rely on (the backend is known as PubSweet or sometimes we refer it to PubSweet core or ‘the backend’). Anyways… note to self, how you build what you build is a determining factor on how your team is structured and where they are… but… back to remoteness…

When we develop front-end components for clients, I go with Alex and/or Kristen to the client’s locale and then work through their design in a Collaborative Design Session. We then write this up and meet with Julien, Yannis and Christos remotely with a online whiteboard tool (BigBlueButton). And we have another collaborative session where we nut out the details. This is all a little by-the-by but just to say that we can segment our work quite nicely and the communication that does take place remotely is either:

  1. bullshit and fun
  2. high value and short

These whiteboard sessions are type 2 from the above. We set 2 hours to have the complete design sorted. When that meeting is done, everyone knows what they need to do. After that, we leave Yannis and Christos to get on with it and let us know when they are done. Any miscellaneous stuff gets sorted out bit-by-bit between the people involved. If, for example, some more UX mocks are needed, or some CSS detail, then Yannis or Christos will ping Julien on Mattermost and sort it out. No project management, no scheduled meetings. Short and sweet as per type (2).

At the same time, Jure and Richard are sorting out the backend. They communicate amongst themselves and solve the complex problems that such an abstracted system requires. All over Mattermost, too. Of course, there are various breakouts to real-time calls when required but it’s a minimum. Watching Jure and Richard tumble through difficult problems in Mattermost is a sight to behold. Both firing off each other and throwing ideas back and forth.

My job is largely to give each of these folks room to move.

So what about when each team needs something from the other? Being right up on the coal face of the client needs, I can see what things we need to address a little ahead of time and I call out to those affected and work out how we can sync the various threads. For example, we need to integrate PubSweet with INK (more about this below) for importing Word docs into PubSweet as HTML. So, seeing this, I talk to Jure mostly, and think through the issues. Jure interprets my partial developer-/partial user-speak and thinks about it. He then discusses it with all those necessary and they work out the best approach. Then we work out when it all needs to happen by and the order of play. Everyone then orientates around that timeline and away we go…in otherwords…the parallel teams ‘touch’ only when necessary – when they need something from each other. That’s not to say we try and stop people from talking to each other 🙂 Quite the opposite, we don’t gate any communication at all and leave people to sort it out. What we don’t do is build things before we need them or layer on complex management overhead. These are smart responsible people, let them work it out 🙂


the above image drawn with the fabulous MyPaint (open source) on a touchscreen Thinkpad running Ubuntu.

We are also achieving the same process with INK. Charlie is down in the Southern hemisphere tinkering away. She’s like a deep sea diver in Ruby and coming up to explain to us surface dwellers what’s going on down there. You saw whaat? …an uncontrolled multi-threaded waaaaaat!?oh good, you killed it Just-in-Time???…phew….. Charlie is building a system for managing file conversion pipelines but it is very abstracted. Essentially it is a job-agnostic queue manager. You can throw anything at it and it will do it. We are first using it for MS Word to HTML conversion. Wendell and Alex are working together to get the conversion process into shape. Wendell is writing the code and Alex is testing. Then we are making this into what we call a ‘step’ – essentially a plugin to INK. So Charlie can build the architecture for INK and then we need to make a light INK wrapper for the conversion scripts Wendell is making and then Alex can (not happening yet but soon) actually use INK to test the whole sheeeeebang. Cool. So, they can all operate pretty well remotely to each other building the same machine.

The cool thing about all this is that, sure sometimes details are hard to transmit, but mostly what happens is that people have most of the day, every day, to work on what they need to work on. I think this is helped by being remote. We have to be efficient. We don’t get in each other’s way. We have to get clear understandings fast. Remote comms aren’t nice for long conversations. We need them short, sweet, and efficient. Then everyone can just get on with what they want to do most…solve interesting problems.

I’m not going to say we are perfect. I’m also not going to say this process is perfect. We see the issues. We plan to have at least one full in-person team meet every 0.8 years so everyone can hang out and fill up the camaraderie tank (important)…the last one was in Athens and it was a blast



…and I make sure I go and see everyone every few months to make sure we are all on the same page and feeling connected. This setup needs these additional things. But it works, and when I travel around to see everyone, I see it working well and I see people performing exceedingly well doing things they want to do.