Workflow Engineering

At Coko we build open source tools for scholarly publishing… sort of… that’s the tagline, but actually, there is a lot more to it. We have built open source technologies for publishers, it is true, but we have been careful to build frameworks which can be moulded to meet a large variety of use cases.

To understand what we actually do, it is worthwhile to look not just at the technology but at how we produce the technology. Essentially, we facilitate publishing staff through a process where they design their own platform… which is awesome in itself …but, actually, that’s not quite it either. What they are actually doing is designing their own workflow, one that gets rid of the current pains and opens up new possibilities. When we do that, we are essentially working as consultative workflow engineers – helping the publishing teams work out what an ideal workflow is for them, and then working out the technology/cultural change mix that must occur to get them there.

I’m very proud of how we work. We don’t create ‘black boxes’ and throw them at a publisher and say, there yo go! Use that! Rather we help them design what they want and build it (using our flexible frameworks and bringing in existing open source software, where possible).

It also allows us, as Karien Bezuidenhout (Shuttleworth Foundation) has said, to ‘bake cultural change into the product development process’. Very true.

Wot I’m Listening to

I used to be in radio as a DJ, managed radio stations in NZ, ran a show on Resonance FM when it first started in London, I’ve been involved in many pirate radio stations (mainly in Amsterdam), taught people how to build FM transmitters all over the world, set up the first artist run radio station in Antarctica, and I’ve been a radio activist and artist. So… there is a lot of radio in my life. I still in some ways see myself as ‘a radio guy’ even though I haven’t made any radio for a long time.

Teaching FM Transmitter building.
Teaching FM Transmitter building, Riga, Latvia 2000 and something something.

Anyways… the point being. I like music ūüôā Ha. I especially like experimental stuff. So, I now have a rekid player in my San Francisco apartment and I’m starting to explore the spectrum again. I’m buying some great records. Mainly I go into Stranded Records, just along from my place, and buy stuff I have never heard of. It’s soooooo great… some really good finds include The Alps, Carla dal Forno, and Craig Leon (Nomos). All are very very good.

Also, it’s interesting to see so many old independent NZ artists making a comeback. All the early Flying Nun stuff is being re-released on vinyl but also some new material is coming out too. It seems the Dead C and Gate (etc) are having a revival, as is Roy Montgomery. I have some of these artists who I haven’t listened to yet but I have listened to Dark Matter which is a new record by Stephen Cogle (Vacuum, The Victor Dimisich Band and The Terminals). So very good…his voice is still the same. Beautiful.

How the Cabbage Tree Method Book was made from HTML


The Cabbage Tree Book pictured above was made using entirely HTML as the base file format. It was then rendered from HTML to PDF using Vivliostyle and printed and bound. Julien Taquet did this work and he has written the first of a series of blog posts about how this was done here:

Making books with HTML + CSS ‚ÄĒ a look at Vivliostyle (Part 1 ‚Äď page layouts)


Thinking of Models

Possibly a bad choice of title for¬†a post about community models… I have been thinking about the Cabbage Tree Method book and how to improve it. My thoughts have been stimulated by being at the Open Source Leadership Summit last week where I gave out about 40 books or so and talked to many people about the ideas. I think I have two takeaways from doing this.

First, I should get rid of the critique of open source. The open source community is, rightly, proud of what it has achieved against enormous odds. Additionally, many people have given this community their all to improve the greater good. So a critique of open source comes across as a critique of them and it falls on cold ears. While I stand by the critique at the beginning of the book I think I need to make the content more palatable to this community and frame the Cabbage Tree Method not as a reaction to a weakness in open source, but as adding to something already successful.

Second, when I talked to people about how open source solves problems and then discuss why this has not worked for user-facing products (covered in the ‘Thoughts about open source’ chapter) people do get it and generally agree. However, I don’t think I have this argument down smooth enough. This prompts me to perhaps consider removing the chapter on open source at the beginning and write another about solutions models – explaining (what I call) the developer-centric solution model, from the user-centric solution model. If I can frame this right I think it will help people ¬†in the midst of it all see the forest, whereas right now all they can see is trees.

There is a third issue that¬†I haven’t yet resolved. If I talk about¬†developer-centric¬†or user-centric¬†models I am making the models about people ie. developers and users. I’m wondering if this is too confronting. I could use the terms (for example) code-centric and product-centric….I’m not sure about this though. It feels like it weakens idea. If you have any thoughts on this I’d appreciate hearing from you.

Models for Track Changes

At Coko, we are building a Track Changes feature for Editoria. There is a request for comments on various models of UX. Below are the 4 different models – please visit the above link to participate in the discussion.

Example with Accept/Reject changes by clicking on the icons on the right of the page.
Example with tooltip dropdown
Items appear for accept/reject below the link when selected
Accept/Reject always displayed below the line.

Upcoming Travels

Some future travels coming up below. If you are nearby let me know if you want to meet for a coffee. Dates are not set in stone yet and might shift +/- a few days.

March 1-4 Berlin

March 5-10 Nairobi (Coko team meeting)

March 11-12 Berlin

March 13-15 Athens (Coko team meeting)

March 16 University of Sussex (panel on Digital Publishing with Geert Lovink and David Berry)

March 17-18 quite probably in the UK (Coko team meeting)

March 19-21 Slovenia (Coko team meeting)

March 22 -> back to San Francisco

Diversity and Open Source Solution Models

This week I attended the Linux Foundations Open Source Leadership Summit. It was a great event. Very relaxed and full of very nice people. Everyone I talked to had an interesting story or perspective to offer.

As far as presentations go, I was mostly interested in those that focused on diversity in open source. These were all very well presented and interesting. However, it was notable that these presentations often started advocating that diversity is essential for the future well-being of open source, but pretty quickly narrowed to address only diversity in the developer community.

This shouldn’t be surprising: the dominant model for open source is the developer-centric community solutions model. This kind of culture, where code is seen as the primary product, almost necessitates that developers are considered as the most valued participants since only developers can produce code. However this narrowing of the diversity discourse¬†to a developer-only focus¬†did surprise me. It woke me to the fact that the fight for diversity in open source is only going to go so far if the current developer-centric models for open source are upheld. As long as we put the production of code at the center of the project culture, we are only going to have limited success in improving¬†diversity within projects.

As far as I can tell, the total number of women developers is something like 15-25% of all people working worldwide as programmers. Some sources and posts that support this figure include the following:

The high end of the scale (25%) comes from the following¬†information, but the data refers to ‘women in computing’, which I think is a wider measure than if we were talking about programmers-only:

Although the US Bureau of Statistics also has around the same % (22.6%):

If anyone has other useful¬†stats, I’d appreciate knowing about them. At any rate, whichever way you look at it the % is low. But, the news gets bleaker when it comes to open source. It appears that women developers are even more under-represented in open source, as this article (based on information from OpenHatch) suggests:

According to a survey conducted last year, only about 11 percent of open source contributors are women. Meanwhile, women account for 23 percent of all computer programmers and 39.5 percent of web developers, according to the Bureau of Labor Statistics.

The % in the above article also reflects the % revealed during presentations at the conference. As outlined during the ‘Diversity in Open Source Projects‘ presentation by¬†Susan Wu, Daniel Izquierdo, and Nicole Rutherford, the figures were something like 9-10% of¬†developers are women in both OpenStack and the Linux Kernel communities.

An independent analyst group, Bitergia, reported that women represented 9.9% of the population contributing to Linux kernel development and was responsible for 6.8% of the activity. Bitergia also reported that women contributed to 10.6% of the code commits and reviews into OpenStack.

I have seen worse speculations. An interesting 2015 research project (A data set for social diversity studies of GitHub teams) looked at 23,493 Github teams and concluded:

75.3% [of the] projects in our data set had no team gender diversity at all, in any quarter.

So… (approx) 22% of the developer population worldwide are women, and women constitute (at best, but I suspect it is much lower) 10% of all open source¬†developers. Whatever way you look at it, it’s pretty grim and it outlines clearly the need to:

  1. grow the total number of women in programming
  2. grow the total number of women in open source

While these two issues may look the same, I think they need to be considered quite differently. Growing the total number of women in programming requires strategies to encourage women to consider programming as a career option, training more women programmers, and finding ways to improve¬†employment decisions (including hiring and promotion). While we would hope this would have a ‘trickle down’ effect, improving the representation of women developers in open source, we can’t ignore the¬†fact that the % of participation of women in open source is¬†already 50% lower than the general populace. Trickle down theory can only help by so much.

So, why is there substantially less representation of women in open source than in programming in general, and how do we address this?

Of course, this is not a new issue and there are many, many, people tackling his problem. The approaches range from changing the culture of open source projects to make them more welcoming, to promoting open source to women – and everything in between. But I’d like to add another approach to the mix….

Open source has celebrated the fact that it attracts people by appealing to¬†intrinsic motivations – the desire to get involved in a community and solve interesting shared problems together. Satisfaction is derived from participation in this process which is why I sometimes refer to open source as a culture-method. Creating the right culture is the primary concern for open source projects as a method for solving problems. Whereas getting a job as a programmer is often seen as satisfying extrinsic motivations – the need to earn money and have a stable/sustainable lifestyle. While intrinsic/extrinsic motivations aren’t a binary, plenty of people accept jobs at wages lower than what they could earn elsewhere because they are motivated by the aims or values of an organisation (and many developers work on open source projects to improve their CV), I believe this distinction is generally useful for understanding the difference between working as a programmer as a day job, and voluntarily contributing to an open source project.

But it is evident that many women do¬†not find participation in open source to be intrinsically satisfying. Otherwise, we would expect the percentage to be higher than 10%. So, no matter how much we promote open source to women developers, or hope for trickle down to improve the situation, the needle isn’t going to move much if the culture of open source projects is geared towards maintaining the status quo.

To raise the representation of women beyond 10% and perhaps to dream of moving it beyond 22% (why not 50% or higher?) we must change the culture of open source radically. We need to look deep into the heart of open source culture and rethink the foundational tenets of the open source culture-method.

To get there I believe we need to look closely at diversity of open source project culture as a whole and not consider developer diversity in isolation. To do this we must look deep into open source culture and ask ourselves a lot of very difficult, and possibly uncomfortable, questions such as :

  • is¬†a techno-meritocratic culture conducive to project diversity?
  • what are the dominant value metrics in open source and do they promote diversity within a project?
  • does the BFDL (or other) leadership model lend itself to the radical change in representation we are after?
  • is technical thinking¬†the only way to solve problems open source projects tackle?
  • do open source¬†workflows and tools¬†promote diverse participation of all members in a project?
  • why do we have terms like ‘non-coder’ and ‘contributor’ and what do they connote?

Take the time, if you will, to think about the above questions with regard to an open source project you are involved in. Then ask yourself the question – what would your¬†open source project look like if you designed it from the beginning with diversity in mind? As a further prompting, consider if there are ways the project¬†could¬†produce solutions¬†in a¬†non- developer-centric manner. Just do it as a thought exercise. Let your mind consider wild and crazy ideas such as ‘user-centric solutions models’ and think¬†through what that might look like.

We need to diversify the approaches to open source, and bring about solutions models (and, consequently, project cultures) that are intentionally designed to be, at their core, more diverse and inclusive. I believe this will mean discarding the developer-centric solutions model, which has not (as we have seen) proven to be inclusive, and building new models for solving problems together.

Note: I focused on pretty traditional gender roles in the above.  I understand gender is not a binary and that diversity is not only a question of gender but has wider inclusion issues such as ethnicity, language, income, physical capabilities and geography. My focus for the post was fueled by the discussions I had at the conference which were driven by the presentations which were, in turn, primarily about gender diversity.

Also, just to be entirely clear in case you missed it. I’m not arguing we should accept that there should be less women programmers than there are or give up hopes to increase the number. Nor am I saying ‘get the numbers up by counting everyone!’ (thereby obscuring the low %s of women in tech roles). These are two important issues but the above text is making another point – about how we solve problems in open source orgs and trying different ways to do this that¬†would also help with creating greater diversity of all kinds. Many thanks to my fellow Shuttleworth Fellow¬†Madeleine Ball¬†for making sure I made this clear to avoid misinterpretation.¬†

Editoria Demo

Below is a quick video demo of Editoria. The University of California Press today started a community forum to discuss the project. You can find it here (open to anyone):!forum/editoria-development

Editoria is open source (MIT license) and you can find it here.

The demo video doesn’t cover everything but I hope you find it interesting and useful.

Video made with Recordmydesktop on Ubuntu.

Open Source is not a Switch

If you ever hear anyone say a platform is ‘open again‘ then you would¬†do well to ask them “what the hell are you¬†talking about?”

Open Source isn’t a switch to be turned on and off. If it was treated like a switch, you would be very wise to consider when it might be again flicked to¬†the ‘off’ position. I think this is a topic I will bring up at the Open Source Leadership Summit¬†to which I was invited and will be attending this week. Specifically, I want to get people’s opinions on how¬†to communicate effectively to those that make these mistakes, including that Open Source is not a switch to be turned on and off. Personally, I find treating Open Source as a switch a stupid and infuriating rookie mistake but I need¬†to find a way to discuss it more constructively to help¬†people who make these errors gain¬†a clearer¬†understanding of what Open Source means.