Open Source – Instructions for Application
As a rule, the University of Helsinki favors open technologies and open-source solutions. The use of open-source principles is recommended when developing software and software components for the University.
See the Open-source code principles on the University website.
On this page you will find practical instructions for applying open-source principles.
You should familiarize yourself with the points related to your own role, whether you are the project owner (PO), project manager (PM) or developer.
Scope of application (PO, PM)
The open-source principles are a declaration of intent and recommendation approved by the CIO.
The University of Helsinki is a publicly funded operator, and its strategy strongly supports openness. It is recommended that source code produced at the University or as an outsourced service is published as open source.
Source code referred to in the principles may be created, for example:
- When producing applications internally or as outsourced services for the use of University administration or teaching activities.
- When producing add-ins internally or as an outsourced service for existing applications, such as publishing system modules.
Research activities have separately defined open science principles, so these are excluded from the recommendation. Similar recommendations can be found in the principles of research activities.
Deviating from openness (PO, PM)
Deviations from the principles are permitted on reasonable grounds. The reasons may differ –some examples are listed below:
- An old application that has been developed before the implementation of these principles and the material of which is not suitable for publication.
- When collecting feedback on the principles, this was raised as a concern. This is also an example of how open source often leads to better quality and a well-designed end-result. This benefits the maintenance and further development of the application. Code unsuitable for publication also typically means poorly understood and poorly documented code.
- In the case of such applications, efforts should be made to make the material ready for publication, for example, during more extensive further development rounds.
- Information security, for example, in cases where sensitive information is processed. Quality control of this kind of software is, as a rule, exceptionally precise and subject to separate information security assessments.
- If the University's Information Security team or a separate information security assessment recommends that the code should not be published, this is a justified reason not to publish it.
- A part of the software can, however, often be published openly despite such a recommendation.
- The source code is related to the configuration of individual systems that cannot be generally utilised.
- Scripts used for configuring the application for use by the University of Helsinki.
It is also possible to develop in a closed environment, e.g. on the University's own GitLab servers, and to publish only production versions for wider use.
Ultimately, the openness of the software is decided by the system owner based on these principles.
Cooperation and sense of community (PO, PM, developers)
Software development often aims to meet a specific need, and these needs are rarely specific to an organisation. Many other universities, higher education institutions and organisations are also trying to solve, or have already solved, the same problems.
It is also recommended that the needs and solutions of parallel communities as well as the opportunities to meet these needs by participating in existing projects or cooperating with other organizations are explored.
Quality objectives (PM, developers)
The main goal of open software publishing is to enable the utilization of the software elsewhere as well. This sets goals for the quality of the software. The quality objectives of an open source application do not differ from the quality objectives of closed applications, but openness makes the achievement of these objectives subject to public assessment.
Reliability, reusability, and maintainability can be improved by good application development practices, such as:
- Well-designed architecture.
- Modularity. The software is divided into functional parts that work with other parts through defined interfaces.
- Adhering to commonly used code and documentation models.
- There are commonly used style guides for many languages and software developments.
- Components of the external software are implemented following the style guides concerning the respective application.
- Clarity, an explanatory approach, consistency and simplicity in code and documentation.
- Code testability and sufficiently comprehensive automation testing.
- Code check by another person before publishing.
- Using tools developed for code analysis.
Selecting the license (PO, PM, Developers)
Open source always requires a license. The selected license defines how the source code can be utilized, and the source code is not available for external use without the license.
The license affects the possibilities and conditions under which the software or parts of it can be reused. The license may also exclude the use of certain components in applications.
It is also possible to use licenses other than those recommended for a justified reason.
The primary recommended license for source code is MIT (model):
- The license was developed at the Massachusetts Institute of Technology in the United States.
- The MIT License is easy to understand.
- The MIT License does not obligate the creator to do anything.
- The only restriction is to keep the copyright text and license information in the distributed parts.
- The MIT License allows sublicensing for a more limited license, which means that it can be used as part of an Apache 2 or GPL licensed application, for example.
If the source code is produced as part of a finished project, it is justified to use the license for the project in question. Many applications also use copyleft licenses, in which case the use of components requires the release of a software code under the same license. A good example of this is Drupal, whose modules are released under the GPL version 2 or later license.
MIT is primarily a software code license and may not be suitable for all other purposes. For separate documentation, images, etc., an up-to-date version of the CC BY license belonging to the Creative Commons license family is recommended. The material can also be published for completely free public use (Public Domain) using, for example, the CC0 license.
Place of publication (PM, developers)
For open-source code to be available to everyone, it must be published on a release platform designated for source code. The de facto publishing platform for source code is GitHub. GitHub is a code-sharing platform implemented using the Git version control system (https://github.com/).
The primary publishing location for the open software of the University of Helsinki is the GitHub University of Helsinki organization (https://github.com/UniversityofHelsinki) or the official GitHub organization of the unit.
The University’s GitLab services are often used in development, but it would also be good to publish production versions of these at least on GitHub and guide development-related issues to the right place.