Ricerca nel sito web

Cos'è il nucleo aperto?


In cosa differisce l'open core dall'open source? Quando uno è più utile dell’altro?

Cos'è il nucleo aperto? Un progetto è open core o un business open core? Questo è discutibile. Come l’open source, alcuni lo vedono come un modello di sviluppo, altri lo vedono come un modello di business. In qualità di product manager, lo vedo più nel contesto della creazione e dell'acquisizione di valore.

(Scott McCarty, CC BY-SA 4.0)

Con l'open source, un team di ingegneri può acquisire più valore di quello che apporta. Un ingegnere che partecipa a un progetto open source può contribuire con un codice del valore di 1 dollaro, ma ottenere in cambio un valore di 10, 20, 30 dollari o più. Questo valore si misura sia nel marchio personale, sia nella capacità di guidare e influenzare il progetto in una direzione vantaggiosa per il proprio datore di lavoro.

Con il core aperto, almeno parte del codice è proprietario. Con il codice proprietario, un'azienda assume ingegneri, risolve problemi aziendali e addebita il software. Per la parte proprietaria del codice base, non esiste un'ingegneria basata sulla comunità, quindi non esiste alcun processo attraverso il quale un membro della comunità possa trarre profitto dalla partecipazione. Con il codice proprietario, un dollaro investito in ingegneria è un dollaro restituito in codice. A differenza dell'open source, un processo di sviluppo proprietario non può restituire più valore di quello apportato dal team di ingegneri (vedi anche: Perché Red Hat sta investendo in CRI-O e Podman).

Questa mancanza di profitto per la comunità è davvero importante quando si analizza l’open core. Non esiste una comunità per quella parte del codice, quindi non c'è partecipazione della comunità, né profitto comunitario. Se non esiste una comunità, non vi è alcuna possibilità per un membro della comunità di ottenere i vantaggi standard dell'open source (marchio personale, influenza, diritto all'uso, apprendimento, ecc.).

Non esiste alcun valore differenziale creato con l'open core, quindi in 18 modi per differenziare i prodotti open source dai fornitori a monte, lo descrivo come una metodologia per acquisire valore. L’open source guidato dalla comunità riguarda la creazione di valore, non l’acquisizione di valore. Questa è una tensione fondamentale tra open source e open core.

Codice a nucleo aperto contro codice adesivo

Innanzitutto, diamo un'occhiata a ciò che le persone in genere considerano open source. Come descritto su Wikipedia, "il modello open-core implica principalmente l'offerta di una versione 'core' o con funzionalità limitate di un prodotto software come software gratuito e open source, offrendo al contempo versioni 'commerciali' o componenti aggiuntivi come software proprietario." Il disegno seguente mostra graficamente questo modello.

Un esempio di questo modello è SugarCRM, che aveva un software open source di base e una serie di plugin, molti dei quali proprietari. Un altro esempio di ciò è il piano originale che Microsoft aveva per la funzionalità Hot Reload in .Net (che da allora è stato invertito).

Un altro modello correlato è quello che chiamerò codice colla. Il codice adesivo non fornisce direttamente un valore aziendale al cliente. Invece, mette insieme un sacco di progetti. Nota: in questo esempio mostro tre progetti open source, un servizio API basato sui dati e del codice collante che tiene insieme il tutto. Il codice colla può essere open source o proprietario, ma non è questo ciò a cui la gente normalmente pensa quando parla di open core.

Un esempio di codice collante open source è Red Hat Satellite Server. È composto da più progetti open source upstream come Foreman, Candlepin, Pulp e Katello, nonché da una connessione a un servizio dati per gli aggiornamenti (oltre a connessioni con strumenti come Red Hat Insights). Nel caso del server Satellite, tutto il codice collante è open source, ma si può facilmente immaginare come altre aziende potrebbero scegliere di utilizzare codice proprietario per questa funzionalità.

Quando il nucleo aperto è in conflitto con gli obiettivi della comunità

Il problema classico con l'open core è quando la comunità upstream desidera implementare una funzionalità presente in uno dei componenti proprietari. L'azienda o il prodotto che impiega il modello open core ha un incentivo a impedire che ciò accada nel progetto open source su cui si basa il codice proprietario. Ciò crea alcuni problemi seri sia per la comunità a monte che per i clienti.

I potenziali clienti saranno incentivati a partecipare alla community per implementare le funzionalità proprietarie percepite come mancanti. I membri della comunità che tentano di implementare queste funzionalità rimarranno scioccati o infastiditi quando le loro richieste pull saranno difficili da accettare o rifiutare completamente.

Non ho mai visto una soluzione seria per questo problema. In questo video, How To Do Open Core Well: 6 Concrete Recommendations, Jono Bacon consiglia di essere sincero con i membri della comunità. Consiglia di dire loro che le richieste pull che competono con le funzionalità del prodotto proprietario verranno rifiutate. Sebbene sia meglio che non essere anticipati, non è una soluzione scalabile. Sia il progetto upstream che il prodotto downstream con funzionalità proprietarie cambiano costantemente il panorama. Spesso, i contributori della comunità non prestano nemmeno attenzione al prodotto downstream e non hanno idea di quali funzionalità siano implementate a valle o, peggio, sulla tabella di marcia per essere implementate come funzionalità proprietarie. La comunità a monte è raramente coinvolta emotivamente con i problemi aziendali risolti dai prodotti a valle e può essere facilmente confusa quando le loro richieste pull vengono rifiutate.

Anche se la comunità è disposta ad accettare le zone vietate (esempio: funzionalità GitLab per livello a pagamento), ciò rende molto probabile che il progetto open source sarà un'impresa di un unico fornitore (esempio: i contributi GitLab sono principalmente dipendenti GitLab ). È altamente improbabile che i concorrenti partecipino e ciò limiterà intrinsecamente la creazione di valore della comunità. Il core business aperto potrebbe ancora acquisire valore attraverso la leadership di pensiero, l’adozione della tecnologia e la fedeltà dei clienti, ma probabilmente non creerà mai veramente più valore del codice di quello che investe.

A parte questi problemi, se un progetto upstream aderisce veramente alla governance aperta, in realtà non c'è nulla che il core business aperto possa fare per impedire l'implementazione di funzionalità proprietarie. Il codice proprietario intra-progetto (all'interno di un singolo progetto) semplicemente non funziona.

Quando l'open core potrebbe funzionare

Il codice colla è un luogo in cui il codice open core o proprietario potrebbe funzionare. Non sto sostenendo l'open core e spesso penso che sia inefficiente, ma voglio essere onesto con la mia analisi. Esistono infatti confini naturali tra i progetti open source. Tornando alla mia tesi sull'open source come catena di fornitura (vedi anche: La delicata arte della gestione del prodotto con l'open source), un iniettore di carburante è un iniettore di carburante; non è un alternatore. Questi punti di demarcazione naturali costituiscono buone aree per la differenziazione del prodotto a valle dal progetto a monte (vedi anche: 18 modi per differenziare i prodotti software open source dai loro progetti a monte).

Un classico esempio di codice collante proprietario è l'originale Red Hat Network (RHN), rilasciato nel 2000. RHN era essenzialmente un'offerta SaaS che forniva aggiornamenti per le macchine Red Hat Linux, e questo prima ancora che Red Hat Enterprise Linux esistesse. . Per fare un esempio, quando RHN è stato rilasciato, il termine open core non era ancora stato inventato (coniato nel 2008), guarda caso lo stesso anno in cui è stato rilasciato il progetto upstream Spacewalk. Allora tutti stavano ancora imparando le competenze chiave su come utilizzare bene l’open source.

In retrospettiva, non penso sia una coincidenza che RHN esistesse al nesso del punto di demarcazione naturale tra una distribuzione Linux upstream e un'offerta a pagamento. Ciò si adatta naturalmente al modello mentale di differenziazione di un prodotto dal fornitore a monte. Potrebbe essere forte la tentazione di concludere: "Vedi!?!? La più grande azienda open source al mondo si è differenziata con il codice proprietario! L'open core è la ragione per cui Red Hat è sopravvissuta e ha prosperato" - ma farei attenzione a non confondere la correlazione con causa. Alla fine Red Hat rese open source RHN come Spacewalk e non subì mai ripercussioni sulle entrate.

Facendo una leggera rotazione, si potrebbe anche sostenere che oggi i fornitori di servizi cloud spesso seguono questo modello. È risaputo nel settore che la maggior parte dei grandi fornitori di cloud utilizza i propri fork del kernel Linux. Questi fork hanno estensioni proprietarie che rendono Linux utilizzabile nei loro ambienti. Queste funzionalità non risolvono direttamente il problema aziendale del cliente, ma risolvono invece i problemi del fornitore di servizi cloud. Sono essenzialmente codice adesivo.

I fornitori di servizi cloud hanno una motivazione leggermente diversa per non apportare questi cambiamenti a monte. Per loro, portare con sé un fork è spesso più economico e/o più semplice (anche se non facile) che apportare queste funzionalità a monte, soprattutto quando le modifiche spesso non sono desiderate dalla comunità del kernel Linux. I fornitori di servizi cloud spesso scelgono la migliore cattiva idea tra un mucchio di cattive idee.

Il codice collante aperto potrebbe essere chiamato codice proprietario interprogetto (tra più progetti). Potrebbe funzionare, ma probabilmente questo tipo di codice è già difficile da implementare e non necessita delle "protezioni" percepite di una licenza proprietaria. Detto in altro modo, i contributori open source non sono necessariamente incentivati a lavorare e mantenere il codice collante. È un luogo naturale in cui un fornitore può differenziarsi. Spesso il codice colla è complesso e richiede integrazioni specifiche tra versioni specifiche di progetti a monte per requisiti specifici del ciclo di vita. Tutti questi requisiti specifici rendono il Glue Code un ottimo posto in cui un prodotto può differenziarsi dai progetti a monte senza la necessità di una licenza proprietaria. La velocità (velocità e direzione) delle integrazioni aziendali è molto diversa dalla velocità necessaria per la collaborazione tra più progetti a monte. Questa discrepanza di velocità tra le esigenze della comunità a monte e le esigenze dei clienti a valle è un luogo perfetto per la differenziazione senza la necessità di un nucleo aperto.

Conclusione

L'open core può funzionare? È meglio dell'open source? Dovrebbero usarlo tutti? Sembra ovvio che Open Core possa funzionare, ma solo in situazioni molto specifiche con tipi di software molto specifici (ad esempio codice adesivo). Sembra meno ovvio che ci sia qualche argomento secondo cui l'open core sia effettivamente migliore per creare valore. Pertanto, non consiglio l’open core per la maggior parte delle aziende. Inoltre, penso che le tutele percepite che offre siano in realtà inutili.  

Spesso i venditori trovano luoghi naturali in cui competere tra loro. Ad esempio, SUSE esegue OpenSUSE Build Service, che si basa su codice completamente open source. Anche se Red Hat ha potuto scaricare il codice sorgente e impostare un servizio di build concorrente, non l'ha fatto. Infatti, il progetto Podman, fortemente sponsorizzato da Red Hat, utilizza il servizio di build OpenSUSE. Sebbene SUSE possa facilmente rendere proprietario questo codice, non è necessario che lo facciano. Configurare, eseguire e mantenere un servizio concorrente richiede molto lavoro e non fornisce necessariamente molto valore ai clienti Red Hat.

Continuo a pensare che Open Core sia un passo nella giusta direzione rispetto al codice completamente proprietario (esempio: GitLab è open core, GitHub è closed source), ma non vedo un motivo convincente per promuoverlo come un'alternativa migliore al completamente open source . In effetti, penso che sia estremamente difficile realizzare bene l'open core e probabilmente impossibile creare veramente valore differenziato con esso (vedi anche: La rinascita guidata dalla comunità dell'open source e del Fauxpen source è dannosa per gli affari).

Questa tesi sull'open core è stata sviluppata lavorando e imparando da centinaia di persone appassionate di Open Source, tra cui ingegneri, product manager, responsabili marketing, addetti alle vendite e alcuni dei principali avvocati in questo ambito. Per rilasciare nuove funzionalità e capacità in Red Hat Enterprise Linux e OpenShift, come il lancio di Red Hat Universal Base Image, ho lavorato a stretto contatto con tanti team diversi in Red Hat. Ho assorbito più di 25 anni di conoscenze istituzionali, nei miei più di 10 anni qui. Ora, sto cercando di formalizzare un po' questo in un lavoro pubblico come La delicata arte della gestione del prodotto con l'open source e in articoli successivi come questo.

Questo lavoro ha contribuito alla mia recente promozione a Senior Principal Product Manager di RHEL for Server, probabilmente la più grande azienda open source al mondo. Anche con questa esperienza, ascolto, imparo e cerco costantemente la verità. Mi piacerebbe discutere ulteriormente questo argomento nei commenti o su Twitter (@fatherlinux).

Articoli correlati: