Şirketimi açık kaynağa dönüştürmeli miyim? (2022)
(supabase.com)- Supabase, kuruluşunun ilk günlerinden itibaren açık kaynak yaklaşımını seçti ve ürünü kamuya açık şekilde geliştirirken topluluk, işe alım ve ürün genişlemesinde beklenenden daha büyük faydalar elde etti
- Başlıca kaygılar kod kalitesinin eleştirilmesi, güvenlik açıklarının ortaya çıkması ve rakiplerin kopyalaması olsa da, açıklık aynı zamanda iyileştirmelere katılımı ve hızlı iterasyonu da teşvik edebilir
- İşe alımda depo katkıları, adayın gerçek kodunu ve iş birliği biçimini gösterir; Supabase, 32 geliştirici işe aldıktan sonra ancak outbound işe alıma başladı
- Azınlık kullanıcıların istediği özellikler, entegrasyonlar ve adaptörler topluluk tarafından doğrudan geliştirilebilir; bu da ürün kapsamını genişletir ve iç ekibin öncelik sınırlarını tamamlar
- Açık kaynak şirketlerinin savunma gücü kodu saklamaktan çok uygulama hızı, marka, ekip ve topluluğu uzun vadede inşa etmekten gelir
Supabase neden en başından açık kaynağı seçti?
- Supabase, ilk günden beri açık kaynaktı ve kurucuları PostgreSQL, Python, Bitcoin ve React gibi açık projelerin uzun süreli kullanıcıları ve destekçileri olduğu için bu, o dönemde zor bir karar gibi gelmedi
- İşi kamuya açık şekilde kurmanın ağır bir yük olacağı beklense de, ürün ve şirket büyürken beklenmedik birçok avantaj ortaya çıktı
- Bu deneyim geliştirici araçları veya bir PaaS şirketi bağlamından gelse de, anlatılanların çoğu genel olarak yazılım şirketleri için de geçerli olabilir
- Açık kaynağa geçişi engelleyen tekrar eden kaygılar temel olarak üç başlıkta toplanır
- İnsanlar dağınık veya tamamlanmamış kodu eleştirebilir
- Hacker'lar güvenlik açıklarını bulup suistimal edebilir
- Rakipler fikri mülkiyeti çalabilir
“Kodum kötü” kaygısı
- Kötü kodla ilgili endişe çoğu zaman daha çok ego meselesidir; biri onu incelemeye vakit ayırıyorsa, muhtemelen içinde peşinden gitmeye değer bir şey bulmuştur
- Stone Soup hikâyesindeki gibi, iyi bir fikri toplulukla paylaşırsanız başkaları bunu sahiplenip birlikte geliştirebilir
- Topluluk kötü kodu refactor edebilir veya değiştirebilir; yeni kod kalite yönergeleri getirerek sonraki katkı süreçlerini de iyileştirebilir
- Yalnızca koddan şikâyet edip iyileştirme önermeyen toksik üyeler, zaten baştan istenen topluluk üyeleri değildir
- Açık kaynak katkıcılarının eski projelerden oluşan birer “mezarlığı” vardır ve bunlar benzer şeyler yapmak isteyenler için bir fikir ve yaklaşım kütüphanesi işlevi görür
- Birileri belirli bir problemi çözme biçiminden ilham alabilir
- En azından aynı hataları tekrarlamak için harcanan zamanı azaltabilir
- Eski bir projenin itibarı zedeleme ihtimalinden çok, faydalı şekilde kullanılması ya da hiç dikkat çekmemesi daha olasıdır
Açık kod ve güvenlik
- Açık kodla barındırılan bir çözüm işletirken en büyük korku, kötü niyetli aktörlerin kodu okuyup zafiyet bularak hizmeti hacklemesidir
- Supabase deneyimine göre Linus's law içindeki “yeterince çok göz varsa tüm hatalar sığdır” sözü güvenlik sorunları için de geçerlidir
- Başlangıçtan itibaren çoğu zaman anonim olan güvenlik araştırmacıları, kodu ve platformu inceleyerek olası sorunları bulmaya yardımcı olur
- Bir SaaS sunuyorsanız
/.well-known/security.txtiçinde kısa bir yönlendirme sunmalı, böylece iyi niyetli araştırmacılar olası sorunları nasıl açıklamaları gerektiğini bilmelidir - Açık projelerin kapalı kod tabanlarından daha güvenli olabileceğine örnek olarak Bitcoin verilir
- Andreas M. Antonopoulos, 2015 tarihli konuşmasında kapalı bankacılık sistemlerinin yazılımsal olarak zayıf bir bağışıklık sistemine sahip olduğunu söyler
- Kapalı sistemlerde büyük güvenlik açıkları uzun süre gizli kalabilir ve sonunda suistimal edildiğinde büyük hasara yol açabilir
- Bitcoin gibi açık kaynak protokollerde ise güvenlik açıkları herkes tarafından görülebilir, exploit'ler erken ve sık bulunur, ardından yamalanır
- Başarılı yazılım şirketleri 10 yıldan uzun sürede inşa edilebilir; bu yüzden uzun vadede açık kaynak sistemler, gizli tutulan kapalı sistemlerden daha güvenli bir duruma yaklaşabilir
- Güçlü güvenlik mühendislerini işe alma rekabetinin çok sert olduğu dönemlerde kamuya açık incelemenin değeri daha da artar
Rakipler ve fikri mülkiyet kaygısı
- Yazılımda fikirler ucuzdur; değer neredeyse her zaman fikrin uygulanmasından doğar
- Fikirlerinizi dünyayla paylaştığınızda, kimin kod tabanına erişeceği konusunda kaygılanmak yerine daha hızlı iterasyona odaklanabilirsiniz
-
Uzman bir topluluk oluşturmak
- Başarılı bir şirket kurmak için uzun bir süre boyunca, örneğin 10 yıl, iyi icra etmeli ve müşteri tabanını büyütmelisiniz
- Bu uzun maratonda rakiplerin kod tabanını inceleyerek elde edeceği avantaj, 10 yılın tamamına bakıldığında muhtemelen büyük olmayacaktır
- Bu süre boyunca kod tabanı birçok kez yinelenmiş ve refactor edilmiş olacaktır
- Uzun vadede kazanmanın yolu, kendi çözümünü dünyadaki en iyi şekilde yineleyip geliştiren ekip ve topluluğu kurmaktır
-
Pazarda kazanmak
- Büyük ve büyüyen bir toplam adreslenebilir pazarın (TAM) gerçekten peşinden gitmeye değerse, bunun winner-takes-all bir durum olma ihtimali düşüktür
- Önce etkileyebileceğiniz bir kullanıcı segmenti bulup hızlı iterasyon yapmalısınız
- Rakiplere odaklanmak için harcanan zaman, ürünü veya ekibi geliştirmeye ayrılabilecek zamandır
- Bir rakip açık kaynak projenizi fork edip daha hızlı piyasaya çıkabiliyorsa, o rekabette zaten baştan kaybetmeye mahkûmdunuz
- Yazılımda IP ve patentlerin uygulanmasının zor olduğu iyi bilinir; bu nedenle avukatlarla yazılım fikirlerini koruma kaygısını azaltmak zaman, para ve zihinsel enerji tasarrufu sağlar
- İş, yazılım fikrini dünyada en iyi uygulayan yapı olarak çok daha iyi korunabilir
-
Geç aşamadaki bulut rekabeti
- Proje belirli bir ölçeğe ulaştığında Elastic veya Mongo örneğinde olduğu gibi, büyük bulut sağlayıcılarının ürünü daha güçlü dağıtım modelleriyle sunduğu bir durumla karşılaşabilirsiniz
- Yeni başlayan bir şirket için en büyük sorun önce o noktaya ulaşmaktır
- AWS, milyarlarca dolarlık ürün ailesinden kaynak ayırıp sizinle barındırılan bir ürün üzerinden rekabet edecek kadar ilgileniyorsa, zaten çok iyi gidiyorsunuz demektir
- Daha yapıcı yaklaşım, kiminle rekabet ederseniz edin önde olabileceğiniz alanı önceden bulmaktır
- Birçok bulut sağlayıcısında geliştirici deneyimi (DX) zayıftır; bu nedenle DX'i temel yetkinliğiniz hâline getirebilirsiniz
- 6 yıl sonra Google öğle yemeğinizi elinizden almaya çalışacaksa, o zamana kadarki yıllarda marka, ekip ve topluluk David ile Goliath tarzı bir mücadeleye hazırlanıyor olmalıdır
- Böyle bir duruma hazırlıksız yakalanmamak için en baştan plan yapmalı, zaman ve odağınızı kazanma stratejisi oluşturmaya kullanmalısınız
- Rakipler fikir aramak için geldiklerinde her zaman bir adım geridedir; özellikle erken aşamada kaynaklar kıtken, rakip kaygısı enerjinizin daha fazlasını tüketir
Geliştirici işe alımında etkisi
- Girişimlerin ölçekten bağımsız olarak yaşadığı büyük sorunlardan biri geliştirici işe alımının zorluğudur
- Aday bulmak zordur
- Geliştiricileri değerlendirmek zordur
- Gelecekteki ekip arkadaşlarının seviyesine adayları ikna etmek zordur
- Açık kaynak, geliştirici işe alımı sorununu azaltmaya yardımcı olabilir
-
Kamuya açık aday bulma
- Tüm geliştiriciler açık kaynaktan faydalanır ve birçok geliştirici de bu faydayı ilginç açık kaynak projelere katkı yaparak geri vermek ister
- Katkı nedenleri iyi bir topluluk, yeni teknoloji öğrenme veya yabancı bir kod tabanında zor teknik problemleri çözmenin keyfi olabilir
- Açık kaynak projesinde koda katkı eşiğini düşürürseniz, harika geliştiricilerin projeyi bulma ihtimali artar
- Katkıcılar issue tartışmalarına, bug düzeltmelerine, problem tespitine ve PR incelemelerine katılabilir
- Her katkıcı iş aramıyor olsa da, birçok kişi açık kaynak kod üzerinde tam zamanlı çalışma ihtimaliyle ilgilenebilir
- Supabase, 2 yılı aşkın süre faaliyet gösterip 32 geliştirici işe aldıktan sonra ancak outbound işe alıma başladı
- Açık kaynak, Supabase için başlıca yetenek keşif kanalı oldu ve olmaya da devam edecek
- Remote ve asenkron şirketlerde açık kaynak işe alım stratejisi, adayın yetkinliğini kendi kendine görünür kılar ve bunu doğrulamayı kolaylaştırır
-
LeetCode ve ödev tarzı testler yerine gerçek katkılar
- Geliştiricilerin yeni iş ararken en çok şikâyet ettiği şeylerden biri, mülakat sürecinde LeetCode soruları çözmek veya ödev tarzı testler yapmak zorunda kalmalarıdır
- Bu yöntemler çok zaman alır, yorucudur ve çoğu zaman gerçek işte yapılacakları temsil etmez
- Birisi depoya katkı yaptığında zaten şu materyaller ortaya çıkar
- Remote ve asenkron ortamda ekip ve topluluk üyeleriyle nasıl iletişim kurduğuna dair örnekler
- Gerçek kod katkısı örnekleri
- Aday da şirketi değerlendirebilir
- Ekibin kod kalitesine önem verip vermediğini görebilir
- Etkili iletişim kurulup kurulmadığını anlayabilir
- İyi teknik kararlar alınıp alınmadığını değerlendirebilir
- Supabase deposu üzerinden işe alınan kişiler kendilerini vazgeçilmez hâle getirdi; mevcut depo geliştirmelerini yöneten ya da yeni client library ve SDK'ler başlatanlar oldu
- Bu kişilerin Zoom'da LeetCode sorusu çözmesi gerekmedi
Azınlık kullanıcı özellikleri ve entegrasyonların genişlemesi
- Bir startup kurarken çoğu zaman yalnızca en büyük problemleri çözmeye vakit vardır
- Hızlı hareket etmek için kullanıcı tabanının %80'inin talep ettiği şeylere odaklanmak gerekir {p:80}
- Azınlık kullanıcıların istediği özellikler sonsuza kadar ertelenmeye yatkındır
- Sistem açık kaynaksa bu kullanıcılar özelliğe doğrudan kendileri katkıda bulunabilir ve yazılımın faydası artar
- Bu etki özellikle entegrasyonlar ve adaptörlerde sık görülür
- Kullanıcılar Azure veya Vercel entegrasyonu isteyebilir
- Başka biri bu bağlantıyı kuracak geliştirme kaynağını sağlarsa, projenin tüm kullanıcıları bundan fayda görür
Aynı tekerleği tekrar tekrar icat etmemek
- Açık kaynağın olmadığı bir dünyada teknoloji şirketleri aynı tekerleği yeniden icat etmeye devam eder
- Supabase yalnızca yeni projeleri açık kaynak olarak yayımlamakla kalmaz, yeni bir şey geliştirmeden önce mevcut açık kaynak projeleri desteklemeye de çalışır
- Otomobil şirketlerinin kapalı işlevler, kapalı UI öğeleri, kapalı pencereleme kütüphaneleri, kapalı işletim sistemleri ve kapalı sürücüler kullanıp neredeyse hiç göremeyeceğiniz hata mesajları göstermesi, geliştirici zamanı ve emeğinin israfıdır
- Supabase Launch Week, ekibin ve topluluğun son 3 ayda üzerinde çalıştığı şeylerin bir toplamıdır; açık kaynak bir şirket işletmenin avantajı, topluluğun ilerleme hızında görülür
- Ayrıntılar için Launch Week 4 post incelenebilir; katkı vermek için Supabase GitHub ziyaret edilebilir
1 yorum
Hacker News görüşleri
Burada sürdürülebilir kârlılık hakkında büyük bir varsayım gizli ve özellikle ABD’deki geliştirici maaşları gibi gerçekler düşünüldüğünde, pratikte hissedilenle uyuşmayan yanları var.
Özetle, bir açık kaynak şirketine yıldırımın iki kez düşmesi gerekir: bir kez açık kaynak projesine, bir kez de şirkete.
Graphistry ekibi her gün açık kaynağı seviyor ve onunla çalışıyor; Apache Arrow ve Nvidia RAPIDS’e uzanan projelerin başlangıcına yardımcı oldu ve Python/JS istemcilerini de açık kaynak olarak yayımladı. PyGraphistry[AI], grafikler için İsviçre çakısı gibi bir araç; ayrıca GFQL gibi Cypher grafik sorgu dilini gömülebilir, veri çerçevesi yerel ve GPU hızlandırmalı biçimde uygulayan araçlar da içeriyor.
Ancak sürdürülebilir büyüme ağırlıklı olarak şirketlere, kamu kurumlarına ve veri şirketlerine GPU grafik görselleştirme sunucusunun bulut/on-prem kendi kendine barındırma lisanslarını satmaktan geliyor. Birkaç yıl dayandıktan sonra neyse ki bu iş iyi büyüyor; yalnızca SaaS barındırma geliri küçük bir ekibi ayakta tutabiliyor ama ekibin çoğunu karşılamaya yetmiyor. Kendi kendine barındırma lisans gelirleri olmasa inovasyon döngülerinin çoğu ortadan kalkardı.
Bu yazı, piyango kazanmak gibi şansın, SaaS pazarının özelliklerinin ve teknik savunulabilirliğin kesişimini kaçırıyor gibi hissettiriyor. Louie.AI ve GFQL’in çıkışı bizim örneğimizde açık kaynağın iş potansiyelini değiştiriyor; yani imkânsız demek değil. Ama buraya kadar gelme deneyimimize bakınca, bu yazıyı okuyan yeni kurucular için endişeleniyorum.
[1] https://graphviz.org/
Yani asıl mesele, “artık kaynağı açıyoruz” dediğinizde “güzel, o zaman sözleşmeyi iptal ediyoruz” diyecek müşteriler olup olmadıkları.
“Açık kaynak iş modelini diğer kurucularla konuştuğumda tekrar tekrar ortaya çıkan üç endişe var: dağınık, kötü ya da tamamlanmamış kod nedeniyle eleştirilmek; hacker’ların güvenlik açıkları bulup bunları kötüye kullanması; rakiplerin fikrî mülkiyeti çalması” denmiş; bence dördüncü bir madde eksik.
Amazon/AWS benim kodumun üzerine bir hizmet ticarileştirip satabilir ve hiçbir şey ödemeyebilir.
Kullanıcılarla ve geri bildirim verenlerle iletişimde nazik davranırım ama içimden “konuşması kolay. Ben gerçekten yaptım. Ya sus ya da PR gönder” diye düşünürüm. Şaşırtıcı olmayacak şekilde, bu insanlar neredeyse hiçbir zaman PR göndermez.
Gerçekten bir şeyler üretmeye devam etmek ve laf edenleri silkeleyip atmak yeterli.
[0] - https://heywillow.io/
Büyük şirketler sizi taklit etmeye çalışıyorsa zaten kazanıyorsunuz demektir; bunu azaltmak için de önceden bir plan gerekir. Ancak yazıyı doğru yorumladıysam, başlangıç aşamasında odaklanılması ya da endişe edilmesi gereken bir konu olmadığı söyleniyor.
Bulut şirketlerinin başka açık kaynak ürünleri yutmasının nedeni, o ürünlerin kendi çalışmalarını düzgün koruyan lisansları seçememiş olmaları.
Gerçekten derinlikli ve iyi bir yazı, ama birçok projenin kaçırdığı bir şey var: sivil kamu sektörüne satış yapabilirsiniz.
ABD hükümetinde NSF hibeleri gibi birçok teknoloji programı var; sivil kurumlar, istihbarat kurumları ve eyalet yönetimleri birbirinden kopuk olduğundan sonuçta inanılmaz geniş bir yazılım tedarik zemini ortaya çıkıyor. Regülasyon ve uyum giriş engelleri sanıldığı kadar yüksek değil; özellikle ilk birkaç işi iş ortaklarıyla birlikte alırsanız. Genellikle 3-5 yıllık taahhütlerle projeleri finanse edebilen istikrarlı ve garanti gelir sağlar, kârlılığı da son derece yüksektir.
Daha fazla açık kaynak şirketinin bundan yararlanmasını isterdim. Çünkü tamamen özel şirketler çoğu zaman açık kaynak kütüphaneleri kendi ürünlerine koyup devasa marjlar ekleyerek satıyor ve tüm değeri kendileri alıyor.
Örnek: https://x.com/ssankar/status/1749202248700420587?s=20
Kamudayken, fiilen açık kaynak harita + açık kaynak DB birleşimi olmasına rağmen 12 milyon dolarlık yazılımlar gördüm. Başka ölçütlerle, PDF OCR’a yılda 2 milyon dolar, weights & biases benzeri araçlara yılda 30 milyon dolar ödendiğini de gördüm.
Yazılım dağıtımı dışında da teşvikler var. Örneğin belirli bir hatayı veya güvenlik kusurunu öncelikli olarak düzeltmek. İstihbarat kurumları safetensors’a büyük para ödemiş olabilir.
Supabase’in izleyebileceği dört yol şunlar: Cybercom’a doğrudan satış, DOS’a doğrudan veya ekip sözleşmesiyle satış, VA’ya PWS üzerinden satış, büyük kamu sözleşmeli yazılım şirketlerine doğrudan satış.
Bunu uygulamanın yolu, GS 14/15 ya da muadili kişilere cold email göndermek, eski bir GS15’i işe almak veya SAM.gov’da uygun ihaleleri bulup teklifleri GovPro.ai ile tam hizmet olarak ya da rogue ile kendin hallet yöntemiyle hazırlamaktır.
Kamu bürokrasisi sözleşmeyi nihai olarak onaylayana kadar, çoğu startup’ın parası çoktan tükenmiş olabilir.
Sözleşmeler kârlı olabilir, ama bürokratik süreç muazzamdır ve bununla uğraşmış deneyimli birine ihtiyaç vardır. Herkese uygun bir yol değil; çok zaman ve pazarlık da gerektirir.
Devasa bürokrasi bir yana, federal hükümet en büyük, en yavaş ve en zor yönetilen kamu örgütüdür. Sadece ABD içinde okullar, şehirler, county’ler, eyaletler, su ve itfaiye bölgeleri, kütüphaneler gibi on binlerce başka kamu tüzel kişiliği var.
Kamu sektörüne girmek istiyorsanız, en büyük yere tüm gücünüzle yüklenmek yerine küçük ve geniş yaklaşmak daha iyi olur.
Dünyanın en kârlı kamu sektörü ABD Savunma Bakanlığıdır.
Ama Savunma Bakanlığı inanılmaz derecede bürokratik, takvime duyarlı ve gizliliğe takıntılıdır.
Supabase’in iş modeli kendini açık kaynak şirketi olarak pazarlamak; ama gerçekte aklı başında hiç kimse bunu production için kendi barındırmaya çalışmaz.
Bunun nedeni ince ince eksik bırakılmış dokümantasyon, belli belirsiz bug’lar, kritik ama ufak görünen eksik özellikler gibi şeyler. Bu yüzden açık kaynak övgüsünü alıyor ama pratikte kullanışlı değil; bence sadece bir pazarlama aracı.
Birincisi iç rahatlığı. Şu anda kendiniz barındırmıyor olsanız bile hizmetten memnun kalmadığınızda çıkış için bir yol daha oluşur. Elbette ham veriye erişim de sunulmalı.
İkincisi kod kalitesi. Dışarıdan iyi çalışıyor gibi görünen ama gerçekten berbat kodlarla uğraştıysanız, herkese açıldığında utanılmayacak koda sahip olmanın ne kadar önemli olduğunu bilirsiniz.
Üçüncüsü katkı imkânı. Eskiden bunu çok önemli görmezdim, ama pratikte birkaç kez yaşayınca; eksik özellik, bug, performans sorunu gibi durumlarda talepte bulunabilmek ya da doğrudan katkı verebilmek büyük bir şey. Çoğu kapalı kaynak projede özellik isteğini şeffaf biçimde iletebileceğiniz bir kanalın olması bile şans sayılır.
Belirli bir eşiğin ötesinde insanlar fork’a emek harcamaya karar verebilir. MariaDB buna bir örnek.
Şirketimizin yönetilen hizmetini kullanma nedenleri arasında tam da bu yüzden içlerinin rahat olduğunu doğrudan söyleyen insanlar da oldu.
Meşru ve gerçek bir açık kaynak şirketi olmak çok daha kolay görünüyor.
Kastınız bu değilse ve ben yanlış okuduysam, yazının geri kalanı Supabase’i aksine oldukça olumlu gösteriyor.
Ticari olarak mümkün olmayabilir, ama mevcut durum açık kaynak yazılımdan beklenebilecek standartları ciddi biçimde aşındırıyor ve bu yolu seçen şirketlere de belirgin bir uzun vadeli fayda sağlamıyor gibi görünüyor.
Geliştirici kendisi çalıştırmasa bile, gerçekten çalışan kodu görebilmesini sağlar.
Supabase’i de seviyorum, ticari açık kaynağı genel olarak da seviyorum ve yazının büyük kısmına katılıyorum.
Ama “yazılımda fikirler ucuzdur. Değer neredeyse her zaman fikrin uygulanmasında oluşur” kısmı bana tuhaf geliyor.
Bu ifadeyi daha çok “Harika bir startup fikrim var, anlatmadan önce NDA imzalar mısın?” gibi durumlarda duymuştum.
Oysa yazılımı açık kaynak olarak yayımlıyorsanız yalnızca fikri vermiş olmuyorsunuz; o fikrin kayda değer uygulama sonucunu da veriyorsunuz.
Elbette kod uygulamanın tamamı değil; satış, pazarlama, destek vb. ile genişler. Yine de bu yazı kodun değerini fazla hafife alıyor ve satış/pazarlama yoksa değersiz olduğunu ima ediyor; bence bu doğru değil.
Değeri paylaştıracak olsam satış/pazarlama/müşteri doğrulaması %90, kod %10 derdim. Yedi haneli düşük ciroya sahip bootstrapped bir SaaS işletiyorum; kodun çoğunlukla dağınık olduğunu ve sürekli evrildiğini söyleyebilirim.
Bir evi ücretsiz kopyalayamazsınız, ama yazılımda bu mümkündür.
Geliştiricilerin para aldığı şey kodu oluşturma süreci ve görünmeyen ufak tefek sorunları çözmektir.
Yazılım satmanın bu kadar kârlı olmasının nedeni de bu. Yazılımı satmazsanız ondan para kazanamazsınız. Yazılım, paylaştığımız gerçekliğin fiziksel nesneleri gibi değildir.
Bana göre temel soru kodun yeterince iyi olup olmadığı ya da rakiplerin kopyalayıp kopyalamayacağı değil; sürdürülebilir bir iş kuracak kadar para kazanıp kazanamayacağınız.
Alıntılanan ve sevilen açık kaynak projeleri iyi birer iş değildir: PostgreSQL, Python, Bitcoin, React.
Mongo ve Elastic harika ama istisna. Başarılı kapalı kaynak veritabanı şirketleri, açık kaynak veritabanı şirketlerinden daha fazla.
Açık kaynak şirketi olmak zor. Ama kullanıcılar için çok değerli.
Hangi lisansın “açık kaynak” olduğu tartışmasını bir kenara bırakırsak, önemli olan bu şirketlerin yaygın kullanılan (A)GPL, Apache, MIT gibi lisansların rakiplere yönetilen/barındırılan hizmetler kurup ölçekle rekabet etmesi için çok alan bıraktığına karar vermiş olmasıdır. Örneğin Amazon’un OpenSearch ile ElasticSearch’ü daha ucuza sunması gibi.
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
Bu soru “Şirketimiz yazılımının kaynak kodunu açmalı mı?” anlamında kullanılmış gibi görünüyor.
Ama benim için asıl soruya cevap vermek, yeniden yazılmış soruya cevap vermenin yolunu da sunuyor. Asıl soru şirketin sattığı yazılımla değil, kullandığı yazılımın niteliğiyle ilgili.
Kişisel olarak alternatif varsa her zaman açık kaynak ürünü seçerim. Destek ücreti ödemeye ya da projeye bağış yapmaya razı olsam bile. Kaynak kodunu özgürce görebilme erişimi, asla değiştirmeyi düşünmediğim yazılımlarda bile temelde önemlidir.
Bunun pek çok kişiye aşırı bir tutum gibi göründüğünü biliyorum. Ama mikrodalga fırını, kapı kolunu, şanzımanı sökememe fikrinden hoşlanmıyorum. Yeniden düzgün takamayabilirim, ama dişi kırılmış bir dişliyi bulup 90 dolarlık değişim yerine 2 dolarlık onarım yapabilirim. Ya da şanzımanlı bir Frankenstein mikrodalga fırın yapabilirim.
Bir web sunucusunun işlevlerini genişletmek ya da eklentimin ana uygulamayı neden çökerttiğini anlamak benim için önemli. Toplum için de önemli olduğunu düşünüyorum. Bu yüzden açık kaynak aşırıcılığıma tutunuyorum. Dahili yapay zeka ile 5 KB içinde HTTPS/4 işleyen en yeni mini web sunucusunu gösterseniz ilgimi çeker, ama açık kaynak değilse mevcut stack’i kullanmaya devam ederim.
Bu zihniyet yüzünden yaptığım yazılımlar açık kaynak oluyor ve bazen insanlar bunun için ödeme yapıyor.
“6 yıl sonra Google öğle yemeğini çalmaya kalkarsa, son birkaç yıldır Davut ile Golyat mücadelesine hazırlanan bir markanız, ekibiniz ve topluluğunuz olmalı” kısmına gelirsek, benim deneyimime göre satın alma sorumluları için marka, topluluk, ekip ve geliştirici deneyimi gibi şeyler uyumluluk karşısında neredeyse hiç anlam ifade etmiyor
Google gibi yerleşik bir tedarikçiyle doğrudan karşı karşıya geliyorsanız bu özellikle böyle
Supabase özelinde, son birkaç yıldır bu tür gereksinimleri karşılamak için SOC2, HIPAA, GDPR gibi uyumluluk hazırlıkları yaptığımızdan isabetli bir tespit
Bizim ürünümüz de bu konuyu düşünüp duruyor. Bir gün tamamını o an içimize sinen lisansa göre MIT ya da Apache ile açık kaynak hâline getireceğiz; bunu sitede de açıkça belirttik. AGPL ya da açık çekirdek gibi bir yaklaşım değil
Ama böyle bir yapıyla üründen para kazanmanın tamamen imkânsız olduğunu hissettim; önceki deneyimlerimde de böyleydi. Danışmanlık mümkün olabilir ama ürün farklı. Supabase çok büyük miktarda risk sermayesi yatırımı aldı ve neredeyse tüm “büyük” açık kaynak projeleri için de durum aynı
Bootstrapped ilerliyorsanız, özellikle iddialı ve zor bir projede bir süre fatura kesemezsiniz. İnsanların ücretsiz çalışabileceği süre sınırlıdır; kapalı koddaki küçük bir ekip sürekli yakın iletişimde kalarak başarılı bir açık kaynak projesi için gereken ek yükü azaltır ve çok daha hızlı hareket edebilir
Benzer ölçekte olup 0 dolar yatırım almış, son 5 yıl içinde başlamış, 2 veya daha fazla tam zamanlı ekip üyesi bulunan, 3 yıldan uzun süredir devam eden ve hâlâ bu yaklaşımı öneren proje örnekleri duymak isterim. Geçimlerini nasıl sağladıklarını merak ediyorum. Redis gibi şeylerin artık yaşanmadığını düşünüyorum. En azından ben görmedim. langchain gibi basit bir proje bile onlarca milyon dolar risk sermayesi alıyor; oysa tam da böyle bir projenin birkaç kişilik bir ekibin birden fazla gelir kaynağıyla para kazanarak deneyebileceği bir aday olduğunu düşünmüştüm
Benim yazılımlarımın tamamı public domain, yani özgür yazılım olarak yayımlanıyor; ama içlerinden hiçbiri başarılı bir açık kaynak projesi ya da topluluğu olmadı. Özgür yazılım her şeyden önce bir ideoloji, ardından bir pratik ya da özellik
Şirketi açık kaynak hâline getirmek, geliştiricileri hedeflemiyorsanız ya da gerçekçi olarak kimsenin kendi barındırmayacağı bir ürün yapmıyorsanız bence mantıklı değil
Supabase bu ikisinin de tipik örneği. İkincisine örnek olarak Plausible Analytics verilebilir; kendi sunucunuzda barındırabilirsiniz. Ben de Coolify.io ile öyle yapıyorum. Ama sürümlerden güncellemeleri alıp birleştirecek kendi CI/CD sisteminizi kurmazsanız güncellemeleri kaçırırsınız