Open Development

Introduction

Open Source

• Publicly accessible source code
• Permission to use, modify, and redistribute
• Driven by transparency and collaboration

Open Development

• Development process is open to the public
• Encourages community participation
• Transparency in decisions, priorities, and changes
• Examples: Linux, Mozilla Firefox, Kubernetes

Contribution

How to Contribute

• Usually host on platforms like GitHub or GitLab
• Fork repositories and create branches
• Submit pull requests and open issues
• Check for a CONTRIBUTING.md guide

Guidelines and Conduct

• Contribution guidelines (see before)
• Respect the Code of Conduct¹
• Communicate clearly and constructively

1. Examples from MousePaw Media Standards

Licenses

Why Licenses Matter

• Define how others can use your code
• Protect both contributors and users legally
• Enable sharing with clear rules

Intellectual Property Rights

Two main legal concepts relevant for software:

• Copyright = legal ownership
• Copyleft = reuse allowed if shared alike
• Balancing freedom with protections

• Any creative work, be it information, literature, art, or software could be replicated if not protected by intellectual property rights.
• copyright can be granted by public law and depends on the given country/state. In Germany, the German Copyright Act (Urheberrechtsgesetz) regulates copyright.
• because of Copyright, we need to think of licenses that regulate usage, modification and sharing of software
• other types of IP rights: patents, trademarks

Types of Software Licenses

• Public domain: No restrictions on use, modification, or distribution
• Permissive: Minimal requirements for reuse (e.g., MIT, Apache 2.0, BSD-2)
• Copyleft/Share-alike: Derivatives must use the same open license (e.g., GPL, LGPL)
• Proprietary: Use, modification, and redistribution are restricted

Further reading

• if you upload code to GitHub without stating a license, in principle, nobody is allowed to use it
• ICON has BSD
• GNU General Public License (GPL)-licensed code cannot be integrated with proprietary closed-source code. mostly used for Linux software
• GPL, AGPL - require sharing of modified source code; LGPL allows linking with proprietary code
• changing licenses can be a huge challenge.
• Unlike proprietary software that places restrictions on usage and distribution, open source software guarantees end users the freedom to use, modify, and share the software.
• more Info here: https://osssoftware.org/blog/open-source-software-licenses-explained-a-beginners-overview/

Creative Commons (CC) Licenses

grant permission for use of copyrighted creative works

• Applicable to images, videos, presentations, …
• CC0: Waives copyright, placing work in the public domain.
• CC-BY: Use allowed with attribution.
• Additional tags: SA (share alike), NC (noncommercial), ND (no derivatives)

check the footer of this slide 😉

Is AI-generated work protected by copyright?

Unclear. Many countries do not put AI-generated work under copyright, but others do (e.g. China).

Documentation

The Value of Documentation

• Helps others understand and use your software
• Onboards new contributors faster
• Can convey intended use and limitations of a tool

What should we document?

intent and usage

Next to source code and data, we need documentation to reproduce an argument.

Types of Documentation

• READMEs: overview, setup, usage
• Manuals: deeper technical or user-focused content
• Docstrings: inline function/class documentation
• Comments: explain why, not just what

Docstrings

def sum(a, axis=None, dtype=None, out=None, keepdims=np._NoValue,
        initial=np._NoValue, where=np._NoValue):
    """
    Sum of array elements over a given axis.

    Parameters
    ----------
    a : array_like
        Elements to sum.
    axis : None or int or tuple of ints, optional
        Axis or axes along which a sum is performed.  The default,
        axis=None, will sum all of the elements of the input array.  If
        axis is negative it counts from the last to the first axis.

        .. versionadded:: 1.7.0

        If axis is a tuple of ints, a sum is performed on all of the axes
        specified in the tuple instead of a single axis or all the axes as
        before.
    dtype : dtype, optional
        The type of the returned array and of the accumulator in which the
        elements are summed.  The dtype of `a` is used by default unless `a`
        has an integer dtype of less precision than the default platform
        integer.  In that case, if `a` is signed then the platform integer
        is used while if `a` is unsigned then an unsigned integer of the
        same precision as the platform integer is used.
    out : ndarray, optional
        Alternative output array in which to place the result. It must have
        the same shape as the expected output, but the type of the output
        values will be cast if necessary.
    keepdims : bool, optional
        If this is set to True, the axes which are reduced are left
        in the result as dimensions with size one. With this option,
        the result will broadcast correctly against the input array.

        If the default value is passed, then `keepdims` will not be
        passed through to the `sum` method of sub-classes of
        `ndarray`, however any non-default value will be.  If the
        sub-class' method does not implement `keepdims` any
        exceptions will be raised.
    initial : scalar, optional
        Starting value for the sum. See `~numpy.ufunc.reduce` for details.

        .. versionadded:: 1.15.0

    where : array_like of bool, optional
        Elements to include in the sum. See `~numpy.ufunc.reduce` for details.

        .. versionadded:: 1.17.0

    Returns
    -------
    sum_along_axis : ndarray
        An array with the same shape as `a`, with the specified
        axis removed.   If `a` is a 0-d array, or if `axis` is None, a scalar
        is returned.  If an output array is specified, a reference to
        `out` is returned.

Python docstring conventions (PEP-257)

Manuals

are often build from docstrings

Commenting Showing Intent (CSI)¹

Do NOT state what you are doing

# set box_width to equal the floor of items and 17
items_per_box = math.floor(items / 17)

DO state why you are doing it

# Divide our items among 17 boxes.
# We'll deal with the leftovers later.
items_per_box = math.floor(items / 17)

• don’t state the obvious

1. Examples from MousePaw Media Standards

Overview

Self-explanatory code	Commenting Showing Intent	Docstrings / Manuals
Actual behavior	Intent & design	Usage & interface
Developers / Maintainers	Developers / Maintainers	End-users / API consumers
What the code does	Why the code exists	How to use it

• Self-explanatory code: meaningful variable and function names, modular structure
• CSI: makes code language-agnostic!
• Docs: includes docstrings

Data

Data Management

• Preserve research materials for a clearly stated period (typically 10 years), including:
  • Data and metadata
  • Protocols and other relevant materials
  • Code and software
• Ensure access to data is as open as possible, as closed as necessary.

(Meta)data and FAIR principles

• Findable: unique identifiers, metadata registered in a searchable resource
• Accessible: (meta)data retrievable via standardized communication protocol
• Interoperable: compatibility with other data (e.g. adhering to CF conventions, use of common data formats like NetCDF, Zarr, CSV)
• Reusable: (meta)data description, attributes, data usage license

“FAIR is not fun, but fun is FAIR”

Issues with FAIR data

• data availability not guaranteed
• accessibility only with credentials possible
• DOIs don’t point to data, but only to landing pages

Beyond FAIR data

• openly accessible
• analysis-ready cloud-optimized data formats (Abernathey et al., 2021)

• “Cloud-ready”: datasets shall be possible to be opened directly from any other server, e.g. OPeNDAP
• cloud-optimized (zarr, TileDB, …)

Good Practices

Clean Code and Version Control

• Write readable, consistent code
• Use meaningful names and modular design
• Commit often with clear messages
• Use branches for features and fixes

Testing and Automation

• Add tests for core functionality
• Use CI/CD pipelines for automated testing
• Build trust through reliability

External libraries

• Use well-established packages when possible
• Usually more robust and effificient
• But you want to understand what they are doing 😉

How to identify a trustworthy source/package?

Supporting the Community

• Use issue and pull request templates
• Document governance and decision-making processes

Keep on learning

stay up to date with coding trends and libraries! 🧑‍🎓

• be open and continue learning: new technologies typically improve your productivity :)

Summary

• Open development fosters transparency and collaboration
• Contributions thrive with clear guidelines, respectful conduct, and good documentation
• Licenses are essential to protect and empower sharing
• It’s not just code — it’s about community and accessibility

Further reading

• choosealicense.com
• opensource.guide