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

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

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, LICENSE del repository). La matrice corrente dei piani 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 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). In un unico codebase, il codice Enterprise risiede in ee/; senza licenza, una build EE deve comportarsi come CE (linee guida EE). 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 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). 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). Sono capacità che acquistano valore quando dashboard e data source diventano infrastruttura aziendale condivisa.

L'attivazione Enterprise 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, subscription self-hosted). È 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, pricing corrente). È 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 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, 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). Quattro settimane dopo, OpenTofu pubblicò il fork di Terraform e avviò l'ingresso nella Linux Foundation (cronologia OpenTofu). 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); OpenSearch documenta di essere nato dal precedente codice Apache-2.0 (FAQ OpenSearch). 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à.