Coko and Open Source

We’ve tried to build software for other people before, but it wasn’t until we worked with the Coko Foundation that we realised how important a “community-first” approach is. The benefits from the conversations, before any code is even written, is obvious when you start writing and even more obvious when you see the quality of the finished product.
– Paul Shannon, Head of Technology, Elife

Paul Shannon is a great advocate for the way we work in the Coko community. eLife was one of the first to see the potential in the way we work, and I remember clearly sitting in a pub talking to Paul about it with Kristen. He was enthusiastic and genuinely supportive when we explained in straight forward terms that we were trying to establish *real* collaboration and not collaboration in name only which is unfortunately so often the case.

We work closely with Paul and the eLife team, as well as the Hindawi team, and in many cases we are each extending the others team. That is what close collaboration is all about. As Paul states:

I love the pleasant surprise when one of your collaborators solves a problem for you, or when you find a problem you thought was just unique to you being discussed elsewhere. For us, the main benefit is knowing that what we’re building is useful to others and is solving the important problems – things get built more quickly and more correctly which reduces the burden on everyone.

This is very true. In a community when you share the burden of a problem you have the luxury of bringing in a bunch of active minds who have a desire to solve the same thing but are not on your payroll. So, you can leverage expertise in areas that your team doesn’t necessarily have. Software development in publishing these days covers a huge scope – everything from workflow, to file formats, OAuth, to containerised deployments and much more. Its hard for any one team to have that scope of expertise. But we have so far found, even with our relatively small foundational group, that we have always been able to find someone in our community that knows a lot about any given problem space.

So, extending your own team and being able to reach out to others with specific expertise is a huge advantage of working in the Coko community. But it doesn’t stop there. It is often the case that someone will be able to improve on your approach to a specific problem, and sometimes it is also true that someone in the community will offer to build it since they have the same need.

dsc04921

This leads to, as Paul says, things getting built more ‘quickly and correctly’. I absolutely agree, as does Andrew Smeall of Hindawi who also collaborates with us:

[Coko] have marshalled a diverse group of publishers towards a shared goal. Together, we’ve implemented a radically open process of constructive collaboration, where each member benefits from the strengths of the others. The result has been rapid progress towards an elegant, maintainable product.
– Andrew Smeall, Head of Strategic Products, Hindawi

This is awesome stuff. Imagine not having to solve all the problems of building a publishing system by yourself?

Of course there is a cost to this. To communicate this I sometimes use the phrase ‘The cost of collaboration is conversation”. This is very true. In order to benefit from collaboration in an open source project, you have to be communicative. We have several mechanisms to help with this, the mattermost chat channel is one. If you visit the Coko GitLab (where the code is stored) you will also find it is very active with conversations in the commits and the issues (eg https://gitlab.coko.foundation/XSweet/XSweet/issues/106) . We also have a lightweight RFC process (eg https://gitlab.coko.foundation/pubsweet/pubsweet/issues/341), and we also have smaller WorkGroups for developers and designers. These WorkGroups consist of one person per collaborating organisation each meeting and is facilitated by Coko. This keeps the group small and the conversation focused, lowering the overhead for all.

The result of all this is that we can keep the overhead low, and produce better products than if we were working alone.  We can also produce them faster, learning from each other as we go. As Andrew also says:

An improvement for one becomes an improvement for all. Individual communities can focus on core areas of expertise — peer review, hosting, discovery — knowing that their innovations will improve the entire system.  The result is more creativity, a more diverse set of solutions, and, ultimately, faster progress.

There is a secondary benefit too… communities are in themselves motivating, as Paul Shannon says:

Having other people build components to solve the problems you are facing is a great benefit of a common infrastructure, but also knowing that what you’re building is useful to more than just your team really adds energy and purpose to our teams of developers and designers.

All in all, its hard to argue against this kind of value in collaboration. I’m not currently seeing any downside except (for me) lots of travel! But thats in my DNA now, so I can handle it….would be good though if there was better surf in London and Athens…

We will add more organisations to the mix as we go…some announcements coming shortly. But here too we are being careful. Its important that we add the right orgs, ones that have a willingness to put in as well as take out…we don’t want to host parasites… this ecosystem can only work if there is close communication and a dedication to working together. This requires trust and good faith and if an org enters this tight community with the intention of free riding they will soon find out they are not welcome. For this to work for you, you need also to work for it. It is not a one way street. If you can accept that and get into the right mode, you will benefit greatly AND you will have a great time… communities are also fun when done right and so far our community meets are super fascinating and filled with awesome folks. It is an honor and a joy to hang out with them and solve problems together.

dsc05118

One of the additional benefits, which I touch on above, is learning from each other. In the last community meet, we had a few weeks ago in London each of the three foundational orgs – Coko, eLife, Hindawi – presented where they were with their journal platforms built on top of PubSweet. Each had taken slightly different paths to solve similar problems. There was much overlap of course, but where I learned the most was where someone had tackled the same problem slightly differently…this was really the first time this had occurred in our community and it was tremendously exciting.

As it happens, there seem to be quite a few orgs wanting to jump into the community. So, from here, it is all about scaling gracefully. We will work out processes to manage and maintain this good faith and good will as we grow. The foundations are there, now it’s all about the mechanics of growth…

Workflow Tweaking at Coko

Yannis and the Athens crew have been tweaking our workflow for the products built on top of PubSweet. This includes (at present) Editoria (book production system) and xpub-collabra (Journal system).

Essentially, after the initial design and build process we slip into faster iterations where I step out of the way and the ‘client’ and developers work in very fast iterations to tweak features and fix bugs. We loop in Julien for UX as necessary. Then we move into a stabilization phase for landing the product.

Right now both Editoria and xpub-collabra are in the tweaks and bugs phase, and we have started adding a ‘roadmap’ to each of the READMEs to list what we are working on now. See:

https://gitlab.coko.foundation/xpub/xpub#roadmap

https://gitlab.coko.foundation/editoria/editoria#roadmap

We’ll be adding a similar table to XSweet and other products. It is a simple, readable, format.

GitLab as Back up

GitLab has a great feature for backing up git repos located anywhere. You can just provide a URL and it will clone that repo and poll every hour for changes and update the mirror accordingly. Info on it here:

https://docs.gitlab.com/ee/workflow/repository_mirroring.html

Super easy to use. I’m using it as an additional backup (we have other back up processes) of our main Coko GitLab repo.

screenshot-2018-3-24-projects-%c2%b7-dashboard

It Always Amazes Me…

Book Sprints is something that popped out of my brain and a lot of experimentation. It’s now its own thing and it constantly surprises me.. .here for example is a post about a Book Sprint last week, where my friend and colleague Barbara Rühling facilitated Cisco to produce a book in 5 days. It had 100 illustrations (!) and will be printed next week…incredible..

https://www.booksprints.net/en/blog/catalyst-9000-done/

I currently don’t facilitate Book Sprints as my Shuttleworth Fellowship requires me to focus on Coko, which is fine with me. It is in good hands 🙂

Rolling Birthday…

I had a rolling birthday over a few weeks. Covering NZ and Berlin, maybe soon birthday drinks in SF….First was  bbq at my place in NZ with the neighbors and Nokome, Jure and Yannis… then dinner with Ma and some old family buddies, and then drinks in Berlin… It was cool for me to see people from different parts of my life hanging together. some photos…

dsc04828

dsc04833

dsc04838

dsc04844

dsc04856

dsc05187

dsc05189

dsc05197

dsc05200

img_0573

p1010457

p1010458

p1010459

p1010462

Pondering Editors

Editors are a hard problem. I don’t mean editors-the people… although that might also be true 😉 … I mean the technology you use to write and edit WYSIWHAT?documents. Its tough stuff. Over the years I’ve bet on several of them starting when I first replaced the native wiki-markup editor in TWiki with TinyMCE… and then later CKEditor…and so on with FLOSS Manuals..

The point with editors is that they are like racehorses… you put your money on the best one available at the time. They will win for a while, but no horse lasts forever.

After I abandoned TWiki and we started building Booki, which was later to become Booktype, I brought a bunch of people together in Berlin at an event called WYSIWHAT? to choose the best horse. Which is funny to me, looking back at it, as I had forgotten that over the years I’ve been involved in trying to build community around several different editors.

imag0618

I had gone into the WYSIWHAT meet thinking it might be the Mercury Editor which was an extremely innovative editor at the time… but the community chose Aloha Editor (see also Kathi Fletcher’s notes from the meeting). So we built that into Booktype. Aloha has since been left behind, although at the time it was the right choice. Funny thing is with these things I still hear people saying “jeez…you chose Aloha, and it wasn’t the best choice”…well… big news… it was the right choice a the time but if you haven’t looked at a clock lately then you might need to be reminded that times change… I wouldn’t pick Aloha today, nor would I pick TinyMCE… you got to go with what is the best choice at the moment.

Then, I chose the Wikipedia Visual Editor for the Tahi/Aperta project. Which was complex, but the right choice at the time.

So, through this history, I have learned some stuff… In my mind, there are several things to consider when choosing an editor, or the underlying libs for building an editor (which is what we are doing now with the Wax editor at Coko). Essentially they come down to:

  1. will itdo what you want it to do technically?
  2. is there good documentation?
  3. is there good community?

It goes without saying that I am talking only about Open Source options. And, just to point out the obvious, with closed source options you might do well on (2) above for user (but not API) documentation, but fail on 1 (because you can’t see the code) and 3 (because closed source isn’t about a development community).

Anyways… now we are somewhat down the road with what we are doing at Coko, we know a lot more about community and why it’s important. For that reason, the above would have once been my order of priority a few years ago, but today it looks more like this:

  1. is there good community?
  2. will it do what you want it to do technically?
  3. is there good documentation?

You can go a long way with community support if the tech isn’t quite there – either with help to work out ways to do things in ways you hadn’t considered, or by eventually getting features you need into the core code. In essence, a good community plays a supporting role (as a good community member you should reciprocate) and a good community listens to what it is that you need…

Although docs are very important, and every project should have them, a functioning community can also help a great deal if the docs are lacking.

That’s not to say that the ideal solution doesn’t check all the boxes (community, tech, docs)… just to say that an open source project with community ranks miles above one without. It is going to be more fun and get you where you need to get quicker. Also, and perhaps most importantly, an open source project with community is substantially less risk for you going forward. The more active the community the less chance the project will die if any one individual decides to leave or change direction.

So… back to the races…