Collaborations (CO)

COs are the way that SURF supports collaboration among researchers. Please refer to the chapter Working Together of the Research Cloud docs in order to learn how to create and administrate COs.

A CO consists of one or more admin members and other invited members that might come from different institutions. In Research Cloud, particularly, a CO can also have members with a "developer" status. Developers are granted special rights that enable them to create, maintain and share Research Cloud catalog items with other COs.


The way sharing is organized in Research Cloud is guided by two principles: owner-responsibility and the mutual chain of trust.


Each catalog item has an "OwnerCO". This is the CO that created the catalog item. The responsibility to maintain and repair a given catalog item is with the developers  of the OwnerCO. They take care that the catalog item works as expected and is shared only with other COs that are entitled to it.

Mutual Chain of Trust

In order to make the agreement on usage and maintenance explicit and personal, a developer can only share a catalog item with COs that s/he is also a developer-member of.

Thus, before any sharing of catalog items can take place, a developer of the offering CO must have been explicitly made a developer-member of the receiving CO.

This creates a mutual chain of responsibility and trust between COs:

The receiving CO ...

  • trusts the sharing developer to offer a working and well-maintained catalog item.

  • trusts the developer not to bloat the catalog with less relevant items.

The offering CO trusts the receiving CO to share the catalog item only with third COs that

  • are entitled to it

  • can actually make good use of it - especially considering the amount of support that would be required.

Alternatively, a developer of the receiving CO might also be invited to the OwnerCO instead of vice versa.

This also enables sharing and makes sense when the developer is going to help with supporting the catalog items of the OwnerCO.

Examples and Best Practices

Sharing plugins


A researcher is a developer in her CO called "A". She has created a plugin that installs Golang on a Linux system. "A" is the OwnerCO to that Golang plugin.

Other researchers also want to use that plugin in their applications and invite her to join their respective CO "B" as a developer.

She accepts the invitation to CO B. Now she is able to allow their CO B to CO A's Golang plugin.

More specifically, she can now add CO B to the list "Allowed COs" in the Golang plugin.

Sharing applications


A researcher has created an application. It is a composition of a number of plugins to form a specific data processing pipeline.

This Application is of use to colleagues in different COs. He can share this application with those other CO's following the same pattern as in "Sharing plugins".

He is entitled to use all the required plugins in the application through his CO-memberships.

The COs he is sharing with, though, do not have to have access rights to the plugins.

The researcher who has composed the application is the link in the chain of trust between the Plugin COs and the COs that are allowed to his application.

Sharing application offerings


The tutor of a course has created an application offering.  It creates a virtual machine where the software and data for a particular course are preinstalled.

In order to grant the course members access rights to the application offering, the tutor creates a CO in which he is a developer.

He adds this CO as an "Allowed CO" to the application offering.

The course members are invited as common members. That way, they can use the application offering to start their virtual machine for the course. They do not have to be developers to do so.

Minimal necessary scope for COs

COs are easy to create and to administrate. Generally, it is a good idea to keep them as small and as short-lived as possible.

When creating a CO, think about its purpose in terms of sharing.

For instance, you might want to have specific COs for sharing long-lived catalog items or other ones for experimenting with new plugins.

Also, as a general rule, a catalog item should only be made accessible to a CO when the item is relevant to all the CO's members.

If the catalog item is not relevant to all members, a new CO with a subset of the members should be considered.


In order to allow for continued support, each CO should have at least two users who are also developers in that CO.

Their memberships to other COs should intersect such that they both can maintain the "Allowed COs" lists of all the catalog items that are owned by the CO.

Four Eyes Principle

Within a CO, you can enforce the four eyes principle. This might be handy for long-lived COs that depend on a number of catalog items of other COs.

If you make sure that no admin member is at the same time a developer, the "invite and share" process remains transparent among the responsible CO members:

the developer has to communicate with the admin for invitations, and the admin has to communicate with the developer for sharing catalog items.