Strategia e adozione
Valutiamo dove l'open source conviene davvero: analisi del parco software, TCO rispetto al proprietario, roadmap di adozione e riduzione della dipendenza da un singolo fornitore.
Adottare, governare e mantenere l'open source su scala aziendale, con la sovranità del dato come filo conduttore.

L'open source dà all'azienda controllo sullo stack, trasparenza su cosa gira in produzione, efficienza sui costi e libertà di scelta: codice ispezionabile e modificabile, sostenuto da community globali, senza vendor lock-in. Per trasformarlo in un vantaggio concreto servono governance, conformità e supporto: ti accompagniamo su tutto il percorso, dalla scelta e dalla migrazione fino al presidio quotidiano, con contratti e responsabilità chiare.
Valutiamo dove l'open source conviene davvero: analisi del parco software, TCO rispetto al proprietario, roadmap di adozione e riduzione della dipendenza da un singolo fornitore.
Istituiamo e facciamo funzionare il tuo OSPO: policy, ruoli, processi di approvazione e cultura del contribuire, così l'uso dell'open source diventa governato e consapevole.
Inventario delle dipendenze, verifica di compatibilità tra licenze (GPL, AGPL, MIT, Apache 2.0), gestione degli obblighi e due diligence, anche in fase di acquisizione o rilascio.
Generiamo e manteniamo la Software Bill of Materials (CycloneDX o SPDX), con tracciabilità delle dipendenze e gestione delle vulnerabilità, allineate a Cyber Resilience Act e NIS2.
Pianifichiamo il passaggio dal software proprietario all'open (virtualizzazione, database, produttività, sistemi operativi), con analisi dei rischi, dei costi e delle fasi.
Contratti di supporto enterprise su stack open source: patching di sicurezza, aggiornamenti, manutenzione a lungo termine e tempi di risposta garantiti su Linux, Kubernetes, database e middleware.
Self-hosting e deployment on-premise, con i dati che restano nel tuo perimetro, fino all'inferenza AI a pesi aperti eseguita in casa, senza dipendere da un interruttore altrui.
Sviluppo su progetti open source, integrazione nei tuoi sistemi, hardening di sicurezza dei deployment e contributi upstream per restare allineati alle community e all'evoluzione dei progetti.
Il nostro obiettivo è metterti in condizione di possedere e governare il tuo stack: capire cosa usi, con quali licenze e con quali rischi, poi costruire attorno i controlli che rendono l'open source affidabile in produzione. Lavoriamo per fasi, con priorità sulle scadenze normative (Cyber Resilience Act, NIS2) e sui punti di maggior valore per la tua infrastruttura.
I nostri servizi includono:
È lo stesso principio che portiamo nei nostri prodotti: Admina Enterprise è costruito su Admina, il framework open source di governance dell'AI rilasciato con licenza Apache 2.0. L'open source, per noi, è il modo di lavorare prima ancora che un servizio da vendere.
L'open source è nel DNA di noze dal 2000, come tecnologia e come comunità. Abbiamo co-fondato T-OSSLab, il centro di competenza toscano sull'Open Source, e CIRS, il consorzio italiano di imprese FLOSS. Siamo stati tra i fondatori dell'Associazione Zope Italia e del lancio di PloneGov in Italia, e negli anni abbiamo preso parte a molte altre iniziative del mondo open. Lo stesso Admina nasce come progetto open source del nostro founder Stefano Noferi, come raccontiamo nell'articolo dedicato. Il quadro completo è nella sezione Open Source.
I progetti che troviamo più spesso nelle infrastrutture dei clienti, e su cui facciamo adozione, hardening e supporto.
Il kernel e le distribuzioni su cui gira tutto il resto dello stack.
Come lo usiamo: Hardening, patching e manutenzione a lungo termine sui server dei clienti.
Virtualizzazione e cluster ad alta disponibilità, con backup integrato.
Come lo usiamo: Base delle infrastrutture on-premise che sostituiscono hypervisor proprietari.
Orchestrazione di container su più nodi, con self-healing e scalabilità.
Come lo usiamo: Cluster on-premise per carichi che devono restare dentro il perimetro del cliente.
Runtime per container senza demone e senza privilegi di root.
Come lo usiamo: Alternativa a Docker dove il rootless è un requisito di sicurezza.
Il runtime per container più diffuso, con il suo ecosistema di immagini.
Come lo usiamo: Sviluppo e integrazione continua, dove conta la compatibilità con il resto della filiera.
Web server e reverse proxy, anche come terminazione TLS e bilanciatore.
Come lo usiamo: Ingresso delle architetture che mettiamo in produzione, con TLS e regole di accesso.
Database relazionale con estensioni per JSON, ricerca full-text e vettori.
Come lo usiamo: Base dati delle applicazioni che sviluppiamo, e destinazione tipica delle migrazioni da database proprietari.
Database relazionale nato come fork di MySQL, compatibile con le sue applicazioni.
Come lo usiamo: Percorso di uscita da MySQL quando la compatibilità applicativa vale più di una migrazione completa.
Motore di ricerca e analisi su log e documenti, fork di Elasticsearch.
Come lo usiamo: Ricerca e analisi dei log senza le incognite di licenza che hanno colpito Elasticsearch.
Storage distribuito unificato: oggetti, blocchi e file system.
Come lo usiamo: Storage replicato on-premise, alternativa aperta alle SAN proprietarie.
Storage a oggetti compatibile con l'API S3.
Come lo usiamo: Bucket S3 dentro il perimetro del cliente, per backup e dati di applicazioni.
Dashboard e visualizzazione su metriche, log e tracce.
Come lo usiamo: Il cruscotto che guarda il cliente: stato dei servizi e rispetto degli SLA.
Raccolta di metriche a serie temporali e regole di allerta.
Come lo usiamo: Monitoraggio degli ambienti che gestiamo, con soglie concordate negli SLA.
Automazione della configurazione, senza agenti sulle macchine gestite.
Come lo usiamo: Configurazioni ripetibili e verificabili, utili come evidenza in ambito NIS2.
Infrastruttura come codice, fork di Terraform sotto Linux Foundation.
Come lo usiamo: Provisioning versionato. Lo preferiamo a Terraform, passato a licenza BUSL nel 2023 e quindi non più open source.
Gestione di segreti e chiavi, fork di Vault sotto Linux Foundation.
Come lo usiamo: Segreti fuori dal codice e dalle pipeline, con la stessa avvertenza di licenza che vale per Terraform.
Piattaforma di sviluppo: repository, code review, CI/CD e registry.
Come lo usiamo: Alternativa self-hosted quando il codice non deve uscire dall'organizzazione.
Gestione di identità e accessi: single sign-on, OIDC, SAML, federazione.
Come lo usiamo: SSO self-hosted quando le identità non devono uscire dall'organizzazione.
Piattaforma di streaming per flussi di eventi ad alto volume.
Come lo usiamo: Integrazione fra sistemi che devono scambiarsi eventi senza accoppiarsi fra loro.
Broker di messaggi con code, routing e garanzie di consegna.
Come lo usiamo: Code applicative dove serve affidabilità sul singolo messaggio più che volume.
Automazione di build, test e rilasci, estensibile con plugin.
Come lo usiamo: Pipeline nei contesti che hanno già Jenkins e non vogliono cambiare catena.
Collaborazione e condivisione file self-hosted.
Come lo usiamo: Alternativa alle suite cloud dove i documenti devono restare in casa.
Runtime JavaScript lato server, con il suo ecosistema di pacchetti.
Come lo usiamo: Backend e strumenti delle applicazioni che sviluppiamo.
VPN moderna, con un codice piccolo abbastanza da essere verificabile.
Come lo usiamo: Accesso remoto e collegamenti fra sedi, al posto di concentratori proprietari.
È l'insieme di servizi che permette a un'azienda di adottare, governare, mettere in sicurezza e mantenere software open source su scala aziendale: dalla strategia e dalla conformità delle licenze fino al supporto con SLA, alla migrazione dal proprietario e all'esecuzione on-premise. L'obiettivo è ridurre il lock-in e i costi, mantenendo il controllo dello stack.
Sì, a patto di governarlo. La sicurezza non dipende dal fatto che il codice sia aperto o chiuso, ma dai controlli attorno: inventario delle dipendenze e SBOM, gestione delle vulnerabilità, patching tempestivo e contratti di supporto con tempi di risposta. Sono esattamente le pratiche che mettiamo in piedi.
Un Open Source Program Office è la funzione che governa come l'azienda usa, contribuisce e rilascia software open source: policy sulle licenze, processi di approvazione, gestione dei rischi e rapporti con le community. È utile a chi usa open source in modo diffuso e vuole passare da un uso implicito a uno governato e conforme.
Entrambe le normative spostano l'attenzione sulla catena di fornitura del software: tracciabilità delle componenti, gestione delle vulnerabilità e obblighi di aggiornamento. La SBOM, un processo di patching definito e una governance delle dipendenze sono i tasselli concreti che aiutano a rientrare nei requisiti.
Sì. Offriamo contratti di supporto e manutenzione con tempi di risposta garantiti su stack open source in produzione: sistemi Linux, Kubernetes, database e middleware, con patching di sicurezza e manutenzione a lungo termine.
Dipende dal punto di partenza. Partiamo da un assessment che mette a confronto il costo totale attuale (licenze, manutenzione, vincoli) con lo scenario open. Da lì costruiamo un piano di migrazione per fasi. Spesso la leva non è solo il costo delle licenze, ma la sovranità e la libertà di scelta che si recuperano.
Raccontaci il tuo parco software e i tuoi obiettivi: partiamo da un assessment e da un piano concreto.