- Supabase memilih open source sejak awal berdiri, dan dengan membangun produk secara terbuka, mereka memperoleh manfaat yang lebih besar dari perkiraan dalam hal komunitas, perekrutan, dan perluasan produk
- Kekhawatiran utama biasanya adalah kritik terhadap kualitas kode, terungkapnya kerentanan keamanan, dan peniruan oleh pesaing, tetapi keterbukaan juga dapat mendorong partisipasi dalam perbaikan dan iterasi yang cepat
- Dalam perekrutan, kontribusi ke repositori menunjukkan kode nyata kandidat dan cara mereka berkolaborasi; Supabase baru mulai melakukan perekrutan outbound setelah merekrut 32 developer
- Fitur untuk sebagian kecil pengguna, integrasi, dan adapter dapat dibuat langsung oleh komunitas, sehingga cakupan produk meluas dan melengkapi keterbatasan prioritas tim internal
- Daya pertahanan perusahaan open source tidak berasal dari menyembunyikan kode, melainkan dari membangun kecepatan eksekusi, brand, tim, dan komunitas dalam jangka panjang
Mengapa Supabase Memilih Open Source Sejak Awal
- Supabase sudah open source sejak hari pertama, dan karena para pendirinya sudah lama menjadi pengguna sekaligus pendukung proyek terbuka seperti PostgreSQL, Python, Bitcoin, dan React, keputusan itu saat itu tidak terasa sulit
- Berbeda dari perkiraan bahwa membangun bisnis secara terbuka akan membawa tekanan besar, dalam proses mengembangkan produk dan perusahaan muncul berbagai manfaat tak terduga
- Ini adalah pengalaman dari perusahaan developer tools atau PaaS, tetapi banyak bagiannya juga dapat diterapkan pada perusahaan software secara umum
- Kekhawatiran berulang yang menghalangi peralihan ke open source secara garis besar ada tiga
- Orang-orang bisa mengkritik kode yang berantakan atau belum selesai
- Hacker bisa menemukan celah keamanan dan mengeksploitasinya
- Pesaing bisa mencuri hak kekayaan intelektual
Kekhawatiran bahwa “kode saya buruk”
- Kecemasan terhadap kode yang buruk sebagian besar lebih dekat ke masalah ego, dan jika seseorang meluangkan waktu untuk melihatnya, kemungkinan mereka menemukan sesuatu di dalamnya yang layak dikejar
- Seperti kisah Stone Soup, jika Anda membagikan ide bagus kepada komunitas, orang lain dapat menerimanya dan ikut memperbaikinya
- Komunitas dapat merefaktor atau mengganti kode yang buruk, serta memperkenalkan panduan kualitas kode baru sehingga proses kontribusi berikutnya juga menjadi lebih baik
- Anggota toksik yang hanya mengeluhkan kode tanpa menawarkan usulan perbaikan sejak awal bukanlah anggota komunitas yang diinginkan
- Kontributor open source memiliki “kuburan” proyek lama, dan bagi orang yang ingin membuat sesuatu yang serupa, itu menjadi pustaka ide dan pendekatan
- Seseorang bisa mendapatkan inspirasi dari cara menyelesaikan masalah tertentu
- Minimal, mereka dapat mengurangi waktu untuk mengulangi kesalahan yang sama
- Dibandingkan merusak reputasi, proyek lama lebih mungkin digunakan secara berguna atau sama sekali tidak mendapat perhatian
Kode Terbuka dan Keamanan
- Ketakutan terbesar saat menjalankan solusi hosting dengan kode terbuka adalah situasi ketika pelaku jahat membaca kode, menemukan kerentanan, lalu meretas layanan
- Berdasarkan pengalaman Supabase, ungkapan Linus's law bahwa “dengan cukup banyak mata, semua bug menjadi dangkal” juga berlaku untuk masalah keamanan
- Sejak awal, para peneliti keamanan yang sering kali anonim membantu menelaah kode dan platform serta menemukan potensi masalah
- Jika Anda menyediakan SaaS, sebaiknya berikan panduan sederhana di
/.well-known/security.txtagar para peneliti beritikad baik tahu cara mengungkapkan potensi masalah - Sebagai contoh bahwa proyek terbuka bisa lebih aman daripada codebase proprietary, disebutkan Bitcoin
- Andreas M. Antonopoulos dalam ceramah tahun 2015 mengatakan bahwa sistem perbankan tertutup memiliki sistem kekebalan software yang lemah
- Dalam sistem tertutup, celah keamanan besar dapat tersembunyi lama, dan ketika akhirnya dieksploitasi, kerugiannya bisa besar
- Dalam protokol open source seperti Bitcoin, celah keamanan terlihat oleh semua orang, eksploit ditemukan lebih awal dan lebih sering, lalu ditambal
- Karena perusahaan software yang sukses dapat dibangun selama lebih dari 10 tahun, dalam jangka panjang sistem open source dapat mendekati kondisi yang lebih aman daripada sistem proprietary yang tertutup
- Pada masa ketika persaingan merekrut security engineer yang hebat sangat ketat, nilai dari peninjauan publik menjadi semakin besar
Kekhawatiran tentang Pesaing dan Hak Kekayaan Intelektual
- Dalam software, ide itu murah, dan nilai hampir selalu diciptakan melalui eksekusi atas ide tersebut
- Dengan membagikan ide ke dunia, Anda bisa berfokus pada iterasi yang lebih cepat alih-alih mengkhawatirkan siapa yang akan mengakses codebase
-
Membangun Komunitas Ahli
- Untuk membangun perusahaan yang sukses, Anda perlu mengeksekusi dengan baik dan menumbuhkan basis pelanggan dalam jangka panjang, misalnya selama 10 tahun
- Dalam lomba jarak jauh ini, keuntungan yang diperoleh pesaing dengan melihat codebase kemungkinan tidak terlalu besar jika dilihat sepanjang 10 tahun
- Selama periode itu, codebase kemungkinan akan mengalami banyak iterasi dan refactoring
- Dalam jangka panjang, cara menang adalah membangun tim dan komunitas yang paling baik di dunia dalam terus mengiterasi dan memperbaiki solusi sendiri
-
Menang di Pasar
- Jika total addressable market (TAM) yang besar dan berkembang memang layak dikejar, kecil kemungkinan kondisinya winner-takes-all
- Anda perlu lebih dulu menemukan segmen pengguna yang dapat dibuat terkesan, lalu beriterasi dengan cepat
- Waktu yang dihabiskan untuk berfokus pada pesaing adalah waktu yang bisa digunakan untuk memperbaiki produk atau tim
- Jika pesaing dapat mem-fork proyek open source dan merilis lebih cepat, maka dalam persaingan itu Anda memang sudah ditakdirkan kalah
- IP dan paten dalam software terkenal sulit ditegakkan, jadi dengan mengurangi kekhawatiran untuk melindungi ide software melalui pengacara, Anda dapat menghemat waktu, uang, dan energi mental
- Bisnis dapat dilindungi dengan lebih baik melalui cara mengimplementasikan ide software tersebut paling baik di dunia
-
Persaingan Cloud pada Tahap Lanjut
- Ketika proyek mencapai skala yang cukup besar, Anda bisa menghadapi situasi ketika penyedia cloud besar menawarkan produk dengan model distribusi yang lebih kuat, seperti yang terjadi pada Elastic atau Mongo
- Masalah terbesar bagi perusahaan yang baru mulai adalah terlebih dahulu mencapai titik tersebut
- Jika AWS sampai mengambil resource dari salah satu lini produk bernilai miliaran dolar untuk bersaing dengan produk hosting, berarti Anda sudah berada dalam kondisi yang sangat baik
- Respons yang lebih konstruktif adalah sejak awal mencari area di mana Anda dapat unggul dari siapa pun
- Banyak penyedia cloud sering kali memiliki developer experience (DX) yang kurang baik, sehingga DX dapat dijadikan kompetensi inti
- Jika enam tahun kemudian Google mencoba mengambil makan siang Anda, maka selama beberapa tahun sebelumnya brand, tim, dan komunitas sudah harus bersiap untuk pertarungan ala David melawan Goliath
- Situasi seperti ini harus direncanakan sejak awal agar Anda tidak terkejut, dan Anda dapat memanfaatkan waktu serta fokus untuk membuat strategi kemenangan
- Jika pesaing datang untuk mencari ide, mereka selalu tertinggal satu langkah, dan terutama pada tahap awal saat resource terbatas, Anda justru akan menghabiskan lebih banyak energi untuk mengkhawatirkan persaingan
Dampaknya pada Perekrutan Developer
- Salah satu masalah besar yang dialami startup terlepas dari skalanya adalah sulitnya merekrut developer
- Sulit melakukan sourcing
- Sulit mengevaluasi developer
- Sulit meyakinkan kandidat tentang kualitas calon rekan kerja mereka
- Open source dapat membantu mengurangi masalah perekrutan developer
-
Sourcing Secara Terbuka
- Semua developer mendapatkan manfaat dari open source, dan banyak developer ingin membalas manfaat itu dengan berkontribusi pada proyek open source yang menarik
- Alasan berkontribusi bisa berupa komunitas yang baik, mempelajari teknologi baru, atau kesenangan memecahkan masalah teknis sulit dalam codebase yang belum dikenal
- Jika hambatan kontribusi kode pada proyek open source diturunkan, developer hebat berpeluang menemukan proyek tersebut
- Kontributor dapat ikut dalam diskusi issue, perbaikan bug, identifikasi masalah, dan review PR
- Tidak semua kontributor sedang mencari pekerjaan, tetapi banyak orang bisa tertarik pada prospek menangani kode open source secara full-time
- Supabase baru mulai melakukan perekrutan outbound setelah beroperasi lebih dari 2 tahun dan merekrut 32 developer
- Open source adalah jalur utama Supabase untuk menemukan talenta, dan akan tetap demikian ke depannya
- Di perusahaan remote dan asinkron, strategi perekrutan open source membuat kemampuan kandidat terlihat dengan sendirinya, sehingga kemampuan tersebut lebih mudah diverifikasi
-
Kontribusi Nyata sebagai Pengganti LeetCode dan Tes Tugas
- Salah satu hal yang paling dikeluhkan developer saat mencari pekerjaan berikutnya adalah harus menyelesaikan soal LeetCode atau tes berbentuk tugas dalam proses wawancara
- Cara seperti ini memakan banyak waktu, melelahkan, dan sering kali tidak merepresentasikan pekerjaan yang akan dilakukan dalam pekerjaan nyata
- Jika seseorang berkontribusi ke repositori, bahan berikut sudah tersedia
- Contoh bagaimana mereka berkomunikasi dengan tim dan anggota komunitas dalam lingkungan remote dan asinkron
- Contoh kontribusi kode nyata
- Kandidat juga dapat menilai perusahaan
- Mereka dapat memastikan apakah tim mementingkan kualitas kode
- Mereka dapat melihat apakah komunikasi dilakukan secara efektif
- Mereka dapat menilai apakah keputusan teknis yang baik diambil
- Orang-orang yang direkrut melalui repositori Supabase telah membuat diri mereka menjadi sosok yang tak tergantikan, dan sebagian memimpin pengembangan repositori yang ada atau memulai library klien dan SDK baru
- Mereka tidak perlu menyelesaikan soal LeetCode di Zoom
Memperluas Fitur untuk Sebagian Kecil Pengguna dan Integrasi
- Saat membangun startup, sering kali Anda hanya punya waktu untuk menyelesaikan masalah terbesar
- Agar dapat bergerak cepat, Anda harus berfokus pada hal yang diminta oleh 80% basis pengguna {p:80}
- Fitur yang diminta oleh sebagian kecil pengguna mudah terdorong mundur tanpa batas waktu
- Jika sistemnya open source, pengguna-pengguna ini dapat berkontribusi langsung pada fitur tersebut, sehingga kegunaan software meningkat
- Efek seperti ini sering terlihat pada integrasi dan adapter
- Pengguna mungkin menginginkan integrasi Azure atau Vercel
- Jika orang lain menyediakan resource developer untuk membuat koneksi itu, semua pengguna proyek mendapatkan manfaat
Tidak Mengulang Membuat Roda yang Sama
- Di dunia tanpa open source, perusahaan teknologi akan terus-menerus menciptakan ulang roda
- Supabase bukan hanya merilis proyek baru sebagai open source, tetapi juga berusaha mendukung proyek open source yang sudah ada sebelum membuat sesuatu dari nol
- Situasi ketika perusahaan otomotif menggunakan fungsi proprietary, elemen UI proprietary, library windowing proprietary, sistem operasi proprietary, dan driver proprietary hanya untuk menampilkan pesan error yang nyaris tidak akan dilihat adalah pemborosan waktu dan tenaga developer
- Supabase Launch Week adalah kumpulan hasil kerja tim dan komunitas selama 3 bulan terakhir, dan keunggulan menjalankan perusahaan open source terlihat dari kecepatan kemajuan komunitas
- Detail selengkapnya dapat dilihat di postingan Launch Week 4, dan jika ingin berpartisipasi, Anda dapat mengunjungi GitHub Supabase
1 komentar
Opini Hacker News
Ada asumsi besar yang tersembunyi di sini tentang profitabilitas yang berkelanjutan, dan khususnya jika mempertimbangkan realitas seperti gaji developer di AS, ada bagian yang terasa tidak selaras dengan kenyataan
Singkatnya, perusahaan open source harus tersambar petir dua kali. Sekali untuk proyek open source-nya, dan sekali lagi untuk perusahaannya
Tim Graphistry setiap hari menyukai dan mengerjakan open source, membantu memulai rangkaian proyek yang berlanjut ke Apache Arrow dan Nvidia RAPIDS, serta merilis klien Python/JS sebagai open source. PyGraphistry[AI] adalah alat serbaguna untuk graph, seperti pisau lipat Swiss Army, dan juga mencakup alat yang mewujudkan hal-hal seperti bahasa kueri graph Cypher ala GFQL dalam bentuk yang bisa di-embed, data frame-native, dan bahkan dipercepat GPU
Namun, pertumbuhan yang berkelanjutan terutama datang dari penjualan lisensi self-hosted cloud/on-premises untuk server visualisasi graph GPU kepada perusahaan, pemerintah, dan perusahaan data. Setelah bertahan selama beberapa tahun, untungnya bisnis ini tumbuh dengan baik, dan pendapatan hosting SaaS saja cukup untuk mempertahankan tim kecil, tetapi tidak akan mampu menanggung sebagian besar tim. Tanpa pendapatan lisensi self-hosted, sebagian besar siklus inovasi akan hilang
Tulisan ini terasa melewatkan perpotongan antara keberuntungan seperti menang lotre, karakteristik pasar SaaS, dan daya tahan teknis. Peluncuran Louie.AI dan GFQL dalam kasus kami mengubah kelayakan bisnis open source, jadi bukan berarti ini mustahil, tetapi melihat pengalaman sampai di titik ini, saya khawatir untuk para founder baru yang membaca tulisan ini
[1] https://graphviz.org/
Intinya, apakah mereka tipe pelanggan yang akan berkata, “Sekarang kami membuka source code-nya,” lalu pelanggan menjawab, “Bagus, kalau begitu saya batalkan kontraknya”
Ia mengatakan, “Saat membahas model bisnis open source dengan founder lain, ada tiga kekhawatiran yang berulang: kode yang berantakan, buruk, atau belum selesai bisa dikritik; hacker bisa menemukan dan mengeksploitasi celah keamanan; pesaing bisa mencuri kekayaan intelektual,” tetapi menurut saya ada yang keempat
Yaitu bahwa Amazon/AWS bisa mengomersialkan dan menjual layanan berbasis kode saya tanpa membayar apa pun
Saat berinteraksi dengan pengguna dan menerima feedback, saya tetap sopan, tetapi dalam hati saya berpikir, “Ngomong memang gampang. Saya yang benar-benar membuatnya. Diam saja atau kirim PR.” Dan tidak mengejutkan, orang-orang seperti itu hampir tidak pernah mengirim PR
Teruslah membangun hal yang nyata, dan singkirkan orang-orang yang hanya mencela
[0] - https://heywillow.io/
Jika perusahaan besar mencoba meniru, berarti Anda sebenarnya sudah menang, dan memang perlu ada rencana lebih awal untuk memitigasinya. Namun, jika saya menafsirkan tulisannya dengan benar, maksudnya itu bukan masalah yang perlu difokuskan atau dikhawatirkan pada tahap awal
Alasan perusahaan cloud melahap produk open source lain adalah karena produk-produk itu gagal memilih lisensi yang benar-benar melindungi hasil kerja mereka
Ini tulisan yang sangat bagus dan mendalam, tetapi ada satu hal yang banyak proyek lewatkan: jual saja ke sektor pemerintah nonpublik
Pemerintah AS punya banyak program teknologi seperti hibah NSF, dan karena lembaga sipil, intelijen, dan pemerintah negara bagian terfragmentasi satu sama lain, pada akhirnya tercipta lanskap pengadaan software yang sangat luas. Hambatan masuk regulasi dan compliance juga tidak setinggi yang dibayangkan, terutama jika beberapa deal pertama didapat bersama mitra. Biasanya ini adalah pendapatan yang stabil dan terjamin, yang bisa mendanai proyek dengan komitmen 3–5 tahun, dan profitabilitasnya juga sangat tinggi
Saya berharap lebih banyak perusahaan open source memanfaatkan ini. Karena terlalu sering perusahaan swasta murni memasukkan library open source ke produk mereka, menjualnya dengan margin besar, lalu mengambil semuanya sendiri
Contoh: https://x.com/ssankar/status/1749202248700420587?s=20
Saat saya berada di pemerintahan, saya sering melihat software senilai 12 juta dolar yang pada dasarnya hanyalah kombinasi peta open source + DB open source. Saya juga pernah melihat OCR PDF seharga 2 juta dolar per tahun, dan alat seperti weights & biases yang dibanderol 30 juta dolar per tahun
Selain distribusi software, ada insentif lain. Misalnya memperbaiki bug atau celah keamanan tertentu lebih dulu. Sangat mungkin komunitas intelijen membayar mahal untuk safetensors
Empat jalur yang bisa diambil Supabase adalah penjualan langsung ke Cybercom, langsung ke DOS atau lewat kontrak tim, penjualan ke VA melalui PWS, atau penjualan langsung ke vendor software kontrak pemerintah besar
Cara menjalankannya adalah dengan mengirim cold email ke GS 14/15 atau setara, merekrut mantan GS15, atau mencari tender yang cocok di SAM.gov lalu membuat proposal, dengan GovPro.ai sebagai layanan penuh dan rogue sebagai opsi dikerjakan sendiri
Saat birokrasi pemerintah akhirnya menyetujui kontrak, sebagian besar startup kemungkinan sudah kehabisan uang
Kontraknya bisa sangat menguntungkan, tetapi prosedur birokratisnya luar biasa besar dan Anda butuh orang yang berpengalaman menanganinya. Ini bukan jalur yang cocok untuk semua orang, dan juga memakan banyak waktu serta negosiasi
Bahkan di luar birokrasi yang sangat besar, pemerintah federal adalah organisasi pemerintahan yang paling besar, paling lambat, dan paling sulit ditangani. Di AS saja ada puluhan ribu entitas pemerintah lain seperti sekolah, kota, county, negara bagian, distrik air dan pemadam kebakaran, perpustakaan, dan lain-lain
Jika ingin masuk ke sektor publik, lebih baik jangan all-in ke yang terbesar; pendekatan yang lebih baik adalah mulai dari yang kecil namun luas
Sektor pemerintah paling menguntungkan di dunia adalah Departemen Pertahanan AS.
Tetapi Departemen Pertahanan sangat birokratis, sangat sensitif terhadap jadwal, dan terobsesi pada kerahasiaan
Model bisnis Supabase adalah memasarkan diri sebagai perusahaan open source, tetapi kenyataannya, orang waras mana pun kemungkinan tidak akan mencoba self-hosting langsung untuk produksi
Alasannya adalah dokumentasi yang sedikit kurang lengkap, bug kecil yang samar, dan fitur penting yang terasa sedikit hilang. Jadi ia mendapat pujian sebagai open source, tetapi dalam praktiknya tidak begitu praktis, dan tampak hanya sebagai alat pemasaran
Pertama adalah ketenangan pikiran. Walaupun saat ini tidak self-hosting, saat layanannya tidak lagi memuaskan, ada satu jalur keluar tambahan. Tentu saja, akses ke data mentah juga harus disediakan
Kedua adalah kualitas kode. Jika Anda pernah berurusan dengan kode yang tampaknya berjalan baik tetapi sebenarnya sangat buruk, Anda akan tahu betapa pentingnya memiliki kode yang tidak memalukan untuk dibuka ke publik
Ketiga adalah kemungkinan kontribusi. Dulu saya menganggap ini sepele, tetapi setelah mengalaminya beberapa kali, besar sekali nilainya bahwa ketika ada fitur yang kurang, bug, atau masalah performa, kita bisa meminta atau berkontribusi langsung. Di sebagian besar proyek closed source, kita sudah beruntung jika ada saluran transparan hanya untuk mengajukan permintaan fitur
Jika melewati ambang tertentu, orang bisa memutuskan bahwa upaya untuk membuat fork layak dilakukan. MariaDB adalah contohnya
Ada juga orang yang secara langsung mengatakan bahwa justru itulah alasan mereka merasa tenang memakai layanan terkelola perusahaan kami
Menjadi perusahaan open source yang sah dan sungguhan tampak jauh lebih mudah
Jika itu bukan maksudnya dan saya yang salah membaca, maka sisa isinya justru membuat Supabase terlihat sangat positif
Mungkin itu tidak memungkinkan secara komersial, tetapi kondisi saat ini sangat menggerus standar yang seharusnya bisa diharapkan dari perangkat lunak open source, dan tampaknya juga tidak memberi keuntungan jangka panjang yang jelas bagi perusahaan yang memilih pendekatan seperti itu
Bahkan jika developer tidak menjalankannya sendiri, ia memungkinkan kita melihat kode yang benar-benar berjalan
Saya suka Supabase, saya juga suka open source komersial secara umum, dan saya setuju dengan banyak bagian tulisan ini
Tetapi bagian “dalam software, ide itu murah. Nilai hampir selalu tercipta dari eksekusi ide itu” terasa janggal
Ungkapan seperti ini pernah saya dengar dalam situasi seperti, “Saya punya ide startup keren, mau tanda tangan NDA sebelum saya cerita?”
Tetapi jika Anda merilis software sebagai open source, Anda bukan sekadar memberikan idenya, melainkan juga memberikan hasil eksekusi yang cukup besar dari ide itu
Tentu saja, kode bukan seluruh eksekusi, karena ada penjualan, pemasaran, dukungan, dan lain-lain. Tetap saja, tulisan ini terasa terlalu meremehkan nilai kode dan seolah menyiratkan bahwa tanpa penjualan atau pemasaran, kode tidak bernilai, padahal menurut saya itu tidak benar
Jika nilainya dibagi, saya akan menempatkannya sekitar 90% penjualan/pemasaran/validasi pelanggan dan 10% kode. Saya menjalankan SaaS bootstrap dengan pendapatan tahunan rendah tujuh digit, dan bisa bilang bahwa kodenya kebanyakan berantakan dan terus berevolusi
Rumah tidak bisa disalin gratis, tetapi software bisa
Yang dibayar kepada developer adalah proses membuat kode itu, dan pekerjaan menyelesaikan banyak masalah kecil yang tidak terlihat
Itulah sebabnya penjualan software bisa sangat menguntungkan. Jika software tidak dijual, Anda tidak bisa menghasilkan uang darinya. Software tidak seperti benda fisik dalam realitas bersama yang kita tinggali
Bagi saya, pertanyaan kuncinya bukan apakah kodenya cukup bagus atau apakah kompetitor akan menirunya, melainkan apakah Anda bisa menghasilkan cukup uang untuk membangun bisnis yang berkelanjutan
Proyek open source yang sering dikutip dan dicintai bukanlah bisnis yang bagus: PostgreSQL, Python, Bitcoin, React
Mongo dan Elastic memang hebat, tetapi mereka pengecualian. Jumlah perusahaan database closed source yang sukses lebih banyak daripada perusahaan database open source
Perusahaan open source itu sulit. Tetapi bagi pengguna, nilainya sangat besar
Mengesampingkan perdebatan soal lisensi mana yang “open source”, yang penting adalah bahwa perusahaan-perusahaan ini menilai lisensi yang digunakan luas seperti (A)GPL, Apache, dan MIT memberi terlalu banyak ruang bagi pesaing untuk membuat layanan managed/hosting dan bersaing lewat skala. Contohnya adalah OpenSearch dari Amazon yang menawarkan ElasticSearch dengan harga lebih murah
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
Pertanyaan ini tampaknya dipakai dengan arti “Haruskah perusahaan kami membuka source code software kami?”
Tetapi bagi saya, menjawab pertanyaan aslinya justru memberi jalan untuk menjawab pertanyaan yang sudah ditulis ulang itu. Pertanyaan aslinya bukan tentang software yang dijual perusahaan, melainkan tentang sifat software yang digunakan
Secara pribadi, jika ada alternatif, saya akan selalu memilih produk open source. Bahkan jika saya harus dengan senang hati membayar biaya dukungan atau berdonasi ke proyeknya. Hak akses untuk bebas melihat source code itu penting secara mendasar, bahkan pada software yang sama sekali tidak pernah saya niatkan untuk modifikasi
Saya tahu bagi banyak orang ini terdengar seperti posisi yang ekstrem. Tetapi saya tidak suka gagasan bahwa saya tidak bisa membongkar microwave, gagang pintu, atau transmisi. Mungkin saya tidak bisa merakitnya kembali dengan benar, tetapi saya bisa menemukan roda gigi yang ompong dan melakukan perbaikan 2 dolar alih-alih penggantian 90 dolar. Atau saya bisa membuat microwave Frankenstein dengan transmisi
Memperluas fungsi web server atau memahami mengapa plugin saya membuat aplikasi host crash adalah hal yang penting bagi saya. Menurut saya itu juga penting bagi masyarakat. Karena itu saya tetap memegang ekstremisme open source saya. Anda boleh menunjukkan web server mikro mutakhir yang menangani HTTPS/4 dalam 5KB dengan AI tertanam, dan saya mungkin tertarik, tetapi jika itu bukan open source, saya akan tetap memakai stack yang ada sekarang
Karena pola pikir ini, software yang saya buat bersifat open source, dan kadang-kadang orang membayar untuk itu
Soal bagian, “jika 6 tahun lagi Google mencoba merebut pasar, harus sudah ada brand, tim, dan komunitas yang selama beberapa tahun terakhir bersiap untuk pertarungan Daud melawan Goliat,” menurut pengalaman saya, bagi tim pengadaan hal-hal seperti brand, komunitas, tim, dan pengalaman developer hampir tidak berarti dibanding kepatuhan
Terutama jika harus berhadapan langsung dengan vendor mapan seperti Google
Dalam kasus Supabase, ini pengamatan yang tepat karena selama beberapa tahun terakhir mereka memang telah menyiapkan kepatuhan seperti SOC2, HIPAA, dan GDPR untuk memenuhi tuntutan semacam ini
Produk kami juga telah memikirkan masalah ini. Suatu hari nanti kami berencana menjadikannya open source sepenuhnya dengan lisensi MIT atau Apache, mana pun yang saat itu kami sukai, dan hal ini juga sudah kami ungkapkan di situs. Bukan dengan model AGPL atau open core
Namun saya merasa menghasilkan uang dari produk dengan struktur seperti itu benar-benar tidak mungkin, dan pengalaman saya sebelumnya juga begitu. Konsultasi mungkin bisa, tetapi produk berbeda. Supabase menerima investasi ventura yang sangat besar, dan hampir semua proyek open source “besar” juga demikian
Jika bootstrap, terutama pada proyek yang ambisius dan sulit, Anda tidak akan bisa menagih dalam waktu yang cukup lama. Orang hanya bisa bekerja gratis untuk waktu yang terbatas, dan jika tim kecil terus berkomunikasi erat di atas kode tertutup, mereka bisa bergerak jauh lebih cepat sambil mengurangi overhead yang dibutuhkan proyek open source yang sukses
Saya ingin mendengar contoh proyek yang skalanya mirip, menerima investasi 0 dolar, dimulai dalam 5 tahun terakhir, punya lebih dari 2 anggota tim penuh waktu, bertahan lebih dari 3 tahun, dan masih merekomendasikan pendekatan ini. Saya penasaran bagaimana mereka mencari nafkah. Menurut saya, hal seperti Redis tidak akan terjadi lagi. Setidaknya saya belum pernah melihatnya. Bahkan proyek yang sederhana seperti langchain menerima puluhan juta dolar investasi ventura; padahal proyek semacam itu justru saya anggap kandidat yang bisa dijalankan oleh tim kecil sambil menghasilkan uang dari beberapa sumber pendapatan
Semua perangkat lunak saya saya rilis ke domain publik, yakni sebagai perangkat lunak bebas, tetapi tidak ada yang menjadi proyek open source atau komunitas yang sukses. Perangkat lunak bebas pertama-tama adalah ideologi, lalu praktik atau fungsinya
Menurut saya, menjadikan perusahaan open source tidak masuk akal kecuali Anda menargetkan developer, atau membuat produk yang secara realistis tidak akan di-host sendiri oleh siapa pun
Supabase adalah contoh utama untuk kedua hal itu. Contoh untuk yang kedua adalah Plausible Analytics, yang memang bisa di-host sendiri. Saya juga melakukannya dengan Coolify.io. Tetapi tanpa membangun sistem CI/CD sendiri yang mengambil dan menggabungkan pembaruan dari rilis, Anda akan ketinggalan pembaruan