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.


The Gits

(updated June 4 – the sale confirmed a few mins ago –

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.


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:

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…

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:

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…


dsc00316_small dsc00324_small dsc00333_small