Off to Book Sprint!

A long time ago I started FLOSS Manuals to create free documentation for free software. It was my big get rich quick plan. Along that journey, which lasted 4 years or so, I had to come up with some things to make it all work… namely, I had to:

  1. learn how to build community
  2. build tools to help people collaborate to make books
  3. come up with methodologies to make books fast

Out of this came the FLOSS Manuals community, many (open source) book production platforms (most notably Booktype), and Book Sprints – a method to produce books from zero in 3-5 days.

Now… 10 years later…. here I am traveling to the Cambridge, UK, to be part of a Book Sprint facilitated by the CEO of the company I started, to write a book about PubSweet (a publishing toolkit for building publishing platforms built by Coko, which I co-founded), and the book will be written by the Coko team and Coko community…and written using Editoria – a book platform built ontop of PubSweet BY the Coko community!!!

Talk about recursive…. its like dog fooding on steroids…

OHBM Announcement

Last week I worked with the cool people at the Organisation for Human Brain Mapping (OHBM) and today they have a new announcement.

We are now working closely with the Collaborative Knowledge Foundation (Coko) to put together a publishing workflow, and we are grateful to the Canadian Open Neuroscience Platform (CONP) for providing generous support for the development of Aperture.

Coko has extensive experience developing open source publishing components, some of which are used by Elife and other open-access publishers. Their framework could give the Open Science SIG and the broader OHBM community the opportunity to participate in the construction of Aperture. We look forward to establishing even more collaborations with like-minded partners.

https://www.ohbmbrainmappingblog.com/blog/announcing-aperture-the-ohbm-publishing-platform

 

The Gits

(updated June 4 – the sale confirmed a few mins ago – https://www.theverge.com/2018/6/4/17422788/microsoft-github-acquisition-official-deal)

For many years I have been trying to warn people against using GitHub. I haven’t made a big deal about it, but the basic argument is that if you are an open source project and you understand all of the downsides of closed source, then why are you storing all your code in a service that is closed source?

The blind spot towards github is so extreme amongst many open source practioners that many hadn’t even considered the issue.

Here is a case in point. I have written on this issue several times, most recently:

Another Good Reason not to use Github

and prior to that, this rather silly short post:

Why Github is Bad for Open Source

Which appealed to the vegetarian side of me…but check out these responses on well known geek hangout reddit to the short silly post :

Why Github is Bad for ‘Open Source’ [sic] from linuxmasterrace

The last post summing it all up:

GitHub is better for open-source than many most other sites, however.

…sigh….

And now…of course…acquisition news….and when I saw it I thought it must be a an April fools joke because it is just too horribly poetic:

https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github

Microsoft and GitHub are in discussions for the acquisition of github by MS.

There are a couple of takeaways already from this. First, even if it doesn’t happen it will hopefully wake some people up.

Second, the mere fact that this is rumored to happen will keep a lot of people awake at night including all those competitors to MS out there who have code in github. This may drive users and backing to GitLab…

https://www.arnnet.com.au/article/641894/gitlab-goes-after-github-users-amid-microsoft-acquisition-rumours/

And, as it happens, this already seems to be the case as GitLab (the open source git repo service) is evidently experiencing a spike in github imported projects:

https://monitor.gitlab.net/dashboard/db/github-importer?orgId=1&from=1523265069688&to=1528103469704

We use GitLab at Coko and have done from the beginning. It is a great software, I highly recommend it.

Of course the lesson is not just for the software sector. This is a good example of why important infrastructure should be open source and be owned by the community that uses it. Otherwise you may wake up one day to find your own tools are owned by your competitor.

At Coko we have been advocating from the beginning that this true also for scholarly publishing, but it is just as true for every other sector.

Hanging in Athens

I’m going to try and be in Athens every month now to work with the team, setting dev priorities for the month (roadmaps are stored in our READMEs). Awesome bunch – doing great work and heaps of fun to hang out with. Can you believe we have four devs in this office and they account for 4 publishing platforms? (wax, micropubs, Editoria, xpub)… I like that we are punching above our weight by some considerable margin… awesome…

Some pics from the week. Geeking and graffiti from around the ‘hood…

dsc00337_small

dsc00316_small dsc00324_small dsc00333_small

CodeMirror Embedded in Wax

The Wax (a web based word processor we are developing) lead dev -Christos Kokosias – yesterday embedded another editor, in the editor. We need this for the PubSweet Book Sprint where we will be including code snippets in  the documentation we create. So we need a nice way to manage that… consequently Christos embedded the CodeMirror code editor into Wax. So it has things like syntax highlighting, line numbering, auto complete etc all built into the code blocks…its pretty cool… below is are two short vids Christos made to show it in action:

 

Pretty cool stuff and extremely useful for writing documentation that includes code…ask yourself… can MS Word or Google Docs do that? #opensourceisbetter

Production Facilitation

I had an interesting chat with Dirk Slater from Fabriders yesterday. It was a live online interview/discussion about the work I’ve done since FLOSS Manuals which I started 10 years ago.

Here are a few points I want to distill out from my experience evolving the Book Sprints, the Cabbage Tree Method, Workflow Sprints and others…

  1. Production Oriented Facilitation is not the same as ‘unconf’ Facilitation
    I like to differentiate facilitation of processes that produce products over a fixed timeline (books, software, workflow designs) from the typical kind of facilitation related to unconfs (etc). They are not the same thing, the former employs some of the tools of the later but also has tools of its own. Importantly, if you bring a (dare I call it ‘too respectful’) unconf tone to a production processes, you won’t get anything done. So don’t expect because you can do unconfs, that you have the tools and right approach to facilitate production processes. Mistaking one for the other is a category mistake.
  2. Remote Facilitation doesn’t work
    Facilitation of production events of the type that enjoys radical efficiencies like Book Sprints is not something you want to do remotely. You can’t get the same attention and commitment. Nor can you get the ‘full spectrum’ communication between all members of the group that you need if you are working remotely. At Book Sprints we believe this so much to be the case we don’t like to have even one person working remote.
  3. Not everyone is a facilitator
    Facilitation is one of those skills that people think they can ‘just do’. Doesn’t need any ramp-up time or experience, its just someone telling everyone else what to do in a ‘nice way’ right?… I have seen this time and time again. If you think like this, thinking you can facilitate with no experience, then you are at a bad starting point because it is clear you don’t know what facilitation is. Don’t experiment on your friends, family, or colleagues if this sounds like you.
  4. Good facilitation can only be learned by experience
    Experience is the only way to learn to be a facilitator. You can’t learn it from a book. So how do you learn? By apprenticeship. Find a mentor that can take you through the process in situ. It is the only way. Don’t expect it to be a quick process.
  5. Technology is not the answer
    So many times I have people ask me what tools Book Sprints uses. What is the software? It is not asked from the position of trying to make sense of the ecology of items that are needed as tools, it is asked in the Silicon Valley sense of ‘software solves everything’. Book Sprints is not about the software. Its about the methodology and the facilitation. We could do Book Sprints without the tech we use (and we have in the past). But if you believe you just need to install the software and stand back and watch the magic happen, then you are wasting your time. Sure the software helps us run things smoothly, but it does not automagically ‘provide’ a Book Sprint.
  6. Don’t put people in a room and expect it to work
    In the case of Book Sprints I have seen many orgs try and emulate it by just putting a whole bunch of people in the same room and expecting the magic to happen. If you have tried this, I know you have failed. It doesn’t work and you are missing the point. It’s all about the facilitation.
  7. A method is a compass, not a religion
    Facilitation methodologies are not religious texts that must be followed to the letter. Unfortunately that is how too many book-learning facilitation courses approach facilitation. It’s very sad to see.  Methods are instead merely navigational instruments. However, they are useless in the hands of someone that does not know how to use them. You need to be an experienced facilitator, with experience of that particular method, for everything to work. A facilitator who is experienced with a particular method and knows how to use it will not only be amazingly good, they will also know when the method doesn’t give them what they need, and how to improvise towards true north.

And as a last coda, a note on who makes a good facilitator… I do believe some people, through a combination of nature and nurture, will make excellent facilitators, while others should really not even attempt it. I must say that this is a very hard thing to determine before training someone. I have some clues as to what qualities may contribute to being a great facilitator but it’s still largely a mystery to me. You never really know it until you see it, which is why I prefer to train people with the option of stopping if I can see it won’t work out.

I will say however, that I have found that most unconf facilitators do not make good ‘production’ facilitators. My best attempt to understand this hasn’t got me very far, although I’d say it has something to do with the two processes looking like they overlap a great deal, but in reality they overlap less than you imagine. Consequently the internal rationale and ’emotional position’ you take, as well as the facilitation tools and tricks, don’t actually transfer, and, worse, will probably lead you in entirely the wrong direction. You need to be rewired, and I haven’t seen this work (yet). This my best take on it and is purely anecdotal – garnered from training several people who knew how to facilitate unconfs only to abandon the effort to facilitate production part way through. I can’t entirely explain it, but there you are – take it for what it’s worth.