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 components and catalog items with other COs.
Principles
The way sharing is organized in Research Cloud is guided by two principles: owner-responsibility and the mutual chain of trust.
Owner-Responsibility
Each component and catalog item has an "OwnerCO". This is the CO that created the component or the catalog item. The responsibility to maintain and repair a given component or catalog item is with the developers of the OwnerCO. They take care that the component or 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 component or a catalog item with COs that s/he is also a developer-member of.
Thus, before any sharing of component and 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 component or a catalog item.
trusts the developer not to bloat the catalog with less relevant items.
The offering CO trusts the receiving CO to share the component or 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 components and the catalog items of the OwnerCO.
Component access additional options
For a component the Owner CO can also choose to make the component "public", this means that developers in any CO can use the component in their catalog item.
Once a developer gets access to use a component they can use it in a catalog item. If component access would be restricted later this means the catalog item won't function anymore. Therefore we don't allow component access to be limited at a later time. You cannot remove "public" access from a component and you cannot remove access to specific COs. If this causes problems you can contact the servicedesk for help.
Examples and Best Practices
Sharing components
Example:
A researcher is a developer in her CO called "A". She has created a component that installs Golang on a Linux system. "A" is the OwnerCO to that Golang component.
Other researchers also want to use that component in their catalog items 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 component.
More specifically, she can now add CO B to the list "Allowed COs" in the Golang component.
Sharing catalog items
Example:
A researcher has created a catalog item. It is a composition of a number of components to form a specific data processing pipeline.
This catalog item is of use to colleagues in different COs. He can share this catalog item with those other CO's following the same pattern as in "Sharing components".
He is entitled to use all the required components in the catalog item through his CO-memberships.
The COs he is sharing with, though, do not have to have access rights to the components.
The researcher who has composed the catalog item is the link in the chain of trust between the component COs and the COs that are allowed to his catalog item.
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 components.
Also, as a general rule, a catalog item or a component should only be made accessible to a CO when the item is relevant to all the CO's members.
If the catalog item or the component is not relevant to all members, a new CO with a subset of the members should be considered.
Continuity
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 and the components 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 and components 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 components and catalog items.