Open source tidak menang karena lebih murah

• Perusahaan open source komersial sulit bertahan lama hanya dengan alternatif yang menempelkan lisensi MIT pada produk berbayar yang sudah ada; mereka membutuhkan alasan mengapa harus open source atau kualitas produk yang lebih unggul
• Berbeda dari proyek nirlaba atau berbasis sponsor, bisnis open source harus memiliki pendapatan agar dapat terus merekrut, tumbuh, dan mengembangkan produk secara berkelanjutan
• Perusahaan tahap awal mudah memilih tier gratis atau versi open source, sementara perusahaan besar memperlakukan biaya SaaS sebagai pos anggaran, sehingga sulit membalik keputusan pembelian hanya dengan harga murah
• Open source menjadi kuat ketika ada masalah transparansi yang membuat source tertutup menggoyahkan kepercayaan pelanggan, dan masalah ekstensibilitas yang membutuhkan banyak integrasi dan plugin
• Kasus PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte, dan Elastic menunjukkan bahwa open source dapat berkembang menjadi produk yang lebih baik melalui kemampuan diaudit, self-hosting, dan kontribusi komunitas

---

Alternatif open source saja tidak cukup

• Deskripsi seperti “versi open source dari Stripe Billing” atau “versi open source dari Chargebee” berguna untuk membuat produk cepat dipahami, tetapi lemah sebagai dasar untuk mempertahankan bisnis
• Alat open source komersial sulit hanya mengandalkan posisi sebagai alternatif open source dari produk berbayar yang sudah sukses
• Tidak cukup bagi developer untuk sekadar meniru produk lalu menempelkan lisensi MIT; open source itu sendiri juga tidak menjamin keberhasilan
• Yang dibahas di sini adalah proyek open source komersial yang bersaing dengan solusi berbayar populer
  • Produk yang berpusat pada komunitas atau didanai sponsor seperti React, TypeORM, dan VSCode memiliki prioritas berbeda
  • React didukung oleh organisasi yang lebih besar seperti Meta, sementara TypeORM membiayai pengembangan lewat donasi
  • Proyek-proyek seperti ini pada dasarnya bukan bisnis
• Agar perusahaan open source berhasil, harus ada alasan yang jelas mengapa produknya perlu open source, atau produknya harus mengungguli pesaing

Tolok ukur keberhasilan adalah pendapatan, bukan penggunaan

• Kecuali proyek nirlaba yang menerima donasi atau sponsor dari perusahaan induk, tolok ukur akhir bagi bisnis open source pada umumnya adalah pendapatan
• Perusahaan berorientasi laba menggunakan pendapatan untuk membiayai perekrutan karyawan, pertumbuhan, keberlanjutan, dan pengembangan berkelanjutan
• Perusahaan yang membuat software gratis sambil tetap menghasilkan pendapatan adalah contoh positif; perusahaan open source juga bukan berusaha mengeksploitasi pelanggan secara berlebihan, melainkan ingin bisnisnya terus berjalan
• MongoDB tumbuh menjadi perusahaan database besar dengan lebih dari 4.600 karyawan
  • Kemudian beralih ke lisensi SSPL untuk membatasi Cloud Provider agar tidak menerapkan layanan tanpa berkontribusi pada proyek
  • SSPL tidak disetujui OSI, tetapi digambarkan secara praktis cukup dekat dengan open source
• Saat mengukur keberhasilan jangka panjang, tingkat adopsi dan pendapatan harus dibedakan
  • Meski tingkat adopsi proyek tinggi, proyek bisa menghilang jika tidak mampu menghasilkan pendapatan
  • Harapan bahwa komunitas akan mengambil alih proyek dinilai hampir tidak memiliki bukti yang mendukungnya

Harga murah bukan medan persaingan yang berkelanjutan

• Strategi yang hanya menargetkan pelanggan sensitif harga hampir seperti pertarungan yang sudah kalah
• Dalam contoh hipotetis membuat versi open source dari Amplitude, argumennya bisa saja: Amplitude mahal, memberatkan perusahaan tahap awal, dan perusahaan besar pun bisa menghemat biaya
• Namun perusahaan tahap awal sensitif terhadap harga, sehingga kemungkinan besar memilih versi open source atau tier gratis, dan itu tidak cukup untuk menopang bisnis
• Strategi membuat alternatif yang lebih murah biasanya lebih mirip tiket menuju kebangkrutan di masa depan
• Perusahaan besar pun umumnya tidak khawatir perusahaannya bangkrut karena biaya Amplitude
  • Dalam negosiasi kontrak, harga bisa dipertimbangkan dalam batas anggaran
  • Namun sebagian besar SaaS pada akhirnya hanyalah salah satu pos biaya
  • Syarat yang lebih penting adalah apakah solusinya baik, apakah akan bertahan dalam jangka panjang, dan apakah mudah dikelola
  • Deploy solusi open source bisa sulit dikelola
• Pengecualiannya adalah ketika biaya solusi mengambil porsi yang sangat besar dari total anggaran
  • Ini mencakup perusahaan yang harus mengurangi Oracle karena biaya Oracle melonjak akibat penggunaan database
  • Namun sebagian besar solusi open source tidak menggantikan tiga pos biaya terbesar, sehingga harga sulit menjadi kriteria keputusan utama

Cara pertama open source menang: transparansi

• Kasus umum ketika solusi open source menjadi kuat adalah saat source tertutup menciptakan masalah transparansi yang menimbulkan ketidakpercayaan antara pelanggan dan vendor
• PostHog adalah alternatif open source untuk Amplitude
  • PostHog tumbuh dengan pelanggan seperti Airbus, DHL, dan Staples
  • Produk ini menggabungkan beberapa solusi SaaS produk dan disediakan sebagai open source
  • Source code blog dan roadmap-nya pun terbuka
• PostHog menempatkan diri sebagai produk yang lebih baik daripada pesaingnya karena alat analitik menangani data pelanggan yang sensitif seperti alamat IP, nama, dan rekaman sesi
• Dalam lingkungan dengan regulasi data yang makin banyak seperti GDPR dan CCPA, menyimpan data seperti itu pada pihak ketiga bisa terasa membebani
• PostHog menyediakan dua pilihan
  • Melakukan self-hosting solusi analitik secara langsung
  • Mempekerjakan PostHog sebagai pihak ketiga, tetapi tetap memperoleh transparansi tentang cara data disimpan dan cara bermigrasi ke self-hosting di masa depan
• Meski metode yang paling ramah privasi adalah self-hosting, banyak perusahaan masih bisa memilih model hosting
  • Dalam kasus ini pun, mereka dapat melihat bagaimana software bekerja baris demi baris
  • Mereka dapat mengetahui prosedur untuk berpindah ke model self-hosting saat diperlukan
• Perusahaan open source tidak menang dengan menghilangkan kebutuhan akan pihak ketiga, melainkan dengan meraih kepercayaan karena cara kerjanya dapat diaudit secara terbuka

Contoh produk yang membutuhkan transparansi

• Medplum adalah platform rekam kesehatan elektronik open source yang bersaing dengan vendor tertutup yang sudah ada
  • Karena open source, pengguna dapat memastikan dengan tepat apa yang didukung dan tidak didukung oleh platform
• SuperTokens adalah alternatif open source untuk solusi autentikasi seperti Auth0
  • Login menangani data sensitif seperti nama, email, dan kata sandi
  • Fakta bahwa produk ini open source membantu memperoleh lebih banyak kepercayaan
• TableFlow adalah alternatif open source untuk platform impor CSV seperti Flatfile
  • Yang penting di sini adalah data yang diimpor bersifat sensitif
• Minio adalah alternatif open source untuk storage AWS S3
  • S3 dapat menyimpan PII pelanggan lewat screenshot atau file JSON terstruktur
  • Minio dapat menjadi alternatif bagi perusahaan yang peduli siapa yang dapat mengakses data pengguna
  • AWS mengklaim bahwa karyawan AWS tidak mengakses data pelanggan secara langsung, tetapi pada source tertutup, klaim itu tetap menjadi soal kepercayaan
• Lago juga menangani informasi penagihan dan penggunaan produk, dan informasi ini cukup dekat dengan konten sensitif, sehingga open source dipandang dapat membangun kepercayaan pengguna dengan lebih baik

Cara kedua open source menang: ekstensibilitas

• Salah satu keunggulan besar open source adalah membuka pengembangan fitur niche bagi komunitas
• Produk inti biasanya dipelihara oleh tim engineering pusat, tetapi integrasi atau plugin dibuat oleh developer komunitas dan terkadang digabungkan ke branch utama
• Solusi tertutup harus bergantung pada tim engineering sendiri, sehingga sulit berkembang dengan cara yang sama
• Hal ini sangat menguntungkan bagi perusahaan open source yang membangun sistem yang harus terhubung dengan banyak library, framework, dan aplikasi
• Airbyte adalah platform ELT open source yang tumbuh besar berkat connector yang ditambahkan komunitas
• Elastic juga merupakan perusahaan yang lebih besar yang awalnya open source, dan menyediakan banyak integrasi data
• SuperTokens menjadikan ekstensibilitas sebagai proposisi nilai inti, dan anggota komunitas dapat membuat integrasi dengan penyedia autentikasi yang jarang digunakan, sehingga menguntungkan semua pihak

Cara ketiga open source menang: produk yang lebih baik

• Transparansi dan ekstensibilitas membantu open source komersial menjadi produk yang lebih baik dalam jangka panjang
• Proyek open source dapat berkembang lebih cepat daripada solusi tertutup dengan memanfaatkan feedback dan bantuan komunitas
• PostHog dimulai sebagai alternatif untuk Amplitude dan FullStory, tetapi kemudian tumbuh menjadi solusi komprehensif besar yang juga bersaing dengan LaunchDarkly dan Pendo
  • PostHog meraih pendanaan Series B sebesar 15 juta dolar AS
  • Pertumbuhan ini terjadi selama beberapa tahun terakhir, dan PostHog melihat komunitas sebagai salah satu alasan utamanya
• Proyek open source tidak terbatas pada open source komersial; selama puluhan tahun, proyek semacam ini telah menjadi pendorong penting peningkatan produk
• Sebagian software dapat tetap tertutup karena karakteristik efek first-mover
• Namun di area yang menghadapi masalah transparansi dan ekstensibilitas, pendatang baru open source dapat menjadi ancaman nyata

[guarder]

Saya menemukannya secara tidak sengaja saat mencari-cari, dan jadi penasaran kapan AI akan memperbaiki terjemahan harfiah dari bahasa Inggris seperti ini (karena murah).

[savvykang]

Berikut hasil menjalankan Claude 4.5 Sonnet hari ini (2026-01-12)

---

"Open source tidak menang karena lebih murah"

Prompt

"Open Source does not win by being cheaper" terjemahkan ke bahasa Korea  

---

Open source tidak menang hanya karena harganya murah.
Faktor keberhasilan open source bukan biaya yang murah, melainkan ada di tempat lain.
Open source unggul bukan karena harga yang rendah.

Open source tidak menang dengan menjadi lebih murah  
  
Paraphrase  

[GN⁺]

Opini Hacker News

• Istilah laba (profit) di sini terasa aneh dan ambigu
  Saya menjalankan proyek open source/perangkat lunak bebas selama hampir 24 tahun, dan sekitar 17 tahun di antaranya juga menghasilkan pendapatan, tetapi tidak ada “laba”, hanya ada pendapatan (revenue)
  Biasanya, seperti yang dilihat perusahaan atau akuntan, laba adalah uang yang tersisa setelah mengurangi kompensasi orang-orang yang terlibat dalam proyek dan biayanya
  Proyek open source yang membutuhkan laba dalam pengertian ini hanyalah proyek yang menerima investasi modal dari investor yang mengharapkan “tingkat pengembalian”, dan proyek seperti itu memang ada, tetapi bukan mayoritas
  Selain itu, seperti tipikal tulisan yang naik di HN, keseluruhannya terlalu condong ke ranah web/SaaS. Mungkin sulit dipercaya, tetapi ada juga jenis proyek open source lain

  • Tulisan ini membahas bisnis berbasis open source, bukan keseluruhan dari begitu banyak proyek open source
    Dalam konteks itu, laba adalah sisa setelah menerima pendapatan dan membayar biaya, dan biaya tersebut mencakup hal-hal seperti gaji tetap, kontrak kerja, dan slip gaji
    Cara bisnis menggunakan laba bisa beragam. Bisa ditumpuk sebagai cadangan kas agar biaya tetap bisa dibayar pada bulan dengan pendapatan rendah, bisa dipakai membeli aset seperti hardware baru, dan bisa memungkinkan perekrutan tambahan. Meski tidak sesering yang dibayangkan, laba juga bisa dibayarkan kepada pemilik sebagai dividen
    Untuk situasi Anda, karena tidak banyak detail, saya hanya bisa menebak; tetapi jika Anda menjalankannya sendiri dan proyeknya kecil sehingga tidak perlu atau tidak berniat menambah karyawan, pendapatan itu pada dasarnya lebih mirip penghasilan pribadi. Karena strukturnya Anda menerima lebih banyak pada bulan tertentu dan lebih sedikit pada bulan lain, dalam konteks ini lebih tepat menyebutnya pendapatan, bukan “laba”
    Terutama jika software tersebut hampir tidak punya overhead lain dan pelacakan biaya untuk tujuan pajak pun tidak terlalu berarti; bisa jadi Anda bahkan tidak benar-benar menyimpan pembukuan. Dalam situasi seperti itu, saya paham mengapa tulisan ini tidak terasa relevan. Tulisan ini membahas situasi yang cukup berbeda
  • Agak lucu melihat seseorang di HN, apalagi yang mengaku menjalankan bisnis, menaruh tanda kutip takut-takut pada kata profit dan membicarakannya seolah-olah ambigu
  • Bahkan tanpa modal ventura, seseorang bisa beroperasi dalam bentuk badan usaha atau memiliki pola pikir yang berfokus pada pertumbuhan dan laba
    Jika investor murni tidak menuntut tingkat pengembalian berkelanjutan, tekanannya jauh berkurang, dan lebih mudah melakukan hal yang sesuai untuk proyek
    Namun di area produk yang bersaing dengan perusahaan-perusahaan ambisius, pertumbuhan juga diperlukan dan kemungkinan besar masuk akal
    Menyisakan laba untuk menghadapi resesi, peluang, atau pengeluaran besar bukan sekadar sesuatu yang masuk akal. Semakin banyak orang yang terlibat dan semakin banyak pelanggan, semakin besar pula alasan untuk tidak membakar habis seluruh pendapatan yang masuk
  • Jika Anda membayar kompensasi kepada diri sendiri, pada akhirnya Anda bergantung pada laba. Di atas pembukuan, laba menjadi 0, tetapi dalam praktiknya tidak berbeda dari menggunakan laba untuk membayar dividen
  • Laba adalah istilah akuntansi, jadi ambigu. Jika ingin benar-benar jelas, berguna untuk membatasinya, misalnya “laba kena pajak” atau “laba dari sudut pandang investor”
    Dalam praktiknya, di perusahaan besar, keduanya sering kali merupakan angka yang tidak saling terkait, dan masing-masing didefinisikan menurut kepada siapa angka itu disampaikan serta aturan yang berlaku untuk penyampaian tersebut
    Bisa juga ada yang disebut “laba manajemen”, istilah umum untuk metrik yang tidak distandardisasi atau diregulasi. Misalnya, meskipun sebuah bisnis telah meninggalkan akuntansi berbasis kas untuk tujuan pajak dan pelaporan investor, bagi manajemen lama mungkin tetap berguna untuk terus melacak definisi laba dengan cara lama. Bisa karena kebiasaan, atau karena itu menunjukkan arus kas dengan baik, atau berguna dengan cara lain
    Ini salah satu masalah yang agak postmodern. SEC, IRS, dan petugas bank tidak akan menerima ungkapan seperti “laba SEC” dan menuntut laba yang “sebenarnya”. Mirip politisi lokal yang secara polos menanyai kontraktor berapa biaya “sebenarnya” sebuah rumah sakit
    Bagaimanapun, penulis juga menggunakan istilah dari sudut pandangnya sendiri, seperti SEC atau IRS. “Open source” dalam kalimat “open source tidak menang karena lebih murah” mengacu pada bisnis open source dengan model seperti MongoDB. Karena itu, hal-hal seperti investor dan target pertumbuhan diasumsikan ada
    Tulisan itu sendiri juga sudah memperjelas hal ini, jadi tidak banyak alasan untuk masuk ke geraman semantik

• Masalah dari model bisnis ini adalah ia menciptakan ketegangan antara versi OSS dan versi berbayar
  Mereka ingin versi OSS-nya bagus, tetapi tidak boleh sampai sebagus itu sehingga tak ada yang merasa perlu membayar SaaS, konsultasi, dan sebagainya
  Ketegangan itu pada akhirnya tampaknya mengarah pada fitur yang jelas-jelas dibutuhkan menjadi tidak tersedia, atau fitur dan pengetahuan yang diperlukan untuk beroperasi dalam skala besar disembunyikan sebagai closed source demi monetisasi perusahaan sponsor
  Jika produknya bersifat infrastruktur, pola seperti Elastic dan Hashicorp yang mengubah lisensi menjadi hanya boleh dilihat dan tidak boleh disentuh agar penyedia cloud besar tidak melahapnya sebagai layanan sekali klik juga sudah menjadi hal yang mapan
  Bukan berarti tulisannya salah, tetapi saya berharap OSS yang disponsori secara komersial tidak berpura-pura menjadi win-win ala kumbaya yang baik untuk semua orang. Kenyataannya, strukturnya lebih mirip startup yang memakainya sebagai growth hacking untuk membangun kepercayaan, lalu ketika tiba waktunya menghasilkan pendapatan, mereka dengan satu atau lain cara menekan komunitas yang membantu pertumbuhannya

  • Saya sama sekali tidak melihat bagian “sponsor menyembunyikan fitur yang jelas atau fitur/pengetahuan yang diperlukan untuk operasi skala besar sebagai closed source demi menghasilkan uang” sebagai masalah
    Saya pernah memelihara modul kecil dan selama bertahun-tahun menerima banyak permintaan fitur dan dukungan. Sampai saya menghasilkan cukup untuk membayar sewa rumah, saya sama sekali tidak merasa bersalah memungut biaya untuk pekerjaan seperti itu
    Bahkan untuk menekan tombol merge Pull Request pun, kalau waktu saya terpakai meski hanya 1 detik, saya mengenakan biaya. Saya menghabiskan berbulan-bulan, bertahun-tahun untuk kode itu, dan merilisnya gratis ke dunia
    Kalau butuh fitur tambahan atau waktu saya, harus bayar
  • Memang ada ketegangan itu, tetapi sama sekali tidak niscaya. Ada juga perusahaan yang melakukannya dengan benar sambil memuaskan pengguna OSS dan pelanggan komersial
    Fakta bahwa banyak perusahaan gagal melakukannya bukan berarti model bisnis ini tidak berjalan, melainkan lebih menunjukkan bahwa melakukannya dengan benar sangat sulit
  • Menarik karpet dari bawah kaki pengguna memang terasa tidak enak
    Namun jika kita menganggap kebanyakan orang pada dasarnya baik, patut juga dipertimbangkan kemungkinan bahwa perusahaan atau orang-orang seperti ini salah dalam pendekatan ke pasar. Bisa jadi bukan niat jahat, melainkan ketidakmampuan
    Jika sejak hari pertama mereka transparan tentang apa yang akan gratis selamanya dan apa yang pada akhirnya akan berbayar, saya tidak akan melihatnya sebagai pengkhianatan terhadap komunitas
    Tentu saja, dengan syarat mereka mematuhi roadmap dan menyesuaikannya berdasarkan masukan serta kontribusi
  • Ada pemisahan yang sangat mudah yang digunakan banyak proyek: membedakan pengguna perusahaan dan pengguna individu
    Dukungan berbayar atau fitur ekstensi bisa tetap berada di ranah komersial, tempat sebagian besar uang dari perangkat lunak memang dihasilkan
    Ini tidak akan cocok untuk semua use case, tetapi memang tidak perlu. Sebagian besar komputasi seharusnya bersifat personal
  • Saya penasaran pola seperti apa yang dimaksud. Saya ingin tahu bagaimana proyek infrastruktur semacam ini bisa bertahan agar tidak mati oleh AWS atau GCP

• Ada pernyataan bahwa “MinIO adalah alternatif yang baik bagi perusahaan yang peduli siapa yang mengakses data pengguna,” tetapi bukankah sebuah perusahaan bisa saja mengklaim menghosting dengan software open source, padahal sebenarnya memakai software internal closed source yang meniru endpoint API yang sama?
  Kalau begitu, jenis kepercayaan yang sama seperti terhadap AWS tetap diperlukan

  • Sebuah perusahaan mungkin dengan tulus mengatakan bahwa mereka menaruh data on-premises untuk melindungi data pelanggan dari cloud besar yang menakutkan, tetapi mereka bisa saja tidak menyebutkan bahwa segala macam orang dari ekosistem konsultan IT lokal memiliki hak admin domain, dan separuh warga sekitar punya akses ke KeepassX di network drive
    Jangan mengasumsikan bahwa self-hosting berarti kesadaran keamanan yang tinggi. Di sebagian besar perusahaan, IT on-premises diperlakukan seperti HVAC atau instalasi listrik, hanya saja lebih merepotkan
    Siapa pun yang memakai baju kerja bisa menipu resepsionis agar memberikan kunci ruang server
  • Benar. Klaim ini sangat umum secara mengejutkan, tetapi tidak masuk akal. Dalam SaaS, istilah open source hampir tidak berarti apa-apa
    Itu hanya berarti penyedia membagikan source code yang mereka katakan berjalan di balik layanan mereka
    Bahkan jika kode itu benar-benar sesuai, kecil kemungkinan itu satu-satunya kode yang berjalan di balik layanan “resmi”. Dan pengguna juga tidak bisa membuild sendiri lalu mendeploynya ke server mereka
    Open source benar-benar bermakna hanya saat self-hosting; jika tidak, pada dasarnya tidak ada bedanya dengan software proprietary. Semuanya bergantung pada kepercayaan terhadap penyedia dan, jika memungkinkan, kontrak
  • Kalau “kepercayaan” dalam arti teknis murni, itu benar, tetapi kita hidup di dalam masyarakat. Jika penyedia bisa bertanggung jawab atas penipuan karena klausul yang mereka masukkan ke kontrak ternyata bohong, pelanggan biasanya tidak sampai khawatir apakah mereka bisa memverifikasinya secara independen
    Misalnya, jika kontrak menyatakan bahwa data masuk dan keluar melalui kode open source ini dan tidak pergi ke tempat lain, lalu mencantumkan prosedur untuk menjamin hal itu, tetapi seluruhnya merupakan kebohongan terang-terangan, maka itu menjadi masalah besar dengan cara yang jelas dan dapat ditegakkan
    Ini juga sulit disembunyikan dari karyawan internal, dan orang datang dan pergi. Jika tidak benar, kecil kemungkinan mereka membuat klaim seperti itu
  • Bahkan jika mantan karyawan saja mengetahui fakta itu, peluang gugatan menjadi sangat bagus
  • Tidak begitu. Jika perusahaan membuat suatu klaim tetapi dalam praktiknya melakukan hal lain, itu penipuan, dan tindakan hukum bisa diambil. Ini adalah masalah yang terpisah dari kepercayaan

• Penulis menyatakan bahwa yang dimaksud secara spesifik adalah solusi open-source yang bersaing dengan produk berbayar
  Secara pribadi, dalam konteks ini saya merasa belum ada kesimpulan apakah open source “menang” atau tidak
  Dalam 10 tahun terakhir, produk open source meningkat pesat, dan sekitar 5 tahun belakangan kita juga melihat banyak di antaranya menjauh dari open source. Contohnya MongoDB, stack Hashicorp, Elastic, Red Hat, MinIO, dan lainnya
  Produk yang benar-benar open source sekaligus kompetitif secara komersial tidak banyak tersisa, dan banyak di antaranya sedang berusaha membuktikan bahwa ini adalah model bisnis yang dapat dijalankan

  • Proyek Caddy sedang berjuang untuk menunjukkan bahwa model ini memungkinkan, dan sampai tingkat tertentu berhasil
    Beberapa minggu lalu saya mempresentasikan topik ini di acara internal perusahaan, dan beberapa minggu lagi akan mempresentasikannya lagi di GoWest
    Premis utamanya adalah lisensi open source memang secara harfiah memberikan kebebasan, tetapi tidak menyediakan hal-hal lain yang layak dibayar oleh perusahaan. Lisensi proprietari menyediakan apa yang dibutuhkan perusahaan, tetapi mengorbankan kebebasan
    Saya percaya ada model ketiga yang bekerja di tengah tanpa mengompromikan kebebasan atau keandalan. Dengan tetap open source dan mengisi celah yang dibutuhkan perusahaan melalui sponsor, ini mungkin bisa berhasil untuk sebagian proyek
    Saat ini kami sedang mendesain ulang situs web Caddy agar sesuai dengan pesan ini, dan semoga berjalan baik
  • Bukankah itu inti tulisan ini? Bukan bahwa open source pasti menang, melainkan jika menang, itu bukan karena menjatuhkan pesaing lewat harga, tetapi karena kekuatan-kekuatan yang disebutkan penulis
  • Melihat repositori MinIO, sepertinya lisensinya berubah dari APL2 ke AGPL3
    Apakah yang dimaksud dengan “menjauh dari open source” tentang MinIO adalah itu?
  • Bagaimana VLC dan Blender dijalankan?

• Judulnya bodoh. Tentu saja open source menang karena lebih murah
  Yang ingin dikatakan penulis adalah bisnis open source tidak menang karena lebih murah
  Codebase open source selalu menang karena lebih murah. Tidak ada yang membayar untuk algoritma kompresi, daemon waktu jaringan, atau transcoder media. Open source telah sepenuhnya menghapus pasar-pasar seperti itu

  • Sebenarnya ini tampak seperti tulisan yang cukup menarik tentang bisnis yang membuat kode open source
    Hanya saja menjengkelkan karena judulnya secara harfiah salah hanya gara-gara satu kata
  • Pada judul “ukuran keberhasilan adalah pendapatan, bukan penggunaan”, konteksnya berubah terlalu mendadak dari pembahasan alat open source ke bisnis open source, sampai rasanya seperti leher terpatahkan
    Saya sampai membaca ulang paragraf-paragraf awal karena merasa mungkin ada yang terlewat

• Dari sudut pandang engineer yang memengaruhi adopsi teknologi, open source menang karena dapat dipahami
  Jika saya dan rekan-rekan bisa melihat source code, kami bisa menilai apakah produk itu mampu melakukan fungsi yang diklaimnya
  Jika saat digunakan kami menemukan bug atau use case yang tidak terduga, setidaknya kami bisa menyelidiki solusinya lalu mengusulkannya dalam laporan bug, atau bahkan membuka PR

  • Ini jelas bernilai. Hampir setiap minggu saya membaca source code untuk melihat apa yang dilakukan sebuah dependensi
    Dengan begitu saya bisa membuat workaround cepat, dan biasanya juga bisa melaporkan bug

• Perusahaan tidak terlalu peduli pada kode itu sendiri. Kalaupun peduli, klausul kelangsungan bisnis dapat mengurangi sebagian besar kekhawatiran terhadap closed source
  Pada akhirnya, berapa banyak perusahaan finansial yang beralih dari Excel ke OpenOffice Calc?
  Strategi go-to-market AWS bergantung pada menarik startup dan developer individu dengan layanan pay-as-you-go berbiaya rendah, dan bagian ini sangat tepat sasaran. Sebab Airbnb, Stripe, Twitch, dan lainnya tumbuh menjadi perusahaan besar sambil tumbuh bersama AWS
  Tidak banyak yang bisa bersaing dengan biaya rendah atau gratis. Nanti bisa naik ke pasar kelas atas. Tanyakan saja pada ARM dan Intel
  Bagi startup developer tools, open source pada dasarnya sudah menjadi strategi go-to-market default. Seperti yang tepat disorot tulisan itu, meskipun ini bukan model bisnis
  Jadi, kecuali Anda seunggul Snowflake dan mampu berhadapan juga dengan kubu bebas dan open source seperti Databricks, model open core lebih baik

  • Itu benar untuk alat seperti Excel, tetapi untuk hal-hal seperti infrastruktur server, terutama perusahaan teknologi besar sangat enggan memasukkannya ke production tanpa akses source code
    Mereka jauh lebih suka jika bisa mengompilasinya sendiri
  • Saya belum pernah bergabung dengan startup tahap awal yang masih memedulikan biaya. Umumnya mereka lebih memedulikan waktu daripada biaya, dan menganggap membeli Amplitude, Segment, AWS, Heroku, dan sebagainya lebih cepat daripada alternatifnya. Entah penilaian itu benar atau tidak, begitulah adanya
    Jika Anda menjalankan Postgres sendiri di server fisik, investor mungkin tidak peduli, atau mereka akan mengajukan pertanyaan sulit tentang berapa banyak waktu yang sudah Anda buang. Saat itu Anda perlu jawaban yang cukup bagus atau investor yang bisa bersimpati

• Mengejutkan bahwa vendor lock-in tidak disebutkan. Itu adalah nilai jual open source yang jelas

  • Setuju. Ini juga bukan poin kecil. Dari sudut pandang pengambil keputusan, ini salah satu pertimbangan utama
    Tentu berbeda-beda menurut organisasi dan orangnya, dan banyak orang tidak peduli pada lock-in jika perusahaannya mereka percayai, tetapi angkanya jelas bukan nol
    Saat bekerja sebagai konsultan OpenShift di Red Hat, saya bertemu banyak eksekutif yang khawatir tentang vendor lock-in. Bagi mereka, memilih OpenShift adalah keputusan yang sudah jelas
  • Sebenarnya, saat membicarakan kemungkinan beralih ke self-hosting, tulisan itu memang menyiratkan tidak adanya vendor lock-in

• Ini hanya sedikit terkait dengan ranah penjualan software, tetapi dulu sekali saya pernah menjual pembaruan antarmuka pengguna untuk game dengan desain yang buruk
  Saya menetapkan harganya 2 kali lipat harga game itu sendiri, tetapi orang-orang tetap membelinya. Karena pembaruan itu dirancang secara profesional
  Sebagai desainer profesional, saya menyisihkan waktu kerja utama saya untuk melakukan sesuatu yang mungkin tidak bisa dilakukan developer tersebut
  Di komentar platform distribusi digital tempat saya menjualnya saat itu, keluhan paling jelas adalah pembaruan itu terlalu mahal, dan orang-orang tentu saja mengomentari positioning harganya
  Tetapi satu hal jelas: game itu sendiri terlalu murah
  Jika orang hanya mengeluh soal harga tetapi tetap membeli, berarti tidak ada hal lain yang bisa mereka keluhkan
  Burung selalu menginginkan makanan gratis. Jangan menyesuaikan diri dengan burung
  Sebagai tambahan, pembaruan itu juga dibajak dan cukup tersebar di kalangan pengguna bajakan. Saya justru senang karena sebagian besar pelanggan membayar
  Selain itu, jelas juga bahwa saya memenuhi sekumpulan fitur yang mereka inginkan dan tidak tersedia di tempat lain. Masalah seperti itu cukup bagus sebagai gejala bahwa Anda telah membuat sesuatu yang diinginkan orang

• Saya melihat banyak proyek open source menjadi open source karena kebutuhan, bukan karena pilihan
  Beberapa produk hanya punya sedikit peluang untuk diadopsi jika dibuat sebagai open source
  Penulis berfokus pada segelintir proyek open source elite, dan proyek-proyek itu tidak mewakili mayoritas proyek open source
  Beberapa perusahaan punya jaringan bisnis dan pemerintahan yang tepat, sehingga bisa dengan mudah menjual lisensi produk dengan harga mahal, tetapi jumlahnya sedikit
  Kebanyakan orang dan usaha kecil tidak memiliki jaringan seperti itu. Tanpa jaringan bisnis yang tepat, sulit menghasilkan uang meski sedikit
  Tidak peduli seberapa bagus produknya, atau seberapa besar produk itu bisa mengurangi biaya seseorang. Tidak ada yang percaya, dan tidak ada yang mau mencobanya. Sekalipun manfaat jangka panjangnya bisa sangat besar, hambatan adopsinya terlalu tinggi
  Membuat produk menjadi open source adalah satu-satunya cara untuk setidaknya bisa masuk. Karena itu memberi peluang yang sangat kecil agar produk terlihat, dan terkadang hanya itu yang ada