Open source: cosa ne pensiamo?
Dall'arrivo di Cal.com, abbiamo ricevuto innumerevoli messaggi da fondatori che chiedevano se l'open source fosse la giusta direzione per la loro startup, e quindi volevamo scrivere sul processo decisionale di avviare cal.com come azienda open source, per aiutare altri a prendere una decisione simile.
Negli ultimi anni c'è stata molta eccitazione attorno all'open source dal 2021, e alcune riviste tecnologiche stanno scrivendo del "Rinascimento dell'Open Source", ma vogliamo assicurarci che tu stia facendo le cose giuste per le ragioni giuste – o almeno riflettere sulle tue motivazioni.
Di recente abbiamo ricevuto molte varianti della domanda sopra (a causa della crescita e della copertura di cal.com), ecco perché volevamo scrivere un post che delineasse come pensiamo a SaaS rispetto a open source e quando aprire il codice sorgente.
Nonostante entrambi abbiamo utilizzato molti progetti open source in passato e abbiamo apprezzato enormemente il lavoro che fanno, nessuno di noi si definirebbe un fan accanito dell'open source. Cal.com è il primo progetto OSS su cui abbiamo lavorato, poiché tutti i progetti su cui abbiamo lavorato in precedenza erano closed source. Nella maggior parte dei casi c'era una motivazione molto valida per cui quei progetti non erano open source.
Perché abbiamo creato Cal.com in primo luogo?
Quando Peer lavorava nella sua precedente azienda, leanhire.com, si era reso conto che aveva un disperato bisogno di uno strumento di programmazione più potente.
Contrariamente al caso d'uso tipico in cui Peer, o i suoi dipendenti, avrebbero effettuato prenotazioni (come nel caso delle vendite o del reclutamento), avevano bisogno di un prodotto di programmazione per il loro mercato del lavoro. In ogni mercato a due lati, gli utenti interagiscono con altri utenti, il che non si adatta bene al modello tipico offerto dai prodotti di programmazione esistenti.
Strumenti di programmazione come Calendly, SavvyCal e Motion sono prodotti straordinari per aiutarti a fare prenotazioni. Tuttavia, non hanno la capacità di fornire l'infrastruttura di programmazione per casi d'uso di programmazione più avanzati, come mercati del lavoro, telemedicina e altro. Ad esempio, non sarebbe fattibile per un mercato del lavoro pagare $19/mese per ogni posto se hai più di 5.000 utenti, come aveva Peer in Lean Hire.
I prodotti di programmazione SaaS esistenti non forniscono nemmeno molte informazioni su cosa sta succedendo internamente. Nel processo di onboarding per Lean Hire, chiedevano ai loro clienti di copiare/incollare semplicemente il loro link di programmazione e la piattaforma lo avrebbe automaticamente aggiunto alle email di contatto. Tuttavia, una volta che il destinatario cliccava sul link di programmazione, la piattaforma di Lean Hire non era in grado di tracciare cosa succedeva dopo.
Non sapevano se o quando si verificavano eventi, e se venivano riprogrammati o annullati. Non c'era modo di cambiare il flusso di lavoro delle prenotazioni, il design o le chiamate API che vengono effettuate al momento della prenotazione. Pertanto, era necessario trovare una soluzione open, accessibile ed estensibile che potessero auto-ospitare.
Peer ha subito cercato su Google "Calendly open source" perché questo è ciò che rappresenta l'open source: aperto, accessibile, estensibile e auto-ospitabile.
Con sua sorpresa, non riusciva a trovare un singolo progetto che facesse ciò che Lean Hire stava cercando. Per inciso, in quel momento, centinaia di altre persone stavano cercando esattamente la stessa cosa. I thread nei forum, le discussioni su Reddit e altro ancora sono stati aperti da persone che chiedevano se esistesse un prodotto di programmazione open source che potesse competere con le soluzioni SaaS più popolari.
Perché abbiamo reso Cal.com open source?
Sin dal primo giorno, era ovvio per noi che Cal.com sarebbe stata un progetto open source. Le cose che volevamo fare erano fondamentalmente più dure essendo un prodotto SaaS chiuso piuttosto che open source.
Il punto chiave qui è che le limitazioni dei prodotti di programmazione esistenti potevano essere risolte solo dall'open source. Molti fondatori seguono la strada sbagliata pensando di dover costruire un'alternativa open source a un prodotto esistente, credendo che il loro prodotto avrà successo semplicemente perché è open source. Invece, dovresti considerare di rendere il tuo progetto open source solo se l'open source risolve effettivamente le sfide che vuoi affrontare (ad esempio personalizzabilità, auto-ospitalità).
Ad esempio, potresti costruire un'alternativa open source a Twitter, ma è improbabile che decolli, perché i social network non traggono veramente beneficio dall'essere open source. Ci sono molti casi di progetti che sono open source solo per il gusto di esserlo.
Tuttavia, se per esempio guardassi all'industria dell'e-commerce, che è per lo più dominata da prodotti SaaS come Shopify o BigCommerce, potresti vedere che avere un'alternativa open source permetterebbe ai negozi di essere auto-ospitati, completamente personalizzati e in modalità white label, e ampliati in modi che non sono possibili con un prodotto closed source. Questo sarebbe un buon caso per cui dovresti aprire il tuo progetto.
In aggiunta a questo, con qualsiasi software aperto, accessibile e gratuito, ci sono svantaggi evidenti e non evidenti. L'open source ha molti vantaggi di cui probabilmente sei a conoscenza, ma l'open source non è privo dei suoi svantaggi.
Monetizzazione
Il software open source commerciale (COSS) è un modello aziendale di tendenza in cui il tuo prodotto principale è open source, ma hai anche offerte commerciali che generano entrate. Questi tipi di aziende possono avere una crescita incredibile. È nella natura del software gratuito e aperto avere una massiccia adozione in una fase iniziale. Gli sviluppatori amano l'open source. Amano essere in grado di dare un'occhiata al codice sorgente, correggere bug semplici che possono infastidirli, o semplicemente essere utili e restituire qualcosa. Chi non ama essere utile?
Ma la massiccia crescita e creazione di valore ha un costo: cattura del valore. Praticamente ogni fondatore di COSS con cui parlo sta pensando al concetto di creazione del valore e cattura del valore.
Un'azienda SaaS freemium ha due clienti: tier gratuito e a pagamento. E il rapporto è solitamente molto buono. Ad esempio:
“Webflow gestisce più di 100.000 siti web per aziende grandi e piccole." – https://webflow.com/customers
La valutazione più recente di Webflow è riportata a $2.1B.
Un'azienda open source, d'altra parte, appare fondamentalmente diversa, con un grande numero di autohost e clienti gratuiti, che a volte non sanno nemmeno che esiste un'azienda commerciale dietro il progetto.
Ad esempio: WordPress alimenta oltre 455 milioni di siti web nel 2021, e quel numero continua solo a crescere.
“L'azienda madre di WordPress.com, Tumblr e altro, Automattic, annuncia un nuovo round di finanziamento portando la valutazione totale dell'azienda a $7.5 miliardi” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Se Webflow alimentasse 455 milioni di siti web - o - se WordPress fosse un'azienda SaaS centralizzata con l'economia e il meccanismo di cattura del valore di Webflow, probabilmente sarebbero le aziende più grandi del mondo.
Essere una startup COSS significa sostanzialmente giocare a lungo termine. Non catturerai entrate da persone che auto-ospitano il tuo prodotto da soli, ma speri che il traino dell'open source ti metta sotto i riflettori delle grandi aziende che potrebbero firmare un accordo più grande con te.
Pertanto, pensare al margine di manovra che la tua azienda ha è importante. Probabilmente ci vorrà un lungo tempo per lanciare la tua azienda, far crescere il prodotto fino a uno stato in cui sia competitivo con le alternative chiuse, poi iniziare a guadagnare trazione e infine iniziare a chiudere grandi accordi. Ciò significa che se non hai i finanziamenti per continuare a lavorare al prodotto mentre genera poco reddito inizialmente, potresti non catturare abbastanza valore per sopravvivere.
Contributi
Uno dei vantaggi significativi dell'essere open source è il contributo della comunità. Abbiamo ricevuto dei contributi fantastici dalla comunità per i quali siamo incredibilmente grati. Alcuni di questi sono piccole correzioni di bug, ma altri possono essere grandi funzionalità.
Di solito, se le persone all'interno di un'azienda estendono Cal.com per le proprie esigenze, ad esempio per scrivere un'integrazione con Microsoft Exchange, è probabile che mettano questo codice in una richiesta di pull affinché possiamo avere questa funzionalità all'interno del progetto stesso.
La maggior parte degli ingegneri del nostro team erano in precedenza persone che hanno contribuito al progetto nel loro tempo libero, il che funziona benissimo per noi perché possiamo vedere subito esempi del loro lavoro, conoscono già il codice sorgente e hanno già una passione per lavorare al progetto.
Furto
Uno dei principali svantaggi dell'open source è che, con il tuo codice liberamente disponibile su Internet, le persone creeranno versioni contraffatte del tuo prodotto e ruberanno il tuo codice.
Nonostante il fatto che siamo AGPL licenziati e che qualsiasi modifica del codice debba essere open source, ci sono ancora persone che violano e continueranno a violare questi diritti. Inoltre, non c'è nulla che impedisca a uno dei nostri concorrenti di dare un'occhiata al nostro codice e vedere come abbiamo costruito le funzionalità, per poi utilizzare quel codice nel loro progetto closed source. Se lo fanno in modo sufficientemente abile, nessuno saprà che è stato rubato, poiché i loro prodotti sono closed source.
Non c'è nulla che possiamo effettivamente fare per fermare questo. Pertanto, cerchiamo di affrontare il problema delle versioni contraffatte di Cal.com semplicemente avendo un marchio forte e ben visibile. Speriamo che se qualcuno dovesse prendere il codice di Cal.com e creare la propria versione contraffatta, non guadagnerebbe nessuna trazione poiché le persone sanno che è una copia, e che la comunità lo segnalerà a noi affinché possiamo intraprendere azioni legali.
Ad esempio, il codice sorgente di Twitch è stato compromesso nel 2021, ma se provassi a prendere il loro codice sorgente e avviare una versione contraffatta di Twitch, non andresti da nessuna parte.
Quindi, dovrei aprire il codice sorgente di X?
Se ti stai ponendo questa domanda, probabilmente non dovresti farlo. Come abbiamo menzionato sopra, è solitamente molto ovvio se hai bisogno di una soluzione che sia aperta, accessibile ed estensibile o meno. Se non ne hai bisogno – non aprirlo solo per il gusto di farlo.
Tuttavia, se desideri vendere in settori aziendali, altamente regolati o desideri semplicemente costruire una soluzione per la massa (455M WordPress contro 100.000 siti web Webflow) allora andare open source ha molto senso.
Inoltre, assicurati di concentrarti sulla creazione del miglior prodotto possibile. La maggior parte dei consumatori non si interessa realmente se sei open source o meno.
Si preoccupano del miglior valore per i loro soldi. L'open source aiuta enormemente nella creazione di valore: il ciclo di retroazione è super veloce, i membri della comunità risolvono bug, aiutano con le traduzioni e molte altre cose, ma non dimenticare mai di costruire un prodotto superiore rispetto al tuo concorrente SaaS.
Perché alla fine, questo è tutto ciò che conta: costruire qualcosa di cui le persone hanno bisogno.
