docs: research open-core conversion patterns

docs/research/2026-09-02-open-core-comparables.md

@@ -0,0 +1,256 @@
+# Prodotti open-core comparabili e meccanismi di conversione per ThothII
+
+Ricerca originale: 2026-09-02
+
+Issue: [Studiare prodotti open-core comparabili e i loro meccanismi di conversione](https://git.tylconsulting.it/mptyl/ThothII/issues/25)
+
+## Domanda
+
+Come separano core gratuito e capacità Enterprise prodotti open-core comparabili nei data tool e
+developer tool, quale bisogno induce la conversione e quali anti-pattern hanno danneggiato adozione
+o fiducia? Quali lezioni sono applicabili a ThothII come Customer-Hosted Installation?
+
+## Risposta in breve
+
+Il pattern più solido non è «far pagare il risultato migliore», ma lasciare aperto un prodotto che
+completa davvero il lavoro fondamentale e far pagare il costo organizzativo del suo uso su scala:
+identità e autorizzazioni, policy, audit di conformità, esercizio production-grade, integrazioni
+governate e responsabilità contrattuale.
+
+Metabase è il confronto più vicino a ThothII: nell'edizione open include interrogazione, generazione
+SQL, funzioni AI, modello portato dal cliente, MCP, Agent API e CLI; Pro aggiunge permessi granulari,
+SSO e auditing, mentre Enterprise differenzia soprattutto deployment air-gapped, procurement e
+SLA. GitLab e Grafana confermano lo stesso schema nei developer tool: il lavoro quotidiano resta
+nel core e la conversione è indotta dalla crescita dell'organizzazione o dal rischio operativo.
+
+Per ThothII ne segue una separazione consigliata:
+
+- **Community Edition open source:** percorso completo domanda → artifact SQL revisionato, Evidence,
+  catalogo, gate umani, BYOM/embedding, connettori fondamentali, CLI e contratti di estensione,
+  installazione singola sicura e utilizzabile in produzione;
+- **Enterprise Edition commerciale:** federazione delle identità e group sync, RBAC/policy avanzati,
+  audit esportabile e resistente alle manomissioni, segregazione dei ruoli, HA/DR/backup e upgrade
+  governati, pacchetti air-gap, integrazioni ETL/CI/CD e secret manager certificate, supporto e SLA.
+
+La qualità del workflow F1–F8, la leggibilità degli artifact e la sicurezza minima non devono essere
+paywall. Una Community Edition incapace di provare il vantaggio distintivo di ThothII non costruisce
+né reputazione né un futuro funnel commerciale.
+
+## Metodo e limiti
+
+La ricerca usa documentazione, licenze e pagine di prezzo ufficiali correnti al 2 settembre 2026.
+Le aziende non pubblicano dati di funnel sufficienti a dimostrare quali singole feature causino una
+conversione. I «trigger» sotto sono quindi inferenze esplicite ricavate dal confine dei piani, dal
+buyer descritto e dal meccanismo di prezzo; non sono tassi di conversione osservati.
+
+## Confronto
+
+| Prodotto | Core gratuito | Confine commerciale | Trigger di conversione inferito | Lezione per ThothII |
+| --- | --- | --- | --- | --- |
+| **Metabase** | Open Source Edition in AGPL. Il piano open include query builder, editor SQL, AI, BYOM, MCP, Agent API e CLI. | Pro aggiunge SSO, permessi row/column, controlli e auditing; Enterprise aggiunge air-gap, procurement, success engineer e SLA. | Dati condivisi fra più gruppi o tenant, requisiti normativi, deployment mission-critical. | Analogo più forte: aprire il motore AI/SQL completo e monetizzare governo e affidabilità. |
+| **GitLab** | Community Edition MIT; il prodotto Free conserva repository e workflow DevOps fondamentali. | Enterprise Edition ha codice dedicato e feature Premium/Ultimate; Premium punta a organizzazioni in crescita, Ultimate a sicurezza e compliance. | Coordinamento su scala, controlli di processo, security e compliance. | Tenere stabile il core e far emergere il valore Enterprise quando crescono attori, ambienti e rischio. |
+| **Grafana** | Grafana OSS è AGPL e resta un prodotto completo di visualizzazione e dashboard. | Enterprise aggiunge RBAC, SAML/team sync, permessi sui data source, audit, Vault, plugin premium e supporto 24/7. | Accesso a dati sensibili, integrazione con stack aziendale, conformità e responsabilità operativa. | Vendere controllo e integrazioni certificate, non la capacità fondamentale di interrogare e capire i dati. |
+| **Mattermost** | Team Edition è MIT e self-hosted; offre il lavoro collaborativo fondamentale. | Un'edizione commerciale self-hosted abilita feature tramite licenza; Entry è il fallback gratuito con limiti e omissioni. | SSO, compliance, HA, supporto e dimensione del deployment. | Il singolo artefatto installabile può semplificare upgrade e trial, ma i limiti quantitativi e il riposizionamento della Community creano confusione. |
+| **Airbyte** | Il protocollo è MIT; Core e connector sono oggi ELv2, utilizzabili internamente ma con restrizione alla rivendita come servizio. Il motore di replica resta gratuito. | Offerte commerciali aggiungono governance, supporto/SLA e deployment controllati; l'offerta corrente Enterprise Flex comprende anche un control plane gestito. | Sovranità, governance multi-workspace, secret manager, operatività e supporto. | Utile per il confine funzionale, non come modello di licenza o architettura: ELv2 non è una licenza open source OSI e Flex non è interamente customer-hosted. |
+
+### Metabase: il comparabile più vicino
+
+Metabase pubblica l'Open Source Edition in AGPL e distribuisce la parte Enterprise con licenza
+commerciale; nel repository le due famiglie di codice sono separate anche per directory
+([licenze Metabase](https://www.metabase.com/license/),
+[LICENSE del repository](https://github.com/metabase/metabase/blob/master/LICENSE.txt)). La
+[matrice corrente dei piani](https://www.metabase.com/pricing/compare-plans) mantiene in Open Source
+le funzioni che dimostrano il valore del prodotto: domande AI, BYOM, MCP, Agent API, CLI, query
+builder ed editor SQL. Sposta invece in Pro permessi row/column, SSO, controlli AI, analytics d'uso
+e auditing.
+
+La [pagina prezzi](https://www.metabase.com/pricing) esplicita anche due scelte economiche utili:
+Open Source ha utenti illimitati; Pro combina un minimo mensile con prezzo per utente; Enterprise
+parte da 20.000 USD/anno e risponde a procurement, air-gap e SLA. Inoltre Pro ed Enterprise hanno
+lo stesso insieme di feature principali: il salto Enterprise vende soprattutto modalità di
+fornitura e responsabilità. Il pricing non va copiato, ma il segnale è pertinente: il cliente
+regolato non paga per una query «più intelligente», paga perché il sistema può essere adottato e
+presidiato secondo le regole dell'organizzazione.
+
+### GitLab: separazione tecnica e crescita organizzativa
+
+GitLab dichiara la Community Edition sotto MIT e la Enterprise Edition sotto licenza più
+restrittiva ([licensing](https://docs.gitlab.com/development/licensing/)). In un unico codebase, il
+codice Enterprise risiede in `ee/`; senza licenza, una build EE deve comportarsi come CE
+([linee guida EE](https://docs.gitlab.com/development/ee_features/)). Questo riduce il rischio che
+l'installazione perda la funzione fondamentale quando una licenza scade e consente di testare
+esplicitamente sia la modalità Community sia quella Enterprise.
+
+Il [pricing corrente](https://about.gitlab.com/pricing/) presenta Premium a 29 USD per utente/mese
+per organizzazioni in crescita e Ultimate a prezzo personalizzato per sicurezza e compliance. Il
+trigger non è l'accesso al repository o alla CI di base: è il passaggio da un team che produce a
+un'organizzazione che deve coordinare, dimostrare controlli e ridurre rischio. Per ThothII il pattern
+tecnico è replicabile, mentre il prezzo per seat lo è meno: pochi specialisti possono produrre un
+datamart di valore per un'intera organizzazione, quindi il numero degli utenti non misura bene il
+valore generato.
+
+### Grafana: integrazioni, governance e supporto
+
+Grafana OSS è passato da Apache-2.0 ad AGPLv3 per le versioni correnti
+([FAQ di licensing](https://grafana.com/licensing/)). Grafana Enterprise è una build commerciale
+che aggiunge RBAC, permessi sui data source, SAML e sincronizzazione dei team, audit, integrazione
+Vault, reporting, plugin premium e supporto continuativo
+([feature Enterprise](https://grafana.com/docs/grafana/latest/introduction/grafana-enterprise/)).
+Sono capacità che acquistano valore quando dashboard e data source diventano infrastruttura
+aziendale condivisa.
+
+L'[attivazione Enterprise](https://grafana.com/docs/grafana/latest/administration/enterprise-licensing/)
+usa una licenza legata all'istanza e agli utenti attivi; per ambienti senza Internet sono previste
+modalità concordate con il vendor. La stessa documentazione mostra un buon principio di scadenza:
+diverse configurazioni di sicurezza già applicate continuano a funzionare, mentre non è possibile
+crearene o modificarne di nuove. ThothII dovrebbe essere ancora più conservativo: una scadenza non
+deve rendere illeggibili gli artifact, invalidare decisioni persistite o interrompere un workflow
+Community già consentito.
+
+### Mattermost: distribuzione semplice, ma confine instabile
+
+Mattermost usa due pattern contemporaneamente: Team Edition è una piattaforma self-hosted MIT;
+l'Enterprise Edition è un binario commerciale che può funzionare gratuitamente in modalità Entry
+e sblocca le funzioni a pagamento con una licenza
+([edizioni](https://docs.mattermost.com/product-overview/editions-and-offerings.html),
+[subscription self-hosted](https://docs.mattermost.com/product-overview/self-hosted-subscriptions.html)).
+È un precedente utile per consegnare a un cliente un solo pacchetto Enterprise che degrada in modo
+prevedibile a un set gratuito.
+
+La documentazione corrente racconta però anche il costo di un confine non stabile: Team Edition era
+stata usata molto oltre il pubblico previsto e alcune integrazioni SSO sovrapponevano capacità
+commerciali; il prodotto ha quindi rimosso SSO dalla Team Edition e l'ha riposizionata per piccoli
+team. Per ThothII è preferibile fissare prima del lancio una promessa Community durevole e non
+ritirare in seguito capacità che gli utenti hanno ragionevolmente considerato parte del core.
+
+### Airbyte: completezza del motore, ma ambiguità terminologica
+
+Airbyte lascia gratuito il motore di replica e un ampio ecosistema di connector; l'offerta
+Enterprise ha aggiunto nel tempo multi-tenancy, RBAC, PII masking, secret manager esterni, air-gap,
+API/Terraform e supporto ([annuncio Self-Managed Enterprise](https://airbyte.com/blog/1-0-enterprise-ga),
+[pricing corrente](https://airbyte.com/pricing)). È un altro esempio di core che svolge davvero il
+lavoro e di conversione legata all'industrializzazione.
+
+Il limite come modello per ThothII è duplice. La [pagina licensing corrente](https://airbyte.com/why-open-source)
+definisce MIT il protocollo, ma ELv2 Core e connector: ELv2 vieta di rivendere il prodotto come
+servizio e quindi introduce una restrizione di campo d'uso. Secondo la
+[Open Source Definition](https://opensource.org/osd), una licenza open source non può imporre tale
+restrizione. Inoltre Enterprise Flex oggi comprende un control plane gestito, incompatibile con la
+decisione ThothII che domande, prompt, metadati e risultati non escano dal trust boundary del
+cliente. Airbyte è quindi un comparabile di packaging, non una licenza o topologia da copiare.
+
+## Anti-pattern osservabili
+
+### 1. Rendere incompleto il lavoro fondamentale
+
+I comparabili più credibili non riservano all'Enterprise l'azione che genera la prima prova di
+valore: Metabase non blocca AI/SQL/BYOM; GitLab non blocca source control e CI di base; Grafana non
+blocca dashboard e interrogazione; Airbyte non blocca il motore di replica. Per ThothII, mettere a
+pagamento fasi F1–F8, qualità SQL, Evidence o review fondamentale trasformerebbe la Community in una
+demo e ridurrebbe la reputazione che l'apertura deve costruire.
+
+### 2. Mettere dietro licenza la sicurezza minima
+
+SSO federato, group sync, ruoli personalizzati e audit di conformità sono boundary Enterprise
+ricorrenti. Non ne segue che una Community possa essere insicura. ThothII Community deve conservare
+autenticazione e autorizzazione di base, secret references, accesso DWH read-only, decision ledger,
+provenienza degli artifact e log operativi minimi. Enterprise può aggiungere segregazione dei
+compiti, policy obbligatorie, retention, export SIEM e audit resistente alle manomissioni.
+
+### 3. Usare «open source» per una licenza source-available
+
+MIT, Apache-2.0, AGPL e le altre licenze approvate OSI permettono uso per qualsiasi scopo. Una
+clausola che proibisce di offrire il software come servizio può essere commercialmente legittima,
+ma cambia la categoria. Presentare ELv2 o BSL come semplice open source crea ambiguità proprio sul
+diritto che utenti e integratori devono poter valutare rapidamente. Se ThothII sceglie MIT o
+Apache-2.0 per il core, deve accettare anche fork e offerte commerciali concorrenti; la protezione
+economica deve venire da marchio, roadmap, moduli Enterprise, certificazioni e servizio.
+
+### 4. Cambiare licenza dopo aver chiesto investimento all'ecosistema
+
+HashiCorp passò i prodotti core da MPL-2.0 a BSL nel 2023, descrivendo BSL come source-available
+([annuncio ufficiale](https://www.hashicorp.com/en/blog/hashicorp-adopts-business-source-license)).
+Quattro settimane dopo, OpenTofu pubblicò il fork di Terraform e avviò l'ingresso nella Linux
+Foundation ([cronologia OpenTofu](https://opentofu.org/blog/the-opentofu-fork-is-now-available/)).
+Elastic cambiò da Apache-2.0 a SSPL/ELv2 nel 2021 e nel 2024 aggiunse nuovamente AGPL, una licenza
+OSI, per la parte gratuita ([FAQ Elastic](https://www.elastic.co/pricing/faq/licensing/)); OpenSearch
+documenta di essere nato dal precedente codice Apache-2.0
+([FAQ OpenSearch](https://opensearch.org/faq/)). Questi fatti non misurano il danno commerciale, ma
+dimostrano un esito verificabile: un cambio tardivo può frammentare progetto, nome ed ecosistema.
+
+### 5. Applicare metriche di prezzo non allineate al valore
+
+GitLab, Metabase e Grafana possono usare utenti o utenti attivi perché la platea operativa cresce
+con l'adozione. ThothII ha invece pochi operatori IT/data e artifact consumati da molti processi
+aziendali. Un prezzo puramente per seat può ostacolare collaborazione e sottovalutare installazioni
+ad alto valore; un prezzo per token è ancora meno coerente quando modello ed embedding sono BYOM.
+La ricerca suggerisce di valutare installazione, ambienti/workspace governati e livello di supporto
+come unità principali, lasciando la decisione economica definitiva al ticket di packaging/prezzo.
+
+### 6. Far fallire il core alla scadenza della licenza
+
+Un contratto annuale deve disabilitare soltanto capacità commerciali future o modificabili. Dati,
+artifact, revisioni e funzioni Community devono restare leggibili ed esportabili; non devono esistere
+ransom lock-in o dipendenze online obbligatorie in un ambiente air-gapped. Questo riduce il rischio
+per il buyer e rende credibile la promessa customer-hosted.
+
+## Boundary raccomandato per ThothII
+
+### Community Edition open source
+
+- workflow deterministico F1–F8 completo e gate human-in-the-loop;
+- catalogo, Evidence, schema linking e generazione del Transformation Package;
+- configurazione BYOM e provider di embedding scelti dal cliente;
+- connettori fondamentali e accesso read-only;
+- persistenza, provenance e decision ledger necessari a riprendere e verificare il lavoro;
+- frontend, backend, CLI, contratti degli artifact e SDK/extension points;
+- installazione customer-hosted singola, backup/export manuale documentato e aggiornamenti
+  Community;
+- sicurezza di base sufficiente a un uso reale, senza limiti artificiali a utenti, domande, token o
+  qualità del risultato.
+
+### Enterprise Edition commerciale
+
+- SAML/OIDC enterprise, directory/group sync, SCIM e integrazione con identity manager;
+- RBAC personalizzato, segregazione dei ruoli, approval policy e policy pack obbligatori;
+- audit immutabile/esportabile, retention, integrazione SIEM e report di conformità;
+- HA, disaster recovery, backup/restore automatizzati, LTS, upgrade orchestrati e immagini firmate;
+- pacchetti air-gap, mirror degli artifact e gestione offline delle licenze;
+- secret manager e connettori certificati, con manutenzione/SLA;
+- promozione degli artifact fra ambienti e integrazioni ETL, CI/CD e cataloghi aziendali;
+- fleet/multi-installation management dentro il boundary del cliente;
+- onboarding, training, supporto con SLA e responsabilità contrattuale.
+
+### Separazione tecnica iniziale
+
+Se TYL Consulting vuole che il codice Enterprise rimanga proprietario, il modello più chiaro è:
+
+1. repository pubblico Community con build e test che non dipendono da codice privato;
+2. contratti stabili per moduli, policy, identity provider, connettori e operator tooling;
+3. repository privato Enterprise che produce moduli o una distribuzione comprendente il core;
+4. una modalità senza licenza che conserva esattamente il comportamento Community;
+5. license file offline firmato, senza telemetria obbligatoria né chiamata periodica a TYL;
+6. test automatici del downgrade e della leggibilità/esportabilità degli artifact.
+
+Il modello Metabase del codice commerciale visibile nello stesso repository è valido soltanto se si
+accetta che l'Enterprise sia source-available. Non corrisponde invece all'obiettivo di mantenere quel
+codice non pubblico. Il modello GitLab della directory dedicata è utile come disciplina di boundary,
+ma non obbliga ThothII ad adottarne struttura o complessità.
+
+## Decisioni che questa ricerca non prende
+
+- MIT contro Apache-2.0: entrambe sono licenze open source permissive e consentono uso commerciale;
+  la scelta finale richiede revisione legale di brevetti, notice, dipendenze e contributi.
+- prezzo e metrica contrattuale definitivi;
+- lista iniziale dei connettori certificati;
+- scelta fra plugin Enterprise, distribuzione unica o immagini separate;
+- dettagli del meccanismo di licenza offline.
+
+## Conclusione
+
+Per ThothII l'open core sostenibile è un **core aperto completo nel risultato** e un'Enterprise
+completa nella **responsabilità organizzativa**. Il primo deve permettere a un IT department di
+provare e usare realmente il percorso domanda → SQL governato; la seconda deve rendere quel percorso
+adottabile in un'organizzazione regolata, multi-ruolo e mission-critical. Questo boundary sostiene
+insieme reputazione, conversione e fiducia senza dipendere da SaaS, consumo token o degradazione
+artificiale della qualità.