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

[tobie]

Rendered content

[denjell-crabnebula]

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?

[rozhukov]

I think this doc is still valuable and we should keep going with it. In the leu of the "FOSS Guidance" that's under preparation by the EU Commission, I'd suggest to wait a bit until it's final/public. This White Paper would be a good addition (or even extension) of that FOSS Guidance. For example, by providing concise tables/charts and additional examples to it with a clear value or open source community.

[denjell-crabnebula]

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?

[sjn]

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)