Beekeeper Studio è stato lanciato nel 2020 come progetto open source gratuito al 100%.

Abbiamo passato 8 mesi di serate e weekend a creare quella prima versione. Avevamo già pubblicato altre app che nessuno usava, ma Beekeeper era diverso: appena l’abbiamo rilasciato e abbiamo iniziato a condividerlo, la gente si è interessata e ha cominciato a scaricarlo e usarlo.

L’interesse è stato così grande che siamo finiti in prima pagina su Hacker News: lo avevamo pubblicato quella mattina senza farci troppo caso, e nel giro di un paio d’ore avevamo migliaia di primi utenti.

Ma poi è arrivata la parte difficile: mantenere e migliorare un’app vera, usata da persone vere… per quanto tempo? Anni? Decenni?

Il cimitero dell’open source

La maggior parte dei progetti, delle app e delle aziende alla fine non ha successo e muore. Non è una cosa esclusiva dei progetti open source, ma nell’open source è più evidente. Dopotutto, fin dall’inizio la maggior parte dei progetti open source nasce per essere gratuita. È un bell’ostacolo per rendere un progetto sostenibile.

Anzi, abbiamo creato Beekeeper Studio proprio perché uno strumento molto amato, Sequel Pro, era stato abbandonato, nonostante fosse la migliore app per database che avessi mai usato.

Chi voleva la fine di SequelPro? Di certo non io. Di certo non le migliaia di altre persone che lo usavano ogni giorno. Io volevo l’opposto: volevo usarlo su Linux e con PostgreSQL.

L’avrei pagato volentieri. Un’app incredibile, ma purtroppo non esiste più.

La stessa sorte è toccata a molte, molte altre app simili.

Perché i buoni progetti muoiono

Perché gli altri strumenti sono morti, mentre Beekeeper Studio è andato avanti? La risposta semplice è: soldi e tempo.

Per soldi intendo soprattutto tempo, ma si sa, il tempo è denaro (sì, alzate pure gli occhi al cielo). Quindi la risposta è tempo e ancora tempo, o soldi e ancora soldi, come preferisci vederla.

Creare software è difficile. Creare software buono è ancora più difficile. Ed è anche lento. Richiede tantissimo tempo e impegno, anche con un LLM che ti aiuta. Davvero: TANTISSIMO tempo. Non riesco a sottolineare abbastanza quanto tempo serva. Ho già detto che serve un sacco di tempo?

Semplicemente non è possibile mandare avanti da soli un progetto open source popolare e attivo, la sera e nei weekend, senza fondi, per anni e anni. Già gestire issue e pull request è un lavoro a tempo pieno.

Approcci alla sostenibilità dell’open source

Ci sono diversi modi per rendere sostenibile un progetto open source. Grandi progetti cardine come Vue.js sono abbastanza visibili da reggersi sulle donazioni. Altri grandi progetti come React sono finanziati interamente da uno sponsor aziendale che paga direttamente gli sviluppatori.

Sul fronte commerciale, grandi software infrastrutturali come Kafka e Trino dominano come progetti ‘open core’: la parte centrale del sistema è aperta, ma vendono un sacco di extra per renderlo utile alle aziende. Seguire questa strada di solito richiede di raccogliere un sacco di soldi e puntare alla luna per diventare una startup unicorno. Purtroppo funziona solo se il tuo progetto è già riuscito a diventare uno standard di settore, adottato in massa da milioni di sviluppatori.

Kafka è stato finanziato e mantenuto da un team interno di LinkedIn per anni, prima di staccarsi e diventare un’azienda a sé.

Questo approccio può funzionare anche per librerie di componenti come AG-Grid, anche se su scala più piccola. Ma anche in quel caso la libreria deve diventare una specie di standard.

App più piccole come Beekeeper Studio hanno meno scelte. Le nostre donazioni hanno raggiunto al massimo 30 $/mese, nonostante avessimo superato il milione di download. E non siamo nemmeno uno ‘standard di settore’ di alcun tipo: siamo un’app usata da persone, non un motore di elaborazione eventi installato su server.

Il nostro modello: vendere software che le persone vogliono

Vendere qualcosa di utile, per cui le persone sono disposte a pagare, è un modello di ricavi semplice, ed è quello che abbiamo scelto per Beekeeper Studio.

Credo sia il modo più pulito e semplice per sostenere il progetto restando centrati sugli utenti: vendere funzionalità extra a chi è disposto a pagarle.

Detto questo, è impossibile ignorare l’ironia: il modo migliore per mantenere la nostra app gratuita e aperta è chiuderne alcune parti e farle pagare. È davvero un equilibrio difficile. Da un lato non dobbiamo penalizzare la community open source, dall’altro la versione a pagamento deve essere abbastanza buona da pagare le bollette.

Ed è anche lento (ho già detto che creare buon software richiede un sacco di tempo?): abbiamo lanciato le prime funzionalità a pagamento nel 2022, eppure sono riuscito a dedicarmi al progetto a tempo pieno solo nel 2026, ben 4 anni dopo.

Per fortuna questo approccio ha dei precedenti: ottimo software open source come Sidekiq di Mike Perham usa questo modello con grande successo, senza alienarsi la community.

Restiamo autentici

Finora il nostro approccio funziona. Siamo un’azienda in attivo, ma siamo anche ancora un progetto open source di community che attira partecipazione e contributi reali. Rendiamo persino source available le nostre funzionalità commerciali, anche se non sono del tutto open source.

Ci teniamo davvero a mantenere Beekeeper Studio il più aperto e accessibile possibile. Per esempio, cerchiamo regolarmente di trasformare funzionalità a pagamento in gratuite, non togliamo mai una funzionalità gratuita dopo averla lanciata e rendiamo gratuite e aperte tutte le funzionalità contribuite dalla community, anche quando preferiremmo farle pagare.

Il migliore del gruppo

Credo che il nostro approccio alla sostenibilità del progetto sia l’equilibrio giusto per noi, e ci dà qualche superpotere, come avere una community edition irragionevolmente potente.

Siamo qui per restare. Nel frattempo, spero che ti piaccia usare il nostro software quanto a noi piace crearlo.

Matthew Rathbone
Fondatore, Beekeeper Studio

Matthew ha avviato Beekeeper Studio nel 2019 perché voleva un’app per database su Linux che fosse davvero piacevole da usare. Scrive ancora la maggior parte delle opinioni dell’azienda, e un po’ del suo codice.