Strategy and adoption
We assess where open source truly pays off: a review of your software estate, TCO against proprietary, an adoption roadmap and reduced dependence on a single vendor.
Adopt, govern and maintain open source at enterprise scale, with data sovereignty as the through-line.

Open source gives a company control over its stack, transparency into what runs in production, cost efficiency and freedom of choice: code that is inspectable and modifiable, backed by global communities, with no vendor lock-in. To turn that into a real advantage you need governance, compliance and support: we accompany the whole journey, from choice and migration to day-to-day operation, with clear contracts and responsibilities.
We assess where open source truly pays off: a review of your software estate, TCO against proprietary, an adoption roadmap and reduced dependence on a single vendor.
We set up and run your OSPO: policy, roles, approval processes and a culture of contribution, so open-source use becomes governed and deliberate.
A dependency inventory, licence-compatibility checks (GPL, AGPL, MIT, Apache 2.0), obligation management and due diligence, including in acquisitions or releases.
We generate and maintain the Software Bill of Materials (CycloneDX or SPDX), with dependency traceability and vulnerability management, aligned with the Cyber Resilience Act and NIS2.
We plan the move from proprietary software to open (virtualization, databases, productivity, operating systems), with an analysis of risks, costs and phases.
Enterprise support contracts on open-source stacks: security patching, updates, long-term maintenance and guaranteed response times on Linux, Kubernetes, databases and middleware.
Self-hosting and on-premise deployment, with data that stays inside your perimeter, all the way to open-weight AI inference run in house, without depending on someone else’s switch.
Development on open-source projects, integration into your systems, security hardening of deployments and upstream contributions, to stay aligned with the communities and the ongoing evolution of the projects.
Our goal is to put you in a position to own and govern your stack: understand what you use, under which licences and with which risks, then build the controls that make open source reliable in production. We work in phases, prioritising regulatory deadlines (Cyber Resilience Act, NIS2) and the points of greatest value for your infrastructure.
Our services include:
It is the same principle we bring to our own products: Admina Enterprise is built on Admina, the open-source AI governance framework released under the Apache 2.0 licence. For us, open source is the way we work before it is a service we sell.
Open source has been in noze's DNA since 2000, both as technology and as community. We co-founded T-OSSLab, the Tuscan open-source competence centre, and CIRS, the Italian consortium of FLOSS companies. We were among the founders of the Zope Italy Association and of the PloneGov launch in Italy, and over the years we have taken part in many other initiatives of the open world. Admina itself began as an open-source project by our founder Stefano Noferi, as we cover in the dedicated article. The full picture is in the Open Source section.
The projects we most often find in our clients' infrastructures, and the ones we adopt, harden and support.
The kernel and the distributions everything else in the stack runs on.
How we use it: Hardening, patching and long-term maintenance on our clients' servers.
Virtualisation and high-availability clustering, with backup built in.
How we use it: The base of the on-premise infrastructures that replace proprietary hypervisors.
Container orchestration across nodes, with self-healing and scaling.
How we use it: On-premise clusters for workloads that must stay inside the client's perimeter.
A container runtime with no daemon and no root privileges.
How we use it: The alternative to Docker wherever rootless is a security requirement.
The most widely used container runtime, with its ecosystem of images.
How we use it: Development and continuous integration, where compatibility with the rest of the chain matters.
Web server and reverse proxy, also used for TLS termination and load balancing.
How we use it: The front door of the architectures we put into production, with TLS and access rules.
A relational database with extensions for JSON, full-text search and vectors.
How we use it: The data layer of the applications we build, and the usual destination for migrations away from proprietary databases.
A relational database forked from MySQL and compatible with its applications.
How we use it: The way out of MySQL when application compatibility is worth more than a full migration.
A search and analytics engine for logs and documents, forked from Elasticsearch.
How we use it: Log search and analysis without the licensing uncertainty that hit Elasticsearch.
Unified distributed storage: objects, blocks and file systems.
How we use it: Replicated on-premise storage, the open alternative to proprietary SANs.
Object storage compatible with the S3 API.
How we use it: S3 buckets inside the client's perimeter, for backups and application data.
Dashboards and visualisation over metrics, logs and traces.
How we use it: The console the client actually looks at: service status and SLA compliance.
Time-series metric collection and alerting rules.
How we use it: Monitoring of the environments we run, with the thresholds agreed in the SLA.
Configuration automation, with no agents on the managed machines.
How we use it: Repeatable, auditable configurations, useful as evidence under NIS2.
Infrastructure as code, forked from Terraform under the Linux Foundation.
How we use it: Versioned provisioning. We prefer it to Terraform, which moved to the BUSL licence in 2023 and is therefore no longer open source.
Secret and key management, forked from Vault under the Linux Foundation.
How we use it: Secrets out of the code and the pipelines, with the same licensing caveat that applies to Terraform.
A development platform: repositories, code review, CI/CD and registry.
How we use it: The self-hosted option when the code must not leave the organisation.
Identity and access management: single sign-on, OIDC, SAML, federation.
How we use it: Self-hosted SSO when identities must not leave the organisation.
A streaming platform for high-volume event flows.
How we use it: Integration between systems that need to exchange events without coupling to each other.
A message broker with queues, routing and delivery guarantees.
How we use it: Application queues where per-message reliability matters more than volume.
Build, test and release automation, extensible through plugins.
How we use it: Pipelines in environments that already run Jenkins and do not want to change toolchain.
Self-hosted collaboration and file sharing.
How we use it: The alternative to cloud suites where documents have to stay in house.
A server-side JavaScript runtime, with its package ecosystem.
How we use it: The backend and the tooling of the applications we build.
A modern VPN, with a codebase small enough to be auditable.
How we use it: Remote access and site-to-site links, in place of proprietary concentrators.
It is the set of services that lets a company adopt, govern, secure and maintain open-source software at scale: from strategy and licence compliance to SLA-backed support, migration from proprietary and on-premise execution. The goal is to reduce lock-in and cost while keeping control of the stack.
Yes, provided it is governed. Security does not depend on whether the code is open or closed, but on the controls around it: a dependency inventory and SBOM, vulnerability management, timely patching and support contracts with response times. These are exactly the practices we put in place.
An Open Source Program Office is the function that governs how a company uses, contributes to and releases open-source software: licence policy, approval processes, risk management and relationships with communities. It helps organisations that use open source widely and want to move from implicit use to governed, compliant use.
Both regulations shift attention to the software supply chain: traceability of components, vulnerability management and update obligations. An SBOM, a defined patching process and dependency governance are the concrete pieces that help you meet the requirements.
Yes. We offer support and maintenance contracts with guaranteed response times on open-source stacks in production: Linux systems, Kubernetes, databases and middleware, with security patching and long-term maintenance.
It depends on the starting point. We begin with an assessment that compares your current total cost (licences, maintenance, constraints) with the open scenario, then build a phased migration plan. Often the lever is not just licence cost, but the sovereignty and freedom of choice you regain.
Tell us about your software estate and your goals: we start with an assessment and a concrete plan.