The new Collaborative Knowledge Foundation website is now live. It was designed by the fabulous Dutch design company the van Leeuwen Brothers. I have known designer Henrik van Leeuwen for many years. He’s a good friend, talented designer, and great artist. Henrik has done all the illustrations for Book Sprint books for many years now and does almost all the Book Sprint cover designs. He developed the Book Sprint and Coko logos and now the Coko website. Henrik and his brother Kresten are huge talents and if you are looking around for good designers I highly recommend them.
Tag: Book Sprints
The first not-really Book Sprint
I have been poking around in my own archives recently. It’s pretty cool to remember things that I had completely forgotten. Anyway, the following is a post I found about the first Book Sprint. It was about Pure Data and held on the little island of Korčula, Croatia. A buddy, Darko Fritz, let us use his apartment in the center of the old town. I was to join two friends, Derek Holzer and Luka Prinčič, at the apartment for 3-ish days. However, on the way I had a health freak out and had to participate remotely. It was our first attempt at a Book Sprint and looks almost nothing like how Book Sprints are done now, but it was a starting point and gave me a lot to think about.
The following is the report written by Luka for the FLOSS Manuals site. I love the two images in the post. They are the only images Luka and Derek sent me of this mysterious event.
So, Adam sent us (he was supposed to come too, but couldn't at the end) - he sent Derek Holzer and myself to this Croatian island Korcula, into the little (but very very cute) town named the same (Korcula) so that we Sprint-it up and write a Pure Data manual for FLOSS Manuals. I took my little old red car and drove down from Ljubljana over Rijeka and under scary stoney Velebit entering the warm sunny region of Dalmatia and driving further towards Split. Now this was a fun ride, especially under Velebit was very scenic. My cup of tea, as I hate the boredom of motorways. And my clutch was going to hell too, so my fingers were crossed. In split I caught this superfast catamaran-pedestrian-ferry that took me in under three hours to Korcula where Derek was waiting for me. And for phone line. And for internet connection.In this lovely little town with incredible feel of Venetian architecture, tiny little streets, all set in stone, we waited for ADSLine to appear, which it did right next morning. The evening before we discussed over a plate of Italian pasta and a beer what would be good to work on in the coming days. After the internet magically appeared (yeah right!) we could also discuss with Adam, who was in Amsterdam, over Skype how to work and what to work on. Derek was somewhat the main captain although each of us worked on our own chapter. Adam was going after installation instructions for various platforms, Derek was rewriting and expanding tutorial on how to build a simple synth, and I was going deep into 'Dataflow' tutorials.
On Monday when I arrived, the sea was quite wild as there was a lot of wind. Tuesday was all gray and rainy. We had some talk about doing some hiking, as Derek had already explored some terrain, but Tuesday was a bit too wet, so we stayed in and worked on bits and pieces trying to see how much work there is and how writing feels. It seems from the after-perspective that this was the day to slowly get the grip on how the writing will go. On Wednesday, we took a bus in the morning to a nearby village by the coast and with a little map from the tourist office tried to find that little path that would correspond to a tiny dashed black line that goes up the hill towards another village about 500m higher. We searched for more than an hour until finally a communicative small but wide man told us that old paths were overridden with a new tarmacced road. "I used to go up those little paths, when I was young..." he said, "but now there's a road so why would one bother, but if you really want there's a little path there, you can find it...." We walked a path for a while and than decended slightly to find a road and walked the road for an hour, maybe two, under not-too-hot spring-ish sun. It was lovely. After icecream in a local shop (those local shops are always something!) we caught a bus and went back 'home'. We started to work immediately, had some lunch and worked quite late into the night. We talked to Adam over Skype and kept working each on our own part. Interestingly, and maybe because we were supposed to leave on Saturday morning (Derek had a plane ticket), next two days somewhat turned into a bit of frenzied work. As we knew we had just two days left, we tried to finish our parts. In consequence, at the end of Friday, we realized we hadn't gone out much. A real Sprint! One of us would go to the shop now and then, couple of times a day, and cook something (mostly pasta! - but I found some local home-made from Istria, and also Korcula olive oil!) The weather was nice, not cold, with many bits of sun. The voices of kids, sometimes horny cats, and other inhabitants were protruding through an open door and were making a special kind of atmosphere. It was lovely to feel this Venetian-medieval town around you. Our flat was on the third, top floor, we could see the sea from it and the roofs around us. On the friday evening we found ourselves with two huge finished chapters, both quite satisfied with it. We were tired but happy we made something. We searched the town for fish and found an empty but slick-looking restaurant with a young owner-cook who made us some fish and vegetables. I guess we could have made them ourselves at home, but none of us spotted a fishery and had much time and energy left. I must say it has also been very educational for me to listen to Derek's peculiar playlist which included a lot of metal, old rock (Black Sabbath, etc) and African (Angolan) music from 70s. Luckily, Derek had a near perfect (or at least compatible) feel for sound levels, so it was always very enjoyable to become aquanted with a genre I haven't explored yet in my life much. In the aftermath of the Sprint of two-and-a-half days, we both felt we wouldn't be able to go like this for another day. If anything, we would need a day, or ideally two days of real break from this and than we could come back to the book with passion. I was thinking this would be great to do three or four times. In waves. Either that, or steadily work for 8, maybe 10 hours per day and then have a break. But I think this also depends on the writer and her/his ability and fitness to write. At the last moment I decided to stay for another two days (as our 'landlord' told us we could stay for us long as we liked, and Adam agreed). So Derek left on Saturday morning (6 am, ugh) and I worked on some of my music and had couple of walks around town and surroundings, really enjoying it immensely. My car was still where I left it in Split, and the clutch was still functioning (barely), so I drove back, under lovely Velebit of course. It was almost like summer all the way to the border with Slovenia, where heavy rain was waiting for me.
Korčula image by PJL (Own work) CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)
The Old Days
Wow…I was browsing some old archives to update this new version of my site. I found the most incredible stuff in the Internet Archives Wayback Machine including the outline of a description of Booki (2010) many years before it became Booktype. Amazing! I didn’t think I had the product manager in me but it seems once upon a time I was really focused on this kind of acute detail for product management. I had forgotten!
Forgive the long post, it’s just pure indulgent nostalgia for me. In any case, here is one of the emails I found really fascinating, from back in 2010, talking about features for Booki and Objavi (book renderer). This has been taken from the zip of a public list we used for dev at the time:
https://web.archive.org/web/20111029143503/http://lists.flossmanuals.net/pipermail/booki-dev-flossmanuals.net/
I’m so astonished how much of my thinking recorded in this email carries through to the way we are approaching product development for Coko now. The statement:
You might have noticed that I prefer to take the easy road for features, leaving as much open as possible, and then refine according to use. That is because,from experience, I have learned that when designing software it is better to be led by the user rather than force them into an imagined work flow.
Might as well be out of the Collaborative Product Design manifesto.
I’ts kind of incredible. The email documents so much of how we were thinking at the time, including using HTML and CSS to create paginated books using browser engines:
* Objavi utilises Webkit for PDF generation. Later Gecko will be added.
…and later in the product description…
3.2.2 CSS Book Design Status: High Priority, Implemented Function: The default PDF rendering engine for Booki is now Webkit and will eventually be Mozilla Firefox hence there is full CSS support for creating book formatted PDF in Booki. This changes the language of design from Indesign to CSS - which means any web native can control the design of the book.
Pretty interesting, if only to me! Anyway, the email is below, it documents some features we built on commission for Source Fabric before they eventually took over the project. Thank you for indulging me 🙂
From adam at flossmanuals.net Wed Jul 28 09:11:21 2010
From: adam at flossmanuals.net (adam hyde)
Date: Wed, 28 Jul 2010 18:11:21 +0200
Subject: [Booki-dev] notes to meeting
Message-ID: <1280333481.1582.143.camel@esetera>
hi Frank,
It was good to meet you and I'm glad Source Fabric is considering working with us and you to develop features they and we need (Aco is also keen for this).
I have sent this email to the dev list and to you and Micz. It might be good for you both to consider joining the list.
http://lists.flossmanuals.net/listinfo.cgi/booki-dev-flossmanuals.net
Below the content of this email is a very basic requirements doc. It does not outline the notes tab, so I thought I would make some notes here for your (and Micz's) consideration should Source Fabric decide they wish to commission all or part of this development.
In essence, I think that the notes tab could nest the following:
1. To do list
2. Book notes
3. Style guide
These could be hidden via a dropdown or accordian style interface. Our plan is to keep everything as simple as possible so I would imagine a page with three headings and clicking on each reveals the information behind it.
Some ideas:
1. To do list
The basic form could be a Jquery to do as we looked at today:
http://demo.tutorialzine.com/2010/03/ajax-todo-list-jquery-php-mysql-css/demo.php
If this is the format, it would be good enough as it is. The good news is that this is done using Jquery so I imagine this is a very easy implementation. What you would need to work out, however, is how Aco implements the dynamic updates so that when a to do is altered everyone has that info updated.
If there was room to take this development a step further, I would recommend considering adding the following fields:
* assigned to
* due date
* priority
I am not married to those ideas though as I think we need to insure that the interface does not have too many things going on. So I would actually recommend we start with the basic implementation and move on. When users have tried it then we can consider extending it with these items.
2. Book Notes
Something like etherpad would be good but too complex (see.
http://piratepad.net/ )
I would suggest considering either a) the same interface as we have now in the notes pad except with a very very simple WYSIWYG or b) a threaded comment system. I think the best would again be to do the easiest and simplest - what we have now with a WYSIWYG interface (and no need to press 'save'). Then when users use it we extend according to demand for most-needed features.
3. Style Guide
This is pretty much the same as (2) except it would be used for storing the Style Guide. A style guide is optional but many people request it in FLOSS Manuals and some go out of their way to create one so I think this would be a very good feature to anticipate based on our user experience so far.
I think all of the 3 above are simple and I think Source Fabric's working process (especially for the forthcoming Sprints) would benefit a lot from them.
You might have noticed that I prefer to take the easy road for features, leaving as much open as possible, and then refine according to use. That is because from experience I have learned that when designing software it is better to be led by the user rather than force them into an imagined workflow.
It has worked well for us so far - everything you now see in Booki is pretty much that way because we have tried similar ideas in FLOSS Manuals and seen their effect. I would prefer to continue to work this way with Booki.
So...there was one more feature we discussed - Chapter Level notes. I think this would be extremely useful for Source Fabric (but Micz needs to comment on this) but we need to be careful that we get it right because it is not so obvious how this might work.
I think the notes have to be associated with the chapter page when you edit it - however there is very little space there. One possibility is to build this into the WYSIWYG editor - Xinha - as a 'notes server' or some such. ie. it opens from the WYSIWYG editor but stores the content (chapter notes) in the booki db. The risk here is that people will not know that the notes are there...so we need to consider this. Another possibility is to build this into a 'sliding tab' as Micz suggested. I think that might be ok but it would have to be done carefully as it might look too much like a gimmick.
The other issue with chapter level notes is that I strongly believe that an overview of all chapter notes for a book should be able to be seen somewhere, in one place. Otherwise it would mean checking each chapter which would be a tedious job (books easily have 30+ chapters). So if you consider Chapter notes then you must also consider how to do this.
So on this I am not so clear what would work well for Chapter level notes and because of this I think it's not such a good feature for our first adventure working together. I would recommend instead the first three to be done all together - however this is up to Micz.
My feeling is that the first 3 are an extremely quick development, first however you need to know how it all fits together so i would suggest emailing this list when you have questions and I am sure Aco will answer your questions...
Also, Aco is currently working on the Booki site update so I expect the GIT repo is not updated but will be within the next days once the booki www is updated....
also you should meet Doug - doug is on this list and he is the Objavi (PDF generator) developer....doug - frank, frank - doug
also, meet John who does the Booki manual and other essential tasks intro intro :)
:)
adam
1 INTRODUCTION
1.1 Description
Booki is designed to help you produce books, either by yourself or collaboratively. A book in this context is a "comprehensive text" which can be output to book-formatted PDF (for book production), epub, odt, screen readable PDF, templated HTML and other formats.
Booki supports the rapid development of content. Booki has tools to support the development of content in 'Book Sprints'. Book Sprints are intensive collaborative events where collaborators in real and remote space focus on writing a book together in 3-5 days.
While you can use Booki to support very traditional book production processes, the feature set matches the rapid pace of publishing possible in the era of print on demand and electronic readers. Booki can output content immediately to multiple electronic formats. Print ready source (book formatted PDF) can be immediately generated, and then uploaded to your favorite Print on Demand (PoD) service, taken to a local printer, or delivered to a publisher.
1.2 Purpose
Booki embraces social and collaborative networked environments as the new production spaces for comprehensive (book) content.
1.3 Scope
Booki is available online as a networked service (http://www.booki.cc) for free. This service is a production tool for the creation of free content and not a publishing/hosting service. Content produced within Booki.cc is intended to be published elsewhere, either under another domain, in paper form (ie. books), distributed in electronic formats, or re-used in other content.
Booki can be installed by anyone wishing to utilise this software under their own domain or within private or local networks.
2 OVERALL DESCRIPTION
2.1 Product Perspective
Booki takes what was learned from building the FLOSS Manuals tool set and posits these lessons within a more suitable architecture.
Booki is the name of the collaborative production environment, however there are 2 associated softwares that provide all the services required :
Booki - production environment
Objavi - import and export engine
This document refers to Booki 1.5 and Objavi 2.2
2.2 Booki Functions
* User account creation requiring minimal information
* One click book creation
* Drag and drop Table of Contents creation
* One click editing of chapters
* Chapter level locks
* Live chat on a book and group level
* Live book status reports (editing, saving, chapter creation) delivered
to the chat window
* Drop down chapter status markers
* One click to join a group
* One click to add a book to a group
* One click exporting to epub, screen pdf, book formatted pdf, odt, html with default templates
* Easily accessible advanced styling options for export (CSS controlled)
* User profile control (status, image, bio)
* One click group creation
* Easy importing of book content from Archive.org, Mediawiki, other Booki installations
* Option to upload content to Archive.org
2.3 User Characteristics
2.3.1 Contributor
The majority of users will be contributors to an existing project. They may contribute to one or more project and may produce text and/or images, provide feedback or encouragement, proof, spell check, or edit content. These are the primary users and the tool set should first meet their needs.
2.3.2 Maintainer
These are advanced users that create their own books or have been elevated to maintainer status for a book by group admins. Maintainers have associated administrative tools for the books they maintain which are not available to other users.
2.3.3 Group admin
These are advanced users that wish to establish and administrate their own group. They have maintenance tools for every book in their group plus additional group admin tools.
2.4 Operating Environment
Booki is designed primarily for standards-based Open Source browser comparability but is tested against other browsers.
2.5 General Constraints
* Booki and Objavi are Python-based.
* Booki is built with the (bare) Django framework.
* Booki uses Jquery for dynamic user interface elements.
* Booki uses Postgres as the database but sqlite3 can also be used
* Redis is used by Booki for persistent data storage to mediate dynamic data delivery to the user interface
* Objavi utilises Webkit for PDF generation. Later Gecko will be added.
* Rendering of .odt by Objavi requires OpenOffice to be installed with unoconv.
* The Booki Web/IRC gateway may eventually (and optionally) require a dedicated standalone IRC service hosted on domain.
* Content editing in Booki is done by default with the Xinha WYSIWYG editor
* XHTML is the file format for content.
* Content will be ultimately be stored in GIT.
* Localisation in Booki is managed with Portable Object files (.po).
* The code repository for both projects is GIT with a dedicated Trac for bug reporting and milestone tracking :
http://booki-dev.flossmanuals.net
* A Dev mailing list is maintained here:
http://lists.flossmanuals.net/listinfo.cgi/booki-dev-flossmanuals.net
* Developers can be reached in IRC (freenode, #flossmanuals)
* Each release will be as source. Beta and later releases will also be available as Debian .deb packages.
* User and API Documentation will be maintained in the FLOSS Manuals
Booki Group.
* For development we use Apache2 for http delivery
* The license is GPL2+ for all softwares
2.5 User Documentation
Maintained here : http://www.booki.cc/booki-user-guide/
3 SYSTEM FEATURES
3.1 Booki Features
3.1.1 Booki-zip (Internal File Format)
Status: High Priority, Implemented
Function: A Booki-specific file structure for describing books
Interface: Used for internal data exchange between Booki and Objavi.
Notes: booki-zip definition maintained here :
http://booki-dev.flossmanuals.net/git?p=objavi2.git;a=blob_plain;f=htdocs/booki-zip-standard.txt
3.1.2 Account Creation
Status: High Priority, Partially Implemented
Function: Quick access to a registration form from the front page for account creation
Interface: Requires only username, password, email and real name (required for attribution). Email is sent to the user with autogenerated link for verification
Notes: email confirmation mechanism missing
3.1.3 Sign in
Status: High Priority, Implemented
Function: Quick access to a sign-in form from the front page
Interface: Username and Password form and submit button. Username and
pass remembered.
3.1.4 Profile Control
Status: Medium Priority, Implemented
Function: When logged in the user can access a profile settings page to set personal details (email, name, bio, image). Personal details can be browsed by other users
Interface: "My Settings" link in user-specific menu on left gives access to a form for changing the details.
3.1.5 Book Creation
Status: High Priority, Implemented
Function: Users can create a book from their homepage ("My Profile").
Interface: User can click on "My Profile" link from the user-specific menu on the left. On the Profile page a text field for the name of the book, and a license drop down menu (license *must* be set) is presented.
Clicking on "Create" adds the empty book with edit button to the listing of the users books on the same page.
3.1.6 Archive.org Book Import
Status: Medium Priority, Implemented
Function: Users can import books from Archive.org
Interface: "My Books" link in the user-specific menu on the left presents the user with a field for inputting the ID of any book from
Archive.org. The book is then imported when the user clicks "Import".
Notes : Interface is through Booki but Objavi does the importing and returns Booki zip to Booki. Relies on Archive.org successfully delivering epub for each book but this is not always happening. Needs error catching and user friendly progress/error messages.
3.1.7 Wikibooks Book Import
Status: Medium Priority, Implemented
Function: Users can import books from Wikibooks
(http://en.wikibooks.org)
Interface: "My Books" link in the user-specific menu on the left presents the user with a field for inputting the URL of any book from Wikibooks. The book is then imported when the user clicks "Import".
Notes : Interface is through Booki but Objavi does the importing and returns Booki zip to Booki. Needs thorough testing as it is sometimes failing possibly due to time-outs. Needs error catching and user friendly progress/error messages. Should be extended to be a "mediawiki import" tool, not just for Wikibooks.
3.1.8 Epub Book Import
Status: Medium Priority, Implemented
Function: Users can import any epub available online
Interface: "My Books" link in the user-specific menu on the left presents the user with a field for inputting the URL of any epub. The book is then imported when the user clicks "Import".
Notes : Interface is through Booki but Objavi does the importing and returns Booki zip to Booki. Needs thorough testing as it is sometimes failing possibly due to time-outs. Needs error catching and user friendly progress/error messages.
3.1.9 Group Creation
Status: High Priority, Implemented
Function: Users can create groups.
Interface: "My Groups" link in the user-specific menu on the left presents user with 2 text fields - group name, and description. When a name for a group is entered and "Create" is clicked then the group is created.
Notes: Group admin features missing.
3.1.10 Joining Groups
Status: High Priority, Implemented
Function: Users can join groups with one click.
Interface: "Groups" link in the general menu on the left presents a list of all Groups, by clicking on link the user is transported to the homepage for that group. At the bottom of the page the user can click "Join this group" and they are subscribed.
3.1.11 Adding Books to Groups
Status: High Priority, Implemented
Function: Users can add their own books to groups they belong to.
Interface: While on a Group page that the user is subscribed to the user can add their own books to the group.
Notes: When Group Admin features are in place we will change this so that Group Admins set who can and cannot add books to groups. At present a book can only belong to one group.
3.1.12 Readable Book Display
Status: High Priority, Implemented
Function: Users can read stable content in Booki without the need to log-in.
Interface: Upon clicking on the "Books" link in the general menu on the left a page listing all books is presented. Clicking on any of these presents a basic readable version of the stable content. Alternatively users can link to a book on the url http://[booki install domain]/[book name]
3.1.13 Edit Page
Status: High Priority, Implemented
Function: Page for editing content.
Interface: The edit page is accessed by clicking on "edit" next to the name of a book in "My Books" or "Books" (all books) listings. The user is then presented with a page with tabs for : editing, notes, exporting, history
3.1.14 Edit Tab
Status: High Priority, Implemented
Function: Edit interface for chapters.
Interface: Clicking ?edit? on a chapter title will open the Xinha WYSIWYG editor with the content in place.
3.1.15 Notes Tab
Status: High Priority, Implemented
Function: A place for contributors to keep notes on the development of the book
Interface: User clicks on the Notes tab for a book and is presented with a shared notepad for recording issues or discussing the development.
Notes : Implemented but future direction TBD
3.1.16 History Tab
Status: High Priority, Implemented
Function: Shows edit history of the book
Interface: User clicks on the history tab and can see the edit history with edit notes.
Notes: Implemented but unreadable. Users should also be able to access diffs here.
3.1.17 Export Tab
Status: High Priority, Implemented
Function: Export content to various formats
Interface: User clicks on the Export tab and is presented with a form for choosing export options. Clicking "Export" returns the desired output for download.
3.1.18 Version Tab
Status: High priority, Not Implemented
Function: can easily freeze content at stable stages while work continues on the unstable version.
Interface: From the Edit Page a maintainer sees an extra tab "Version".
>From here a maintainer can click "create stable version" - the last stable version is archived recorded and the current version becomes the new stable version.
3.1.19 Subscribe to edit notifications
Status: High Priority, Not Implemented
Function: Users can subscribe to edit notifications
Interface: User clicks "Subscribe to edit notifications" from the Edit Page for a book. If there are edits made a synopsis is emailed with basic edit information (time, chapter, person who made the change, version numbers) and a link to the diff.
3.1.20 Chat
Status: High priority, Implemented
Function: A real time chat (web / IRC gateway).
Interface: Persistent on the edit page for any book.
3.1.21 Localisation
Status: High priority, Not Implemented
Function: Booki needs to be available in any language where it is needed. Hence we may integrate the Pootle code base into Booki to enable localisation of the environment.
Interface: TBD
3.1.22 Translation
Status: High priority, Not Implemented
Function: Content can be forked and marked for translation. A
translation version of a book will provide link backs to the original
material, be placed in a translation work flow, and edited in a
side-by-side view where the translator can also see the original
source.
Interface: TBD
3.1.23 Copyright Tracking (Attribution)
Status: High Priority, Implemented
Function: Any user contributions are recorded and attributed.
Interface: All attributions are automated in Booki. Book level attribution is output in any chapter that contains the string "##AUTHORS##"
Note: should be a syntax for producing Attribution notes on a per-chapter basis eg. "##CHAPTER-AUTHORS##"
3.2 Objavi Features
3.2.1 Book-Formatted PDF Output
Status: High Priority, Implemented
Function: the server side creation of Book Formatted PDF is a pivotal feature. This is managed by Objavi which runs as a separate service. The book formatted PDF supports Unicode, bi-directional text, and reverse binding for printing right-to-left texts on a left-to-right press and vice versa. The formatting engine outputs customisable sizes including split column PDF suitable for printing on large scale newsprint.
Interface: This feature is managed by Objavi, an API is functional and feature rich but not well documented at present. Objavi also presents a web interface for those wanting more nuanced control (see http://objavi.flossmanuals.net/).
3.2.2 CSS Book Design
Status: High Priority, Implemented
Function: The default PDF rendering engine for Booki is now Webkit and will eventually be Mozilla Firefox hence there is full CSS support for creating book-formatted PDF in Booki. This changes the language of design from Indesign to CSS - which means any web native can control the design of the book.
3.2.3 Export Formats
Status: High Priority, Implemented
Function: Users also can export to self contained templated (tar.gz) HTML, to .odt (OpenOffice rich text format), epub, and screen readable PDF. Other XML output options can be developed as required.
I guess I can never claim to not having project management experience again. Darn it.
On creating a methodology
Some years ago, I developed the Book Sprints methodology. It’s now pretty well defined and is being used very successfully to develop many books for all types of organisations. I am now working on another methodology – Collaborative Product Development. So, this time round, it’s sooo much easier and I thought perhaps I should write down some of the journey from zero to methodology. It will certainly help me to do so and maybe someone else out there will find it useful.
First of all, methodologies are odd things. Book Sprints is a methodology but, at the same time, I often wonder exactly what this means? I mean…you can’t just take a written template and turn it into a successful facilitated process. It just doesn’t work. The reason is because facilitation is a little, if you pardon the strange analogy, like administering the law. The law exists on paper but every time it is administered by a judge it is new. The context requires the law to be interpreted to enable it to be applied.
I think facilitation is like this. You can take a method and apply it but the context is everything. You must always make the application of the method new each time it is applied. Further, you need to extend it and break it when necessary and you have to do it effectively, other wise you break the process and, in the facilitation game, process is everything.
So…you must first be a facilitator to apply a facilitation methodology. Even then you can still screw it up. For example Book Sprints, and Collaborative Product Design, employ all the same skills that you need for ‘unconference’ facilitation plus more. The more is specifically the skills required to drive people effectively along a finite timeline to completion of the thing you are making. The need to drive product in this manner often freaks unconference purists out because you wield a lot of ‘do it now’ power else you will never get there. ‘Do it now’ power is only subtly used in unconferences, in product-driven facilitation you use it like a hammer.
Anyways… the point being that a methodology on paper is nothing. You need to define it, so out comes the pen and paper.
Defining a methodology is actually pretty strange and, in my experience, the newer the ideas in the methodology are to you, the longer it takes to define. Book Sprints, for example, took me about 4 years to work out and I only really knew it had a definition when I had to train someone else. CPD, on the other hand, took me a day to outline on paper. I’m still refining it but that’s normal, the body of CPD came into existence in one day-long session. What’s more, it appears to be working. The bits that are taking the longest to work out are the bits I haven’t experienced before. We haven’t taken a full product to market with CPD, so, consequently, the production implementation phase still needs to be tested and refined. The rest of it, however, seems pretty well constructed.
It took a long time for me to work out a method for Book Sprints. I was really just trying stuff completely blind. It didn’t start that way, as it happens. I first went to people in the publishing industry and asked them how I should do it. I figured they knew how to make books and surely they would have some ideas on how to make it faster. Hah. Was I ever wrong. My experience was that publishing people screwed up the process with their own process. Too much process. So I had to, finally, after a long period of angst, decide I was going to have to work this thing out myself. I didn’t want to do it. I didn’t even know what it was I was trying to do. So, sigh, I relented and proceeded to slug it out.
It was like slugging it out too. I mean, I had no experience in making books. I didn’t want to do anything I considered ‘publishing’. I have an aversion to cathedrals – which is what publishers looked like to me. A deeply institutionalised sect. So I had to actually learn to trust myself and do it my way. It was quite scary at first. I mean, I was inviting a bunch of people to come to some place to work for a week to develop a book using a methodology that actually didn’t exist. I didn’t have much idea what it might look like either. Geez… I must actually be pretty stubborn when I look back on it.
So I went about inviting people to Book Sprints and I challenged myself to trust myself. To listen to myself and observe. I came to understand that the only thing that could enable or prevent a successful Book Sprint was me. There was no other factor. That was pretty frightening at times. I spent many nights during Book Sprints completely terrified that I was about to send this nice group of people into an unproductive deep abyss. They might return from that dark hole but I was pretty sure I wouldn’t.
On this journey, however I had some starting points. I don’t know what triggered it but very early I came to understand that rapid book development of the kind that Book Sprints represents could not be about publishing processes – it was about unconference processes. Luckily I had a mentor, who had, for reasons unknown to me, taken me under his wing. At the time I didn’t know how lucky I was. That was Allen Gunn (Gunner). I had seen him in action many times as a facilitator and I had a few clues to a process. It wasn’t much but it was a start.
So I tried my hand at facilitation. I would, at the time, tell myself that Book Sprints were more about facilitation of people than the production of a book. To say so out loud sounded odd. It didn’t sound true. It sounded like I just made it up. But I kept saying it and trusting it. I kept challenging myself to trust myself. It wasn’t easy but as I became used to it, the process became easier.
Anyway, I still couldn’t call this thing a methodology. All I knew was that I was trying things out and formulating some kind of Book Sprints worldview. I think it’s fair to say the worldview was nothing I could articulate. I worked through gut and felt that everything was instinctual. However, I was learning useful tricks. For example, I remember Gunner saying he tried something new each time he facilitated an event. So I tried something new each time. I learned that if you failed with the something new, the trick was to make out like it was a success and, further, an expected success. This way I created a fallback framework that would allow me to experiment, to try and fail, to learn on the job and to get away with it.
So, I iterated forward. Rather slowly really. I mean, I had to convince people that this non-existent Book Sprint thing was not only possible, but they should do it, while I had little to point to as proof. Yeesh. Talk about a hard sell. But some people saw the possibilities and tried it out. I am forever grateful to Leslie Hawthorn who was working at Google Open Source Programs Office at the time. Leslie (introduced to me by Gunner) backed me and sponsored the first 3 Book Sprints. Amazing. I got something I could start with and that was critical. Later, with a few under my belt, it became easier to convince others.
So I did this for many years and felt I something taking shape. It was actually working. The books were getting better which seemed to indicate I was improving the process. I was starting to construct an embedded framework and the things I did were tested against it. It was filling out and becoming more consistent. I could finally start becoming a little more playful with the process. Still, when I started to talk about it as a method it was a query more than a statement. I wasn’t even sure what a methodology was. I wasn’t sure if Book Sprints was a method or even a stable set of practices. Others also said they same thing. David Berry and Michael Dieter, two good friends and critical theorists, would ask me what I thought it was. I had no idea how to articulate it. I asserted at time that it was a methodology but I wasn’t even sure I convinced myself.
A critical break through came when David and Michael (who had both been to 2 Book Sprints by this time) wrote a post about the process:
http://ausserhofer.net/2013/02/the-method-of-book-sprints/
I was amazed. They saw things that I didn’t. It was stunning to me. They had given me my own framework. From this point I started to construct a much better understanding of what I was doing.
The next step that finally defined the process was when I actually had to train someone to do it. I had other work offered to me (designing platforms) and I had a Book Sprints client base to keep happy. So I needed to scale. I needed me times 2. So I brought in Barbara Rühling (as introduced to me by Zara Rahman). It was at this moment, during a Book Sprint in Malta, and Barbaras first training session, that I started to make up a language to explain what a Book Sprint was. It flowed out of me like I knew it all along. I was very lucky in that Barbara trusted my narrative. It allowed me to expand notions as they came out of my mouth. I could define and refine a language and process as I spoke. It was fantastic and it was the final moment in the long process of defining a method. Hard won experiences were suddenly made salient and coherent though in situ explanation.
Now when I look at Book Sprints it appears pretty concrete. I laugh when people talk about it as if its a ‘known thing’. How can it be? I just made it up! 🙂 Of course, I didn’t just make it up. It is the result of a lot of trial and error and observation, risk, stress, unbelievable elation when things worked out, and the inability to give up. I still don’t know why I didn’t give up. I like to think if I did it again I’d give up. It might be a better way to live my life 😉
Some publishing systems I have developed
I recently went over some publishing systems with Yannis and Christos from Coko. We looked at various systems and discussed them. As we did this, I realised that I’d actually built quite a few! Although we weren’t just talking about those I had built, I began to think through what I had done right and wrong when building those earlier systems. Each development is a learning process and you will always get things both wrong and right at the same time. The trick is to get less wrong the next time round…
In the ten years that I have been building these systems, I have worked with some pretty talented people, including Luka Frelih, Douglas Bagnall, Alexander Erkalovic, Johannes Wilm, Remko Siemerink, Juan Gutierrez, Lotte Meijer, Fred Chasen, Michael Aufreiter, Oliver Buchtala, Nokome Bentley, Andi Plantenberg, Mike Mazur, Rizwan Reza, Gina Winkler and many others including the entire team of Coko – the most talented bunch of them all. Coko team:
Kristen Ratan – CoFounder, San Francisco
Jure Triglav – Lead PubSweet Developer, Slovenia
Richard Smith-Unna – PubSweet Developer, Kenya
Yannis Barlas – PubSweet Frontend Developer, Athens
Christos Kokosias – PubSweet Frontend Developer, Athens
Charlie Ablett – INK Lead Developer, New Zealand
Wendell Piez – XSL-pro, East Coast USA
Julien Taquet – UX-pro, France
Henrik van Leeuwen – Designer, Netherlands
Kresten van Leeuwen – Designer, Netherlands
Juan Guteirez, Sys Admin, Nicaragua
Alex Theg – Process, San Francisco
All systems except, unfortunately, one (see below) are open source.
FLOSS Manuals
The first publishing system I designed and built didn’t have a name really. It was the glue behind the FLOSS Manuals English site. FLOSS Manuals was, and is still, a community focussed on building free manuals about free software. I started the development in English but the system needed to be useful to a number of different language communities, of which Farsi was the most interesting. Today, only the French and English communities are still operational.
I built the FLOSS Manuals system in Amsterdam in about 2006. It was based on TWiki, an open-source Perl-based wiki. I chose TWiki because back then it was the only wiki around that had good PDF-generation support – I think this came from some of its plugins. TWiki had a good plugin and template system and I came to think of it as a rapid prototyping application – it was pretty malleable if you knew how. I was a crap programmer so I cut and pasted my way to a system that became usefully functional.
I leveraged the account creation and permission systems of TWiki, and ripped out the wiki markup editing and replaced it with an HTML WYSIWYG editor (I think it was TinyMCE). So in wiki world terms I had committed something of a crime. Throwing out wiki markup at the time was unheard of in the post-2004 euphoria of Wikipedia. But JavaScript WYSIWYG editors were coming along just fine, and I thought wiki markup no longer made any sense (in fact it had been invented to make making HTML easier than writing raw HTML). But y’know… wiki markup was no easier than using a WYSIWYG editor, despite the sacred status of Wiki markup in the Wikimedia community. And despite my heresy,the Wikimedia did give me a barnstar for my efforts, which was nice of them:)
After I reached the limit of my coding skills, a friend, Aco (Alexander Erkalovic), helped build the next bits. I found some money to pay him and that is when things started to move forward. I can’t remember all parts of the system, although it’s still in up and running for some FLOSS Manuals language sites. The core of the system was the manual overview page. This contained a list of all chapters in a manual. You could also set the status, add new chapters, view overall progress etc. from this one page. We had a separate mechanism for creating an ordered table of contents (index) for a manual.
Index builder, essentially a dynamic drag and drop mechanism for arranging chapters
The overview page
Essentially, you added a chapter on the overview page and then opened the index builder and arranged the chapters. When saved, the (refreshed) overview page displayed the correct (new) order of chapters. We had to do it like this because back then, in the era of the ‘page refresh,’ it wasn’t possible to synchronise dynamic elements across multiple clients. So we couldn’t have one ‘shared’ index builder that would dynamically update all user sessions simultaneously. Nevertheless, it worked pretty well.
From the overview page, you could choose a chapter to edit. When you did so, you locked the chapter and, through some JS trickery Aco cooked up, we wereable to do this across multiple clients so everyone could see in real time who was editing what.
When editing a chapter, you could save the document and then, when ready, publish it. This way you could have an ‘in progress’ state of a chapter and a published state. At publish time the chapter was copied across to the system’s web delivery cache.
We also added chapter status markers, as you can see from the above image. It was pretty basic but nifty.
Next I hacked in a live chat, initially using IRC (freenode) for a global FLOSS Manuals-wide chat:
Then I hacked a fancy AJAX script into the chapter edit interface so each manual could have its own chat with the interface present while you were editing a chapter. It also looked a little nicer than the IRC channel. From the beginning, I tried to make everything look like it was meant to be there, even if it was a fiddly hack.
FLOSS Manuals also had a lot of other interesting goodies. We had federated content, for example. This was established so one language site could import an entire manual from another and set up a translation workflow.
We also had a simple side-by-side editor set up for translation that worked pretty well for translators.
In addition, we had a remix system for generating new versions using mixed content from other manuals. This was useful for workshops and for making personal manuals, for example.
One of the cool things about the remix is that you could output in many formats such as PDF and zipped HTML, add your own styles through the interface, PLUS you could embed the remix in your own website 🙂 The embed worked similarly to methods used today to embed YouTube or Vimeo videos in websites (by cut and pasting a simple snippet). The page delivery was ‘live,’ so any updates to the original manual were also displayed in the embed. I thought that was pretty cool. No one used it of course 🙂
The system also had diffs so you could compare two versions of a chapter. It was good for seeing what had been done and by whom. In addition, it was possible to translate the user interface of the entire system to any language using PO files and a translation interface we custom built:
But by far the most interesting thing for me was building FLOSS Manuals to support Farsi. It was interesting because, at the time, no PDF-renderer I could find would do right-to-left rendering. Behdad Esfahbod advised me to just use the browser to do it. Leslie Hawthorn from Google Open Source Programs Office introduced me to him after I went on a naive search in the free software world for ‘someone that knew something about RTL in PDF’. I was very lucky. The guy is a generous genius. He just suggested an approach a new way to think about it and later I worked with Douglas Bagnall (see below) to work out how to do it. The basic idea being that HTML supported RTL and the PDF print engines rendered it nicely…so…it was my first realisation that the browser could be a typesetting engine.
Implementing RTL in the FLOSS Manuals system was so very tricky, and I was unfortunately on my own for working out Farsi regex .htaccess redirects and other mind-numbing stuff. Just trying to think in right-to-left for normal text did my head in pretty fast, but somehow I got it working.
Outputs of all language books were PDF and HTML, later also EPUB. I initially used HTMLDoc for HTML-to-PDF conversion. It was pretty good but didn’t really think like a book renderer needs to. This was my first introduction to the overly long wait for a good HTML-to-PDF typesetting engine. Later I found some money and employed Luka Frelih and then Douglas Bagnall to make a rendering engine separate from the FLOSS Manuals site (see Objavi below). Inspired by my chats with Behdad (above) Douglas introduced some clever PDF tricks with the Webkit browser engine to get book formatted PDF from HTML. I can’t remember exactly how he did it but essentially he used xvfb frame buffer to run a ‘headless browser’. In short, and for those that don’t know those terms, he came up with a very clever way to run a browser on a server to render PDF. It did it by rendering HTML to PDF in pages (using the browser PDF renderer) and then rendered another set of slightly larger blank PDF with page numbers etc and embedded one within the other. Wizard. Hence we were able to make PDF books from HTML. It also supported RTL 🙂 I think I need to say here that this whole process was immensely innovative and we did it on a dime. Also, because we refused to use proprietary systems we were forced to innovate. That was a very good thing and I welcomed the constraint and the challenge.
Later we also used WKHTMLTOPDF to make PDF. It worked and we worked with that for a long time. I even tried to start a WKHTMLTOPDF consortium with Jacob Trulson, the founder of the project, it got some way but not far enough (I am very happy WKHTMLTOPDF is still going strong!).
I played a lot with Pisa and Reportlab for generating PDF and finally cracked it when I started book.js (more on this below). Actually, when it comes down to it I think I used everything that wasn’t proprietary to make book formatted PDF from HTML. It was the start of a long love affair with the approach. I promoted this approach for a long time, even calling for a consortium to be formed to assist the approach:
http://toc.oreilly.com/2012/10/the-new-new-typography.html
http://toc.oreilly.com/2012/11/gutenberg-regions.html
As it happens, all this time later I’m still doing the same thing 🙂
http://www.pagedmedia.org
We integrated FLOSS Manuals with the Lulu API (now defunct). This allowed us to generate books automatically from HTML using Objavi (below) and they would be automagically uploaded to the Lulu print-on-demand marketplace for sale…that was amazing! Ah…but also no one used it. Lulu shut down the API as soon as they realised no one was using it.
We made many many manuals with this setup. Many of them printed from the auto-PDF magic and were distributed as paper books. Many of the books were in Farsi. The One Laptop Per Child community even built a FLOSS Manuals app that was distributed on all OLPC laptops with the documentation made with FLOSS Manuals.
The system produced loads of manuals and printed books about free software. All free content.
The FLOSS Manuals platform didn’t have a name. It was a hack of TWiki. While you could get all the plugins online, it would have been a nightmare to deploy. I did deploy it many times but I essentially copied one install to another directory and then cleaned out all the content and user reg etc. and went to town rewriting all the .htaccess redirects. It sounds stupid now, but I spent a lot of time doing URL redirects to ditch the native TWiki URLs (which were extremely messy) and make them readable. Hence the system was a pain to deploy or maintain. It was feeling like we needed a standalone, dedicated, system….
Booki
Booki was the next step. It was clear we needed something more robust and also it was clear no web-based book production system existed, hence the hackery Twiki approach. So it was about time to build one. At the time, though, I remember it being very difficult to convince anyone that this was a good idea. I didn’t have access to publishers, and everyone else thought books were just soooo 1440. What they didn’t realise is that we were building structured narratives and that, IMHO, will have a lot of value for a long time. Call it a book or not. Anyway, we built Booki on Django (a Python framework) and the first time we used it was a Book Sprint for the Transmediale Festival in Berlin.
Aco literally would be building the platform as it was being used in the Book Sprint – restarting when everyone paused to talk. It was an effective trick. We learned a lot working with the tool and building it as it was being used.
At the time I couldn’t imagine book production being anything other than collaborative. FLOSS Manuals collaboratively built community manuals. Book Sprints were short events building books collaboratively. So Booki was meant to be all about collaboration. Booki also was run as a website (booki.cc) which was freely available for anyone to use.
Many groups used it which was cool.
Booki.cc run from with the OLPC laptop
Booki had all the basic stuff the FLOSS Manuals system had and we advanced the feature set as our needs became more sophisticated, but the basics were really the same.
The main differences were that we had a dynamic ‘table of contents’ where you could add and rearrange chapters etc and the updated ToC would be dynamically updated across all user sessions. Hence the ToC became a kind of ‘control panel’ for the book.
We also experimented with data visualisations of book production processes.
We did some cool stuff with the visualisations. For example, during the Open Web Book Sprint (also in Berlin) we worked in the Hungarian Embassy. They had a huge window that you could backwards project onto so people could see the projections on the street. So we made a visualisation of text from the book being overlayed as we wrote it. Below is an image shot with us standing in front of the projector…I mean..c’mon…how cool is that? 🙂
Booki also had federation. You could enter the target URL of a book from another install and Booki 1 would make a portable archive (booki.zip) and send it to Booki 2. Booki 2 then unpacked the zip and populated the book structure complete with images etc. I liked the idea very much of using EPUB instead as a transport technology instead and was later able to do so for Aperta and PubSweet 1 (see below).
In general, Booki didn’t advance much further from the FLOSS Manuals set up. It kind of did ‘more of the same’. I think the only stuff that went further than the previous system was the dynamic table of contents plus it was easier to install and maintain. Having groups was also new, but that wasn’t used much. It was in some ways just a slightly different version of the previous system.
Booki was also used for producing a tonne of books.
Objavi 1 & 2
Alongside the development of the FLOSS Manuals system and Booki, I headed up the development of Objavi. Objavi is basically a separate code base that was used as a file conversion workhorse. Objavi 1 was a little bit of a hacky maze but it did a good job. It would basically accept a request and then pipe that through a preset conversion pipeline. It did a good job. What I found most useful from this is that each step left a dir that I could open in a browser to inspect the conversion results. So if the conversion needed several steps, this was very helpful in troubleshooting.
Objavi 2 was meant to be an abstraction. However I don’t think it really got there, and Booki, which later became Booktype, came to internalise these conversion processes after I left the project. I always thought internalising file conversion was a bad idea because file conversion is resource-intensive, making it better to throw it out to another external service. And having a separate conversion engine enables you to completely overhaul the book production code without changing the conversion code. Hence FLOSS Manuals could migrate to Booki but still use the same external conversion engine. This was a HUGE advantage. Further, all the FLOSS Manuals instances, as well as booki.cc could use a single Objavi install for their conversions.
Objavi was actually also the magic behind the federated content in both the FLOSS Manuals system and Booki. All content would be passed through Objavi for import and export so Objavi became the obvious conduit for passing a book from one system to another. This gave me a lot of ideas about federated publishing which I have written about elsewhere and archived here.
Booktype
Booktype was really Booki taken to market. I was frustrated by not getting much uptake, so I took Booki to Sourcefabric in Berlin and headed up the development there. Booktype gained a UX cleanup. The editor was changed after an event I organised in Berlin called WYSIWHAT. The event was meant to catalyse energy around the adoption of a shared editor for many projects. It was of many things I did in pursuit of the perfect editor. At that event, we chose the Aloha contenteditable editor. I don’t think that was as useful a change as expected at the time, but back then contenteditable looked like the way to go despite there being few editors that supported it. Since then TinyMCE, CKEditor and others all have contenteditable support, further econtenteditable became a bit of a lacklustre implementation in browsers.
Booktype was literally the same code as Booki but rebranded. So many of the same features persisted for quite some time until Booktype eventually took on a life of its own.
Displaying ‘diffs’ (differences) between 2 different versions of a chapter
Activity stream of a book
I prototyped some interesting things in Booktype but not much of it got built. For example, I was keen on editing content in the style of the final output. The example below is using the CSS layout of Open Design Now which I mentioned below with reference to BookJS.
I also made a task manager prototype based on kanban cards but it was never integrated into Booktype.
I think there are only really three parts of Booktype’s development that occurred while I was in charge of the project. First was the integration of a short messaging system into a user’s dashboard and into the editor. Essentially you could highlight text in a chapter, click on the msg widget and a short message could be sent with that text to whoever you wanted (in the system). It was intended for fact checking or editing snippets etc. The snippets were loaded into an editor to assist with this kind of use case.
A good idea but seldom used.
In addition, Booktype supported groups, so users could form groups which were populated by users and books. The idea behind this was that you could form a group to work on a collection of books collaboratively.
Lastly, the renderer was integrated in a more sophisticated way so you had more control of the output from within Booktype. Essentially you could choose a number of output options and style them from within Booktype.
These were all interesting additions, but in the end, Booktype was really only Booki taken a step further as a product without offering much that was new. I think we should have probably actually removed a lot of things rather than adding new things that didn’t get used.
Booktype developers added some interesting stuff after I left. I particularly like the image editor and the application of themes to the content.
The image editor enables you to resize and effect an image from within the chapter editor.
The theme editor allows you to choose from an array of styles/themes and edit them.
Booktype 2 has since been released. It has become a standalone business and is doing good work. Also, the Omnibook service is a ‘booki.cc’ online service based on Booktype 2.
Booktype has been used by many organisations and individuals to produce books.
I think Booktype 2 is good software but I didn’t particularly like the direction of the Booktype UX after I left the project – it was becoming too ‘boxy’ and formal. ‘Good UX’ is not necessarily good UX. So I eventually developed another system with a much simpler approach, specifically for using with Book Sprints (but it has had other uses as well). More in this in a bit.
book.js
One innovation, and a further exploration of using the browser as a typesetting engine, that resulted from my time with Booktype is book.js. Essentially I had been looking for a new way to render books from HTML using the browser. I wanted to understand how Google docs could have a page in the browser and then render it to PDF with 1-to-1 accuracy. Surely the same could be done with books? However, no one could tell me how it was done. So I researched and eventually found out about the nascent CSS Regions that would allow you to flow text from one box to another in HTML. I worked with Remko Siemerink at a workshop in Amsterdam to explore PDF production from CSS. We made an interesting book with some of the Sandberg designers.
After more research and breaking down what I thought could happen, Remko worked with CSS Regions (& js) to replicate the page design of a book called “Open Design Now.” It was amazing. He got the complex design down plus it was all just HTML and CSS, it looked like a page AND when printed from the browser it retained a 1:1 co-relation. Awesome.
The following summer I was able to employ someone for Booktype to work on the tech and I hired a developer (Johannes Wilm) to work on the PDF rendering. From there we eventually had BookJS that enabled in-browser rendering of books which could then be exported to print-ready PDF by just printing from the browser. Whoot!
After time, BookJS (original site still available) could also formulate a table of contents etc. It was, and is, pretty cool and IMHO is the right way to do this. Unfortunately, Google Chrome decided to discontinue CSS Regions so if you now want to use BookJS you have to use a very old version of Google Chrome. However, better technologies have come along that support the same approach, namely Vivliostyle (which Johannes later worked on).
Github Editor
During the time with Booktype, I also did some experiments in other processes. One was using Github as the store for an EPUB and using the native zip export that Github offered to output EPUB (since EPUB is just a zip formatted in a specific way). Juan Gutierrez put together a quick demo and I published about it here:
http://toc.oreilly.com/2013/01/forking-the-book.html
Sadly the demo is no longer available but later a good buddy, Phil Schatz, adopted the idea and built something similar and (I think) much better:
http://philschatz.com/2013/06/03/github-bookeditor/
PubSweet 1
Since Booktype was going its own way, I wanted to develop a new, lighter, system for Book Sprints. Hence Juan and I worked out PubSweet, a simple PHP-based system. This would later be reformulated as a JavaScript system (see below).
PubSweet was very simple. Essentially 3 components – a dashboard, a table of contents manager, and an editor. It would later evolve to include more features but it was really the same as the systems I had developed earlier, though simpler. I wanted to get to a cleaner interface and bare basic features. I also wanted to retain some book elements, hence the table of contents manager looks a little like a book table of contents (except the garish colors ;).
PubSweet 1 is still in use by the Book Sprints team and functions well. It uses BookJS for rendering paginated books and for PDF rendering straight out of the system. It can also generate EPUB directly. Apart from that, it is pretty simple and effective. I used a basic card-based task manager for this, based on an earlier prototype I made when working with Booktype. It was a simple kanban type board but we never properly integrated it.
We included annotation using Nick Stennings Annotator project:
PubSweet 1 has been involved in producing more books than I can count, for everyone from OReilly books to Cisco, to the World Bank, UNECA, IDEA etc etc etc
PleigOS
Somewhere along the way, I developed a simple system for creating Pleigos – one-page books created by folding a single piece of paper which has text and images. The system places text and images so that when you fold a single page after printing, a small book is formed. It was more an artistic experiment than anything but it was fun.
http://www.pliegos.net/
Note: the Pleigos project was by my good friend Enric Senabre Hidalgo, I just developed the initial Pleigos software.
Lexicon
The UNDP approached me to build software for developing a tri-lingual lexicon of electoral terminology. The languages to be supported were English, French, and regional Arabic. It sounded interesting so I used PubSweet as the basis for this.
The main difference between Lexicon and PubSweet was that you could choose to create a chapter from 2 different types of editor. Editor 1 (‘WYSI’) was a typical WYSIWYG editor. This was used for producing chapters with prose. The second type of editor (‘lexicon’) allowed you to create a list of terms, each with three different translations – English, French, and Arabic. This opened my eyes to the possibilities of having different types of editors for different content types, a strategy I hope to use again.
The ‘lexicon’ editor in action
The final print output looked pretty good:
The system enabled a dozen or so people from different Arabic regions to discuss translations and work collaboratively through a list while at remote locations. We built a specific discussion forum for them as part of the system and had up and down voting etc. I liked this project a lot because it was very different from any other project I had worked on yet it employed many of the same strategies.
Aperta
Along the way I was approached by John Chodacki of PLOS to build a Journal system for them. I knew nothing about scientific journals, so I went through a process of re-education 🙂 It sounded interesting! I spent a year-and-a-half heading up a team to design and develop this system. This is pretty much the first time I wasn’t scraping together pennies to build a system.
Journal systems aren’t that different from book production systems, in fact doing this project helped me realise that the production of knowledge, in general, follows a particular high-level conceptual schema:
- produce
- improve
- manage
- share
Each artifact (journal article, chapter, book, issue, legislation, grant application etc) follows its own kind of path, with its own unique processes, through these four stages. I have written more about this elsewhere in this blog so won’t go into more detail about it here.
Research articles, (Aperta wasn’t initially intended to deal with Journal Issues which are a collection of articles) come into a Journal as (predominantly) MS Word. They then need to follow a process of checks (eg. to make sure the article is right for the journal etc) before going through the hands of various editors (handling editors, academic editors, etc) and reviewers, including a back-and-forth with the author(s) and a final pass through a production team and/or external vendor to prep the files for publication. The biggest difference I found from my previous experience with book production systems is that there is more to-and-fro involved. Simply put, there is more workflow. So Aperta addresses this with a simple workflow engine based on the Trello/Wekan kanban card-based model.
Aperta was built in Rails with Ember JS. The front end was pretty much decoupled from the backend. It was pretty ambitious and we decided to use the Wikimedia Foundations Visual Editor at the heart of the project. It was the most sophisticated editor available at that moment. I have come to learn that you have to take what you have at the time and work with it. We committed to adopt it and make contributions. I hired the Substance.io chaps (Michael and Oliver) to work on the editor. They did a great job. (Subsequent development of their own editor libs has enabled us to work with them for Coko (more below). )
Aperta’s approach was to simplify the submission process that was managed by Aries Editorial Manager. We leveraged the OxGarage project for MSWord-to-HTML conversion and imported the manuscripts into Aperta. Then workflow templates could be set using kanban cards (as per above). These cards then enabled a flexible method for gathering information (submission data) from the authors at submission time. A lot of time was spent on getting good clean, simple, UX. The kanban card system was very modular – the cards themselves were their own applications, enabling anyone to build a card to their own requirements. This made the cards extremely powerful as they were essentially portable applications.
Further, I developed a model of sorting a lot of cards into columns much like Tweetdeck’s saved-columns model. It was all rather neat. A ton of innovation. Unfortunately, I don’t have any screenshots apart from what I see PLOS has on their website:
http://journals.plos.org/plosbiology/s/aperta-user-guide-for-authors
http://journals.plos.org/plosbiology/s/file?id=d45b/Aperta-Quickstart.pdf
http://journals.plos.org/plosbiology/s/aperta-user-guide-for-reviewers
Aperta is in production now for PLOS Bio but unfortunately the code still isn’t available.
I think Aperta radically rethought how Journal workflows might be managed. I learned a lot through this process and it informed decisions and architecture for the next platform I was to work with – PubSweet 2, developed by Coko.
I also think taking a step into another realm where many concepts were transferable but the use case was different was very good for me. It helped me abstract a few notions. It was also good to build a sophisticated framework in another language and to have the resources to try things out. It was an excellent incubation period where I learned a lot while building a pretty good platform.
During this period I also developed a kind of Objavi 3 but I’m not sure now what it is called or if it is used.
PubSweet 2
The following systems are a result of a team of very talented people at Coko. This has been the first group of people that I have worked with that enable the systems to get close to what I believe is an ideal state for the problems at hand, the time we live in, and with the technology available. If I have learned one thing over the past years, it is that, generally speaking, development teams often prevent good solutions from happening. The Coko team is a rare case where the solutions can flourish and become what they need to be. I’m very lucky to be working with such people.
PubSweet 2 is not actually a publishing platform, it is a de-coupled JavaScript framework that enables the production of multiple publishing platforms.
With all the other platforms I have been involved with I have always learned something. So the next platform is always better. Strangely enough, because when I look back I remember, for example, thinking that Booki was the best platform ever, and perhaps the best I could do. But not so. Each subsequent platform has been much better. So… why not build a framework that enables the rapid development of many platforms at once? good idea! Imagine what you could learn… Indeed!
Using PubSweet, we have developed two platforms to date. Science Blogger and Editoria. For the purposes of this blog post I’ll just focus on Editoria as Science Blogger is more of a reference implementation. However, all these front components can be developed independently of each other, and independent of the core framework. Hence we have released some PubSweet NPM modules (sort of like front end plugins) online:
If you would like to read more about PubSweet check here:
http://slides.com/eset/ismte
Editoria
Editoria Book Builder component
What is interesting about Editoria is that I didn’t design it. I facilitated the staff at the University of California Press to design it. And what is really interesting is that it is a better book production software than any of the above that I did design…. That’s not to say that I finally realised I was a crappy designer 😉 , rather I came to realise that given the right guidance and parameters, the people with the problems can solve the problem with more deep understanding and nuance than I could as an outsider to their processes. It was a great thing to realise.
In general, Editoria follows the same model as PubSweet 1. It is a simple collection of 3 interfaces – dashboard, book builder (in PubSweet 1 we refer to it as a table of contents manager) and a chapter editor. Very similar to PubSweet 1 and also these components fit into the conceptual schema I mentioned above of:
- produce – this happens outside the system and we convert authored MS Word files to HTML
- improve – styling, editing, reviewing, all occurs in the editor component
- manage – basic workflow managed by the Book Builder component
- share – when done we export to book formatted PDF, and EPUB
Editoria is a very simple and elegant solution. It’s the only one of the systems I have worked with that is not in production but I’m looking forward to seeing it up and running soon.
It uses the Substance.io libraries to build a custom made and elegant editor. Finally with some real $ to spend on moving this field forward, and as part of my 2015 Shuttleworth Fellowship I committed $60,000 USD (10k a month) or so to Substance, Coko followed it by a similar amount, so they could focus on the development of their libraries to 1.0. Coko also put considerable effort into founding a consortium around Substance (although I’m not convinced it is really working well yet).
http://substance.io/consortium/
Editoria brings some nice implementations to the table including the use of Vivliostyle to render PDF from HTML. Plus MSWord-to-HTML conversion, front and back matter divisions plus body content. Pagination information (left/right breaking) etc. In addition, we are building into Editoria various tools in the editor including its own annotation system and a host of publisher-specific markup options for different styles (quotes, headings etc). Coko has employed Fred Chasen for some part time work to contribute to the Vivliostyle development (although we are still working out what we should work on).
In many ways, Editoria is the system I always wanted to be involved in. It is better than any other system I have seen or been involved in and this is a result of two critical factors:
- the technologies have matured, including Vivliostyle and Substance.io, that enable critical solutions to be solved
- the people who need the system have designed it
There is more to come from Editoria, so stayed tuned…
INK
INK is like Objavi on steroids. It is possibly an Objavi 4 😉 but done the right way. INK is a Rails-based web service which is primarily built to manage file conversions. However, it can actually be used for the management of any job you wish to throw at it. These jobs are what we call steps, and steps can be compiled into recipes. For example, you might have a step ‘convert MS word to HTML’ and then a second step ‘Validate HTML’. Hence INK enables you to chain together these steps.
Additionally, these steps are plugins written as Gems. A gem is a Ruby-based plugin architecture. Accordingly, you can develop gem steps and distribute them online for others to use. We hope in time there will be a free (as in beer) market around these steps.
Summary thoughts
I think I learned a lot from writing this personal ‘sense making’ piece. I didn’t realise just how strong some of the themes were that I pursued until a wrote them down…for example, I pursued collaborations from inter-organisational consortiums a number of times and none of them have worked. Huh. Interesting. I’ve also seen various practices evolve from an idea to being mature thoughts, prototypes, workable solutions and eventually, eventually, adopted. But over many more years than I expected. Also interesting.
It is also obvious that there are some big ticket technological problems that still need to be solved for good to really move forward. They are mostly there but still in need of work, the top two being:
- browser as typesetting engine
- sophisticated editor libraries
I add a third which I haven’t noted much in the above. I have worked on this since Aperta onwards and it is necessary only in the publishing world where content is authored in the legacy ‘elsewhere’ (ie MSWORD):
- reusable, sensible, MSWord to HTML conversion
This has been solved many times but has not yet been solved well.
These all need to be open source solutions. At Coko we are trying to move all these on and we are making good contributions. We, as a sector, are nearly there. Although it would be good to work more together to solve these problems by either making contributions to the existing efforts, or using their technologies. This is really the only way things move forward.
Finally, in the tech world people sometimes quote “Being too far ahead of your time is indistinguishable from being wrong,”. I’m not sure who said it but when I look through the evolution of technologies I have written about above, seeing various things evolve from idea to a production implementation many years later, I’m also thinking that perhaps sometimes waiting might be indistinguishable from being right 🙂
Leadership, diversity and sector change in open source
Examples of sector change
Community building begins with convincing people who don’t need to work together that they should.
– John Abele
Recently I have found some clues to these questions in the writings of John Abele (founder of Boston Scientific), particularly “[Bringing Minds Together]”(https://hbr.org/2011/07/bringing-minds-together). His writings have inspired me to look again at how I see Open Source.
Early in his career, John was involved with some technologies for non-invasive surgery. Today, such matters are handled day-to-day. Back then, however, surgery was invasive by definition. Back then, talk of non-invasive instruments for surgery would be like talking about screen-less phones today. Imagine trying to sell that.
So he had a hard time trying to sell a new idea that he knew could transform the medical sector. As he writes, “We were developing new approaches that had huge potential value for customers and society but required that well-trained practitioners change their behaviour. … Despite the clear logic behind the products we invented, markets for them didn’t exist. We had to create them in the face of considerable resistance from players invested in the old way and threatened with a loss of power, prestige, and money.”
That’s more-or-less what we face with Coko (Collaborative Knowledge Foundation) at the moment. Smart people that are under the painful burden of outdated workflows and technology often resist systemic change because it requires them to alter their normal ways of working. Their resistance to change is a huge problem if you wish to modernise the way knowledge is produced and reduce that burden on them.
In John’s case, he drew on some insights he had gathered early on in his career from Jack Whitehead, CEO of Technicon, a small company that had the patent for a new medical device. When trying to bring this product to market, Technicon had the odds stacked against them. No one, from the lab technicians through to the professional societies and manufacturers, wanted anything to do with it. So Jack drummed up some interest from early adopter types and came up with a surprising next step. He “told all interested buyers that they’d have to spend a week at his factory learning about it.”
That sounds like an odd sales pitch now, but back then (early 60s) apparently it sounded a whole lot more crazy. Nevertheless, Jack convinced a handful of excited early adopters to seize that day, and brought them into his factory.
During that week, the early adopters were not treated like customers but like partners. They were part of the team. They came to know each other, they worked together, they shaped the product. They became the team. As John says:
“When the week ended, those relationships endured and a vibrant community began to emerge around the innovation. The scientist-customers fixed one another’s machines. They developed new applications. They published papers. They came up with new product ideas. They gave talks at scientific meetings. They recruited new customers. In time, they developed standards, training programs, new business models, and even a specialised language to describe their new field.”
This meeting of once potential customers, now team members, not only contributed to the design of the technology but then took it out into the world and fueled adoption and interest in the product. What had humble roots with a group of early adopters was on its way to creating large-scale change.
John witnessed this process and realised this was strategy, not whimsy: “[Jack] was launching a new field that could be created only by collaboration — and collaboration among people who had previously seen no need to work together.”
John went on to form Boston Scientific and refined this strategy further with Andreas Gruentzig when introducing the balloon catheter to a hostile and uninterested market. Again he was successful in catalysing large-scale change.
Astonishing. But you could have told the same story about any number of successful Open Source projects. Indeed, John reflects on the parallels to Open Source :
“Just as Torvalds helped spawn the Open Source movement, and Jimmy Wales spearheaded the Wiki phenomenon, Andreas [Gruentzig] created a community of change agents who carried his ideas forward far more efficiently than he could have done on his own.”
The strategy in both cases started with a simple idea – to create a community of change agents.
Leadership
Leaders need to cede control, not vigorously exert it.
– John Abele
The creation of a community where collaboration can flourish is a product of a particular kind of leadership – what John calls ‘collaborative leadership’. I have also seen this in many places including Open Source, Unconferences, and Book Sprints (which I founded). In the latter two cases, we call the collaborative leader a facilitator.
There are many modes of facilitation and choosing the right characteristics, the right mode, to create the right environment, is critical. John gives some interesting tips on what this mode looks like. The characteristics that I have gleaned from his article include the ability to:
- foster “collaboration among people who had previously seen no need to work together”
- manage egos
- earn trust
- respect stakeholder interests
- be authentic
- “listen, share, and ask good questions”
- share the credit
- use “we” not “I”
- support the choice of ‘alternative methods’
- create rituals
- create non-traditional spaces and experiences to come together
- ensure people “feel like partners”
- be willing to take direction from the ‘customer-participants’
- build trust over control
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
A good facilitator knows this language and these modes and can apply them but there are different requirements for facilitation depending on what you are trying to achieve. Book Sprint facilitation, for example, is much more product- orientated (books) than Unconference facilitation and requires a different set of strategies and tools. Most of the issues above I would categorise as being general rules of facilitation, however, those that modes that hint at enabling a group to create llarge-scalechange are the most interesting here. I think the last four points are telling:
- be willing to take direction from the ‘customer-participants’
- build trust over control
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
The most important issue at stake here is for the facilitator to create the space so others will come up with the product solution. This kind of facilitation creates vacuums, spaces where solutions don’t yet exist. This kind of facilitation is focused on a diverse range of stakeholders to design the product. This kind of facilitator doesn’t have all the answers but instead highlights problems and brings people together to create the solutions. Typical facilitation modes are necessary to enable an environment of trust and sharing, but enabling the participants to own the problems and create the productized solution requires a very specific mode of facilitation.
Can Open Source do this?
Open source software is about people.
– Sacha Greif
While these examples are about proprietary technology. It is not the proprietary-ness at stake here, it is the process that is important – and good process is the product of good facilitation. Often there is facilitation active in Open Source projects, but not necessarily, and where it does exist it is not typically with the kind of framing John has pioneered. Sure projects want people to use their software, they want to be sustainable, they don’t want to do all the work, they want community. However, Open Source projects are typically interested in bringing in more developers and not necessarily on fueling wide scale adoption (as odd as that may sound), and this informs the kind of people involved and the facilitation strategy employed.
There is a great article by Telescope founder Sacha Greif that illustrates this quite well. Sacha writes – “So why did I decide to make Telescope open source in the first place? It’d be easy to answer with typical clichés about “giving back to the community” or “believing in free software”….But the truth is a lot more pragmatic and selfish: I thought it would be a good way to get other people to help me accomplish my own goals, for free.”
Sacha goes on something of a journey with Telescope, undertaking some course corrections, and concludes “when it comes to Open Source software, software actually plays a fairly minor role. Open Source software is about people.”
I think this illustrates quite nicely where the mindset of open source projects generally are. Sacha went past the ideal of ‘build it and they will come’, a very tech-centric way of seeing things, through to understanding that the secret to success for an Open Source project lies with people, not technology. Sacha transitioned from developer to facilitator.
That is very laudable. However, facilitating developers to build your technology, is very different from facilitating a diverse set of stakeholders to develop a product, fuel adoption, changing user behaviors and putting your project on the path to creating wide scale change. The later requires involving different stakeholders and it involves a different mode of facilitation.
This is where Open Source is getting in its own way. Open source is about employing the right tools, facilitation included, to expand your developer base. That’s fine if you are building the plumbing – Open Source libraries, under-the- hood services, backend functionality etc can all be built well using this kind of method. However, if you want to be part of a team that creates wide scale change through a user-facing product, then I would suggest that open source as a culture-methodology is not the way to do it. Open Source is, at its heart, a techno-meritocratic culture. Great for building under- the-hood tools (builders building for other builders), terrible for producing products.
This shouldn’t be surprising. Somehow, however, it is. But then again when we look closely it sort of makes sense…Even the term ‘Open Source’ expresses just how much the code and those that make it form the core orientation and value metrics. Additionally, in a typical Open Source project, the person at the top isthe person with all, or most of, the technical answers (in a techno-meritocratic culture you can only not know so much before you ain’t the boss anymore). The famed benevolent dictator. And they are the culture keepers, the arbitrators, the facilitators. This sets the scene for a particular kind of facilitation that privileges the involvement of those with technical skills over anyone else. This all points to a certain kind of mono-cultural community.
To see a good example of this have a look at this post about Octocat. The entire emphasis of this article is to find ways to celebrate ‘non-code’ contributions. The term ‘non-code’ in itself is an indicator that anything other than code only has value by association (imagine a manager in any industry thanking a group of workers for their ‘non-management contributions’). Octocat was developed to measure ‘non-code contributions’ and to be effective ‘non-coders’ must log their activities in the projects issue tracker. Hence all contributors must use the same tools that the developers use. Octocat is a good project but it highlights just how focused the entire culture of Open Source is on technical development and needs everyone to fit into that paradigm. I believe this is at the cost of the product, adoption, and the potential change the product could make if managed differently.
Diversity
“Diversity creates better projects. So, why aren’t designers participating in open source?” – Una Kravets
So, what must open source change to enable a project to create massive change? Open source requires a different kind of culture. Open source must diversify away from technocratic meritocracy to become diverse communities of stakeholders. Unfortunately just the opposite is happening – ‘non-coders’ are being chased away in droves.
This is not new news. Open source has sort of known there was something wrong with its culture for sometime. The wholesale migration to closed source desktops (Apple) by the open source development world highlights this. Why did we see this enormous migration? Because OSX is ‘nicer to use’. That tells us something. Open Source has generally failed on user experience (I must note that I do not believe that to be the case now for open source desktops) and it has failed because Open Source culture is not inclusive of designers. The mono-culture has very firm boundaries for what it can do well, and it cannot provide good UX unless it diversifies.
Una Kravets has done a very nice presentation about these issues. In this presentation Una goes into detail of why designers are not involved in open source and how to enable the conditions to improve participation.
The point here is that it is not just a question about representation (and the shockingly low numbers of women involved), it is also a question of the health of a product. As Una has argued well ‘diversity creates better projects’. I would like to take that one step further and suggest that diversity not only creates better projects, it creates better conditions for wide scale adoption and change. To develop a successful product you need to have the customers designing the solution, you need UX designers to finesse the interactions, designers to make it look great, evangelists to present it at conferences, you need developers to do the plumbing, you need users for the feedback, and you need facilitators that can bring all these people together and enable them to function as a passionate, problem-solving, engaged whole. To do that, all those people need to be drawn from a diversity of contexts, valued equally, and they must all have a say in what it is that is being created. You need what John Abele calls ‘a community of change agents,’ not a community of developers.
Involving and privileging only developers is not the right kind of culture to achieve success with a product. We must do away with the techno-meritocratic culture of Open Source and replace it with a more change-centric paradigm – the community of change agents. The root of this new kind of product development culture requires a specific kind of facilitation (‘collaborative leadership’), and the passionate involvement of a diverse set of stakeholders.
The writings of John Abele have led me through a curious journey. While I was always troubled by the technocratic nature of Open Source, I figured it was a transformational movement and I would figure out a way to exist within in it and assist where I could. However, I am now seeing very clearly that, while there are individual exceptions, Open Source as a movement has its own hard coded limits. Unfortunately, these are limits that stunt effectiveness and the ability to create wide scale change, especially with the user-facing products. Unfortunately, the Open Source movement itself is barely cognizant of these limitations, why they exist, and how they could be removed.
Coda for the trolls
It probably won’t help moderate your responses but just in case… a bit of a background of where I am coming from. I love Open Source, I think it has done amazing things. I am a free license and free culture advocate. I started communities of free documentation writers to support Open Source, have initiated many software projects – all Open Source – and contributed in humble ways to others. The Open Source projects I work in now use entirely open source tools. I have supported free culture campaigns with my own time and money including (most recently) The Cost of Freedom. I have lived and breathed Open Source for about the last 20 years. I haven’t used any other desktop since 2000 or so, and have belonged to, and worked with, many hacker collectives. I don’t intend to give up on Open Source any day soon, but I do intend to do what I can to make it better, however small that contribution might be.
*original article and history here https://www.adamhyde.net/open-source-is-not-about-people-or-technology-its-about-change/ *
With thanks to Andrew Rens for great feedback, and Steve Song for some inspiring asides.
Open Source is not about technology, or people, it’s about change
https://www.adamhyde.net/leadership-diversity-and-sector-change-in-open-source/
v 0.5.1 – Feb 3 “clean up”
v 0.5 – Feb 2 “rewrite, thanks to Andrew Rens”
v 0.4 – Jan 31 “add facilitation mode on product dev”
v 0.3 – Jan 30 “added more detail on good collaboration”
v 0.2 – Jan 29 “some lessons for open source added”
v 0.1 – Jan 28
needs more content, fact checking, structure. Be patient with me! Will improve it in the next days
[new working title]
Leadership, diversity and sector change in open source
Recently I have been pondering how sector change is possible. Sector change, specifically to change the publishing sector, is a key goal of mine. I don’t want to be involved in just improving it, I want to change it completely – so even the language we use to describe what was once “publishing” is shifted into another domain, namely knowledge production.
But how to do such a thing? How can you shift an entire sector sideways and rewrite processes, tools, value systems, expectations, career paths, language? The whole works.
Examples of sector change
Community building begins with convincing people who don’t need to work together that they should. - John Abele
Recently I have found some clues to these questions in the writings of John Abele (founder of Boston Scientific), particularly “Bringing Minds Together“. His writings have inspired me to look again at how I see open source.
Early in his career, John was involved with some technologies for non-invasive surgery. Today the stuff is day-to-day. Back then, surgery was invasive by definition. Back then, talk of non-invasive instruments for surgery would be like talking about screen-less phones today. Imagine trying to sell that.
So, he had a hard time trying to sell a new idea that he knew could transform the medical sector. As he writes, “We were developing new approaches that had huge potential value for customers and society but required that well-trained practitioners change their behaviour. … Despite the clear logic behind the products we invented, markets for them didn’t exist. We had to create them in the face of considerable resistance from players invested in the old way and threatened with a loss of power, prestige, and money. ”
This is what we face with Coko (Collaborative Knowledge Foundation) at the moment. Smart people that are under the painful burden of outdated workflows and technology are often resistant to change because it requires them to change their behaviours. It is a huge problem if you wish to modernise the way knowledge is produced and reduce that burden on them.
In John’s case, he drew on some insights he had gathered early on in his career from Jack Whitehead, CEO of Technicon, a small company that had the patent for a new medical device. When trying to bring this product to market, Technicon had the odds stacked against it. No one from the lab technicians, through to the professional societies and manufacturers, wanted anything to do with it. So Jack drummed up some interest from early adopter types and came up with a surprising next step, he “told all interested buyers that they’d have to spend a week at his factory learning about it.”
That sounds like an odd sales pitch now, but back then (early 60s), apparently it sounded a whole lot more crazy. However, Jack convinced a handful of excited early adopters to take that step, and brought them in.
In this week, the early adopters were not treated like customers but like partners. They were part of the team. They came to know each other, they worked together, they shaped the product. They became the team. As John says:
“When the week ended, those relationships endured and a vibrant community began to emerge around the innovation. The scientist-customers fixed one another’s machines. They developed new applications. They published papers. They came up with new product ideas. They gave talks at scientific meetings. They recruited new customers. In time, they developed standards, training programs, new business models, and even a specialized language to describe their new field.”
This meeting of once potential customers, now team members, not only contributed to the design of the technology but then took it out into the world and fueled adoption and interest in the product. What had humble roots as a group of early adopters, was on its way to creating large-scale change.
John witnessed this process and realized this was strategy not whimsy: “[Jack] was launching a new field that could be created only by collaboration—and collaboration among people who had previously seen no need to work together.”
John went on to form Boston Scientific and refined this strategy further with Andreas Gruentzig when introducing the balloon catheter to a hostile and uninterested market. Again he was successful in catalyzing this kind of large-scale change.
Astonishing. You could have told the same story about any number of successful open source projects. Indeed, John reflects on the parallels to open source:
“Just as Torvalds helped spawn the open source movement, and Jimmy Wales spearheaded the Wiki phenomenon, Andreas [Gruentzig] had created a community of change agents who carried his ideas forward far more efficiently than he could have done on his own.”
The strategy in both cases started with a simple idea – to create a community of change agents.
Leadership
Leaders need to cede control, not vigorously exert it. - John Abele
The creation of a community where collaboration can flourish is a product of a particular kind of leadership – what John calls ‘collaborative leadership’. I have also seen this in many places including open source, unconferences, and Book Sprints (which I founded). In the later two cases we call the collaborative leader a facilitator.
There are many modes of facilitation and choosing the right characteristics, the right mode, to create the right environment is critical. John gives some interesting tips on what this mode look like. The characteristics that I glean from his article includes the ability to:
- foster “collaboration among people who had previously seen no need to work together”
- manage egos
- earn trust
- respect stakeholder interests
- be authentic
- “listen, share, and ask good questions”
- share the credit
- use “we” not “I”
- support the choice of ‘alternative methods’
- create rituals
- create non-traditional spaces and experiences to come together
- ensure people “feel like partners”
- be willing to take direction from the ‘customer – participants’
- build trust over control
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
A good facilitator knows this language and these modes and can apply them but there are different requirements for facilitation depending on what you are trying to achieve. Book Sprint facilitation, for example, is much more product-orientated (books) than Unconference facilitation and requires a different set of strategies and tools. Most of the issues above I would categorize as being general rules of facilitation, however those modes that hint at enabling a group to create large-scale change are the most interesting here. I think the last four points are telling:
- be willing to take direction from the ‘customer – participants’
- build trust over control
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
The most important issue at stake here for the facilitator is to create the space so others will come up with the product solution. This kind of facilitation creates vacuums, spaces where solutions don’t yet exist. This kind of facilitation is focused on a diverse range of stakeholders to design the product. This kind of facilitator doesn’t have all the answers but instead highlights problems and brings people together to create the solutions. To do this, typical facilitation modes are necessary to enable an environment of trust and sharing while enabling the participants to own the problems and create the productized solution. This comprises a very specific mode of facilitation.
Can Open Source do this?
Open source software is about people. - Sacha Greif
While these examples are about proprietary technology, it is not the proprietariness at stake here, it is the process that is important – and good process is the product of good facilitation. While facilitation is active in many open source projects, it is not necessarily so, and where it does exist it is not typically with the kind of framing John has pioneered. Sure projects want people to use their software, they want to be sustainable, they don’t want to do all the work, they want community. However, open source projects are typically interested in bringing in more developers yet not necessarily on fueling wide-scale adoption (as odd as that may sound) and this informs the kind of people involved and the facilitation strategy employed.
There is a great article by Telescope founder Sacha Greif that illustrates this quite well. Sacha writes – “So why did I decide to make Telescope open source in the first place? It’d be easy to answer with typical clichés about “giving back to the community” or “believing in free software”….But the truth is a lot more pragmatic and selfish: I thought it would be a good way to get other people to help me accomplish my own goals, for free.”
Sacha goes on something of a journey with Telescope, undertaking some course corrections, and concludes “when it comes to open source software, software actually plays a fairly minor role. Open source software is about people.”
I think this illustrates quite nicely where the mindset of open source projects generally are. Sacha went past the ideal of ‘build it and they will come’, a very tech-centric way of seeing things, through to understanding that the secret to success for an open source project lies with people, not technology. Sacha transitioned from developer to facilitator.
That is very laudable. However, facilitating developers to build your technology is very different from facilitating a diverse set of stakeholders to develop a product, fuel adoption, change user behaviours and put your project on the path to creating wide- scale change. The later requires involving different stakeholders and it involves a different mode of facilitation.
This is where open source is getting in its own way. Open source is about employing the right tools, facilitation included, to expand your developer base. That’s fine if you are building the plumbing – open source libraries, under the hood services, back end functionality, and so on can all be built well using this kind of method. However, if you want to be part of a team that creates wide scale change through a user-facing product, then I would suggest that open source as a culture-methodology is not the way to do it. Open source is, at its heart, a techno-meritocratic culture. Great for building under the hood tools (builders building for other builders), terrible for producing products.
This shouldn’t be surprising. Somehow however it is. But then again when we look closely it sort of makes sense…Even the term “Open Source” expresses just how much the code and those that make it form the core orientation and value metrics. Additionally, in a typical open source project, the person at the top is the person with all, or most of, the technical answers (in a techno-meritocratic culture you can only not know so much before you ain’t the boss anymore- and become the famed benevolent dictator. And they are the culture keepers, the arbitrators, the facilitators. This sets the scene for a particular kind of facilitation that privileges the involvement of those with technical skills over anyone else. This all points to a certain kind of mono-cultural community.
To see a good example of this, have a look at this post about Octocat. The entire emphasis of this article is to find ways to celebrate ‘non-code’ contributions. The term ‘non-code’ in itself is an indicator that anything other than code only has value by association (imagine a manager in any industry thanking a group of workers for their ‘non-management contributions’). Octocat was developed to measure ‘non-code contributions,’ and to be effective ‘non-coders’ must log their activities in the projects issue tracker. Hence all contributors must use the same tools that the developers use. Octocat is a good project but it highlights just how focused the entire culture of open source is on technical development and wants everyone to fit into that paradigm. I believe this is at the cost of the product, adoption, and the potential change the product could make if managed differently.
Diversity
"Diversity creates better projects. So, why aren't designers participating in open source?" - Una Kravets
So, what must open source change to enable a project to create massive change? Open source requires a different kind of culture. Open source must diversify away from technocratic meritocracy to become diverse communities of stakeholders. Unfortunately just the opposite is happening – ‘non-coders’ are being chased away in droves.
This is not new news. Open source has sort of known there was something wrong with its culture for sometime. The wholesale migration to closed source desktops (Apple) by the open source development world highlights this. Why did we see this enormous migration? Because OSX is ‘nicer to use’. That tells us something. Open source has generally failed on user experience (I must note that I do not believe that to be the case now for open source desktops) and it has failed because open source culture is not inclusive of designers. The mono-culture has very firm boundaries for what it can do well, and it cannot provide good UX unless it diversifies.
Una Kravets has done a very nice presentation on these issues. In this presentation, Una goes into detail why designers are not involved in open source and how to enable the conditions to improve participation.
The point here is that it is not just a question about representation (and the shockingly low numbers of women involved), which is an effort we should all support in its own right, it is also a question of the health of a product. As Una has argued well, ‘diversity creates better projects’. I would like to take that one step further and suggest that diversity not only creates better projects, it creates better conditions for wide-scale adoption and change. To develop a successful product, you need to have the customers designing the solution, you need UX designers to finesse the interactions, designers to make it look great, evangelists to present it at conferences; you need developers to do the plumbing, you need users for the feedback, and you need facilitators that can bring all these people together and enable them to function as a passionate, problem-solving, engaged whole. To do that , all these people need to be drawn from a diversity of contexts, valued equally, and they must all have a say in what it is that you are creating. You need what John Abele calls ‘a community of change agents,’ not a community of developers.
Involving and privileging only developers is not the right kind of culture to achieve success with a product. We must do away with the techno-meritocratic culture of open source and replace it with a more change-centric paradigm – the community of change agents. The root of this new kind of product development culture requires a specific kind of facilitation (‘collaborative leadership’), and the passionate involvement of a diverse set of stakeholders.
Summary
I love open source, I think it has done amazing things. I am a huge free license and free culture advocate. I started communities of documentation writers to support open source, have initiated many software projects – all open source – and contributed in humble ways to others. However, the writings of John Abele have lead me on a curious journey. While I was always troubled by the technocratic nature of open source, I figured it was a transformational movement and I would figure out a way to exist within in and assist where I can. However, I am not seeing very clearly, that, while there are individual exceptions, open source as a movement has its own hard-coded limits. Unfortunately, these are limits that stunt its effectiveness and its ability to create wide-scale change, especially with user-facing products. Unfortunately, the open source movement itself is barely cognizant of these limitations, why they exist, and how they could be removed.
tbc
older version:
Recently I have been pondering how sector change is possible. Sector change, specifically to change the publishing sector, is a key goal of mine. I don’t want to be involved in just improving it, I want to change it completely – so even the language we use to describe what was once ‘publishing’ is shifted into another domain, namely knowledge production.
But how to do such a thing? How can you shift an entire sector sideways and rewrite processes, tools, value systems, expectations, career paths, language. The whole works.
It seems to me that the critical methodologies for wide-scale change like this are ‘almost native’ to open source. I’ll explain the ‘almost’ in a bit. But as an opener, open source has the ability to produce massive change. I don’t mean that open source can change the way that software is produced, we all know that. I mean the strategy for running a successful open source project is the same strategy you should adopt if you are trying to enable change, or massive change – of a sector, for example. I’m kind of surprised to arrive at this conclusion. I always loved open source but I am starting to realise that I have loved it for the wrong reasons.
Over the last 20 years or so of being involved in open source I have felt myself in a kind of continual falling forward into open source values. Who can’t love open source when you get down to it? The idea that software should be available to anyone that wants it, to do with it as they please. Its a great idea. It is about empowerment and that is something powerfully valuable it itself.
Empowerment through open source occurs because people have access to free tools and for this to happen we need generous tool makers. That highlights more good values active in open source, namely sharing. The fact that the technically gifted have brought these tools into our lives and generously shared them for free is something we should celebrate.
Of course, the sharing has its own reward system and isn’t all altruistic. Paid programmers building everything from Facebook to the technology that runs your dentist’s office systems (a reference to this ridiculous article in case you missed it) could not do their work without all the open source libraries they can handily import for free into their projects. Also, to ensure they don’t have to do the same work again in other projects, possibly for different clients or employers, they also share what they build (where possible). By reusing your own work and that of others like this, the total workload is then also decreased and people can get further faster. Progress can be made. Programmers can also enhance their reputations if their work is re-used by other programmers. This becomes value in the market place. Hence this sharing has turned into an economy. It’s a good one, who couldn’t love an economy that encourages sharing? This economy also makes many open source software projects sustainable so the whole system has a beautiful internal logic.
The openness of all this is also something to be valued. Exposing the code to all eyes is a famous strategy for reducing bugs. It’s also touted as a strategy for increasing security. It also means programmers can learn from code developed by others (both the good and the bad). Openness and transparency also have a lot of utility in this world, and open source has proven this utility time and time again. Openness is not only good for the code, but it makes us feel good (if we are not too tainted by the proprietary way of life).
Then there is community. You can’t go far into a conversation about open source without mentioning community. Community is the metric for the well-being of any open source project and seeing a healthy open source community is a sight to behold. It is astonishing. All these people somehow, impossibly, co-ordinating to pull in (more or less) the same direction. Good governance plays a role in this after a certain threshold of participants has been exceeded and good governance in itself is quite miraculous to consider. How do the guardians make the wise decisions necessary to balance participation and technical development, uptake, funding, systems, protocols, agreements…the whole works. To consider the day-to-day decisions, project leads must need to make and the context in which they operate is quite dizzying.
I love all of this.
These are many of the reasons I have loved open source. I mean, who couldn’t love sharing, transparency and community? Well, there are actually many, many other values! But I want to think of the open source developers as very cold-hearted. I still believe in good guys and bad guys – the world is more fun that way, more energising. However, as much as I love open source, I think I have been in love with it for the wrong reasons.
How did I get to this realisation?
Recently I have been reading the writings of John Abele (founder of Boston Scientific). This has lead me down another path and provided me with fresh lens through which to value open source. Strange for me as I am allergic to proprietary-ness and John Abele is a good proprietary citizen. Ranked high on the Forbes rich list – net worth 600 million I believe – John has made a lot of money from Intellectual Property, specifically via the sale of medical instruments.
So, why did this entrepreneur, with whom I would initially assume I would share few values, inspire me to look again at how I valued open source? Well…it all comes down to the fact that John did achieve wide scale, sector-wide, change and he did it in a way that is radical to proprietary culture, but I would consider more native, almost native perhaps, to open source.
Early in his career, John came up with some technology for non-invasive surgery. Today the stuff is day to day. Back then surgery was invasive by definition. Talk of non-invasive instruments for surgery back then would be like talking about screen-less phones today. Imagine trying to sell that.
So, he had a hard time trying to sell a new idea that he knew could transform the medical sector. He did transform a sector, so how did he do it?
John has written quite a bit on how he was able to do this, in particular he writes a lot about collaboration and even brought a conference center specifically to change it into a center for collaboration. But it is his ideas on change that most interest me. His article in this HBR article “Bringing Minds Together” gives some good insights. In this article John speaks of how openness can accelerate adoption where ‘walled’ processes have failed:
https://hbr.org/2011/07/bringing-minds-together
I really encourage you to read that article, I summarise it in part below but the full article is well worth reading.
As he writes:
“We were developing new approaches that had huge potential value for customers and society but required that well-trained practitioners change their behavior. … Despite the clear logic behind the products we invented, markets for them didn’t exist. We had to create them in the face of considerable resistance from players invested in the old way and threatened with a loss of power, prestige, and money. ”
So to overcome this John drew on some insights he had gathered early on in his career from Jack Whitehead, CEO of Technicon, a small company that had the patent for a new medical device. When trying to bring this product to market Technicon had the odds stacked against them. No one from the lab technicians, through to the professional societies and manufacturers wanted anything to do with it. So Jack drummed up some interest from early adopter types and came up with a surprising next step, he “told all interested buyers that they’d have to spend a week at his factory learning about it—and that payment was required in advance.”
That sounds like an odd sales pitch now, but back then (early 60s) apparently it sounded a whole lot more crazy. However, Jack found this handful of excited early adopters and brought them in.
In this week the early adopters were not treated like customers but like partners. They were part of the team. They came to know each other, they worked together, they shaped the product. They became the team. As John says:
“When the week ended, those relationships endured and a vibrant community began to emerge around the innovation. The scientist-customers fixed one another’s machines. They developed new applications. They published papers. They came up with new product ideas. They gave talks at scientific meetings. They recruited new customers. In time, they developed standards, training programs, new business models, and even a specialized language to describe their new field.”
They were on the way to creating large-scale change.
John witnessed this and realized that this was no one-off but “something much bigger was actually going on. [Jack] was launching a new field that could be created only by collaboration—and collaboration among people who had previously seen no need to work together. ”
Astonishing. You could have told the same story about any number of successful open source projects. Indeed after applying this strategy with Andreas Gruentzig some years later with Boston Scientific, introducing the balloon catheter to a hostile and uninterested market, John reflects on the parallels to open source:
“Just as Torvalds helped spawn the open source movement, and Jimmy Wales spearheaded the Wiki phenomenon, Andreas [Gruentzig] had created a community of change agents who carried his ideas forward far more efficiently than he could have done on his own.”
The strategy in both cases was simple. To create a community of change agents.
The change agent meeting became something of a user group, which in turn became a regular symposium, which then grew in size and prestige that it rivaled the established legacy events.
I feel compelled to note that the kind of product development we are talking about here is qualitatively different from developing a product for an organisation. Product development for a sector and creating large scale change is what this post is investigating.
There are many factors that play into the success of this approach. John Abele doesn’t go into detail what these are but he gives some hints, notably the creation of a culture of what he calls ‘leader – followers’ and a specific kind of ‘collaborative leadership’.
I think by ‘leader – followers’ he is referring a culture where everyone has the opportunity to be heard and to participate in the development of the solutions at stake. This kind of environment is what I would describe as strong collaboration and the interesting thing about this kind of approach is that it creates a strong feeling of shared ownership of the output. Who it is that owns the product, who are the best kinds of candidates to make up this group, so that they can go forward and take the product into the world, is a very interesting question and there might be some lessons to be learned here for open source.
John Abele doesn’t provide much detail in his article as to the desired make-up of this group. Beyond stating that they are potential customers there is very little detail on who these people are. It is interesting that they are customers however as this reflects a lot of the ‘itch to scratch’ mantra of the open source world – get people that have a problem to create the solution. However there might be something of an unintended but interesting critique here for open source. The open source world, it might be argued, leans too heavily on programmer involvement and does not necessarily directly involve the people that have the problem – the users – to design the solution.
The creation of a collaborative environment, in turn, is a product of collaborative leadership, which I have also seen in many places including open source and in Book Sprints (which I founded). In the later case we call the collaborative leader a facilitator.
Facilitation is a good art to place at the center of this strategy to create change and I far prefer this framing (‘collaborative leadership’ is a fine term but I think not many people know what this means, whereas I think ‘facilitator’ has much more currency) than those that exist in the open source world ie. ‘cat herder’ or ‘benevolent dictator’. These roles in open source are applied to co-ordinating programmers, and this highlights the techno-meritocratic approach that open source projects tend to subscribe to. Once again, the open source world could be criticized as too closely marrying this leadership to technical expertise. In the cases John outlines, the leaders don’t seem to necessarily have deep technical skills (although they appear to have a hand in the technical development), but they do have strong facilitation skills.
There are many modes of facilitation. Choosing the right characteristics, the right mode, to create the right environment is critical. John gives some interesting tips on what this might look like. The characteristics that I glean from his article includes the ability to:
- foster “collaboration among people who had previously seen no need to work together”
- manage egos
- earn trust
- respect stakeholder interests
- be authentic
- “listen, share, and ask good questions”
- share the credit
- use “we” not “I”
- be willing to take direction from the ‘customer – participants’
- support the choice of ‘alternative methods’
- build trust over control
- create rituals
- create non-traditional spaces and experiences to come together
- make people “feel like partners”
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
A good facilitator knows this language and these modes and can apply them but it is good to recognise that there are different requirements for facilitation depending on what you are trying to achieve. Book Sprint facilitation, for example, is much more knowledge product (books) orientated than Unconference facilitation and requires a different set of strategies and tools. Most of the issues above I would categorise as being general rules of facilitation, however those that are specific to the kind of product-orientated process designed to enable large scale adoption and change are the most interesting. I think the last two points are pointing in this direction:
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
The most important issue at stake here for the facilitator of this kind of project is to create the space so others will come up with the product solution. Don’t have all the answers, instead identify problems and bring people together to create the solutions. To get to that point the typical facilitation modes are necessary to enable an environment of trust and sharing but enabling the participants to own the problems of a product and create the solutions is slightly different from other facilitation modes.
This is the key ingredient, I believe, to the kind of processes that John and colleagues have pioneered and others have made the same observation. The quote below is taken from here:
http://www.kornferry.com/institute/709-growth-through-collaboration-john-abele-s-vision
“…Abele’s success at Boston Scientific was built upon his ability to bring together extremely competitive intellects and create an environment where participants could meet and be candid about what they were working on, including the new techniques, the risks, the benefits and the strategies they employed…’It was about really sharing what they were learning rather than lecturing about what they were teaching’ Abele said. ‘That was powerful because it really accelerated the development of these new technologies in health care — such as revolutionary steerable catheters — and I believed there must be more opportunities to apply this collaboration in a lot of different areas.'”
While these examples are about proprietary technology. It is not the proprietariness at stake here, it is the process that is important – the methods you use to enable early engagement with a wide diversity of stakeholders, bring them into the team, and enable them to be part of the product development. As the passage above states this is a default almost native methodology for open source but also found in the proprietary world. I say ‘almost native’ because I don’t think that this particular framing is the modus operandi for most open source projects, especially those starting out. Sure projects want people to use their software, they want to be sustainable, they don’t want to do all the work, they want community. Most open source projects start off thinking this way but few develop their thinking beyond this starting point, as this beautiful article by Telescope founder Sacha Greif states well:
https://medium.com/@sachagreif/open-source-lessons-learned-two-years-of-telescope-be4ed955b39
Sacha writes – “So why did I decide to make Telescope open source in the first place? It’d be easy to answer with typical clichés about “giving back to the community” or “believing in free software”….But the truth is a lot more pragmatic and selfish: I thought it would be a good way to get other people to help me accomplish my own goals, for free.”
Sacha goes on something of a journey with Telescope, undertaking some course corrections, and concludes “when it comes to open source software, software actually plays a fairly minor role. Open source software is about people.”
I think this illustrates quite nicely where the mindset of open source projects generally are. Sacha went past the ideal of ‘build it and they will come’, a very tech-centric way of seeing things, through to understanding that the real secret to success for an open source project lies with people, not technology.
That is very laudable. However, thinking about how to get people involved to build your technology, is very different from thinking about what you do as a methodology for creating change. I would say one particular issue at stake here is who you involve. If you want to create a technical product, you try and engage developers. If you are trying to create change, you must engage a much wider group of stakeholders.
Open source is a strategy, and a proven one, for product development. All the standard lessons have been learned for this, if not universally shared. Openness, sharing, community can lead to a healthy open source project. However these methods are not only about how the product is developed and who is developing it, but they are the basic tools necessary to create change. When wielded right, these strategies can, and have, lead to large-scale change as John Abele has already proven more than once in his life time and as we have seen with some open source projects.
Although I’m very much in love with the many values of open source I am more interested in their ability to create change which I think is an under considered effect. Its not that creating change is the only thing that should be considered but rather it is a lens that must be considered. It is as important to look at your open source project as a strategy for creating change (which, whether you own it or not, you are trying to do) as much as it is important to see it as being about technology and people.
This is a new realization for me. It opens a lot of doors. It perhaps explains, for example, why many open source projects do not succeed. The famous ‘build it and throw it over the wall’ strategy, for example, that so often leads to a lack of adoption and eventual failure. It perhaps presents an argument that the success of a project aimed at large-scale adoption and change is reliant on the involvement of a diverse range of stakeholders – changemakers not just programmers. It explains why open source is good at developing libraries and tools for other programmers but not necessarily very good at producing platforms for non-programmers. It also explains why other projects succeed even if they are not conscious of this framing.
This is, as if it had to be said, extremely important for publishing right now, or ‘knowledge production’ as I would prefer to talk about it, since sector change is what we need as workflows and outputs are still stuck in (what one may call) ‘post-paper’ processes and thinking. Open source can change this sector if viewed as a strategy for creating change. Massive change. However, if you want change to be native to your open source project, you have to own it. And that’s what I intend to do from now on.
Projects
Some of my projects. As you can see, partially complete. Will add more and then make this a static page.
Publishing-related
Collaborative Knowledge Foundation
Current
The Collaborative Knowledge Foundation’s mission is to evolve how scholarship is created, produced and reported. CKF is building open source solutions in scholarly knowledge production that foster collaboration, integrity and speed.
CKF envisions a new research communication ecosystem that gives rise to wholly unique channels for research output.
CKF was founded in October 2015 with support from the Shuttleworth Foundation.
Shuttleworth Foundation
Current
I have just been awarded a Shuttleworth Foundation Fellowship. I’m deeply honoured to have been selected. I was awarded a second year of Shuttleworth Fellowship for my work on reformulating how knowledge is produced.
Recent Presentations
The Future of Text
Google Headquarters in Silicon Valley, Aug 2016
http://www.thefutureoftext.org/
Organised by friends and followers of Douglas Englebart, Adam was invited to present on collaboration and book production.
Association of Learned and Professional Society Publishers
London, Sept 2016
http://www.alpsp.org/2016-Programme
Adam was invited to present at the annual ALPSP conference about ways that Open Source could change publishing.
International Society of Managing & Technical Editors
Brussels, Nov 2016
http://www.ismte.org/page/2016EuroConference
http://www.slides.com/eset/ismte
Adam was invited to present on Open Source tools for publishers at the Brussels edition of the 2016 IMSTE series of conferences.
Open Fields
Riga, Latvia, Oct 2016
http://rixc.org/en/festival/Open%20Fields%20Konference/
I was invited to speak about the intersection of art, science, and publishing at the cutting edge Open Fields festival.
Unlearning Collaboration
Berlin, Oct 2016
http://www.supermarkt-berlin.net/event/un-learning-networked-collaboration/
Adam was invited to facilitate a one day conference on collaboration and facilitation.
Development projects
PagedMedia
2016 – present
http://wwwpagedmedia.org
Founded the blog about paged media.
Substance Consortium
2016 – present
http://substance.io/consortium/
Foundational member of the Substance Consortium.
Book Sprints
2008 – present, New Zealand
http://www.booksprints.net/
Book Sprints is a methodology and a company I founded to rapidly produce books.
Nov 2016: transitioned from founder and CEO to the board. I appointed Barbara Rühling as CEO.
A Book Sprint is a collaborative process where a book is produced from the ground up in just five days. But even more important, this collaborative process captures the knowledge of a group of subject-matter experts in a manner that would be nearly impossible using traditional methods. The result at the end of the Book Sprint is a high-quality finished book in digital and print-ready formats, ready for distribution.
Book Sprints Ltd, is a team of facilitators, book-production professionals, and illustrators specialised in Book Sprint facilitation and rapid book production. Our organisation developed the original methodology and has refined it since 2008 through the facilitation of more than 100 Book Sprints. Topics have ranged from corporate documentation to industry guides, government policies, technical documentation, white papers, academic research papers, and activist manuals.
Book Sprints clients include Cisco, PLOS, F5, the World Bank, USAID, African Development Bank, Open Oil, Liturgical Press, Ausburg Fortress, Cryptoparty, OpenStack, European Commission, JISC CETIS, UNECA, Mozilla, IDEA, Engine Room, Heidy Collective, Transmediale, Google… to name a few.
"If Book Sprints did not exist, we would be forced to invent them, so powerful is the knowledge production paradigm." --Allen Gunn, Aspiration "Book Sprints get more brilliant work out of bright people in 1 week than most project can evoke across many months." --Loy Evans, Cisco "Writing a book through a Book Sprint turned out to be efficient, thorough and enjoyable; I can’t imagine a better outcome." --Phil Barker, JISC CETIS
Aperta
2013 – July 2015. Public Libary of Science, San Francisco
In 2013, I designed a platform for the Public Library of Science (PLOS), originally called Tahi but renamed to Aperta. In 2014 I was asked to lead a team to build the platform. I led the 15 strong team to the production-ready 1.0 release of this multi-million dollar project to completion, on time and under budget in June 2015.
Aperta is an entire submission and peer review platform for multiple scientific journals housed within the single instance. The entire system is designed to be highly collaborative and concurrent. The platform includes a manuscript production interface, HTML and LaTeX document editing support, Word ingestion, a workflow management system, task management interfaces, admin interfaces, reports, and user dashboards. The platform was built in Ember-CLI, Rails, implements a highly customised Wikimedia Foundations Visual Editor, and uses Slanger for concurrency. It is an HTML-first system, has many innovative new approaches to journal systems, and solved many long-standing problems in this space. The project also involved a separate codebase named iHat that provides Aperta with an API service for queue-managed file conversions.
"At its core, this new PLOS editorial environment brings simplicity to the submission and peer review process by providing advanced task-management technology and a vastly improved user interface, which will enhance the publishing experience for our community of authors, editors, and reviewers." http://blogs.plos.org/plos/2015/07/publishing-initiatives-at-plos-a-look-back-and-a-look-ahead/
NB: I only work on Open Source systems. The sources are not yet available for this project.
PubSweet
2012 – present
PubSweet is a platform designed to assist the rapid production of books in Book Sprints. The platform is very simple to use, with very little overhead for new users. The system provides dashboards, publishing consoles, card-based workflow management (task manager), discussions, data visualisations of contributions, a dynamic table of content management, and support for multiple chapter types. PubSweet can produce EPUB and leverages book.js (see below) to produce print-ready PDF (paginated in the browser). PubSweet is written in PHP, using Node on the backend, and CKEditor as the content editor.
Lexicon
2012
Lexicon is a platform produced for the United Nations Development Project to collaboratively produce a tri-lingual (Arabic, French, English) lexicon of electoral terms for distribution in Arabic regions. Lexicon provided concurrent editing for chapters with multiple terms, sorting by language, discussion forums and voting. Lexicon was written quickly in php with Node.
"The Lexicon was created with the aid of an innovative collaborative writing tool customized to suit the needs of this project. This web-based software allowed the authors, reviewers, translators and editors to simultaneously input their contributions to successive drafts from their various countries. "http://www.undp.org/content/undp/en/home/presscenter/pressreleases/2014/11/19/undp-launches-first-lexicon-of-electoral-terminology-in-three-languages.html
book.js
2012
book.js is a Javascript library that you can use to turn a web page into a PDF formatted for printing as a book. Take a web page, add the JavaScript, and you will see the page transformed into a paginated book complete with page breaks, margins, page numbers, table of contents, front matter, headers etc. When you print that page you have a book-formatted PDF ready to print.
book.js has given inspiration to a number of other JS pagination engines. See Vivliostyle, bookJS Polyfil, Pagination.js, simplePagination.js, and CaSSiuS.
Booktype
2010 / 2012
Booktype is a book production platform. I brought this platform to Sourcefabric (Berlin) as ‘Booki’ in 2012. Booki was started in 2010. Booktype is written in Python (Django).
“Booktype resolves challenging issues in collaborative knowledge production resulting in high quality print and ebooks.” – Erik Möller, deputy director, Wikimedia Foundation
Google Summer of Docs
2011, 2012, 2013
The GSoC Doc Camp was an annual event over three years. It was a place for documenters to meet, work on documentation, and share their documentation experiences. The camp improved free documentation materials and skills in GSoC projects and helped form the identity of the emergent free-documentation sector.
The Doc Camp consisted of 2 major components – an unconference and 3-5 short form Book Sprints to produce ‘Quick Start’ guides for specific GSoC projects.
Each Quick Start Sprint brought together 5-8 individuals to produce a book on a specific GSoC project. The Quick Start books were launched at the opening party for the GSoC Mentors’ Summit immediately following the event.
Bookimobile
2011
The Bookimobile was a a mobile print lab in a van – essentially a van that contained all the equipment necessary to create perfect bound books. It was designed to take the ideas of Booki to people and make real books that have been created in Booki. The first Bookimobile was based on the Internet Archives Book Mobile and we took it to several book fairs and events throughout Europe. It was sponsored by Mozilla, CiviCRM, Archive.org, Francophonie.org, Google Summer of Code, and iCommons.
Objavi
2008
Objavi is an API-software service originally written for Twiki Book (see below) but also serviced Booki and later Booktype. Objavi converts books from their native HTML into PDF for printing. It also handled other file conversions (eg HTML to ODT, HTML to EPUB etc). I later produced a similar API-based conversion software for PLOS known as iHat. Objavi is written in Python.
TWiki Book
2006
TWiki Book didn’t have a real project name at the time. The project was the first publishing system I built. TWiki Books was created solely to meet the needs of FLOSS Manuals (see below) and it was built on top of TWiki, a Perl-based wiki. TWiki Book included book remixing features, side by side translation, table of contents building, publishing interfaces (I actually wrote a separate php-based system to manage this), edit notifications, versioning, diffs, live chats and many other features. It was a good system but reasonably difficult to extend and maintain since it re-purposed an existing wiki software (hence my approach to building purpose-built book production systems after this point).
FLOSS Manuals
2006
FLOSS Manuals was the project I founded in 2006 that got me started on this whole publishing thing. FM was, and is still, an active community of volunteers that creates free manuals about free software. There is now a foundation and several language communities (notably French and English). The contributors include designers, readers, writers, illustrators, free software fans, editors, artists, software developers, activists, and many others. Anyone can contribute to a manual – to fix a spelling mistake, add a more detailed explanation, write a new chapter, or start a whole new manual on a topic. The aim was produce high quality free works and we succeeded – creating many fantastic manuals in over 30 languages (and still growing).
“Introduction to the Command Line” is at least as clear, complete, and accurate as any I’ve read or written. But while there are countless correct reference works on the subject, FLOSS’s book speaks to an audience of absolute beginners more effectively, and is ultimately more useful, than any other I have seen.” -- Benjamin Mako Hill, Wikimedia Foundation Advisory Board, Free Software Foundation Board
Presentations about publishing
I am asked to talk about publishing from time to time. The following are some links to some of those presentations.
Choosing a document network
August 2015, Vancouver, Public Knowledge Project
Open Access and Open Standards
Oct 2014, San Francisco, Books in Browsers
Books are Evil
May 2014, Rotterdam, Off the Press
May 2014, Rotterdam, Off the Press
Regional Lexicon Project
May 2014, San Francisco, I Annotate
May 2014, San Francisco, I Annotate
Changing the Culture of Learning
May 2013, San Francisco, I Annotate
The Death of the Reader
Oct 2013, San Francisco, Books in Browsers
A Web Page is a Book
May 2012, Berlin, re:publica
May 2012, Berlin, re:publica
Writings
I have been writing about publishing here and there. Since last year these efforts have been focused on this site. The following are some links to some of my other works:
Fantasies of the Library : After the Proprietary Model
Interview with me about the future models for publishing, published by k-verlag (Berlin).
Radar O’Reilly posts
When Paper Fails
What happens when books, ownership, authority and authors are all challenged by a network.
Visualizing Book Production
Why is no one visualising data on how we make books?
Zero to Book in 3 Days
A little bit about Book Sprints.
Forking the Book
When books are forked.
Over Thinking EPUB
Commentary on why EPUB might be confusing the issue.
Changing the Culture of Production
How to change the way we produce knowledge.
WYSIWYG vs WYSI
The evolution of the editor.
Math Typesetting
the sorry state of math typesetting.
InDesign vs CSS
Why HTML wins versus Desktop Apps.
The Blanche Dubois Economy
Why ‘Open API’ is really a silly idea.
Gutenberg Regions
Paginating in the browser.
Browser as Typesetting Engine
More commentary on the browser as a typeset engine.
The New New Typography
The evolution of Javascript Typesetting.
Other Projects
Seaweed
2008, Quarantine Island, New Zealand
This project was actually called ‘Intertidal’ but I like the name Seaweed better. Douglas Bagnall and I created a one-day community project to discover a new species of seaweed. We hosted this on Quaratine Island in the Dunedin Harbour and invited anyone to come work with us and a marine biologist from the local research center to search for a new species. The project was a community project and a reflection on the notions of species as an out-moded idea, and on taxonomy as a dying art. About 50 or 60 people – individuals, groups, and families – came out on the free boat (provided by the local sea scouts) and hiked across the island to participate on a coldish Dunedin day to search for and document seaweed. We possibly discovered a new species.
throwing into focus the ever-present potential for new knowledge. Drawing upon 19th century methods of species discovery, involving collecting, looking and drawing, their work formed questions around what we don't know.
Geek-o-system
2008, Christchurch, New Zealand
Julian Priest, Dave Merritt and I drove about a tonne of old electronics 700km or so in an old landrover (top speed 35km/hr) from Daves warehouse in Wanganui to an art gallery in Christchurch, New Zealand. In the gallery, we served up the old electronics as a participatory art project and invited anyone to come and build new objects from the old. It took 3 days to get there. It was an adventure.
A Geekosystem was a participatory workshop based on a redundant technology collection created by David Merritt. Items were selected from the collection and packed into a Landrover and driven to The Physics Room in Christchurch. A call for participation was issued by The Physics Room and a group of geeks gathered to re-configure the technology into artworks. A workshop space was created and plinths were placed at once end of the gallery and populated with artworks made from the e-waste. The workshop was open to the public and continually added to during the duration of the show. Old technology books were formed into a library. Proprietary software manuals were shredded and mixed with coffee grounds. This was mulched into soil and silver beet seedlings were successfully germniated in floppy disk trays.
A Geekosystem was shown first at the Physics Room in Christchurch in 2008 and then at The Green Bench during the Whanganui Open studio week in 2008. The Geekosystem garden was transferred to a permanent location and produced vegetables for a number of years.
Paper Cup Telephone Network
2006, Exhibited at the Exploratorium in San Francisco, Zero One Festival in San Jose, and many other venues.
This was a project I made with Matthew Biederman and Lotte Meijer. The Paper Cup Telephone Network (PCTN) was a free communication system and comment on how ‘simplicity’ in technical systems is trickery, and problematising the corporatisation and ever increasing individualisation of modern communications.
The PCTN was a network of paper cup telephones. Just like the games played by children, anyone could put a PCTN cup to their ear to listen, or to their mouth to speak. However, the difference between the PCTN and the original game is that the “string” is connected to the World Wide Web where your voice is streamed to all the cups on the network carrying it, blocks or even miles or a continent away. We built the entire system from free software telephony systems (asterisk and SIP phones), open and standards-based telephony protocols, cups, and string.
As simple as it was, it remains the most difficult technical project I have ever undertaken.
Wifio
2006, exhibited at the Waves exhibition in Riga, Latvia
Wifio was a project I did with Lotte Meijer and Aleksandar Erkalovic. Wifio was a comment on the naivety in which we broadcast our personal information. It was a hardware UI and software that allowed anyone to tune into the World Wide Web wifi traffic. If someone near you was browsing the web on a wifi network, you could simply tune in with Wifio by selecting the right channel and tuning into their IP address.
…but don’t worry, you don’t need to know what their “IP Address” is, in fact you don’t even need to know what an IP address is! Just move the dial until you hear their emails or what they are saying in chatrooms.
I was proud when Julian Oliver (an old buddy from NZ) referenced this project as inspiration for one of his works.
Sound Elevator
2007
r a d i o q u a l i a (see below) were commissioned to make a new work for Forte di Bard in Valle d’Aosta in Italy for “Cima alle stelle (Stars)”, a large exhibition showing historical works by major masters like Durer, Tintoretto and Guercino; contemporary artists such as Pierre Huygue, Olafur Eliasson and others; and astronomical instruments and writings by Copernicus, Galileo, Kepler, Newton and Einstein.
We made a new site-specific sound installation inside two of the glass elevators which take visitors from the arrival area of Forte di Bard, to the gallery levels. Much of the elevator travel is external to the Forte (pictured below). Sound Elevator consisted of two linked sound environments inside the elevators. As the elevators ascended to the exhibitions halls, visitors experienced an auditory journey from the local celestial environment to the edges of the Universe. In the first elevator, visitors sonically travelled through the Earth’s ionosphere and magnetosphere, hearing our closest star, the Sun, interacting with our planetary atmosphere. The upward and outward journey continued in the second elevator, with sounds from our planetary neighbours, the sonic echo of distant stars, and finally the sound of the Big Bang itself.
I-TASC
2006/2007 Antarctica
I did a 2-month residency in Antarctica at SANAE (South African Research Base) as part of I-TASC, ultimately a failed network of individuals and organisations working collaboratively in the fields of art, engineering, science and technology on the interdisciplinary development and tactical deployment of renewable energy, waste recycling systems, sustainable architecture and open-format, open-source media. But it was still a great experience.
The coolest thing about it, was the 2 weeks each way on the beautiful icebreaker the SA Agulhas (now decommissioned). I kept some diary pages on the Interpolar site. I also did a few other projects while there including Polar Radio (see below).
The worst thing about it was that we shouldn’t have been there. There is no need for anyone to be in Antarctica. Most of the ‘science’ projects are strategic positioning for a land grab when the time comes. Some science might be justifiable… but arts projects?
Leaving Antarctica I cried my eyes out. It was just too much for me to deal with. Too amazing. After Antarctica, I gave up the art world. I couldn’t think of anything else the art world could do for me.
It was a conflicted but beautiful experience.
Polar Radio
2006/2007, Antartica
Polar Radio was a community radio project initiated by I-TASC and
r a d i o q u a l i a. The first prototype station began FM broadcasts on 29 December 2006 in the Dronning Maud Land sector of Antarctica, where South Africa maintains their base, SANAE IV. It was Antarctica’s first artist-run radio station. It was the first step towards establishing a permanent polar radio presence in Antarctica, which may eventually broadcast in between geographically dispersed Antarctic bases.
But y’know…I wish I hadn’t done it. When I first got to Antarctica I turned on a radio and went through many many frequencies… and I heard nothing… that was amazing. Where else in the world can you not hear anything on your radio? I then went ahead and polluted the spectrum. Darn. I regret it.
Polar Radio was part of a series of projects run by I-TASC – the Interpolar Transnational Art Science Constellation.
Mobicast
2005, Transiberian Express
Capturing the Moving Mind was a conference on board the Trans-Siberian train. It was about new forms of movement and control, war and economy, in the current situation. 50 international researchers, artists and activists participating in the mobile conference formed a mobile production unit aboard the train. For the audiovisual streams, Luka Princic and I developed a free software ‘mobicasting’ platform which enabled mobile transmission of material on the web from mobile phones on the train. Mobicast was initially developed during a residency I had at MAMA Media Lab (Zagreb, Croatia).
It was a great project but really really fragile. The tech of the time was not up to it. Mostly it ran on Puredata and some obscure bits of code from here and there. Still it worked. Best moments were hanging out on the train laughing at people trying to be ‘artists’ in real time… huh? …and getting sardonic with Dr Gillian Fuller – the world’s best queue hacker. Watching the train wind around the Gobi desert… also kinda cool.
mobicast was initially developed to overcome the problem of delivering live video from a moving train to the internet. Traditionally this is the domain of OB (Outside Broadcast) technologies or expensive vehicular satellite uplink hardware. However mobile phones are now very capable remote broadcast environments. Many modern phones record images, video, audio and allow the editing and transfer of these media through wireless data networks (eg. GPRS) with almost global coverage. The quality of these recorded media have generally been considered 'low-fi' but fidelity is increasing and importantly, the expectations of networked media are becoming more appropriate. Once upon a time there was a mythic "broadcast quality" threshold all media had to pass before being accepted by broadcast organisations and (theoretically) audiences. However, now there are active calls for content generated by "on the spot" accidental observers by large scale media organisations. The tide and scale of remote media is changing. The nature of experimental media on this type of platform is the intentional playground of mobicasting. With this emerging new type of media witness cultural forms are also emerging. Multiple networked media phones is in itself a platform for collaborative cultural development and opens interesting doors for experimental media.
MiniFM and SilentTV
2001-2004, International
For many years I had a wonderful mentor – Tetsuo Kogawa. He is the father of MiniFM. I saw Tetsuo build a mini FM transmitter at the Next Five Minutes festival in Amsterdam. Sometime after that, I asked him if he would teach me how to make them too, and he very generously spent a good deal of time making sure I understood the ins-and-outs of the process. Together we designed a workshop and Tetsuo worked out even simpler ways to build the transmitters. For many years I travelled the world leading transmitter-building workshops and often Tetsuo would stream in from his studio in Tokyo to talk about the idea and give a quick demonstration before we started building.
Later Tetsuo and I created a project called SilentTV which was the same idea but using simple elements to broadcast TV.
I’m forever grateful to Tetsuo for his kindness and mentorship.
re:Play
November 2003, South Africa
re:Play explored the world of the computer game. It featured an exhibition of artists’ computer games by Andy Deck, Josh On + Futurefarmers, Mongrel, Natalie Bookchin, the escapefromwoomera collective and Max Barry, and a programme of workshops and lectures. re:Play was a collaboration between the Institute for Contemporary Art, Cape Town and r a d i o q u a l i a. It launched at L/B’s – The Lounge at Jo’Burg Bar in central Cape Town, South Africa, and went on to be exhibited at Artspace and the Physics Room in New Zealand.
The games in the exhibition were not typical computer games. While all of them encouraged play, and involved a gaming objective, unlike regular computer games, they had a strong political dimension and explored how play, interaction and competition can be utilised in an artistic context.
The re:Play education programme included talks and workshops lead by Graham Harwood of Mongrel and r a d i o q u a l i a at Cape Town High School, Fezeka Senior Secondary School in Gugulethu; the Alexandra Renewal Project, Johannesburg and at Wits School of Arts, University of the Witwatersrand, Johannesburg.
Free Radio Linux
2002, The World
Another project that got a lot of attention for r a d i o q u a l i a, most notably through being exhibited at the New Museum in NYC, but it also at Banff and other places. I loved this project because it brought together several threads.
Formally, Free Radio Linux was an online and on-air radio station. The sound transmission was a computerised reading of the entire source code used to create the Linux Kernel, the basis of all distributions of Linux.
Each line of code was read by an automated computer voice – a speech.bot
utility I built for the work. The speech.bot’s output was encoded
into an audio stream, using the early open source audio codec, Ogg Vorbis, and was broadcast live on the internet. FM, AM and Shortwave radio stations from around the world also relayed the audio stream on various occasions.
The Linux kernel at that time had 4,141,432 millions lines of code. Reading the entire kernel took an estimated 14253.43 hours, or 593.89 days.
Listeners tracked the progress of Free Radio Linux by listening to the
audio stream, or checking the text-based progress field in the ./listen
section of the website (which is no longer up)…
Essentially this was all about how free radio and free software were wierdly the same. If you ever worked with free radio geeks, you will know they are nerdy technophiles who believe in the purity of what they are doing. Very much the same as Open Source geeks at the time. Most were interested in the tech and the political ideal of the respective mediums (radio and software). So, FRL was a comment on this. It was also a comment on how free radio was, ironically, very difficult to achieve on the internet unless serious attention was made to developing free codecs. But also FRL had two other elements going for it. The first was to (again) poke fun at the ridiculous hyperbole that surrounded the open source movement. People were expounding this ‘amazing new phenomenon’ and extrapolating how it would change the world (much as they did about wikis a short time after) when they had never come into contact with code or geeks. So this was an attempt to expose those people to the code…or what it sounded like. But also, at the time there was a lot of early talk about how to preserve digital media (a problem still not solved) and radio waves apparently never die… so by broadcasting the Linux kernel into space we were preserving it on the oldest medium ever, forever. Hehe…
I did, however, feel very sorry for the attendants at the New Museum who had to work 8-hour shifts listening to “one dollar sign dollar sign comma hatch four new line seven two dollar sign dollar sign…”
Thing FM
2002, New York City
This was, in theory, a radio network but in reality, just a few transmitters got installed. Still, it was fun. Thing FM was based in NYC and built during a residency I did at the Thing in NYC. The same week that the Yes Men came into the office to film their ‘shit burger’ stunt. They came into the Thing and asked who wanted to go and I didn’t go! doh! Anyway, we built the network using internet audio (via wireless and wired connections) and miniFM. Each of the transmitters was about 0.1 W output and sourced their audio live from the internet using the Frequency Clock scheduling system I had built earlier.
This partly adopts the ethic of micro-radio as founded by Tetsuo Kogawa, where many low powered FM transmitters are coupled to create an effective broadcasting entity that ‘falls beneath the radar’ of the communication authorities. fm.thing.net combined this ethic with that of net.radio which was a relatively new phenomenon focusing on the use of the internet as a carrier signal, best illustrated by the practices of the Xchange network. By combining the net.radio and micro-radio we hoped to build an efficient radio network in New York that used the internet as a primary carrier of the audio for re-broadcasting on legal or almost legal microFM broadcasts.
Hanging with Ted Byfield and Jan Gerber was a highlight of this experience. Wolfgang Strauss was also pretty fun but I was so intimidated by him. He was just so cool. Also sharing a tenement apartment in Ludlow Street with 3 people (bath in the kitchen) was pretty fun.
Radio Astronomy
2001
Radio Astronomy was an art and science project which broadcasts sounds intercepted from space, live on the internet and on the airwaves. The project was a collaboration between r a d i o q u a l i a, and radio telescopes located throughout the world. Together we were creating ‘radio astronomy’ in the literal sense – a radio station devoted to broadcasting audio from our cosmos.
Radio Astronomy had three parts:
- a sound installation
- a live on-air radio transmission
- a live online radio broadcast
Listeners heard the acoustic output of radio telescopes live. The content of the live transmission depended on the objects being observed by partner telescopes. On any given occasion, listeners may have heard the planet Jupiter and its interaction with its moons, radiation from the Sun, activity from far-off pulsars or other astronomical phenomena. Honor from rQ later made a TED Talk about it.
Dino, drummer from HDU, did the website design…thats gotta rate…
RT32
2001, Latvia
In 2001 I had the good fortune to be part of the Acoustic.Space.Lab project which started a long love affair with the RT32 radio telescope. Formerly a cold war device, this telescope was liberated when the Russian Army pulled out of Latvia. I worked with this telescope as an artistic device and with the generous scientists for many years after. The doco clip below introduces the explorations of the international Acoustic Space Lab Symposium which took place on the site of RT-32 in 2001.
Highlights of this period in Latvia included being evicted by Russian builders, getting a hernia, and being amazed Marc Tuters survived eating so many dodgy looking mushrooms he found in the forest.
Open Sauces
May 2001, Scotland and also later…
I have come to realise there is just too much stuff I have tinkered with to comment on. Open Sauces falls into that bucket. Google tells me this was 2001. Essentially I got sick of all the Open Source blah blah of the time.. everything was suffixed by OPEN and it got very tiring (Open Gov, Open Hardware, Open Society…). No critical reflection on the fact that geek methods are geek methods and they are not transportable – AND – OPEN processes, methods etc existed well before geeks came along and inherited the word. No geek invented openness. I’m still tired of this I have to say…still…. I created Open Sauces which was an open database of recipes… anyone that did a residency could add their favourite recipe and you could just tick all the ingredients you have in your fridge and get a recipe to suit… doesn’t sound too revolutionary but at the time this sort of thing didn’t exist. It was a comment on this abuse of the use of the word ‘open’ and how cooking way preceded sharing of ‘code’ / ‘instructions’ etc… and also how food is probably the most important part of any collaborative project, whereas unsocial nerdy talk is optional. Later Fo.am in Brussels were inspired by the idea and started an Open Sauces theme.
net.congestion
2000, Amsterdam
I’m particularly proud of this project. It came about when I was a very naive newly arrived resident of Amsterdam. I suggested to Geert Lovink this idea for a festival and he said to speak to Erik Kluitenberg. Both huge legends in my mind you understand… I mustered the courage up to suggest it to Erik who was a cultural curator at De Balie at the time. He said he would think about it and I thought I wasn’t very convincing. A week later he called me up and said let’s do it! Whoot!
The festival was held in Amsterdam in October 2000. Net.congestion was an intensive three-day celebration and critique of the new cultures that have arisen from all forms of micro-, narrow- and broad- casting via the internet, now collectively known as streaming media.
The event covered most of the interesting ground of the time for streaming media, from the transformation of issues surrounding intellectual property to the uses of streaming as a mobilisation tool for global resistance through to the more rarefied questions of aesthetics and how narratives are transformed when embedded in networks. The overwhelming experience of many visitors to Net.congestion was a sense of tools, networks and sensibilities being re-purposed, returning us, again and again, to a primary experience of the net as a social space.
Net.congestion occurred just months before dot.com bubble burst, exploding the ‘new economy’ and ‘the long boom’ with its fantasies of a world in which the economic laws of gravity had been repealed. There is no doubt that if the same event were to be held now, the atmosphere would be markedly different. It is not that Net.congestion was an industry event which depended on the hype for its existence, as the very title indicates that we mixed a healthy dose of skepticism with our festivities. But none of us, however critical, can entirely escape the zeitgeist and there is no doubt that in those brief heady days Warhol’s aphorism was re-written; we could all dream of becoming billionaires, if only for 15 minutes. A strange historical phase when (particularly for anyone involved in streaming media) the normally fixed boundaries between business, art, technology, science fantasy and just plain bullshit temporarily blurred to create a moment of unique cultural hysteria. In that sense our timing was perfect.
The Theory Machine
2000
In an attempt to make theorists a little more funky, I made a software they could use to put their brainy thoughts to glitchy syncopation. It was mainly used by Eric Kluitenberg including one memorable performance at Club Otok in Dubrovnik.
HelpB92
1999, Amsterdam
I helped found an organisation during the Nato bombing of Serbia and Kosovo in 1999. The international support campaign for independent media in Yugoslavia, including the famous Radio B92 media centre, in operation between March and July 1999. We did some pretty cool things but mostly I was very happy to be involved in what must have been one of the web’s early large-scale activist campaigns. It was also the start of my longish relationship with Amsterdam as XS4ALL offered me a job and I stayed for a few years. I still have a bike there somewhere.
What was tricky, though, is that I agreed to go to Skopje to assist an Albanian refugee radio station (Radio 21). It was kinda nerve wracking. There were literally bombs set to explode to take out as many Albanians as possible. Some kids lost their legs across the street from where I was working. I was a milk and cookies boy from NZ.. what was I doing here? Still, I stuck it out and we managed to set up quite an innovative way of getting radio transmissions out of the refugee camps to Radio Netherlands Shortwave.. .I’ll write that up when I get time.
The Frequency Clock
1998 – 2004 or so, The World
This was one of the earliest r a d i o q u a l i a projects and how I learned to program. To understand this project you have to understand the dark ages of the internet when video and audio hardly existed. Essentially we built a media scheduling system that allowed you to build archives of live and pre-recorded content, tag them, and then schedule them. All built in JavaScript… remembering these were these days when Javascript was very rudimentary.
The Frequency Clock was originally conceived as a mechanism to control FM transmitters over the internet. In essence it was a networked timetabling system, connecting globally dispersed FM transmitters so they could broadcast the same internet audio simultaneously. The original player was a popup window but we also built desktop apps to do the same thing using VisualBasic (Win) and RealBasic (Mac). All open source.
However… then we realised that video could also work… and we used it to control community TV channels in Amsterdam and Linz and we also controlled giant video billboards in Estonia and a whole lot of other things. It was exibited a lot, most notably at the Walker when Steve Dietz was still there. We even installed a transmitter in the roof of De Waag! It was a remarkable experiment for its time. Yes, yes, pre-Napster and YouTube and all those other toys… while writing this I found some kind of prototype online.
Sound Performances
1996 – 2008, the world.
Performing solo as ‘eset’ and with Honor Harger as r a d i o q u a l i a I did a lot of sound performances, most using sounds from space and either live performances in real space or on radio. Some stuff still exists online:
https://soundcloud.com/radioqualia
Or eg:
r a d i o q u a l i a
This was the project that liberated me from the south and the reason I moved to Europe with no money and no return ticket. My plan was to make coffee and do some arty stuff in London. Thankfully, Nato bombed Serbia (hoho) and everything changed.
What I really loved about this time, was that I felt part of a lovely international community of artists. We used to travel around and bump into each other in various crazy places. This group included people like Marko Pelijhan, Heath Bunting, Rachel Baker, James Stevens, Luka Frelih, the Mama crew, Lev Manovich, Steven Kovats, Matthew Beiderman, Giovanni D’Angelo, Zita Joyce, Adam Willetts, Rasa Smits, Raitis Smits and so many many others…it was an awesome time.
r a d i o q u a l i a was an artist project that consisted of myself and Honor Harger. I have described some of our exhibitions and performance projects above, and listed some below. There were many more.
In August 2004, r a d i o q u a l i a was awarded a UNESCO Digital Art Prize for the project Radio Astronomy. In September 2003, we were awarded the Leonardo-@rt Outsiders 2003 New Horizons Prize together with the participants of the Open Sky installation at the @rt Outsiders exhibition at the Museum of European Photography in Paris.
Selected r a d i o q u a l i a exhibitions and performances:
Lecture & performance at the Centre Pompidou, Paris, France
Work: Sonifying Space, as part of the Space Art conference
Exhibition at the New Museum of Contemporary Art, New York, USA
Work: Free Radio Linux, as part of the OpenSourceArt_Hack exhibition
Exhibition at the NTT InterCommunication Centre, Tokyo, Japan
Work: Radio Astronomy, as part of open nature, a show curated by Yukiko Shikata
Online exhibition / commission / installation at Gallery 9, Walker Art Centre, USA
Work: Free Radio Linux
Exhibition at Arsenals Exhibition Hall, Riga, Latvia
Work: solar listening_stations, part of WAVES
Exhibition at HMKV, Dortmund, Germany
Work: solar listening_stations, part of Solar Radio Station
Exhibition at the Walter Philips Gallery, Banff, Canada
Work: Free Radio Linux, as part of The Art Formerly Known As New Media
Exhibition at Centre d’Art Santa Monica, Barcelona, Spain
Work: Radio Astronomy, as part of Sonar 2005
Performance at Tesla, Berlin, Germany
Work: from polar radio to solar wind
Performance, La Batie Festival, Geneva, Switzerland
Work: signals as part of signal-sever
Exhibition at Ars Electronica, Linz
Work: Radio Astronomy
Exhibition at ISEA 2004, Helsinki, Finland
Work: Radio Astronomy
Symposium & Performance, Ventspils International Radio Astronomy Centre, Latvia
Work: Acoustic Space: RT32: Orchestrating the Solar System
Broadcast on Radio New Zealand
Work: Revolutions Per Minute 1: Frequency Shifting Paradigms in Broadcast Audio
Broadcast on Radio New Zealand
Work: Revolutions Per Minute 2: Little Star
Exhibition at Small Gallery, Los Angeles, USA
Work: comma.data.space: 11 Ghz
Performance at the Moving Image Centre in Auckland, New Zealand
Work: comma.data.return :: 56:30 – 21:1
Performance at Version festival, Auckland, New Zealand
Work: listening_stations v0.3: langmuir waves
Exhibition at the Physics Room, Christchurch, New Zealand
Work: re:Play
Exhibition at Artspace in Auckland, New Zealand
Work: re:Play
Exhibition & education programme, South Africa
Work: re:Play
Exhibition at the Reg Vardy Gallery, Sunderland, UK
Work: Free Radio Linux, as part of the Art for Networks exhibition
Exhibition at Museum of European Photography/ Maison Europeenne de la Photographie, Paris, France
Work: listening_stations, as part of @rt Outsiders exhibition
Exhibition at the Physics Room, Christchurch, New Zealand
Work: data.spac.ereturn, as part of the Audible New Frontiers exhibition
Locative media Residency at K2, Karosta, Latvia
Work: Locative Media
Exhibition at Turnpike Galleries, Leigh, UK
Work: Free Radio Linux, as part of the Art for Networks exhibition
Exhibition at Fruitmarket Galleries, Edinburgh, UK
Work: Free Radio Linux, as part of the Art for Networks exhibition
Radio show on Resonance 104.4FM, London, UK
Work: r a d i o q u a l i a on resonanceFM
Exhibition at the Generali Foundation, Vienna, Austria
Work: listening_stations as part of the Geography and the Politics of Mobility exhibition
Exhibition at Chapter, Cardiff, UK
Work: Free Radio Linux, as part of the Art for Networks exhibition
Performance & Broadcast, Ars Electronica, Linz Austria
Work: Radiotopia @ Ars Electronica
Radio Broadcasts on Austrian National Radio, Vienna, Austria
Work: i s o l
Exhibition at CCCB, Barcelona, Spain
Work: frequency clock – gallery installation – [sNr v.0.1]
Sonar 2001, Barcelona, Spain
Action & Broadcast, Ars Electronica, Linz, Austria
Work: Take Over Cultural Channel
Performance, Residency & Symposium at, Ventspils International Radio Astronomy Centre, Latvia
Work: Acoustic Space-Lab
Exhibition at Video Positive, Liverpool, UK
Work: Frequency Clock – gallery installation – [ vp00 v.0.0.3 ]
Workshop & Performance, Adelaide Festival of the Arts, Adelaide, Australia
Work: Closing the Loop 2000
Seminar & Performance at Lux Centre, London, UK
Work: Tuning the Net
Performance at the Stockton Festival, Stockton, UK
Work: transitions & undercurrents part of live-stock
Exhibition & Performance at OK Centrum, Ars Electronica, Linz, Austria
Work: pso.Net, as part of Sound Drifting
Exhibition at Experimental Art Foundation, Adelaide, Australia
Work: Frequency Clock – gallery installation – [ eaf v.0.0.2 ]
Exhibition at Experimental Art Foundation, Adelaide, Australia
Work: Illata
Exhibition at Contemporary Art Centre of South Australia, Adelaide, Australia
Work: e Q
Performance at LADA98 Festival, Rimini, Italy
Work: we are alive and well but terribly uncommunicative
Exhibition, Ars Electronica, Linz, Austria
Work: Frequency Clock – gallery installation – [ aec98 v.0.0.1 beta ]
Performance, Ars Electronica, Linz, Austria
Work: 56h LIVE!: Acoustic Space
Exhibition at Bregenz Festival, Bregenz, Austria
Work: gl^tch.bot
Performance and presentation at net.radio.days 98, Berlin, Germany
Work: self.e x t r a c t i n g.radio (.ser)
Online Project
Work: self.e x t r a c t i n g.radio (.ser)
Exhibition at the Machida City Museum of Graphic Arts, Tokyo, Japan
Work: The Qualia Dial
Exhibition at Fabrica New Media Art Institution, Italy
Work: Balance
more to do….
Streaming Suitcase
PliegOS
Re:mote
Low Res
Skint Stream
Open Source Streaming Alliance
Open Channels for Kosovo
self.extracting.radio
ovalmaschina
Gema
simpel
Building Book Production Platforms p5
Workflow
Much more to come.
Most of the book production platforms in circulation have very little workflow tools to speak of. This is not necessarily a bad thing. A platform that is ‘just an editing environment’ is still pretty powerful. If you do need tools to assist with workflow, then in situations where a small group know each other well they can use email or, if in real space, Post-it notes or paper to track what needs to be done next. In many cases, a live chat in the interface, or integrated topic-based forum, will be enough to satisfy many workflow needs, and in other cases the platform can be augmented by external systems such as wikis, online spreadsheets, content management systems and other tools to meet particular requirements.
However, there are a number of situations where these ‘solutions’ become unsatisfactory. This is especially true for organsiations which have a large number of people involved in processing content, or which have sophisticated content-processing needs (such as book publishers).
Before going too much further, let me clarify what “workflow tools” are. In the broadest sense, they are tools that help you to know what needs to be done, and when it needs to be done by. Using this very broad definition, we can see that mechanisms such as discussion forums and live chats are workflow tools. By chatting with colleagues through a live chat or forum, you can work out what needs to be done next, or get a ‘notification’ (a shout out) that it needs to be done now… From there, systems can evolve into complex technical environments which are either relatively open-ended (such as Trello) or relatively closed, such as hard-coded workflow pipelines.
The first book production system I built for FLOSS Manuals was ‘built’ on top of Twiki in 2006-2007, had some basic workflow tools, namely:
- a basic live chat
- a dropdown status-selector for marking chapter statuses (needs content, needs images, finished, and so on)
- notifications in the table of contents when someone is editing a chapter
- a mailing list where efforts could be coordinated
These tools were simple and effective and served us well for a number of years. I also incorporated similar mechanisms into Booktype and PubSweet. In addition, when we used these platforms for Book Sprints, lots of whiteboard scribbles and Post-its were utilised.
In a Book Sprint, notably, the facilitator is the main coordinating workflow mechanism. I point that out because it is important to understand that workflow tools can include humans – often the easiest way to know what needs to be done and when is to be done by, is to get someone else to tell you.
And let’s not forget that human factor! We are living at a time when we tend to want to programmatically solve problems with overly prescriptive technical systems. But sometimes underdetermining the technical systems is the right way to go.
I first tried pushing past these basic software workflow tools with Booktype – a book production system I founded, now housed with Sourcefabric. I leveraged the kanban idea of multiple columns (phases) populated by ‘todo’ items to build the equivalent of a digital kanban system, making the first simple prototype in a demo for the Frankfurt Book Fair in 2012. The inspiration came from Pivotal Tracker and the Open Source Fulcrum.
Most often the technology used to set up a kanban system is a whiteboard, with marker pens to draw and label the columns, and Post-it notes as a marker of the tasks. This kind of system is popular in unconferences, and also often used by software development houses. We also use this type of kanban approach a lot in Book Sprints.
The task manager (as I called it) and the production system were linked to each book and worked nicely. Although this system didn’t make it into the core code of Booktype, this version got the idea across, and later Juan Gutierrez made an integrated version for PubSweet. (During 2014, I also built this idea into a system for PLOS).
The task manager used a whiteboard-like interface in which the user could use to create columns (phases). Cards could be added to each phase and simple notes kept on each card. It was simple but effective.
In time I discovered Trello, and Why Cards are the Future of the Web by Paul Adams – these examples placed cards nicely within evolving design paradigms of the Internet, and I started to think about this model in more detail.
There are many advantages to cards, not the least being that cards can ‘follow the user’ – think of them as powerful work-unit-applications that can be accessed by a user within any context where they are needed.
Additionally, when thinking of digital cards within the digital workflow-kanban paradigm, the nice thing is that it is a very simple model. There are essentially just 2 elements – cards and columns. You can create as many of each as you like. Further, you can name the columns and cards anything you like. That means these two devices can be used to represent any number of simple or complex workflows. You can start from the kanban default – three columns marked ‘to do’, ‘doing’ and ‘done,’ and add cards for each task – progressing them from left to right as tasks progress from ‘to do’ to ‘done.’ This is the default configuration when creating a new Trello board.
Replicating this system in an application is pretty easy to do. Trello is an excellent example. While Trello is not easily integrated into another technical system (such as an in-house publishing system), it is interesting in that the designers, while surely tempted by all that a web application could offer, have endeavoured to keep the Trello system true to the kanban ideology of useful but simple. With Trello, therefore, you can add columns, and cards to columns, naming each as required. When you open a card, however, you have some nice widgets for making lists, comments, discussions, attaching files etc. This is something paper cannot easily do, at least not with the small real estate afforded by Post-it notes.
Trello is a lovely application precisely because these systems, like the paper kanban, have been designed to be simple to use and serve as many generic use cases as possible.
However,while digital kanban systems like this are useful as standalone ‘context agnostic’ systems, they could be much more powerful for publishers (or anyone) if this simplicity and flexibility could be preserved while the system also served their specific use case. The trick is to preserve the simplicity and flexibility to allow publishers to model existing and future workflows in an easily ‘grok-able’ drag and drop manner (similar to Trello), while building cards that reflect the publisher’s specific needs (to invite editors, push content to external vendor services, perform peer review etc).
Building cards like this, means pushing cards away from the Trello/kanban generic-use paper metaphor towards a more sophisticated specific-use digital and networked paradigm. This means embracing the idea that cards are networked applications and building cards that precisely serve the publisher’s needs and integrate into their existing internal and external systems.
Single Voice
version 1.0 ‘not as raw’
During a Book Sprint, or when talking about Book Sprints, the question very quickly arises – ‘what about the author’s single voice?’
The fear is that collaboratively produced books will lose that personal, individual voice that we know so well from all the books we have read and loved.
Wouldn’t Frankenstein be a little lumpy if it was written by a collective? Same goes for any Tom Clancy book (he famously said that “Collaboration on a book is the ultimate unnatural act”). Clancy’s books are not high art, but they do seem to contain a particular ‘Clancy’ style. What about good contemporary literature? Could, for example, the wonderful The Art of Fielding be as wonderful if written by anyone other than Chad Harbach? And what about poetry by the father of English literature – Chaucer? It’s unimaginable that his works could be produced by anyone other than Chaucer.
We believe that both high and low literature would suffer if the works weren’t produced by a single author. There is only one Chaucer, one Clancy (thankfully), one Harbach, one Mary Shelley. We can tell their works apart because each contains a distinctive authorial voice. We know these writers. We know those voices.
We can only imagine what a mess would be created if books were written by more than one person. They would lose the single point of view. That special perspective. That special voice.
Well… first of all, it might be worth knowing that each of these examples actually had more than one contributing author, and each in its own interesting way. From Erick Kelemen’s work in the forensic field of textual criticism, there is good evidence that both Byron and Percy Shelly had a hand in at least some of Frankenstein. According to Kelemen, the extent of the collaboration is not exactly known, and we need to be aware that the discussion is also tainted by a good ole sexist lens. However, there is good evidence of collaboration, not just in the Preface (which some say is written entirely by Percy Shelly), but also in the content of the rest of the story.
Tom Clancy, in his own mind the enemy of collaborative book production, actually collaborated with others on many of his books. Some of the books he has credit for were actually written mostly by others, a common practice amongst authors of best-selling thriller and mystery series for at least the past twenty years.
And in fact, manuscripts produced at the time Chaucer was writing were shared documents, and it is extremely likely the exact words that we now consider to be Chaucer’s were not his at all. As Lawrence Liang has noted, in his discussion of the process of Chaucer’s canonisation, the process was essentially a gathering of manuscripts after Chaucer’s death by experts who decided which words were, and which were not, Chaucer’s, for all time.
In the disclaimer before the Miller’s Tale for instance, Chaucer states that he is merely repeating tales told by others, and that the Tales are designed to be the written record of a lively exchange of stories between multiple tellers, each with different, sometimes opposing, intents. Interestingly, Chaucer seems not only to recognize the importance of retelling stories, but also a mode of reading that incorporates the ability to edit and write.
If you want to understand the role of collaboration in single-author-culture right now, there is no better story to read than The Book on Publishing which provides a great tale about the publishing of Harbach’s The Art of Fielding and acknowledges the huge value an editor can play in re-writing and restructuring a book.
There are two points here to keep in mind.
Firstly, we don’t know much about how books are written, nor how models of the writing process have changed over time. Paper is not a good medium for preserving versioning, and we lack an on-paper-process mechanism like git blame that can backtrack to show how the text was created. A great pity. The lack of this kind of tool for the vast majority of publishing history means publishing has been able to propagate the very marketable myth of the single author. Collaboration has been obscured and de-valued. Worse, the extent and value of collaboration is not understood. We don’t even have a good language for talking about it.
Secondly, we are left believing claims such as “books have a single voice because they are written by a single author” when this is demonstrably false. Almost every published book has had at least two authorial contributors – the author and the editor; and most books will have been improved during the drafting process by the contributions of test readers.
Collaboration exists to improve works. It is why there are editors in publishing. Editors give feedback and shape the work to, amongst other things, strengthen the impression of the single authorial voice. It is very probably true that an effective single voice can only be achieved by 2 or more people collaborating.
So next time you find yourself asking “how can an authoritative singular voice be preserved in collaborative book production?” it might be better to take a deep breath and ask yourself “how could a single voice ever be effectively realised without collaborating?” That is the real question at play.
Colophon: version 1.0 Written in an hour by Adam Hyde. Raewyn Whyte then improved it (‘made it stronger’). Also, some references still need to be checked as the needed books are in storage in NZ somewhere! Written with Ghost Blog free software (MIT) https://github.com/tryghost/Ghost.