Consulenza Open Source Enterprise

Adottare, governare e mantenere l'open source su scala aziendale, con la sovranità del dato come filo conduttore.

Open Source Enterprise

Open source come vantaggio strategico

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.

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.

Open Source Program Office (OSPO)

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.

Conformità delle licenze

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.

Supply chain e SBOM

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.

Migrazione verso l'open source

Pianifichiamo il passaggio dal software proprietario all'open (virtualizzazione, database, produttività, sistemi operativi), con analisi dei rischi, dei costi e delle fasi.

Supporto e manutenzione con SLA

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.

Sovranità e on-premise

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, hardening e upstreaming

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 approccio

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:

  • Assessment del parco software e della dipendenza da fornitori proprietari
  • Policy e governance delle licenze open source
  • Istituzione e operatività di un OSPO
  • Generazione e manutenzione di SBOM (CycloneDX, SPDX)
  • Gap analysis Cyber Resilience Act e NIS2 sul software in uso
  • Piani di migrazione dal proprietario all'open source
  • Contratti di supporto e manutenzione con SLA
  • Deployment on-premise e inferenza AI a pesi aperti

È 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.

Lo stack su cui lavoriamo

I progetti che troviamo più spesso nelle infrastrutture dei clienti, e su cui facciamo adozione, hardening e supporto.

  • Linux GPL-2.0

    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.

  • Proxmox VE AGPL-3.0

    Virtualizzazione e cluster ad alta disponibilità, con backup integrato.

    Come lo usiamo: Base delle infrastrutture on-premise che sostituiscono hypervisor proprietari.

  • Kubernetes Apache-2.0

    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.

  • Podman Apache-2.0

    Runtime per container senza demone e senza privilegi di root.

    Come lo usiamo: Alternativa a Docker dove il rootless è un requisito di sicurezza.

  • Docker Apache-2.0

    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.

  • NGINX BSD-2-Clause

    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.

  • PostgreSQL PostgreSQL License

    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.

  • MariaDB GPL-2.0

    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.

  • OpenSearch Apache-2.0

    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.

  • Ceph LGPL-2.1

    Storage distribuito unificato: oggetti, blocchi e file system.

    Come lo usiamo: Storage replicato on-premise, alternativa aperta alle SAN proprietarie.

  • MinIO AGPL-3.0

    Storage a oggetti compatibile con l'API S3.

    Come lo usiamo: Bucket S3 dentro il perimetro del cliente, per backup e dati di applicazioni.

  • Grafana AGPL-3.0

    Dashboard e visualizzazione su metriche, log e tracce.

    Come lo usiamo: Il cruscotto che guarda il cliente: stato dei servizi e rispetto degli SLA.

  • Prometheus Apache-2.0

    Raccolta di metriche a serie temporali e regole di allerta.

    Come lo usiamo: Monitoraggio degli ambienti che gestiamo, con soglie concordate negli SLA.

  • Ansible GPL-3.0

    Automazione della configurazione, senza agenti sulle macchine gestite.

    Come lo usiamo: Configurazioni ripetibili e verificabili, utili come evidenza in ambito NIS2.

  • OpenTofu MPL-2.0

    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.

  • OpenBao MPL-2.0

    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.

  • GitLab CE MIT

    Piattaforma di sviluppo: repository, code review, CI/CD e registry.

    Come lo usiamo: Alternativa self-hosted quando il codice non deve uscire dall'organizzazione.

  • Keycloak Apache-2.0

    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.

  • Apache Kafka Apache-2.0

    Piattaforma di streaming per flussi di eventi ad alto volume.

    Come lo usiamo: Integrazione fra sistemi che devono scambiarsi eventi senza accoppiarsi fra loro.

  • RabbitMQ MPL-2.0

    Broker di messaggi con code, routing e garanzie di consegna.

    Come lo usiamo: Code applicative dove serve affidabilità sul singolo messaggio più che volume.

  • Jenkins MIT

    Automazione di build, test e rilasci, estensibile con plugin.

    Come lo usiamo: Pipeline nei contesti che hanno già Jenkins e non vogliono cambiare catena.

  • Nextcloud AGPL-3.0

    Collaborazione e condivisione file self-hosted.

    Come lo usiamo: Alternativa alle suite cloud dove i documenti devono restare in casa.

  • Node.js MIT

    Runtime JavaScript lato server, con il suo ecosistema di pacchetti.

    Come lo usiamo: Backend e strumenti delle applicazioni che sviluppiamo.

  • WireGuard GPL-2.0

    VPN moderna, con un codice piccolo abbastanza da essere verificabile.

    Come lo usiamo: Accesso remoto e collegamenti fra sedi, al posto di concentratori proprietari.

Domande Frequenti

Cos'è la consulenza open source enterprise?

È 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.

L'open source è sicuro e affidabile per l'azienda?

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.

Cos'è un OSPO e serve alla nostra azienda?

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.

Come si lega l'open source al Cyber Resilience Act e alla NIS2?

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.

Potete fornire supporto con SLA su software open source?

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.

Quanto costa uscire dal software proprietario?

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.

Contattaci

Vuoi valutare l'open source per la tua azienda?

Raccontaci il tuo parco software e i tuoi obiettivi: partiamo da un assessment e da un piano concreto.

Contattaci ora →

Vuoi supporto?Sei sotto attacco?Stato dei servizi
Vuoi supporto?Sei sotto attacco?Stato dei servizi