SDLC open source: gli strumenti giusti per ogni fase, dal requisito al rilascio

Verificato il: 2026-10-01

Costruire una software factory senza licenze proprietarie è possibile, ma non è un elenco della spesa: è una scelta di architettura del processo.

L'open source copre ormai ogni fase del ciclo di vita del software (SDLC, Software Development Life Cycle), con un però che va detto subito: le licenze non sono tutte uguali e alcune, presentate come libere, impongono una licenza a pagamento nel momento in cui le usi in produzione.

Questa rassegna mette in fila gli strumenti che ho verificato come open source su licenza approvata OSI e gratuiti in autohosting, con la fase in cui lavorano, la licenza, la maturità e il limite principale. Il perimetro esclude di proposito i progetti source-available o open-core che chiedono una licenza per l'uso commerciale: Terraform, Vault e Nomad (passati a BUSL), Outline, le versioni Enterprise di GitLab e Mattermost.

Restano fuori anche i servizi gestiti: qui si parla solo di software che puoi installare in casa. Su Redis, assente da questa mappa, va una nota di versione: le release 7.4-7.8 sono sotto RSALv2/SSPLv1, dalla 8 Redis Open Source è tri-licenziato e include AGPL-3.0.

La mappa: quattordici fasi e la scelta per ciascuna

La tabella è il punto di partenza, ogni riga nasconde un compromesso che vale la pena leggere per esteso.

Analisi, pianificazione e design

Analisi dei requisiti

L'obiettivo è trasformare bisogni vaghi in requisiti tracciabili e verificabili. Le attività sono la raccolta, la prioritizzazione, la stesura e il collegamento di ogni requisito ai test che lo dimostrano. Sul versante agile la scelta ricade su OpenProject (GPL-3.0), che lega i work package tra loro e alle baseline, con Taiga (MPL-2.0 e AGPL-3.0) più leggero per il backlog. Per requisiti strutturati e tracciabilità formale esistono StrictDoc (Apache-2.0) e Doorstop, nati per tenere i requisiti in file di testo accanto al codice. Il limite è che nessun progetto open source eguaglia gli strumenti di requirements engineering commerciali, e questa resta la fase più debole dello stack libero. Il caso d'uso tipico è il team che vuole i requisiti versionati come il codice; la maturità di OpenProject e Taiga è consolidata, quella di StrictDoc è emergente.

Pianificazione e project management

Qui si decide cosa entra nella prossima iterazione e chi lo fa. Le attività sono la pianificazione degli sprint, la gestione del backlog, il tracciamento del tempo e la reportistica. OpenProject è la scelta più completa: Gantt, Scrum e Kanban, time tracking e budget in un'unica piattaforma. Plane (AGPL-3.0) è l'alternativa moderna per chi vuole la sensazione di Linear, Kanboard (MIT) il minimalismo per chi usa solo la kanban. La forza di OpenProject è la profondità funzionale e il modello a work package; il limite è un'interfaccia meno immediata dei concorrenti recenti. Consigliato ai processi ibridi o waterfall; Plane è più rapido per un team di prodotto puro. Maturità consolidata per tutti e tre.

Modellazione e design

L'obiettivo è descrivere l'architettura e l'esperienza prima di scrivere il codice. Le attività sono i diagrammi UML e di flusso, la modellazione dei dati e il design dell'interfaccia. PlantUML (GPL-3.0, con build alternative LGPL, Apache e MIT) copre l'UML completo via testo, Mermaid (MIT) vive dentro i file Markdown e si renderizza direttamente nelle pull request, draw.io (Apache-2.0) è il diagramma visuale self-hostable. Per il design di prodotto, Penpot (MPL-2.0) è l'alternativa open source a Figma, con componenti, token e prototipazione. La forza è la diagrammazione come codice, versionabile e diffabile; il limite è che nessuno di questi strumenti mantiene un modello architetturale coerente con il codice nel tempo. Caso d'uso: architettura as-code nei repository e mockup UI per i team di prodotto. Maturità consolidata.

Codice, integrazione e consegna

Gestione del codice sorgente

Il controllo di versione è il cuore. Le attività sono il branching, la revisione del codice e la gestione delle release. Git (GPL-2.0) è lo standard, mentre l'hosting può restare in casa con GitLab Community Edition (MIT), che porta con sé CI, registry e gestione dei progetti, oppure con Forgejo (GPL-3.0 e oltre) e Gitea (MIT) quando serve leggerezza, o Gerrit (Apache-2.0) per la revisione formale basata su change. La forza di GitLab CE è l'integrazione verticale; il limite, se lo autohosti, è l'onere operativo di aggiornamenti e backup. Consigliato a chi vuole un'unica piattaforma; Forgejo a chi cerca leggerezza.

Continuous integration

L'integrazione continua verifica ogni modifica appena arriva. Le attività sono il build automatico, i test unitari e la produzione di artefatti. Jenkins (MIT) resta la scelta più diffusa per l'ampiezza dell'ecosistema di plugin, ma quella stessa ampiezza è il suo limite: aggiornamenti e plugin da manutenere. Tekton (Apache-2.0) porta la pipeline dentro Kubernetes come risorse native, Woodpecker (Apache-2.0) è l'opzione leggera per chi usa Gitea o Forgejo. La forza di Tekton è la portabilità cloud native; il caso d'uso è il team già su Kubernetes. Jenkins per pipeline esistenti, Woodpecker per i team piccoli.

Continuous delivery e deployment

Consegnare significa portare in produzione in modo ripetibile. Le attività sono il rilascio automatizzato, il provisioning dell'infrastruttura e il rollback. Argo CD (Apache-2.0) e Flux (Apache-2.0) realizzano il GitOps: lo stato desiderato vive in Git e viene riconciliato nel cluster. OpenTofu (MPL-2.0) è il fork libero di Terraform, sotto la Linux Foundation, per infrastruttura come codice; Spinnaker (Apache-2.0) copre i rilascio multi-cloud più complessi. La forza è la reversibilità e l'auditabilità dei rilasci; il limite è che il GitOps pretende disciplina: manifesto sbagliato, cluster divergente. Consigliato a chi ha adottato Kubernetes; per una PMI basta Docker Compose.

Test, qualità e sicurezza

Test automation

Automatizzare i test è ciò che rende sostenibile il rilascio continuo. Le attività sono i test unitari, di integrazione ed end-to-end. Playwright (Apache-2.0) è oggi il riferimento per l'E2E su browser, Selenium (Apache-2.0) resta la base storica e multi-linguaggio, Cypress (MIT per il core) punta sull'esperienza di sviluppo. Robot Framework (Apache-2.0) copre l'accettazione keyword-driven, Testcontainers (MIT) porta database e servizi reali nei test di integrazione. Per il carico, k6 (AGPL-3.0), Apache JMeter (Apache-2.0) e Gatling (Apache-2.0) coprono esigenze diverse. La forza è la copertura a costo zero di licenza; il limite sono i test fragili, che vanno curati come codice.

Code quality e static analysis

L'analisi statica intercetta i difetti prima dell'esecuzione. Le attività sono il linting, il calcolo del debito tecnico e il controllo delle regole. SonarQube Community Build analizza decine di linguaggi con quality gate, ma va letta la licenza: il server è LGPL-3.0, mentre dal novembre 2024 gli analyzer bundled sono passati alla Sonar Source-Available License, gratuita ma non OSI. Semgrep CE (motore LGPL-2.1) cerca pattern di sicurezza e anti-pattern. Per i singoli linguaggi ci sono ESLint (MIT), Ruff (MIT), Pylint (GPL-2.0), PMD (BSD) e Checkstyle (LGPL-2.1). La forza è l'automazione delle regole; il limite sono i falsi positivi da tarare.

Security testing (DevSecOps)

La sicurezza si sposta a sinistra, dentro la pipeline. Le attività sono l'analisi statica del codice, la scansione delle dipendenze e delle immagini, il test dinamico e la gestione delle vulnerabilità. OWASP ZAP (Apache-2.0) è il riferimento per il DAST, Trivy (Apache-2.0) scansiona immagini, filesystem e dipendenze, OWASP Dependency-Track (Apache-2.0) analizza gli SBOM CycloneDX, Gitleaks (MIT) intercetta i segreti e DefectDojo (BSD-3-Clause) aggrega e deduplica i risultati di oltre 200 strumenti. La forza è una catena DevSecOps interamente libera; il limite resta il triage umano dei falsi positivi.

Esecuzione, osservabilità e conoscenza

Containerizzazione e orchestrazione

Imballare l'applicazione e orchestrarla è ciò che rende ripetibile l'esecuzione. Le attività sono la costruzione delle immagini, la schedulazione dei carichi e la gestione delle configurazioni. containerd (Apache-2.0) è il runtime di fatto, Podman (Apache-2.0) l'alternativa rootless a Docker, Kubernetes (Apache-2.0) lo standard per l'orchestrazione. K3s (Apache-2.0) riduce Kubernetes a un singolo binario, Helm (Apache-2.0) e Kustomize (Apache-2.0) gestiscono i manifest, OKD (Apache-2.0) è la distribuzione community di OpenShift. La forza è la portabilità; il limite è il costo cognitivo e operativo del control plane. Consigliato oltre una certa scala: sotto, Docker Compose è più che sufficiente.

Monitoring e observability

Ciò che non si osserva non si governa. Le attività sono la raccolta di metriche, log e tracce, l'alerting e la diagnosi degli incidenti. Prometheus (Apache-2.0) è lo standard per le metriche, OpenTelemetry (Apache-2.0) per strumentare in modo neutro, Grafana (AGPL-3.0) per visualizzare, con Loki e Tempo per log e tracce. Zabbix (AGPL-3.0 dalla versione 7.0) e Netdata coprono il monitoraggio infrastrutturale, Uptime Kuma (MIT) il controllo degli uptime. La forza è una catena completa senza licenze; il limite è che storage e cardinalità delle metriche hanno un costo reale.

Documentazione tecnica

La documentazione nel codice evita che il sapere si disperda. Le attività sono la scrittura, la pubblicazione versionata e la generazione dalle API. MkDocs (BSD-2-Clause) è la via Markdown più semplice, Docusaurus (MIT) offre ricerca e versionamento, Sphinx (BSD-2-Clause) eccelle sull'estrazione dalle docstring Python, Antora (MPL-2.0) assembla documentazione AsciiDoc da più repository. La forza è il docs-as-code: la documentazione segue le pull request; il limite è che senza una pipeline in CI si disallinea.

Knowledge management

Sapere organizzato è il complemento della documentazione tecnica. Le attività sono la base di conoscenza interna, i runbook e le FAQ di team. BookStack (MIT) organizza il sapere in scaffali, libri e capitoli, con un modello mentale immediato; Wiki.js (AGPL-3.0) è più moderno e flessibile; MediaWiki (GPL-2.0) regge grandi volumi. La forza è il costo zero e il pieno controllo dei dati; il limite è che senza una struttura e un proprietario, il wiki diventa un cimitero di pagine.

Collaboration e workflow

La comunicazione tiene insieme il processo. Le attività sono la chat di team, le chiamate e le automazioni di workflow. Mattermost (Team Edition, MIT) è l'alternativa self-hosted a Slack con piena sovranità sui dati, Rocket.Chat (MIT) ha un core flessibile, Zulip (Apache-2.0) organizza le conversazioni per argomento, Element (AGPL-3.0, con opzione commerciale) porta il protocollo Matrix con la cifratura end-to-end, Jitsi (Apache-2.0) copre le videochiamate. La forza è l'indipendenza dal fornitore; il limite è la migrazione e la disciplina sulle notifiche.

Quattro stack completi, dal garage all'enterprise

Le quattro colonne non sono compartimenti stagni: una startup può adottare Kubernetes troppo presto e pagarne la complessità. Il criterio non è la moda, è il numero di persone che devono condividere lo stesso processo. Crossplane, Open Policy Agent e Kyverno sono il tassello che distingue lo stack cloud native: policy as-code e controllo delle risorse.

Gli otto modelli di processo gratuiti

Il ciclo di vita non è solo strumenti, è anche il metodo con cui li usi. Questi modelli non si comprano: sono descritti in guide pubbliche e si applicano con gli strumenti in elenco.

Nessuno di questi è incompatibile con gli altri, e la maggior parte delle organizzazioni reali ne combina due o tre. Il rischio è scegliere il modello prima del contesto: Scrum su un team che non ha un product owner è solo cerimonia.

Un workflow di esempio, dall'idea al rilascio

Ecco come le tessere si incastrano lungo un singolo lavoro, dalla richiesta al rilascio:

1. Il requisito nasce come work package in OpenProject e diventa un issue nel forge (GitLab CE o Forgejo).
2. Lo sviluppatore apre una pull request; la CI (Tekton o Woodpecker) esegue lint, test unitari e build.
3. Nella stessa pipeline girano SonarQube per il quality gate, Semgrep e Gitleaks per il codice, Trivy per le dipendenze.
4. L'immagine viene costruita, Syft ne genera l'SBOM, Trivy la scansiona e Harbor la conserva.
5. Su staging, OWASP ZAP esegue il test dinamico; DefectDojo raccoglie e deduplica tutti i findings.
6. OpenTofu provvede l'infrastruttura e Argo CD sincronizza il cluster con lo stato desiderato in Git.
7. OpenTelemetry esporta tracce e metriche verso Prometheus e Grafana; Uptime Kuma sorveglia la disponibilità.
8. MkDocs pubblica la documentazione aggiornata, BookStack il runbook, Mattermost notifica l'esito al team.

Lo stesso flusso si può ridurre o ampliare: la startup dei primi stack salta Kubernetes e OpenTofu e vive felicemente con Docker Compose, ma tiene CI, scanning e test. La parte che non si può saltare è l'ultima: senza osservabilità e senza documentazione, ogni incidente ricomincia da capo.

Domande frequenti

Serve davvero Kubernetes? No. Sotto i dieci servizi o con un team piccolo, Docker Compose è più semplice e tracciabile. Kubernetes diventa conveniente quando servono scalabilità automatica, isolamento e self-healing su molti servizi.

Quanto costa uno stack completamente open source? Le licenze sono zero; i costi reali sono l'infrastruttura (server, storage, rete) e soprattutto il tempo delle persone che installano, aggiornano e sorvegliano. Un self-hosting senza un responsabile interno è un debito, non un risparmio.

Quali strumenti evitare se si vuole restare su licenza OSI? Quelli passati a BUSL (Terraform, Vault, Nomad), le release di Redis 7.4-7.8 (RSALv2/SSPLv1) e i prodotti source-available come Outline e le funzioni Enterprise di progetti open-core come GitLab e Mattermost, che richiedono una licenza in produzione.

Si può coprire tutto l'SDLC con un solo strumento? GitLab CE copre molto (codice, CI, registry, issue), ma la pianificazione avanzata, la gestione dei requisiti e la sicurezza applicativa richiedono strumenti dedicati. Un unico vendor semplifica l'integrazione, non elimina le fasi.

Come si mantiene aggiornata una panoramica come questa? Le versioni e i limiti cambiano in fretta. Prima di adottare uno strumento verifica pagina di licenza, changelog e ultima release: la verifica di questo pezzo è datata 1 ottobre 2026.

Tre raccomandazioni pratiche

Primo: parti dal flusso, non dagli strumenti. Disegna il percorso da requisito a rilascio e solo dopo scegli chi lo copre. Adottare Kubernetes o un data portal senza il problema che li giustifica è il modo più rapido di aggiungere complessità.

Secondo: un solo strumento per fase, integrato via API. Due strumenti che fanno la stessa cosa creano due verità. Se ne aggiungi un secondo, decidi prima quale è la fonte autorevole del dato.

Terzo: leggi la licenza, non lo slogan. Open source, source-available e open-core sono tre cose diverse. Terraform è ancora gratuito per molti usi, ma non è più su licenza OSI; GitLab è aperto, ma le funzioni che servono in produzione spesso stanno nell'edizione Enterprise. Il costo nascosto più caro non è la licenza, è scoprire il vincolo dopo l'adozione.

Il codice aperto per l'intero ciclo di vita esiste ed è maturo: la parte difficile non è trovarlo, è scegliere il sottoinsieme che il tuo contesto può sostenere. Un pezzo correlato di questo blog racconta come Cloudflare proponga un ciclo di vita per agenti al posto dello SDLC: utile per capire dove il processo tradizionale inizia a scricchiolare.

Fonti

Fonti primarie, consultate e ricontrollate il 1 ottobre 2026:

• OpenProject (repository e licenza GPL-3.0, piattaforma di project management)
• Taiga (licenza MPL-2.0 e AGPL-3.0, backlog agile)
• Plane (licenza AGPL-3.0, project management moderno)
• Kanboard (licenza MIT, kanban minimale)
• StrictDoc (licenza Apache-2.0, requirements management)
• PlantUML (GPL-3.0 con build alternative LGPL, Apache e MIT, diagrammi UML da testo)
• Mermaid (licenza MIT, diagrammi in Markdown)
• draw.io (licenza Apache-2.0, diagrammi visuali)
• Penpot (licenza MPL-2.0, design e prototipazione)
• Git (licenza GPL-2.0, controllo di versione)
• GitLab Community Edition (licenza MIT, forge con CI integrata)
• Forgejo (licenza GPL-3.0 e oltre, forge leggero non profit)
• Jenkins (licenza MIT, automazione delle build)
• Tekton (licenza Apache-2.0, pipeline cloud native)
• Woodpecker CI (licenza Apache-2.0, CI leggera)
• Argo CD (licenza Apache-2.0, GitOps per Kubernetes)
• Flux (licenza Apache-2.0, GitOps)
• OpenTofu (licenza MPL-2.0, infrastruttura come codice)
• Playwright (licenza Apache-2.0, test end-to-end)
• Selenium (licenza Apache-2.0, automazione browser)
• Robot Framework (licenza Apache-2.0, test di accettazione)
• Apache JMeter (licenza Apache-2.0, test di carico)
• SonarQube Community Build (LGPL-3.0 con analyzer SSALv1, analisi statica)
• Semgrep CE (motore LGPL-2.1, analisi di sicurezza)
• OWASP ZAP (licenza Apache-2.0, test dinamico di sicurezza)
• Trivy (licenza Apache-2.0, scansione vulnerabilità)
• OWASP Dependency-Track (licenza Apache-2.0, analisi SBOM)
• DefectDojo (licenza BSD-3-Clause, gestione vulnerabilità)
• containerd e Kubernetes (licenza Apache-2.0, runtime e orchestrazione)
• Harbor (licenza Apache-2.0, registry di immagini) e Syft (licenza Apache-2.0, generazione SBOM)
• Prometheus e OpenTelemetry (licenza Apache-2.0, metriche e tracing)
• Grafana (licenza AGPL-3.0, visualizzazione e osservabilità)
• Zabbix (licenza AGPL-3.0 dalla 7.0, monitoraggio infrastrutturale)
• MkDocs (licenza BSD-2-Clause) e Docusaurus (licenza MIT), documentazione tecnica
• BookStack (licenza MIT) e Wiki.js (licenza AGPL-3.0), knowledge base
• Mattermost (Team Edition, MIT), Zulip (Apache-2.0) e Element (AGPL-3.0, multi-licenza con GPL-3.0 o licenza commerciale), collaborazione
• Redis licenses (RSALv2/SSPLv1/AGPL-3.0 dalla versione 8, fonti del perimetro)
• Backstage (licenza Apache-2.0, CNCF), Crossplane e Kyverno, platform engineering