Bagaimana Perusahaan Open-Source Menghasilkan Uang

Oleh Brian Tr · Diperbarui 2 Oktober 2026

Perusahaan open-source membagikan produk intinya secara cuma-cuma, namun tetap harus membayar gaji. Kedengarannya kontradiktif, dan itulah pertanyaan pertama yang diajukan setiap pendiri dan investor tentang model ini. Jawabannya, kode jarang menjadi hal yang dijual. Pelanggan membayar untuk apa yang melingkupi kode: seseorang yang menjalankannya, mendukungnya, mensertifikasinya, memperluasnya, atau menanggung tanggung jawab hukumnya.

Artikel ini menjelaskan apa arti sebenarnya dari "open source", cara utama perusahaan mengubahnya menjadi pendapatan, dan ketegangan yang mendorong beberapa perusahaan ternama mengubah lisensi mereka antara 2021 dan 2026. Artikel ini adalah referensi tentang model bisnis, bukan nasihat hukum, dan tidak membandingkan harga terkini para vendor. Untuk gambaran lebih luas tentang cara startup memperoleh uang, lihat model penetapan harga SaaS.

Apa arti sebenarnya dari "open source"

"Open source" bukan sinonim longgar untuk "gratis" atau "kodenya publik." Open Source Initiative (OSI) memelihara Open Source Definition, daftar sepuluh kriteria yang harus dipenuhi sebuah lisensi. Tiga di antaranya paling penting bagi model bisnis:

• Redistribusi bebas. Lisensi tidak boleh menghalangi siapa pun menjual atau membagikan software tersebut.
• Karya turunan. Lisensi harus mengizinkan modifikasi dan karya turunan.
• Tidak ada diskriminasi terhadap bidang usaha. Lisensi tidak boleh membatasi siapa pun menggunakan program di bidang tertentu, yang dalam praktiknya mencakup menjalankannya secara komersial.

Kriteria terakhir itulah tempat model bisnis bertabrakan dengan definisi. Lisensi yang berbunyi "siapa pun boleh memakai ini, kecuali untuk menjualnya sebagai layanan hosting yang bersaing" membatasi bidang usaha. Itu bisa menjadi pilihan komersial yang sangat masuk akal, tetapi menurut pembacaan OSI, itu bukan open source. OSI menyatakan hal persis ini tentang Server Side Public License (SSPL) dalam pernyataan Januari 2021, dan menyebut praktik menggambarkan software semacam itu sebagai open source sebagai penipuan.

Jadi sebenarnya ada dua kubu:

Sisa artikel ini menjaga keduanya tetap terpisah. Perbedaan ini penting bagi pelanggan (apa yang boleh mereka lakukan?), bagi kontributor (apakah karya saya akan tetap terbuka?), dan bagi pendiri (apa yang bisa saya janjikan?).

Paradoks membagikan inti produk secara gratis

Jika siapa pun bisa mengunduh, memodifikasi, dan menjalankan produk secara gratis, mengapa ada yang mau membayar? Perusahaan open-source menjawabnya dengan salah satu dari empat cara:

1. Mengurangi beban. Menjalankan software dengan baik itu sulit. Pelanggan membayar agar orang lain yang mengoperasikannya.
2. Mengurangi risiko. Organisasi besar menginginkan vendor yang bisa dihubungi, tim respons keamanan, dan jaminan hukum.
3. Menambahkan apa yang tidak ada di versi gratis. Fitur yang terutama penting bagi tim besar (kontrol akses, audit log, single sign-on) dijual terpisah.
4. Melindungi hak untuk menarik biaya. Sebagian perusahaan membiarkan kodenya terbuka untuk dibaca tetapi membatasi siapa yang boleh menjualnya kembali.

Membagikan inti produk juga berfungsi sebagai distribusi. Developer mengadopsi apa yang bisa mereka coba tanpa proses pengadaan, dan perusahaan yang memenangkan adopsi itu memiliki saluran penjualan inbound. Ini mendekati logika product-led growth dan model bisnis freemium, dengan satu perbedaan: pengguna gratis software open-source juga dapat membuat fork dari kodenya, meng-host sendiri, dan tidak pernah menjadi pelanggan.

Model monetisasi utama

1. Dukungan dan langganan (model Red Hat)

Model tertua menjual jaminan di sekitar software gratis. Red Hat adalah contoh standarnya. Pengumuman Oktober 2018 dari IBM tentang kesepakatannya mengakuisisi Red Hat dengan harga $190 per saham, nilai perusahaan (enterprise value) sekitar $34 miliar, menggambarkan target tersebut sebagai penyedia terkemuka software open source enterprise, termasuk teknologi Linux, hybrid cloud, container, dan Kubernetes.

Untuk apa pelanggan Red Hat membayar? FAQ langganan milik Red Hat sendiri mencantumkan patch, perbaikan bug, pembaruan dan peningkatan, dukungan teknis dengan ketersediaan 24/7, serta sertifikasi perangkat keras, software, dan penyedia cloud. FAQ itu juga menyatakan bahwa pelanggan yang membiarkan langganannya lapse kehilangan errata keamanan, perbaikan bug, dan dukungan teknis. Dengan kata lain, produknya adalah versi yang dipelihara, tersertifikasi, dan didukung, bukan kode sumbernya sendiri.

Di mana model ini berhasil: software infrastruktur yang dijalankan organisasi besar di lingkungan produksi dan tidak boleh sampai rusak. Di mana model ini kesulitan: penjualan lambat dan berat, dan model ini berskala bersama orang dan kepercayaan, bukan bersama jumlah unduhan.

2. Open core

Pada perusahaan open-core, produk dasarnya open source dan sekumpulan fitur tambahan bersifat proprietary dan berbayar. Tambahannya biasanya hal-hal yang diminta organisasi besar: keamanan tingkat lanjut, tata kelola, perangkat skalabilitas, integrasi resmi, dan dukungan khusus.

Pertanyaan strategisnya adalah di mana menarik garis. Jika terlalu sedikit di versi gratis, komunitas tidak punya alasan mengadopsinya. Jika terlalu banyak, tidak ada yang punya alasan membayar. Pendiri sering memakai uji sederhana: fitur yang membantu developer individu tetap gratis, dan fitur yang membantu organisasi berkoordinasi (izin akses, kepatuhan, administrasi) berbayar.

Risikonya adalah kepercayaan. Ketika perusahaan memindahkan sebuah fitur dari tingkat gratis ke tingkat berbayar, komunitas dapat membacanya sebagai pengkhianatan, dan sebuah fork dapat menyusul.

3. Cloud terkelola (layanan hosting)

Sebagian besar pendapatan open-source modern berasal dari menjalankan software untuk pelanggan. Perusahaan meng-host-nya, menangani peningkatan versi, backup, dan penskalaan, serta menarik biaya berdasarkan penggunaan atau kapasitas. Ini adalah model SaaS yang diterapkan pada produk open-source, dan mekanisme penetapan harganya dibahas dalam penetapan harga berbasis penggunaan.

MongoDB menunjukkan seberapa besar skala yang bisa dicapai. Dalam rilis hasil fiskal 2026 (tahun fiskal yang berakhir 31 Januari 2026), MongoDB melaporkan total pendapatan $2,46 miliar, dan layanan cloud Atlas menyumbang sekitar $1,81 miliar dari jumlah itu, sekitar 73%. Itu angka tahun fiskal satu perusahaan, bukan tolok ukur industri, dan database inti MongoDB bersifat source-available, bukan open source (dibahas lebih lanjut di bawah).

Di mana model ini berhasil: produk yang merepotkan untuk dioperasikan, sehingga kenyamanan layak dibayar. Di mana model ini kesulitan: siapa pun dengan akun cloud dapat menawarkan layanan yang sama, termasuk penyedia cloud terbesar. Itulah akar sengketa lisensi yang dijelaskan di bawah.

4. Lisensi ganda

Dengan lisensi ganda, kode yang sama ditawarkan di bawah dua lisensi. Satu adalah lisensi gratis, biasanya copyleft, yang mewajibkan siapa pun yang membangun di atasnya membagikan kode sumber mereka sendiri dengan syarat yang sama. Yang lain adalah lisensi komersial berbayar untuk perusahaan yang ingin menanamkan software itu ke dalam produk tertutup tanpa kewajiban tersebut.

Model ini paling cocok untuk library dan komponen yang ditanamkan perusahaan lain ke dalam produk mereka. Model ini kurang cocok untuk aplikasi pengguna akhir, tempat tidak ada yang membutuhkan pengecualian dari ketentuan copyleft. Model ini juga biasanya mengharuskan perusahaan memegang hak untuk melisensikan ulang, dan di situlah perjanjian kontributor berperan (lihat di bawah).

5. Source-available dan perubahan lisensi

Kelompok perusahaan yang makin banyak kini menerbitkan kode sumber di bawah lisensi yang membatasi penggunaan komersial, biasanya untuk mencegah pesaing menjual ulang produk sebagai layanan hosting. Contoh umum adalah SSPL, Business Source License, dan lisensi bergaya fair-code. Lisensi-lisensi ini memungkinkan pelanggan membaca, menjalankan, dan memodifikasi kode, serta membiarkan vendor mempertahankan hak eksklusif untuk menjualnya sebagai layanan.

Sebagian lisensi ini juga berubah menjadi lisensi yang sepenuhnya terbuka setelah jangka waktu tertentu. Ini cara untuk menjanjikan keterbukaan pada akhirnya sambil melindungi keunggulan awal saat ini.

6. Donasi, sponsor, dan yayasan

Tidak semua proyek open-source adalah perusahaan. Banyak yang dipelihara oleh sukarelawan, didanai sponsor, atau bernaung di bawah yayasan. Apache Software Foundation, misalnya, meminta kontributor penting menandatangani perjanjian lisensi kontributor individu agar yayasan dapat membela proyek jika timbul sengketa hukum atas software tersebut. Yayasan memberi proyek tata kelola yang netral dan perlindungan hukum, tetapi tidak membayar para pendirinya. Perusahaan komersial sering tumbuh di sekitar proyek yayasan dan menjual dukungan atau hosting, yang kembali mengalir ke model 1 sampai 3.

Membandingkan model-model tersebut

Kebanyakan perusahaan nyata menggabungkan beberapa model. Produk yang umum memiliki open core gratis, versi hosting, tingkat enterprise, dan opsi dukungan.

Masalah hyperscaler dan gelombang perubahan lisensi 2021 sampai 2026

Cloud terkelola adalah model paling menguntungkan, dan juga yang paling mudah ditiru pesaing yang lebih besar. Jika lisensi mengizinkan, penyedia cloud dapat meng-host database atau perangkat open-source, menarik biaya, dan memberi sedikit kontribusi kembali. Vendor open-source menyebutnya "strip-mining."

Beberapa perusahaan menanggapinya dengan mengubah lisensi. Setiap pengumuman di bawah berasal dari perusahaan itu sendiri.

Beberapa hal menonjol ketika Anda membaca pengumuman-pengumuman ini bersama-sama.

Alasannya konsisten. Elastic menyatakan perubahan itu dimaksudkan untuk mencegah penyedia menawarkan software-nya sebagai layanan tanpa memberi kontribusi kembali. HashiCorp berargumen bahwa sebagian vendor mengambil manfaat dari karya open-source tanpa berkontribusi. Redis menyatakan bahwa mayoritas penjualan komersialnya disalurkan melalui penyedia layanan cloud terbesar.

Kejujuran soal label itu penting. Redis menyatakan dengan jelas bahwa lisensi barunya tidak memenuhi definisi OSI dan bahwa versi gratisnya akan disebut "Community Edition", bukan open source. OSI memiliki pandangan yang sama terhadap SSPL.

Pembalikan arah terjadi. Elastic dan Redis sama-sama kemudian menambahkan AGPL yang disetujui OSI sebagai opsi. Redis menyatakan perubahan sebelumnya telah merusak hubungannya dengan komunitas, dan Elastic menyatakan langkahnya didorong oleh kekhawatiran atas praktik Amazon tetapi situasinya telah berubah. Bagi pendiri, pelajarannya bukan bahwa satu lisensi itu benar. Pelajarannya adalah bahwa perubahan lisensi merupakan keputusan bisnis dengan biaya komunitas yang bisa bertahan bertahun-tahun.

Sebagian lisensi memiliki jam hitung mundur. Directus menyatakan setiap versi software-nya menjadi sepenuhnya open source di bawah GPLv3 setelah empat tahun, dan menurut ambang batasnya, organisasi dengan pendapatan tahunan di bawah $5 juta dan kurang dari 50 karyawan dapat memakainya secara gratis. Lisensi dengan jeda waktu mencoba melindungi vendor sekarang sambil menepati janji open-source di kemudian hari.

Komunitas versus pendapatan: ketegangan inti

Perusahaan open-source komersial hidup dengan konflik permanen. Komunitas menginginkan software yang stabil, gratis, dan berlisensi permisif. Investor dan karyawan menginginkan pendapatan yang tumbuh. Setiap keputusan monetisasi menggeser keseimbangan.

Beberapa titik tekanan praktis:

• Pembatasan fitur. Memindahkan fitur yang sudah ada ke balik paywall melanggar janji tak tertulis kepada pengguna dan kontributor.
• Tata kelola. Jika satu perusahaan mengendalikan roadmap, kontributor luar mungkin menjauh. Yayasan memberi kendali netral tetapi mengambil sebagian kendali dari perusahaan.
• Fork. Jika perubahan lisensi membuat cukup banyak anggota komunitas marah, sebuah fork dapat muncul di bawah lisensi permisif. Fork mempertahankan kode lama dan dapat menarik penyedia cloud yang hendak diblokir perusahaan.
• Merek dagang. Bahkan ketika kode bebas disalin, namanya biasanya tidak. Redis, misalnya, kini membatasi penggunaan "Redis" dalam nama produk lain berdasarkan kebijakan merek dagangnya.

Perjanjian lisensi kontributor

Perjanjian lisensi kontributor (contributor license agreement, CLA) adalah dokumen tempat kontributor memberi proyek hak yang dibutuhkannya untuk memakai kontribusi mereka. Yayasan memakainya demi kejelasan hukum, seperti ditunjukkan oleh dasar pemikiran ICLA dari Apache Software Foundation.

Bagi perusahaan, CLA memiliki tujuan kedua: CLA memungkinkan perubahan lisensi di kemudian hari atau penjualan kode di bawah lisensi komersial, karena perusahaan memegang hak yang dibutuhkannya. Redis, misalnya, menyatakan bahwa mereka mewajibkan kontributor menerima CLA-nya sebelum mempertimbangkan kontribusi mereka.

Kontributor kadang memandang CLA sebagai jalan satu arah. Perusahaan yang ingin menjaga niat baik komunitas sebaiknya jelas tentang alasan mewajibkannya dan apa yang dijanjikan sebagai imbalan.

Apa artinya bagi sebuah startup

Jika Anda mempertimbangkan model bisnis open-source, beberapa pertanyaan layak dikerjakan sejak dini.

1. Untuk apa pelanggan membayar jika kodenya gratis? Kenyamanan, pengurangan risiko, fitur, atau izin. Jika Anda tidak bisa menyebutnya, Anda belum punya model bisnis.
2. Siapa yang bisa menjual ulang produk Anda? Jika jawabannya "penyedia cloud mana pun," pilih lisensi Anda dengan mempertimbangkan hal itu sejak awal, karena mengubahnya nanti mahal.
3. Bagaimana Anda akan memperoleh kepercayaan komunitas? Tentukan apa yang tidak akan pernah Anda pindahkan ke balik paywall, dan tuliskan.
4. Apakah Anda memahami ekonominya? Pengguna gratis membutuhkan biaya untuk dilayani dan didukung. Lacak unit economics untuk segmen yang membayar, bukan jumlah total unduhan.
5. Adakah moat di luar kode? Merek, keahlian hosting, ekosistem, dan data bisa lebih penting daripada lisensi. Artikel economic moat membahas gagasan ini secara rinci, dan efek jaringan dapat berlaku ketika komunitas developer yang besar membuat produk lebih bernilai.

Tim tahap awal khususnya sebaiknya membandingkan model ini dengan opsi lain, seperti model bisnis platform, sebelum berkomitmen.

Praktik seputar lisensi dan perjanjian kontributor bervariasi menurut negara dan investor, jadi pendiri sebaiknya mencari nasihat hukum untuk situasi mereka sendiri. Kami belum menemukan sumber komparatif yang andal tentang praktik bisnis open-source di Asia Tenggara secara khusus.

Fakta Utama

• Open Source Definition dari OSI memiliki sepuluh kriteria dan terakhir diubah pada 2007. Salah satunya melarang pembatasan terhadap bidang usaha.
• OSI menyatakan pada Januari 2021 bahwa SSPL bukan lisensi open-source.
• IBM mengumumkan pada Oktober 2018 bahwa mereka akan mengakuisisi Red Hat dengan $190 per saham, sekitar $34 miliar dalam enterprise value.
• FAQ langganan Red Hat mencantumkan patch, pembaruan, dukungan, dan sertifikasi sebagai apa yang disediakan oleh langganan.
• Layanan Atlas milik MongoDB menghasilkan sekitar 73% dari pendapatannya sebesar $2,46 miliar pada fiskal 2026.
• Elastic pindah ke SSPL pada Januari 2021 dan menambahkan AGPL pada Agustus 2024.
• HashiCorp mengadopsi BSL 1.1 pada Agustus 2023.
• Redis beralih ke source-available pada Maret 2024 dan menambahkan AGPLv3 pada Mei 2025.
• NocoDB dan Directus sama-sama pindah ke lisensi source-available pada 2026.
• Lisensi source-available bukan open source menurut OSI, meskipun kodenya publik.

Bacaan Terkait

• Model Bisnis Freemium
• Product-Led Growth
• Economic Moat
• Model Bisnis Startup Hardware
• Model Penetapan Harga SaaS
• Model Bisnis Platform