> ## Content Index
> Fetch the complete content index at: https://adrianoamalfi.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# SDLC open source: gli strumenti giusti per ogni fase, dal requisito al rilascio
- URL: https://adrianoamalfi.com/tech-scratchpad/sdlc-open-source-strumenti-per-fase/
- Published: 2026-10-01T17:23:00.000Z
- Updated: 2026-10-19T14:36:34.000Z
- Description: Quattordici fasi del ciclo di vita del software, quattro stack pronti (startup, PMI, enterprise, cloud native) e otto modelli di processo: solo strumenti open source e gratuiti, con licenza, maturità, limiti e quando sceglierli.
- Author: Adriano Amalfi
- Tags: Open Source, SDLC, DevOps, CI/CD, DevSecOps, Platform Engineering, Panorama, AI Tools, #Tech Scratchpad: Appunti avanzati e esperimenti per esperti e amatoriali

**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

| Fase                                | Scelta di riferimento                  | Alternativa leggera    | Licenza della scelta                  | Maturità                | Limite della scelta                                 |
| ----------------------------------- | -------------------------------------- | ---------------------- | ------------------------------------- | ----------------------- | --------------------------------------------------- |
| Analisi dei requisiti               | OpenProject + StrictDoc                | Taiga                  | GPL-3.0 / Apache-2.0                  | Consolidata / emergente | Manca l'analisi formale dei requisiti               |
| Pianificazione e project management | OpenProject                            | Plane, Kanboard        | GPL-3.0                               | Consolidata             | Interfaccia tradizionale, agile meno fluido di Jira |
| Modellazione e design               | PlantUML + Mermaid + draw.io           | Penpot                 | GPL-3.0 / MIT / Apache-2.0            | Consolidata             | Nessun round-trip code-first sull'architettura      |
| Gestione del codice sorgente        | Git + GitLab CE                        | Forgejo, Gitea, Gerrit | GPL-2.0 / MIT                         | Consolidata             | Autohosting = onere operativo                       |
| Continuous integration              | Jenkins o Tekton                       | Woodpecker             | MIT / Apache-2.0                      | Consolidata             | Jenkins: ecosistema di plugin da manutenere         |
| Continuous delivery e deployment    | Argo CD + OpenTofu                     | Flux, Spinnaker        | Apache-2.0 / MPL-2.0                  | Consolidata             | Il GitOps richiede disciplina sui manifest          |
| Test automation                     | Playwright + Robot Framework           | Selenium, Cypress      | Apache-2.0                            | Consolidata             | Test fragili e matrice browser da gestire           |
| Code quality e static analysis      | SonarQube Community Build + Semgrep CE | ESLint, Ruff           | LGPL-3.0 (analyzer SSALv1) / LGPL-2.1 | Consolidata             | Alcuni analyzer non sono più liberi                 |
| Security testing (DevSecOps)        | OWASP ZAP + Trivy + DefectDojo         | Grype, Gitleaks        | Apache-2.0 / BSD-3-Clause             | Consolidata             | Falsi positivi e triage manuale                     |
| Containerizzazione e orchestrazione | Kubernetes + containerd + Helm         | Podman, K3s            | Apache-2.0                            | Consolidata             | Complessità operativa del control plane             |
| Monitoring e observability          | Prometheus + Grafana + OpenTelemetry   | Zabbix, Netdata        | Apache-2.0 / AGPL-3.0                 | Consolidata             | Costo di storage e cardinalità delle metriche       |
| Documentazione tecnica              | MkDocs o Docusaurus                    | Antora, Sphinx         | BSD-2-Clause / MIT                    | Consolidata             | Il docs-as-code richiede una pipeline               |
| Knowledge management                | BookStack                              | Wiki.js, MediaWiki     | MIT / AGPL-3.0                        | Consolidata             | Ricerca e struttura da governare                    |
| Collaboration e workflow            | Mattermost o Element                   | Rocket.Chat, Zulip     | MIT / AGPL-3.0                        | Consolidata             | Migrazione e rumore delle notifiche                 |

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](https://www.openproject.org/?ref=adrianoamalfi.com) (GPL-3.0), che lega i work package tra loro e alle baseline, con [Taiga](https://www.taiga.io/?ref=adrianoamalfi.com) (MPL-2.0 e AGPL-3.0) più leggero per il backlog. Per requisiti strutturati e tracciabilità formale esistono [StrictDoc](https://strictdoc.readthedocs.io/?ref=adrianoamalfi.com) (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](https://www.openproject.org/?ref=adrianoamalfi.com) è la scelta più completa: Gantt, Scrum e Kanban, time tracking e budget in un'unica piattaforma. [Plane](https://plane.so/?ref=adrianoamalfi.com) (AGPL-3.0) è l'alternativa moderna per chi vuole la sensazione di Linear, [Kanboard](https://kanboard.org/?ref=adrianoamalfi.com) (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](https://plantuml.com/?ref=adrianoamalfi.com) (GPL-3.0, con build alternative LGPL, Apache e MIT) copre l'UML completo via testo, [Mermaid](https://mermaid.js.org/?ref=adrianoamalfi.com) (MIT) vive dentro i file Markdown e si renderizza direttamente nelle pull request, [draw.io](https://www.drawio.com/?ref=adrianoamalfi.com) (Apache-2.0) è il diagramma visuale self-hostable. Per il design di prodotto, [Penpot](https://penpot.app/?ref=adrianoamalfi.com) (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](https://git-scm.com/?ref=adrianoamalfi.com) (GPL-2.0) è lo standard, mentre l'hosting può restare in casa con [GitLab Community Edition](https://about.gitlab.com/?ref=adrianoamalfi.com) (MIT), che porta con sé CI, registry e gestione dei progetti, oppure con [Forgejo](https://forgejo.org/?ref=adrianoamalfi.com) (GPL-3.0 e oltre) e [Gitea](https://about.gitea.com/?ref=adrianoamalfi.com) (MIT) quando serve leggerezza, o [Gerrit](https://www.gerritcodereview.com/?ref=adrianoamalfi.com) (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](https://www.jenkins.io/?ref=adrianoamalfi.com) (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](https://tekton.dev/?ref=adrianoamalfi.com) (Apache-2.0) porta la pipeline dentro Kubernetes come risorse native, [Woodpecker](https://woodpecker-ci.org/?ref=adrianoamalfi.com) (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](https://argo-cd.readthedocs.io/?ref=adrianoamalfi.com) (Apache-2.0) e [Flux](https://fluxcd.io/?ref=adrianoamalfi.com) (Apache-2.0) realizzano il GitOps: lo stato desiderato vive in Git e viene riconciliato nel cluster. [OpenTofu](https://opentofu.org/?ref=adrianoamalfi.com) (MPL-2.0) è il fork libero di Terraform, sotto la Linux Foundation, per infrastruttura come codice; [Spinnaker](https://spinnaker.io/?ref=adrianoamalfi.com) (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](https://playwright.dev/?ref=adrianoamalfi.com) (Apache-2.0) è oggi il riferimento per l'E2E su browser, [Selenium](https://www.selenium.dev/?ref=adrianoamalfi.com) (Apache-2.0) resta la base storica e multi-linguaggio, [Cypress](https://www.cypress.io/?ref=adrianoamalfi.com) (MIT per il core) punta sull'esperienza di sviluppo. [Robot Framework](https://robotframework.org/?ref=adrianoamalfi.com) (Apache-2.0) copre l'accettazione keyword-driven, [Testcontainers](https://testcontainers.com/?ref=adrianoamalfi.com) (MIT) porta database e servizi reali nei test di integrazione. Per il carico, [k6](https://k6.io/?ref=adrianoamalfi.com) (AGPL-3.0), [Apache JMeter](https://jmeter.apache.org/?ref=adrianoamalfi.com) (Apache-2.0) e [Gatling](https://gatling.io/?ref=adrianoamalfi.com) (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](https://www.sonarsource.com/open-source-editions/sonarqube-community-edition/?ref=adrianoamalfi.com) 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](https://semgrep.dev/products/community-edition?ref=adrianoamalfi.com) (motore LGPL-2.1) cerca pattern di sicurezza e anti-pattern. Per i singoli linguaggi ci sono [ESLint](https://eslint.org/?ref=adrianoamalfi.com) (MIT), [Ruff](https://docs.astral.sh/ruff/?ref=adrianoamalfi.com) (MIT), [Pylint](https://pylint.readthedocs.io/?ref=adrianoamalfi.com) (GPL-2.0), [PMD](https://pmd.github.io/?ref=adrianoamalfi.com) (BSD) e [Checkstyle](https://checkstyle.org/?ref=adrianoamalfi.com) (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](https://www.zaproxy.org/?ref=adrianoamalfi.com) (Apache-2.0) è il riferimento per il DAST, [Trivy](https://trivy.dev/?ref=adrianoamalfi.com) (Apache-2.0) scansiona immagini, filesystem e dipendenze, [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/?ref=adrianoamalfi.com) (Apache-2.0) analizza gli SBOM CycloneDX, [Gitleaks](https://gitleaks.io/?ref=adrianoamalfi.com) (MIT) intercetta i segreti e [DefectDojo](https://www.defectdojo.com/?ref=adrianoamalfi.com) (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](https://containerd.io/?ref=adrianoamalfi.com) (Apache-2.0) è il runtime di fatto, [Podman](https://podman.io/?ref=adrianoamalfi.com) (Apache-2.0) l'alternativa rootless a Docker, [Kubernetes](https://kubernetes.io/?ref=adrianoamalfi.com) (Apache-2.0) lo standard per l'orchestrazione. [K3s](https://k3s.io/?ref=adrianoamalfi.com) (Apache-2.0) riduce Kubernetes a un singolo binario, [Helm](https://helm.sh/?ref=adrianoamalfi.com) (Apache-2.0) e [Kustomize](https://kustomize.io/?ref=adrianoamalfi.com) (Apache-2.0) gestiscono i manifest, [OKD](https://www.okd.io/?ref=adrianoamalfi.com) (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](https://prometheus.io/?ref=adrianoamalfi.com) (Apache-2.0) è lo standard per le metriche, [OpenTelemetry](https://opentelemetry.io/?ref=adrianoamalfi.com) (Apache-2.0) per strumentare in modo neutro, [Grafana](https://grafana.com/?ref=adrianoamalfi.com) (AGPL-3.0) per visualizzare, con [Loki](https://grafana.com/oss/loki/?ref=adrianoamalfi.com) e [Tempo](https://grafana.com/oss/tempo/?ref=adrianoamalfi.com) per log e tracce. [Zabbix](https://www.zabbix.com/?ref=adrianoamalfi.com) (AGPL-3.0 dalla versione 7.0) e [Netdata](https://www.netdata.cloud/?ref=adrianoamalfi.com) coprono il monitoraggio infrastrutturale, [Uptime Kuma](https://uptime.kuma.pet/?ref=adrianoamalfi.com) (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](https://www.mkdocs.org/?ref=adrianoamalfi.com) (BSD-2-Clause) è la via Markdown più semplice, [Docusaurus](https://docusaurus.io/?ref=adrianoamalfi.com) (MIT) offre ricerca e versionamento, [Sphinx](https://www.sphinx-doc.org/?ref=adrianoamalfi.com) (BSD-2-Clause) eccelle sull'estrazione dalle docstring Python, [Antora](https://antora.org/?ref=adrianoamalfi.com) (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](https://www.bookstackapp.com/?ref=adrianoamalfi.com) (MIT) organizza il sapere in scaffali, libri e capitoli, con un modello mentale immediato; [Wiki.js](https://js.wiki/?ref=adrianoamalfi.com) (AGPL-3.0) è più moderno e flessibile; [MediaWiki](https://www.mediawiki.org/?ref=adrianoamalfi.com) (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](https://mattermost.com/?ref=adrianoamalfi.com) (Team Edition, MIT) è l'alternativa self-hosted a Slack con piena sovranità sui dati, [Rocket.Chat](https://rocket.chat/?ref=adrianoamalfi.com) (MIT) ha un core flessibile, [Zulip](https://zulip.com/?ref=adrianoamalfi.com) (Apache-2.0) organizza le conversazioni per argomento, [Element](https://element.io/?ref=adrianoamalfi.com) (AGPL-3.0, con opzione commerciale) porta il protocollo Matrix con la cifratura end-to-end, [Jitsi](https://jitsi.org/?ref=adrianoamalfi.com) (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

| Profilo      | Team tipico                               | Stack                                                                                                                                        | Punto di forza                                    |
| ------------ | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| Startup      | 1-5 sviluppatori, budget zero             | Forgejo + Woodpecker + Plane + Playwright + Trivy + Docker Compose + Uptime Kuma + MkDocs + Mattermost                                       | Si avvia in una giornata, nessun costo di licenza |
| PMI          | 10-50 persone, processo da standardizzare | GitLab CE + GitLab CI + OpenProject + SonarQube Community + OWASP ZAP + Argo CD + Kubernetes gestito + Prometheus/Grafana + BookStack        | Una piattaforma copre codice, CI e registry       |
| Enterprise   | 100+ persone, compliance e audit          | GitLab self-hosted + Tekton o Jenkins + OpenProject + SonarQube + DefectDojo + OpenTofu + Argo CD + OKD + OpenTelemetry + Backstage + Sphinx | Tracciabilità e governance end-to-end             |
| Cloud native | Platform team interno                     | Forgejo o GitLab + Argo CD o Flux + Backstage + Crossplane o OpenTofu + Kubernetes + Prometheus/Grafana/Loki/Tempo + OPA o Kyverno + Trivy   | Self-service e policy as-code                     |

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](https://www.crossplane.io/?ref=adrianoamalfi.com), [Open Policy Agent](https://www.openpolicyagent.org/?ref=adrianoamalfi.com) e [Kyverno](https://kyverno.io/?ref=adrianoamalfi.com) 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.

| Modello              | Cosa aggiunge                                         | Dove vive la regola       | Strumenti gratuiti       |
| -------------------- | ----------------------------------------------------- | ------------------------- | ------------------------ |
| Agile                | Iterazioni brevi e adattamento continuo               | Manifesto Agile           | OpenProject, Plane       |
| Scrum                | Ruoli, eventi e artefatti con cadenza fissa           | Scrum Guide               | Taiga, OpenProject       |
| Kanban               | Flusso continuo e limiti al lavoro in corso           | Kanban Guide              | Kanboard, Plane          |
| Extreme Programming  | Pratiche tecniche: TDD, pair programming, CI          | Regole XP                 | Jenkins, Playwright      |
| DevOps               | Cultura di collaborazione e automazione del rilascio  | DORA                      | GitLab CI, Argo CD       |
| DevSecOps            | Sicurezza integrata a ogni stadio                     | NIST SSDF                 | Semgrep, ZAP, DefectDojo |
| GitOps               | Git come fonte di verità, riconciliazione automatica  | OpenGitOps                | Argo CD, Flux            |
| Platform Engineering | Piattaforma interna self-service per gli sviluppatori | CNCF Platform White Paper | Backstage, Crossplane    |

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](https://github.com/anchore/syft?ref=adrianoamalfi.com) ne genera l'SBOM, Trivy la scansiona e [Harbor](https://goharbor.io/?ref=adrianoamalfi.com) 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](https://adrianoamalfi.com/cloudflare-adlc-agent-development-lifecycle/): utile per capire dove il processo tradizionale inizia a scricchiolare.

## Fonti

Fonti primarie, consultate e ricontrollate il 1 ottobre 2026:

- [OpenProject](https://www.openproject.org/?ref=adrianoamalfi.com) (repository e licenza GPL-3.0, piattaforma di project management)
- [Taiga](https://www.taiga.io/?ref=adrianoamalfi.com) (licenza MPL-2.0 e AGPL-3.0, backlog agile)
- [Plane](https://plane.so/?ref=adrianoamalfi.com) (licenza AGPL-3.0, project management moderno)
- [Kanboard](https://kanboard.org/?ref=adrianoamalfi.com) (licenza MIT, kanban minimale)
- [StrictDoc](https://strictdoc.readthedocs.io/?ref=adrianoamalfi.com) (licenza Apache-2.0, requirements management)
- [PlantUML](https://plantuml.com/license?ref=adrianoamalfi.com) (GPL-3.0 con build alternative LGPL, Apache e MIT, diagrammi UML da testo)
- [Mermaid](https://mermaid.js.org/?ref=adrianoamalfi.com) (licenza MIT, diagrammi in Markdown)
- [draw.io](https://www.drawio.com/?ref=adrianoamalfi.com) (licenza Apache-2.0, diagrammi visuali)
- [Penpot](https://penpot.app/?ref=adrianoamalfi.com) (licenza MPL-2.0, design e prototipazione)
- [Git](https://git-scm.com/?ref=adrianoamalfi.com) (licenza GPL-2.0, controllo di versione)
- [GitLab Community Edition](https://about.gitlab.com/install/?ref=adrianoamalfi.com) (licenza MIT, forge con CI integrata)
- [Forgejo](https://forgejo.org/?ref=adrianoamalfi.com) (licenza GPL-3.0 e oltre, forge leggero non profit)
- [Jenkins](https://www.jenkins.io/?ref=adrianoamalfi.com) (licenza MIT, automazione delle build)
- [Tekton](https://tekton.dev/?ref=adrianoamalfi.com) (licenza Apache-2.0, pipeline cloud native)
- [Woodpecker CI](https://woodpecker-ci.org/?ref=adrianoamalfi.com) (licenza Apache-2.0, CI leggera)
- [Argo CD](https://argo-cd.readthedocs.io/?ref=adrianoamalfi.com) (licenza Apache-2.0, GitOps per Kubernetes)
- [Flux](https://fluxcd.io/?ref=adrianoamalfi.com) (licenza Apache-2.0, GitOps)
- [OpenTofu](https://opentofu.org/?ref=adrianoamalfi.com) (licenza MPL-2.0, infrastruttura come codice)
- [Playwright](https://playwright.dev/?ref=adrianoamalfi.com) (licenza Apache-2.0, test end-to-end)
- [Selenium](https://www.selenium.dev/?ref=adrianoamalfi.com) (licenza Apache-2.0, automazione browser)
- [Robot Framework](https://robotframework.org/?ref=adrianoamalfi.com) (licenza Apache-2.0, test di accettazione)
- [Apache JMeter](https://jmeter.apache.org/?ref=adrianoamalfi.com) (licenza Apache-2.0, test di carico)
- [SonarQube Community Build](https://www.sonarsource.com/open-source-editions/sonarqube-community-edition/?ref=adrianoamalfi.com) (LGPL-3.0 con analyzer SSALv1, analisi statica)
- [Semgrep CE](https://semgrep.dev/products/community-edition?ref=adrianoamalfi.com) (motore LGPL-2.1, analisi di sicurezza)
- [OWASP ZAP](https://www.zaproxy.org/?ref=adrianoamalfi.com) (licenza Apache-2.0, test dinamico di sicurezza)
- [Trivy](https://trivy.dev/?ref=adrianoamalfi.com) (licenza Apache-2.0, scansione vulnerabilità)
- [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/?ref=adrianoamalfi.com) (licenza Apache-2.0, analisi SBOM)
- [DefectDojo](https://www.defectdojo.com/?ref=adrianoamalfi.com) (licenza BSD-3-Clause, gestione vulnerabilità)
- [containerd](https://containerd.io/?ref=adrianoamalfi.com) e [Kubernetes](https://kubernetes.io/?ref=adrianoamalfi.com) (licenza Apache-2.0, runtime e orchestrazione)
- [Harbor](https://goharbor.io/?ref=adrianoamalfi.com) (licenza Apache-2.0, registry di immagini) e [Syft](https://github.com/anchore/syft?ref=adrianoamalfi.com) (licenza Apache-2.0, generazione SBOM)
- [Prometheus](https://prometheus.io/?ref=adrianoamalfi.com) e [OpenTelemetry](https://opentelemetry.io/?ref=adrianoamalfi.com) (licenza Apache-2.0, metriche e tracing)
- [Grafana](https://grafana.com/licensing/?ref=adrianoamalfi.com) (licenza AGPL-3.0, visualizzazione e osservabilità)
- [Zabbix](https://www.zabbix.com/license?ref=adrianoamalfi.com) (licenza AGPL-3.0 dalla 7.0, monitoraggio infrastrutturale)
- [MkDocs](https://www.mkdocs.org/?ref=adrianoamalfi.com) (licenza BSD-2-Clause) e [Docusaurus](https://docusaurus.io/?ref=adrianoamalfi.com) (licenza MIT), documentazione tecnica
- [BookStack](https://www.bookstackapp.com/?ref=adrianoamalfi.com) (licenza MIT) e [Wiki.js](https://js.wiki/?ref=adrianoamalfi.com) (licenza AGPL-3.0), knowledge base
- [Mattermost](https://docs.mattermost.com/product-overview/faq-license.html?ref=adrianoamalfi.com) (Team Edition, MIT), [Zulip](https://zulip.com/?ref=adrianoamalfi.com) (Apache-2.0) e [Element](https://github.com/element-hq/element-web?ref=adrianoamalfi.com) (AGPL-3.0, multi-licenza con GPL-3.0 o licenza commerciale), collaborazione
- [Redis licenses](https://redis.io/legal/licenses/?ref=adrianoamalfi.com) (RSALv2/SSPLv1/AGPL-3.0 dalla versione 8, fonti del perimetro)
- [Backstage](https://backstage.io/?ref=adrianoamalfi.com) (licenza Apache-2.0, CNCF), [Crossplane](https://www.crossplane.io/?ref=adrianoamalfi.com) e [Kyverno](https://kyverno.io/?ref=adrianoamalfi.com), platform engineering