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.
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.
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.
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:
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.
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.