Skip to content

Add initial draft and resources for white paper on open source project types #240

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions white-papers/project-types/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# White paper on types of open source projects

This is [deliverable 3.4](https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md#34-white-paper-on-types-of-open-source-projects) of the SIG's [Deliverable Plan](https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md).

**👉 [White paper on types of open source projects](./project-types.md)**

## Resources

The following resources have been shared with the WG as input to this white paper. They do not represent WG consensus:

* ["Typical open source projects"](./resources/open-source-projects.key.pdf) - a presentation by Olle E. Johansson (Edvina AB)
* ["Real world use cases from the industry"](./resources/industry-use-cases.docx.md) - case studies collected by Steffen Zimmermann (VDMA) and Götz Görisch (VDW).
* ["Open Source Archetypes"](https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf) - a 2018 report by Open Tech Strategies commissioned by Mozilla
* ["The PLD and OSS"](https://www.degruyterbrill.com/document/doi/10.9785/cr-2025-410407/html) — a research paper on creating open source project categories mapped to the PLD. In German and behind a paywall.
* [Nadia Eghbal's Project Types](https://project-types.github.io/) - originally described in her 2018 book ["Working in Public"](https://press.stripe.com/working-in-public).
56 changes: 56 additions & 0 deletions white-papers/project-types/project-types.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# White paper on types of open source projects

## Abstract

The open source ecosystem is a rich ecosystem composed of very different types of projects and of communities, organizations, and maintainers supporting them. This diversity of project and community types isn't well documented and is rarely considered by policymakers. As a result, the whole open source ecosystem is often lumped together as a whole, or separated into arbitrary groups that don't match reality. The purpose of this white paper is threefold:

1. Identify important traits of open source projects that help differentiate and categorize projects into meaningful groups.
2. Define a set of categories based on those traits.
3. Propose a mapping from identified traits and categories to CRA roles (_Manufacturer_, _Open Source Software Steward_, not in scope).
4. Provide examples of open source projects for each category and demonstrate where they fit and why.

## Status of this document

This document is a [deliverable](https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md#12-inventory) of the [Cyber Resilience SIG](https://github.com/orcwg/orcwg/tree/main/cyber-resilience-sig#readme) of the [Open Regulatory Compliance Working Group (ORC)](https://orcwg.org/) of the [Eclipse Foundation](https://www.eclipse.org/). It is a draft and does not yet represent the consensus of ORC or its [members](https://orcwg.org/membership/). <!---It was approved to be released as version 1.0 by the Cyber Resilience SIG on May 12, 2025. It represents the consensus of ORC and its [members](https://orcwg.org/membership/).-->

This document is released under the [CC-BY 4.0 License](https://github.com/orcwg/orcwg/blob/main/LICENSE.md). It is not governed by the Eclipse Foundation Specification Process (EFSP).

This document is developed in the open, [on GitHub](https://github.com/orcwg/cra-hub/blob/main/white-papers/project-types/project-types.md). To contribute to future revisions of this document or submit errata, please send a pull request or [open an issue](https://github.com/orcwg/cra-hub/issues/new).

## 1. Differentiating traits of open source project

While open source projects share a number of critical traits such as license recognized by the Open Source Initiative, there's a number of traits that differentiate them.

These traits provide a usefull framework to categorize open source projects together.

Traits:

- governance
- trademark ownership
- contribution model
- business model
- etc.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here are a couple base types of open source projects...

  • programming languages
    • compilers
    • language ecosystem tooling
    • component or library or module
  • kernels
    • kernel drivers (hardware/os adjacent or dependent projects)
  • language ecosystem infrastructure tooling
    • tooling for downloading, extracting, building, testing, installing, packaging, indexing and distributing other software & components
  • frameworks
    • plugins for frameworks (Drupal, WordPress, Firefox extensions)
  • runtime execution environments, including
    • containers and their registries end orchestration software
    • virtual machines, and their management software
  • user-interfacing tools and applications
  • API providers (server or systems)
  • Analysis and verification software
  • Firmware

…and from these, I think we can find a few more traits to consider:

  • project independence (depending on another ecosystem, or being ecosystem-agnostic)
  • project ownership (including commit rights, ecosystem namespace rights, etc.; this is different from the bigger projects concern themselves with actual Trade Mark ™ registration)
  • it's place in the supply chain and dependency graph; the more dependents (downstream users) the higher demand for stability; same goes for it's closeness to hardware (kernels or firmware vs. end-user applications). Alternatively - to what extent the project can be considered "infrastructure" for something else.
  • it's requirements for long-term interoperability and/or forward/backward compatibility (e.g. implementations of cryptography or compression algorithms)
  • whether or not a project solves a "closed" or an "open" problem. Solutions to "closed" problems can be implemented fully, and therefore be "done" (e.g. implementing a sorting algorithm) - Solutions to "open" problems cannot become "done" since the problem domain evolves over time (e.g. spam detection)


## 2. Open source project categories

Projects which share certain traits naturally fall in the same category. We've regrouped them in the following categories.


## 3. CRA Mapping

This section proposes from the traits and categories identified in section 2 ann 3 respectively to CRA roles (_Manufacturer_, _Open Source Software Steward_, not in scope).

## 4. Case studies

Using the framework described in section 1 and the mapping described in section to 3, provide a few case studies.

## Acknowledgements

The following people have contributed to this document either directly or indirectly (e.g. by raising issues):
Florian Idelberger,
Georg Link,
Götz Görisch,
Steffen Zimmermann,
and Tobie Langel.

If you have contributed to this document and aren't properly acknowledged or if you want to edit or remove your name, please let us know by [opening an issue](https://github.com/orcwg/cra-hub/issues/new) and we will fix this right away.
87 changes: 87 additions & 0 deletions white-papers/project-types/resources/industry-use-cases.docx.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
**EG CRA – OSS work strand – real world use cases from the industry (collected via VDMA, VDW)**
April 15, 2025

**Role/view:** manufacturer of a final product with digital elements, where OSS is not the main activity.

**Why it matters:** European manufacturers should take advantage of OSS in the future, therefore guidance and clarification based on real world use cases should be provided.

**Note:** Questions provided come from manufacturers and are included to give full view on the use cases.

**UseCase 1**
(e.g. open62541 SDK)

The manufacturer of the final product with digital elements integrates an open-source software component.
This OSS component is maintained by a not-for-profit entity.
Maintenance is funded by public money (research projects) and donations from users or projects to develop new features.

Questions:

* What is the role of the manufacturer of the final product and the not-for-profit entity?
* What is the role of both if a certain feature was developed in a project between the
manufacturer and the not-for-profit?

**UseCase 2**
(e.g. .NET SDK – OPC Foundation)

A not-for-profit foundation develops an OSS software development kit (SDK) with a GPL-2 license.
This SDK is used by manufacturers of the final product to build products with digital elements.
Maintenance of the SDK is funded by membership fees to the not-for-profit foundation and provided by developer resources from its members. This same SDK is also provided to the members using a non-OSS license.

Questions:

* Who is responsible for this SDK?
* Who is responsible for providing patches and maintaining a vulnerability disclosure process?
* How is liability structured for these scenarios?

**UseCase 3**
(e.g. library from the package systems NPM, PyPi, NuGet)

A manufacturer of the final product with digital elements uses open-source libraries from the large package ecosystems as a component in the product.

Questions:

* What are the obligations for proper due diligence before a manufacturer may integrate such libraries?
* What is the manufacturer ‘s liability for such a library?
* May the manufacturer only use libraries which have an Open-Source Stewart or where there is a responsible manufacturer for the library?

**UseCase 4**
(e.g. providing a library which one uses in their product also as open source to be reused)

A manufacturer provides a product with digital elements to the European market. The manufacturer needs to develop a new software library on its own to use it as a component in the product with digital elements. The software library is also made available under an open-source license to be used by others, without charging a price for it.

Questions:

* What are the manufacturers obligations, does he automatically become manufacturer for this library with all obligations?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* What are the manufacturers obligations, does he automatically become manufacturer for this library with all obligations?
* What are the manufacturer's obligations, do they automatically become a manufacturer for this library with all obligations?


Special case: The manufacturer develops a software library to interact with its product. This library is provided under an open-source license as is, as a sample implementation to interact with the product. How can the manufacturer ensure that this library is not a product with digital elements? Otherwise it would not be published.

**UseCase 5**
(e.g. providing software implementations as a demo software under an open-source license)

A not-for-profit association, where manufacturers of products used as components are members, is developing sample software which showcases the use of industry standards (e.g. OPC UA) and how various components from different manufacturers can work together.
The not-for-profit association also runs a test bed which is publicly accessible to showcase certain use cases and
provide guidance.

Questions:

* How can it be ensured that the not-for-profit association does neither become an Open-Source Steward nor a manufacturer for sample implementations?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* How can it be ensured that the not-for-profit association does neither become an Open-Source Steward nor a manufacturer for sample implementations?
* How can it be ensured that the not-for-profit association neither becomes an Open-Source Steward nor a manufacturer for sample implementations?


**UseCase 6**
(e.g. manufacturer providing code as a demo software under an open-source license)

A final product manufacturer directly provides sample computer code (e.g. python script, C code, PLC code...) which showcases the use and integration of its products with digital elements.

Questions:

* How is the manufacturer classified regarding the demo software, as a manufacturer or as a steward? If as an OSS steward, what are the obligations on sample code/implementations?

**UseCase 7**
(e.g. embedded device as part of a product with custom build operating system)

Yocto is a toolkit for building operating system distributions for embedded systems. Operating systems are classified as "important". An embedded device manufacturer leverages the Yocto toolkit to build a custom operating system for the product with digital elements (used as a component).

Questions:

* What does the use of a customized OS mean for the embedded device manufacturer that uses the toolkit to build a custom OS for its embedded device?
* Does this mean the embedded device manufacturer is building an operating system and has the obligations to fulfil all requirements according to the CRA important product class of Operating Systems?

Binary file not shown.