OSS Stewardship

We help transition hobbyist or manufacturer-led FOSS projects into a stewardship model prepared for long-term governance, operations, and CRA-aligned practices.

If an Open Source Product aligns well with MoM’s purpose and statutes, our laboratory can typically host the project on GitHub or Codeberg and act as its official OSS Steward. We support CRA-aligned stewardship practices and evidence collection as part of sustainable project operations.

OSS Stewardship comes in different shapes and sizes, depending on project activity, operational complexity, and alliance ambition. Below is an overview of the transition model and engagement options.

Overview

• Each FOSS product will have its own project, where stewardship activities are organized.
• Each project will define an alliance or members who jointly serve as sponsors of the FOSS product.
• The OSS steward will organize the alliance and maintain a roadmap for the product (executed as an upstream kanban board).
• The product will be hosted in a standardized, continuously optimized infrastructure model, enabling shared tools, support, and learnings across multiple FOSS projects.
• The project alliance will jointly bear the cost of:
  • The infrastructure it utilizes.
  • The OSS Stewardship services and labour it receives from MoM’s laboratory.

Transition phases

Phase 1: Assessment

In the first phase, we assess practical suitability for MoM to take on the OSS Steward role.

• Fit and viability assessment — We evaluate whether the project is a practical candidate for stewardship. This includes business relevance, product intent, maintainer capacity, and likely community traction.
• Ethical and governance alignment — We review ownership posture, decision rights, contribution model, and governance expectations. The goal is to ensure the project can be stewarded credibly by an independent non-profit organization.
• Technical due diligence — We assess code quality, architecture boundaries, test strategy, release hygiene, documentation, CI/CD, dev container setup, security posture, and AI instruction artifacts. We assess the project’s current infrastructure and DevOps approaches.

Phase 1 outputs:

• A transition brief with key risks and constraints.
• A prioritized backlog for phases 2 and 3.
• A first budget range based on scoped work items.

Phase 2: Platform and organization transition

In the second phase, we plan and execute practical transfer tasks: repository organization, permissions, issue workflows, project boards, release automation, and maintainer operations on GitHub or Codeberg.

Phase 2 outputs:

• Operational ownership transferred to the stewarded setup.
• Baseline automation and governance routines in place.
• Documented maintainer runbook and role boundaries.

Phase 3: Value stream mapping and workflow

When the product has landed with us, we run a first optimization cycle using standardized stewardship practices and learnings from other OSS projects.

• Value stream mapping — We map the current flow from ideation to product release, identify bottlenecks and risk concentration, and update the roadmap for the next operating period.
• Stewardship workflow launch and cadence — We establish recurring stewardship routines across DevOps, Configuration Management, Release Management, Quality Assurance, and Developer Experience. We also establish role boundaries, quality guardrails, and decision checkpoints so the project can run sustainably after transition.

Phase 3 outputs:

• Updated roadmap with bottlenecks and risks addressed.
• Agreed cadence for planning, release, and quality checkpoints.
• A predictable stewardship operating model.

Phase 4: Community building

Think of the previous stages as the Minimum Viable Product (MVP): the project can now take ideas through implementation and reliable public release. Phase 4 focuses on visibility and growth: attracting contributors, publishing tutorials and technical posts, producing demos, organizing events, improving documentation, and growing sponsor participation in the alliance.

When does an OSS Stewardship make sense

• A project started as an internal experiment or side project has grown to become included in a commercial product and therefore must comply with EU’s CRA.
• The current maintainer model is too fragile for commercial use.
• You need to formalize stewardship before broadening adoption.
• The project should move from founder-led work to resilient shared ownership.
• You want to protect maintainer bandwidth for innovation while delegating routines, infrastructure, and formal stewardship.
• Your employees build software that is used commercially, but ownership, governance, and maintenance responsibilities are unclear.

Engagement and pricing model

We do not use a one-size-fits-all fixed price model. Total cost depends on product complexity, available community-contributed effort, and alliance ambitions and budget.

In most cases, it is best to start with the smallest viable transition scope, then scale stewardship investment as adoption and sponsorship grow.

Example

As a minimum, the project must fund recurring infrastructure and the agreed baseline stewardship workload.

Illustrative baseline:

• Infrastructure: from about 100 EUR/month.
• Stewardship labour: about 10 hours/month on retainer.

At a favorable member rate of 110 EUR/hour, this corresponds to approximately 14,400 EUR/year plus infrastructure.

For heavier infrastructure demands such as duplicate cloud environments for development, staging, and production, plus AI token usage, artifact management, and heavy CI/CD usage, costs will increase materially. The project alliance should establish and review a dedicated budget.

For projects requiring sustained maintenance after transition, or a main contributor role from the MoM laboratory, we recommend a retainer so both development and stewardship capacity are predictable month by month.

What you can expect

It all starts with a conversation. From there, we work through the phases together.

The Phase 1 assessment is included for active members of the MoM alliance, meaning there is no separate Phase 1 invoice within the agreed assessment scope. For non-members, Phase 1 can be purchased as a standalone transition assessment. æ