Jitsi vid quality

We are trying out Jitsi as an open source conferencing app to replace various proprietary (ugh) conferencing softwares we have used. It has always felt to me to be a bit of a last frontier… happily, though, initial tests are¬†awesome. Video and audio quality is way better than, for example, Google Hangouts. Below are screenshots from a 6-way call this morning between San Francisco, France, the UK, Kenya (via Android App), and Athens (x2). Quality looks great!






The big 4

I’ve been in the business of trying to work out how to get Publishing (capital ‘P’) into the web. From the start, there have been some ‘big ticket’ items that have needed to be solved. Some are more urgent than others, but by and large we are cracking these nuts one by one. I have considered for a long time the big 4¬†to be:

  1. MS Word to HTML conversion
  2. an open source web-based word processor
  3. paginated output via the browser to print-ready copy
  4. in-browser designer

1,2 an 3 are the ‘now’ critical items, number 4 is necessary but a little further down the line. Thankfully, at Coko we¬†are solving these first 3 problems. To solve (1) we are building XSweet, a comprehensive (open source) XSLT conversion suite for converting MS Word to HTML. We are also building Wax to solve (2), Wax is an open source web based word processor based on the Substance.io libs. And for (3) we are using Vivliostyle for in-browser rendering. Number 4) is still on the cards.

Interestingly, the pagination technology (3) might need re-evaluating since pagination will eventually be required for the editor and the in-browser designer.

While pagination inside a web-based processor is not critical for publishers, it is critical for authors and small offices etc and if we are going to get publishers to use a web-based word processor then it would be better that they share infrastructure rather than sit on their own island of technology ie. eventually¬†we need authors to use these tools too. By sharing infrastructure I don’t mean they need to use exactly the same tools, they just need to use compatible tools. So, eventually, we need to migrate authors into the web. It is not critical now, but over time, as the workflow for authors and publishers inevitably becomes more integrated, it will turn out to be necessary.

For in-browser design we need pagination support also so we can work off a single source for the content and then design in the browser to output to the various formats publishers need. Think Gimp or InDesign in the browser. It’s not as far away as it might sound, but to do this we need to be able to paginate inside the browser and have that update with live style changes to CSS.

So far, we are solving the big ticket issues 1-3, but for the next stage of changes we may need to change the tools we use for pagination so we can live-update content and styles and reflow in an editor and in-browser designer. That may mean we to start looking for a different pagination solution.

When a Code of Conduct is too much for some poor souls

Interesting to see this:

It is a discussion in the Node issues in Github about their Code of Conduct. One developer, with the handle ‘binoculars’, also known as Barrett Harber, is a developer from the Center of Open Science and objecting to the¬†idea of Codes of Conduct. To quote him:

I think the concept of having and effectively enforcing a Code of Conduct is fundamentally flawed…I think you’re alienating a much larger portion of your potential and current contributor base by handing over control to the wrong-think police…Obviously, this is not avoiding conflict. It’s creating conflict. Case in point, this conversation. We wouldn’t be having it if it didn’t create conflict.

and the following two bald statements which are absolute doozies:

I’m not concerned with people’s feelings….


There’s no definition of harassment.

jeeez……it is one of those amazing moments when the speaker doesn’t realise that what¬†they are trying to say¬†is, as the words come out of their mouth, making exactly the opposite point to everyone in the room.

Although this person seems to have a problem with CoCs in general, the critique is directly pitched at the Node Code of Conduct which is particularly hard to understand given that the Node CoC is pretty light, easy to understand, and (I would say) rather standard and non-controversial.

The conversation is blossoming a little around the net including here.

Going where your people are

Recently, I have been involved in some discussions around what tools to choose for open communities. This came up with regard to the Open Source Alliance for Open Scholarship (links to the new website coming soon!).

One argument that¬†always comes up with these kinds of discussions, and I have been involved in many, is that we should use platform X because ‘thats where the people are’. Because open source has lost in the platform game¬†(but its not too late) this argument almost always points to a closed source platform eg. github, twitter, slack etc

‘Going where the people are’ feels intuitively like a good idea. You want your project to succeed, go where the people are. Hard to argue against that. But argue against that we must, and I’ve started to think a little about how to counter this position better because sometimes, when people get stuck on this argument, there is no budging them.

One thing I have experienced recently that has fed a counter argument is the growing community around Coko. We use Mattermost and Gitlab as our primary web spaces for community and collaboration. What I notice with¬†our gitlab, for example, is that when you open it up in the browser it looks like Coko. It looks like a home for a variety of connected and interesting projects that all revolve around Coko’s mission to reshape publishing. It is my hope that this will grow to be even more true over time. If that proves to be the case, then this gitlab instance will be a home (possibly one of many) for a certain approach and certain kind of thinking about how to change publishing. And that there is incredibly valuable because it speaks to the need for your community tools to surface and reflect¬†your communities activities and values.

Coko GitLab

That’s not so easy to do in github. Go to a github org space and it looks like every other github org space. It looks¬†dull. It reflects the identity of¬†github and not of your community. This doesn’t just come down to theming, but it comes down to more subtle nuances such as with gitlab¬†(or similar open source solution),¬†the¬†space is committed only to the things your community is doing. Things that are not connected are¬†not a click away. From a community members point of view its a space dedicated to them.¬†In this day I believe this is increasingly more unusual, important, and appreciated.

Consequently, I use the argument that developing community identity is more important than ‘going where the people are’. Don’t create a space ‘where the people are’, create a space where your people can go.

Self hosted open source video conferencing

I have tried various open source video conferencing apps. Actually, as it happens my first introduction to open source was through streaming back in the day. Since WebRTC came on the scene I have been excited by the possibility of open source web-based video conferencing. However, the promise seemed to take a while to deliver. I tried many products, the most sophisticated and promising being, for a while, BigBlueButton. But BBB, and other softwares, just seemed so clunky and hard to install, ugly UI etc. We installed and ran BBB for Coko but no one really wants to use it and we had bandwidth issues etc. Sorry to say it, but open source has been lagging behind the closed source world with regard to video conferencing.

I have been keeping my eye on Jitsi for some time. It looks pretty good. But I was caught up with my legacy understanding of such systems and it took a while, also, for Jitsi to evolve. I tried out their demo for a few meetings but it had some lag issues. Of course, trying out a demo ‘for real’ is a bit dumb and I should not have expected anything like you want in a real world production environment. But… I was a little deterred. I also assumed it would be hard to install.

Finally, this weekend I thought I would give it a go…so I started up a digitalocean droplet (a server) – which costs $20 a month and took about 2 mins to get going. I then followed these instructions –¬†https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md. I had a Ubuntu install at digitalocean so followed those steps. But I expected complications…the install mentions it relies on jitsei-videobridge and I thought… I bet this doesn’t work…I’ll have to install some mad java app or something…What do you know…within 5 mins I had a working version of Jitsi-meet! amazing! The process worked as described, basically 3 commands and it was running.

If it works for Coko it is also very interesting because Jitsi on the front end is all JavaScript and there seem to be some react components…which means we could integrate into xpub/editoria (publishing systems) etc…

We will try it out in the next weeks. Expect more info soon!

What I’m listening to now…

Currently listening to Hearing Music by Joanna Brouk. Super crazy beautiful. Sparse, drifting tones Рsynth, flute, piano, field recordings. She is an American composer that died earlier this year. Hearing Music was released in 2016 as a compilation of some of her works previously released on cassette tape. Just amazing.


Also listening to Tower of Silence by Roberto Musci.


Also a compilation of hard-to-find earlier releases. Sometimes cacophonous, but mostly eerie and soothing at the same time. A mix of field recordings and almost every instrument you can think of from water drums to French horn and synth. Also fantastic.

Yep, its a brief brief

Following up an earlier post I made about the Collabra journal brief, here is the updated version with mocks.


Mocks by the talented Julien Taquet. You can follow xpub development here https://gitlab.coko.foundation/xpub/xpub and Design Briefs and issues are all contained here https://gitlab.coko.foundation/xpub/xpub/issues.

If you want to learn more about xpub or wish to be part of the xpub effort then join us in the Coko chat!

We are working on the above brief, but the second brief is already posted to the repo above.