Practice Report Open Science: These Tools Promote Collaboration

we were talking with Lukas Galke

Tools for digital collaboration are central to open science. But the variety of available tools is hard to oversee; building a suitable portfolio is complex. In our interview, Lukas Galke gives an insight into his project practice and explains criteria for selecting suitable tools. He is a research associate in the project “Q-Aktiv” (link in German) at the ZBW. The project analyses the dynamics of the science and innovation system and looks at research questions such as: How do existing science and technology sectors merge? Or: Which fusion of disciplines and technologies can be predicted? ZBW’s joint partners are the Chair of Technology Management at the University of Kiel and the ZB MED – Information Centre for Life Sciences.

How do you organize your everyday project life in Q-Aktiv?

In the project, there are three of us scientific employees who work in different places. It is essential to exchange ideas and to discuss intermediate results; to work together and coordinate. We are very focused on collaborative tools. Roughly speaking, one can subdivide these tools with regard to their purpose: communication, cooperation and coordination.

Could you explain in detail which tools you use?

On the one hand, the “communication” group includes the asynchronous tools with which I can transmit messages with a time delay. Of course, in Q-Aktiv we use e-mails – but also issues in GitLab. On the other hand, this group includes the synchronous tools for audio and video conferencing. For this, we prefer to use Jitsi-Meet instead of Skype, for example.

The “cooperation” group includes tools that facilitate distributed collaboration. Access and version control are the key features of these tools. While access control should just allow distributed access for the participating actors, version control is important in order to bring together different versions of the respective actors in the best possible way and, if necessary, to be able to undo changes.

In Q-Aktiv, depending on the use case, we use different collaborative tools for cooperation. For scientific articles we use Overleaf. Overleaf is a LaTex-Editor in the browser that also supports synchronous editing. The version control is implemented by Git, so it is also possible to edit the LaTeX code locally and load the changes with a time delay. To use Overleaf, no local LaTeX installation is necessary. Along with automatic compilation and hints for LaTeX code errors, working with and getting started with LaTeX becomes a lot easier.

But when it comes to working together on source code for programmes or experiments, we rely on Git. As a platform for Git, we use GitLab. GitLab is related to Git as Overleaf is to LaTeX. It provides a central hosting and offers various convenience features, for example, to view the changes between two versions and to comment on them.

In the area of “coordination”, defining action items and milestones is particularly relevant. Again, there are collaborative tools such as Atlassian’s Jira or Trello. However, in Q-Aktive we also use GitLab for coordination. In GitLab, issues can be created and assigned to individual actors if necessary. Milestones can be assigned, too. In particular, further details within the issue can be discussed. We also use Git or GitLab to work together on agendas for project meetings or workshops, record their protocols, share relevant literature, record a common vocabulary, and share presentation slides. For this purpose, we have created a special, separate repository within the project group.

Why does GitLab play a central role in collaboration in your project?

The big advantage of platforms like GitLab is that they cover many different requirements at the same time. I find that very enjoyable because it’s a central entry point; I therefore do not have to manually connect emails, source code, to-do items, and milestones. Instead, this is clearly summarized on a single platform and cross references can be generated at will.

Another advantage of GitLab is that it is under the MIT license in the community edition. This not only means that the source code of GitLab is transparent, but also that an institution or a private person can set up their own GitLab instance and thus does not rely on any external hosting provider. This is a unique selling point compared to the recently acquired by Microsoft competitor platform GitHub. Although this is a central place – probably the largest – for open source software, GitHub’s source code itself is not open.

For the other tools we use in the project, we had similar motivations in the selection: Overleaf is based on free software (Git, LaTeX, ShareLaTeX). If the central Overleaf instance fails, you can seamlessly switch to Git and LaTeX. Of course, if necessary, then you need the local Tex installation if it isn’t available. With regard to virtual project meetings or meetings in the working group, we decided on Jitsi-Meet. Jitsi Meet is also under an open source license (Apache 2.0) while providing a convenient interface (without login) to hold videoconferencing.

At what points do your current tools reach their limits?

Mainly for Word and PowerPoint files. Although these can be exchanged wonderfully over Git, here the version control is problematic. Git usually compares files line by line. However, in their saved state, Word and PowerPoint files are not structured so that they can be compared line by line. Even LibreOffice documents would not perform better under the aspect. Git reaches its limits here. While certain patterns for interim reports or presentation slides are often only available as Word/PowerPoint templates, we prefer writing scientific articles with LaTeX. LaTeX is a Turing-complete programming language and the source code can be perfectly compared line by line. On the other hand, we use Markdown as a flexible format for smaller documents.

What must tools be able to do to support collaboration well?

As with all tools, it is important that the cost of using the tool is not greater than the utility of the tool. For collaboration tools, the benefit is generally collaboration (for example, between project partners). However, this collaboration manifests itself in various aspects such as communication, cooperation and coordination. For each of these aspects, it must be considered separately whether the use of a tool in a benefit-cost ratio is worthwhile.

Good collaboration tools are those where the costs are as low as possible. Because the benefits of collaborative work are usually high, the cost or effort is often the critical issue. If the tools for several aspects are grouped together in one platform, the “costs” required to familiarize and use the tools will decrease. This is how synergies between the tools develop. Apart from that, good collaboration tools should be based on free software. Otherwise, not only do the indirect costs with respect to the incorporation and the overhead for the use of a tool increase, but so do direct costs – such as by additional license fees for proprietary software or, where appropriate, by the adjustment of the partner systems. Free software usually uses established and above all non-proprietary standards, which constantly promotes synergy effects. Even a Linux system is based on thousands of individual programmes that work so well together to create a full-featured operating system – although each of these programmes serves a well-defined purpose and has been developed by a different programmer.

Back to collaboration tools: From the ingredients of many small tools created by synergies arises a kind of menu for collaborative work. This menu is packaged in convenience tools like GitLab and Overleaf. Of course, there are other convenience tools as well, but the same principle applies here as with food. Convenience is only as good as the ingredients it contains. When eating, good ingredients are possibly plant-based and natural; in software, good ingredients are free and open software as well as established standards.

What is personally important to you when using collaborative tools?

For collaborative tools, as with any other programmes, it’s important to me that they are free. Free software not only means that it is free to use or that the source code is exposed, but in particular that “users have the freedom to execute, copy, distribute, study, modify and improve the program [i.e.] for free as in free speech, not as in free beer.” – Richard Stallman.