Tribulations in Open Collaboration, Part 1.
This is the first part of a series on tools for open collaboration. This first part will focus on managing content in an open way with collaborative editing platforms. In the next posts we'll look at file sharing and document management, task management and communication tools.<!-- more -->
One way I like to procrastinate is by trying to find betters tools. When things aren't as smooth and natural as I would expect, then after a while I go for a round of search and trials, fill up comparison spreadsheets - like for project management software - or think about how to build tools to compare tools better (no really). I find it edifying to see how different people think differently about organising the way they work. Well that's my justification anyway, sometimes it's just me spending too much time thinking about doing rather than doing...
Our team is tech savvy, willing to experiment and push the boundaries of how we do things. For instance, with the Open Integrity index, we've tried to be as open as possible during the implementation of the project. In her art and writing, Kat is a supporter of Open Access publishing and Creative Commons. Sam is completely dedicated to the principles of sharing, such as his log about his time at Open Source Ecology, with the aim of allowing to build on top of what he's done.
In the world of Open practices
As when I start any new project, I've been researching the best ways to work together openly for Droplet. I've used different approaches for different projects, both to try them out and to cater for different audiences and teams. There are some great experiments out there to learn from: from the more business inspired to the more community driven.
Gittip's founder - also one of the initiators of the (Open Company Initiative](http://www.opencompany.org/about/) - made it a practice to hold partner calls "on air". There are also some formal methodologies out there to implement an Open Design process like the Open P2P Design Toolkit - "a simple tool for helping people approach design thinking on a metadesign level". Sounds simple to me! Though it would be nice to see the source for the toolkit on github.... And the Open Design Definition which however probably will focus on the nature of the knowledge shared rather than the processes that enable it.
Putting it in motion
Droplet aims to adhere to the principles of the current version (v0.3) of the Open Design Definition and in particular commits to ensure that the "source documentation is made publicly available so that anyone can study, modify, distribute, make, prototype and sell the artifact based on that design." So then what about our processes and tools?
There's a spectrum of choices out there from using "ready made" tools that are proprietary and cost money or to integrate various existing open source components to achieve desired functionalities. I'll mention both approaches, but often in order to test if a process is the right one, it's good to be up and running fast and online platforms can be a good way to do that. You can then migrate to open source tools when you know the process works for you.
For us text means rich text, our design documents, engineering documents, blog posts but also sometimes spreadsheet data like our budget data. Allow a team to work together on text during various moments in the project - when face to face, in a call, when we're working separately - is a way to make sure you capture things as you go along and that people are on the same page.
Real-time collaborative editing is a good way to capture the important elements of a conversation and have a easy to access place where everyone can jot down their ideas without interrupting the conversation. In fact sharing links and pictures can help enhance a conversation as long as participants keep the right balance between face time and screen time.
We like Markdown and the alternate flavors of markdown because they allow you to write your formatting without interrupting your writing of content. I particularly like interfaces which format your text live - such as Penflip, but also FoldingText, Task paper is also an interesting variation on live formatting for task management - and I find them much better than interfaces that require to click on buttons to achieve the same goals, so while we started on google docs (because of the Google Drive integration, the Spreadsheet and the new Track Changes add-on) we've been looking into other approaches.
We also need versioning and commenting and ways to allow the public to contribute in these ways. Ideally we want to blur the lines between content publishing and collaborative documentation where various circles in the community contribute and have the permission to "publish" (which might mean the same thing as merging or accepting pull requests).
In summary the features we are looking for are:
- Realtime collaborative editing
- Distraction free writing
- Inline (live) formatting
- Versionning (Git)
Open Source Tools
Etherpad-lite (and its plethora of less known plugins)
Substance shifted its focus to desktop document editing (when originally it was also looking at realtime web based collaboration. But I keep an eye on this one because its technology fundamentals are great!
Penflip - which this blog post was prepared on, but doesn't allow for live editing by multiple users. However it allows to completely open text to external collaboration. It has "git" at its core and therefore also allows to do version control and offline working. It has some UX problems however, for instance comments are only attached to request for modifications of the text. Also saving is a two step process (committing and pushing) which can be confusing and can be forgotten.
Typewrite - which does allow live editing but doesn't have document folders like Penflip, and doesn't allow to comment or integrate with a git workflow.
Stackedit - which seems promising, connects to Google Docs and Dropbox while still using Markdown. Is able to publish to github. We might try this next since Penflips's overall UI is not fantastic.
I feel that the tools in this space have been changing fast in the past year. I think that organisations need to invent the processes that will work to make the most of them. I've been told before that the most important is to just put your code out there. You can't claim to be "wanting to be open source" and have nothing out there for others to look at. There is a shyness and counter-intuitive thing about putting your unfinished work out there, but I find it's a healthy practice, very much worth the effort. To be honest, we can't claim to have any open source project that has garnered enough attention for it to reap the benefits of the collective intelligence and cognitive surplus pouring our way. But Panic Button might become that, and hopefully Droplet and our other projects too. Until then, it just puts the right sort of pressure on us to deliver better work and think more about how to engage with contributors beyong traditional boundaries of organisations, roles and status.
We'd really love to hear from you about your thoughts on open collaboration. Have you got a project where you're trying similar things out? Is there anything you think we could improve on? At the moment the best way to do that is to comment here on the blog, submit a change to this blog post to improve it or contact us through firstname.lastname@example.org - but we're going to continue to try to improve on those means too!