Open Source Engineering
We build and maintain the open source your platform runs on
Not a reseller, not a support desk. We contribute to and maintain the projects our clients depend on, and we stand behind them commercially.
The problem
Your critical path runs through software nobody in your organization maintains
This is normal. It is also, increasingly, a governance problem with a regulatory dimension.
It shows up in three predictable ways. A critical CVE lands in a component nobody owns, and remediation takes weeks because nobody knows the codebase well enough to assess exposure, let alone patch it. A project you depend on loses its maintainers, and there is no plan. Your engineers write a fix, carry it as a fork because upstreaming is work nobody has time for, and two years later that fork blocks every upgrade path you have.
The Cyber Resilience Act, NIS2, and DORA all now assume you can answer questions about the provenance, maintenance, and security response of the software you run and ship. “It is open source” has stopped being an answer.
What we do
The work that we deliver
We develop upstream
We contribute features, fixes, and reviews to the projects our clients depend on. When your requirement is best solved in the project rather than around it, we take it there, through the project’s process, as contributors with standing rather than as strangers opening a pull request.
We maintain
For projects where our engineers hold maintainer or reviewer roles, we carry real responsibility: reviewing, releasing, security response, and the unglamorous work that keeps a project alive. That standing is what makes our commercial commitments credible.
We support
Contracted assurance for the components in your critical path: security response with impact assessment specific to your usage rather than a generic severity score, upgrade and compatibility support, and deep-dive help when something breaks in a way the documentation does not cover.
We handle the supply chain
SBOM generation and validation, provenance, license position, and the documentation your compliance function needs, framed against the obligations that actually apply to you.
We advise on strategy
Contribution policy, governance, inner source practice, open source program office design, and foundation engagement, for organizations that want to participate in the ecosystem rather than only consume it.
Our offerings
How we engage
Open Source Assurance
Contracted coverage for the components that matter to you: security response, upgrade support, upstream contribution capacity, and supply chain evidence.
Outcome
A named, accountable answer to “who maintains this”.
Upstream development
Feature and fix development in the projects you depend on, delivered upstream.
Outcome
Your requirements in the project, your fork count going down.
Fork reduction and upstreaming
Cataloguing the patches you carry, and taking them upstream.
Outcome
An upgrade path that is no longer blocked by your own patches.
Supply chain and compliance
SBOM, provenance, and license position for your open source estate, mapped to CRA, NIS2, and DORA obligations.
Outcome
Evidence rather than assertion.
Long-term support paths
Where a project moves faster or slower than you can, we work out and maintain the answer, including extended maintenance of versions you need to stay on.
Outcome
A supported position rather than an unmanaged one.
Open source strategy and governance
Contribution policy, OSPO design, inner source, foundation engagement.
Outcome
A deliberate open source posture instead of an accidental one.
How we work
Our approach
Public by default
The work we do on your behalf goes upstream, publicly, under our own names in the project. That is what makes it durable: an upstreamed fix is maintained by the project forever, a private patch is maintained by you forever.
Specific, not general
We cover named components, with your version and your configuration recorded, because a CVE that is critical in general is often irrelevant in your usage and occasionally much worse. Generic advisory feeds cannot tell you which.
Inside the projects, not outside them
Getting a change into a healthy open source project is a social process as much as a technical one. Standing, history, and knowing the maintainers is the difference between a fix landing in three weeks and a fix landing never.
Honest about our reach
We do not claim to maintain the entire cloud native landscape. We tell you where we hold real standing, where we have working relationships, and where we would be starting from the same position you are. That distinction is in your scoping document.
What you get
Object driven outcomes
A named, documented component scope with your versions, configurations, and carried patches recorded
Security advisory monitoring with impact assessment for your specific usage
Upstream contributions made publicly on your behalf
SBOM and provenance evidence in the format your compliance function needs
Upgrade and breaking-change guidance in advance
A named technical contact and an escalation path
Quarterly review of scope, contributions, and roadmap
Where this sits in the stack
Why this underpins everything else
Open source is what makes the rest of the stack verifiable. A sovereignty claim backed by a contract is a promise. A sovereignty claim backed by software you can inspect, run anywhere, and leave is a property of the architecture. A platform built on open source can be operated by your team, moved to a different substrate, and audited by anyone you choose.
It is also why we can say “no lock-in” and mean something specific by it.
Packaged offers
Start with a defined step
12 months, rolling
Open Source Operations & Maintenance
Your platform runs on open source. We maintain it, upstream your fixes, and stand behind the components that matter to you, as maintainers rather than as a support desk.
8 weeks, operation optional
OpenBao Implementation and Operation
Production secrets management on OpenBao in eight weeks: deployed, integrated with your workloads, and optionally operated by us. Open source, in your infrastructure, with your key custody intact.
FAQ
Questions we get asked
Is this a support contract like Red Hat’s?
No, and the difference matters. A vendor support contract covers that vendor’s distribution. Ours covers the components you actually run, from whichever projects, in your configuration, and includes capacity to change those projects on your behalf. If your estate is a single vendor’s distribution, that vendor’s contract is probably the better answer and we will say so.
What if you do not maintain a component we depend on?
We tell you. Coverage scoping includes an honest statement of our standing per component: where we maintain, where we contribute, where we have relationships, and where we would be learning the codebase alongside you. You should be suspicious of anyone who claims uniform depth across a landscape this large.
Do our fixes have to go upstream publicly?
Yes, and this is worth understanding rather than negotiating. A public upstream fix is maintained by the project from then on. A private patch is maintained by you, forever, and it blocks your upgrades. Where the change contains genuinely sensitive business logic, that logic usually should not be in an infrastructure component in the first place, and we will work out where it belongs.
Can you provide indemnification?
No. We provide engineering, maintainership, and evidence. Indemnification is an insurance product and should be bought from an insurer.
How does this help with the Cyber Resilience Act?
It gives you the two things the obligations assume you have: a documented maintenance and security response position for your components, and supply chain evidence in a form you can produce on request. We provide the technical position and the evidence; your legal and compliance functions own the determination of what your obligations are.
Which components keep you up at night?
Most conversations start with a short list: three or four components in the critical path with no owner. That is a good place to begin.