- WiX Toolset projesi, uzun vadeli sürdürülebilirliği güvence altına almak için Open Source Maintenance Fee (açık kaynak bakım ücreti) politikasını devreye aldı
- Kaynak kodu lisans kapsamında ücretsiz sunulsa da, issue açma, görüş yazma, yeni sürümleri indirme gibi çoğu işlem bakım ücreti politikasına tabi
- Özellikle bu projeyi kullanarak gelir elde eden durumlarda, ilgili bakım ücretinin ödenmesi zorunlu
- Ücret ödemesi, GitHub Sponsor olunarak desteklenebiliyor
- Küçük ölçekli organizasyonlar (20 kişiden az): $10/ay
- Orta ölçekli organizasyonlar (20-100 kişi): $40/ay
- Büyük ölçekli organizasyonlar (100 kişiden fazla): $60/ay
- Politikanın ayrıntıları Open Source Maintenance Fee resmi sitesinde görülebilir
2 yorum
Fiilen RHEL ile aynı.
Hacker News görüşleri
Bu yeniliği beğendim. Temel fikir şu: kimse bunun kapalı kaynak olmasını istemiyor, kod herkes için serbestçe açık ve herkes özgürce kullanabiliyor. Çünkü kodu dağıtmanın ek maliyeti fiilen sıfır. Ama bakımcılar bunu şirketlere bir hayır işi gibi ücretsiz sunmak istemiyor. Zamanları sınırlı olduğu için, gelir üreten faaliyetlere katkı sağlıyorlarsa bundan bir miktar gelir istemeleri doğal. Bu yöntemin kusursuz biçimde zorunlu kılınmaması da sorun değil. Artık bakımcılar taleplere “Bununla ilgilenmemizi istiyorsanız ücret ödeyin” diye cevap verme özgürlüğüne sahip. Ücret ödeyen şirketler belli bir düzeyde destek alır, genel kullanıcılar ise aynı deneyimi yaşamaya devam eder. Sadece bu uyarıyı görmezden gelen şirketler sonuçlarına katlanır ve özellikle “çok sayıda önemli kullanıcı etkileniyor” gibi çağrılar yapıldığında etkili olur. Gerçekten gerekiyorsa ödeme yapmak gerekir. Yapay zekanın ürettiği kodun, raporların vb. arttığı bugünlerde, açık kaynakta sık görülen bir soruna oldukça temiz bir çözüm olduğunu düşünüyorum
Bu konuda duygularım karışık. Wix kullanıcısı değilim; bu olayın kendisine dair genel bir görüş bu. Açık kaynak projeleri kimse zorla sürdüremez. Tüm düzeltmeler gönüllülük esasına dayanır. Hiçbir şirket bir PR’ı kabul etmeye ya da üzerinde çalışmaya zorlayamaz. FOSS geliştiricileri sık sık stres yaşasa da, maddi motivasyon yoksa sadece reddetmeleri gayet normal. Şikayet olabilir ama bir sorunu mutlaka düzeltmek gibi bir yükümlülük yok. Sponsor modeli sonuçta FOSS’u bir iş modeline dönüştürüyor gibi hissettiriyor. O zaman da artık FOSS olmaktan çıkıyor. FOSS’un özü, herkesin kopyalayabilmesi, değiştirebilmesi ve bunu bir işe dönüştürebilmesidir. Çoğu lisansla zaten buna baştan razı olunmuş oluyor. Görüşüm popüler olmayabilir ama bu konuda öfke patlaması yaşanmasına gerek olmadığını düşünüyorum
Bu politika hakkında iki açıdan olumsuzluk söylemek istiyorum. Birincisi, daha fazla katkıcı toplamak zorlaşabilir. Ücretli katkıcılar ve ücretsiz katkıcılar şeklinde iki katmanlı bir yapı oluşabilir. “Ben ücretsiz bug fix yapıyorum ama başkaları para kazanıyor” gibi rahatsızlıklar çıkabilir. İkincisi, para alınmaya başladığı anda ilişki daha çok bir ticari işleme dönüşür. Para alındıysa ona karşılık beklentiler ve işler de oluşur. Elbette gönüllü modelin de sürdürülebilirlik sorunları var
Bunu o kadar da yenilikçi bulmuyorum. Ürünü ücretsiz verip şimdi ücretli satılan bir düzene geçilmiş. Yani sıradan bir işletme gibi yürütülüyor gibi geliyor
Bence isteyen herkes istediği özellik ya da destek için para ödeyebilmeli ve kod da belli bir eşiğe kadar kapalı kaynak kalmalı. Bu eşik, ilgi düzeyine ve gelire göre birkaç ay ya da birkaç yıl sürebilir. Sonunda yine açık kaynak olur. Aksi halde herkes başkasının parayı ödemesini bekler. Tabii çok fazla fork oluşmaması için yapıyı iyi kurmak gerekir ama gayet mümkün bir yöntem
Zaten birçok açık kaynak projesinin bunu yaptığını sanıyordum. Busybox bakımını yapan danışman örneğinin buna girdiğini düşünmüştüm ama durumu yanlış anlamış olabilirim
Bunun Wix adlı website builder ile hiç ilgisi yok; burada söz konusu olan WiX Toolset
“En güçlü Windows kurulum deneyimini oluşturan araç takımı. 2004’ten beri açık kaynak!” şeklinde tanıtılıyor
Teşekkürler. İlk başta bunu Wix sandım. Wix gerçekten çok kaliteli React Native kütüphaneleri yapıyor
Birkaç ay önce açık kaynak projem için bir installer incelerken bu politikayı tesadüfen öğrendim. Kaynak kod OSI lisansı altındaysa binary satılmasıyla ilgili bir sorunum yok. Ama README’deki şu ifade beni rahatsız etti: "Bu projenin uzun vadeli sürdürülebilirliği için, WiX Toolset kullanımında açık kaynak bakım ücreti gerekir. Kaynak kod lisans kapsamında serbestçe sunulur, ancak issue açma/yorum yapma, tartışmalara katılma, release indirme gibi diğer tüm işlevler de bakım ücretine tabidir. Yani gelir amaçlı kullanımda bakım ücreti gerekir." Bunun kısa bir cümleyle açıklanması zor bir kavram olduğunu düşündüğüm için iyi niyetle yorumlayabilirim. Ama “ticari kullanımda para öde” özeti daha çok yanlış anlamaya yol açabilir. MS-RL lisansı altında kendin derleyip kullanırsan ticari amaçta bile bir kısıtlama yok; bu yüzden bunu, ticari kullanıcıları sponsora dönüştürmek için bir tür “göz korkutma” yöntemi gibi görüyorum. Açık kaynak bakımcılarının yaşadığı zorlukları anlıyorum ama bu yaklaşım bana etik olarak doğru gelmedi. Bu yüzden ticari kullanıcı olmamama rağmen WiX kullanmaktan vazgeçtim
Bu, ticari kullanıcılara ücretsiz destek vermeyeceklerinin açık bir ifadesi. Açıklamanın net olmadığını söyledin ama alıntıladığın cümlede “kaynak lisans kapsamında serbestçe kullanılabilir” deniyor
Startup’lar ya da bütçesi kısıtlı küçük şirketler açık kaynak projeyi alıp kendileri derler, dağıtım artifact’ı haline getirir ve kendi başlarına yönetir. Belli bir ölçeğe geldiklerinde, tüm bu süreci yöneten resmi desteğe para vermek daha değerli hale gelir. Bu politika da şirketler, sadece açık kaynak binary indirip kullanmanın doğrudan destek riskini almak istemediğinde, onları resmi destek için ödeme yapmaya yönlendirmeyi amaçlıyor
Bu fikri tek cümleyle kısa biçimde anlatmak gerçekten zor. Çünkü açık kaynak projelerine dair beklentiler çok farklı. Metni nasıl iyileştirebileceğimize dair önerin varsa duymak isterim
Bana göre mesele şu: gelir üreten bir kuruluş adına bir talepte bulunuyorsan, konuşabilmek için ücret ödemen gerekiyor. Gelir elde etme amacıyla iletişim kuruyorsan ücretli bir yapı var
GitHub issue yorumlarını okuyunca ekibin oldukça makul olduğunu düşündüm. Benim anladığım kadarıyla, sadece gerçekten gelir elde edilen durumlarda para istiyorlar. Gerçekten tek başına çalışan bir solo geliştiriciysen ya da çok erken aşamadaki bir ürünse muhtemelen pek umursamazlar. Bir sponsorluk sayfaları da var
Bu, https://opensourcemaintenancefee.org/ sitesinin kendisiyle ilgili. Sadece dark mode’da düzgün görünüyor, light mode’da neredeyse okunmuyor. Repoda issue açmak da mümkün değil. Belki yazarı burada yorumları görür (düşük ihtimal)
Demek issue açmak için bakım ücreti ödemek gerekiyormuş! Şaka yapıyorum
Aa, ciddi bir sorunmuş. Şimdi rastgele bir katkıcı sayesinde düzeltilmiş!
Benim şirketimin hukuk ekibi böyle bir EULA’yı görse, bize ödeme yapın demek yerine bu aracı kullanmayı hemen bırakmamızı söylerdi. Çoğu şirketin de böyle tepki vereceğini düşünüyorum. Belki bakımcı açısından bu kabul edilebilir olabilir ama ben hep şunu savundum: ticari kullanımı bu şekilde sınırlayarak açık kaynak kalmak istiyorsan AGPL kullan. AGPL, enterprise için neredeyse zehir gibidir. Çalıştığım hiçbir şirket AGPL kodunun ticari üründe kullanılmasına izin vermezdi. Sonrasında da ticari lisansı ücretli satarsın
Açık kaynak projeler çoğu zaman bir hayır ve onur sistemi gibi işliyor. Katkıcılar itibar, kullanan şirketler ise gelir elde ediyor. Böylece iki taraf da kazanıyor ve dolaylı olarak insanlığa da fayda sağlanıyor. Ben şahsen—belki naifçe—bu hayrın tüm insanlığa daha doğrudan ve net biçimde geri dönebileceğini düşünüyorum. Örneğin proje açık lisansla yayımlandığında, onu kullanarak gelir elde eden şirketler cirolarının %1’i kadarını küresel bir fona, yani "Decentralized Universal Kindness Income" (DUKI)’ye bağışlar. Lider katkıcı şirketler bu bağışın tamamı ya da bir kısmından muaf olma ayrıcalığı kazanabilir; böylece diğer büyük şirketler rekabet için kullansa bile bir miktar avantajları olur (Redis’in lisans değiştirmesinin sebeplerinden biri de buydu). Katkıcılar dünya çapında daha fazla tanınma ve itibar kazanır, bağış yapan şirketler ise açık kaynak kaynaklarını geniş ölçekte kullanabilmenin yanı sıra pazarlama açısından da itibar artışı elde eder. Sadece kâr peşinde koşan şirketlerden çok daha rekabetçi olabilirler. Ben buna “DUKI lisansı” diyorum. Esas fikir, MIT lisansına tek bir kâr paylaşımı şartı eklemek. Ne yazık ki bunu pazarlayacak kadar etkim yok ve açık kaynak ekosistemini yönlendiren çekirdek bakımcılar ile kurucuların bunu benimseyip benimsemeyeceği belirsiz
“Kaynak kod lisans kapsamında serbestçe sunulur, ancak issue açma/yorum yapma, tartışmalara katılma, release indirme gibi diğer tüm faaliyetler bakım ücretine tabidir” deniyor; buna release indirme de dahil edilmesine şaşırdım. Avukat değilim ama bana lisansın kendisiyle çelişiyor gibi geliyor. Özellikle de “her katkıcı, çalışmayı ve türevlerini dağıtmak/kullanmak/değiştirmek için münhasır olmayan, dünya çapında, telifsiz bir telif hakkı lisansı verir” maddesi yüzünden. Bu yaklaşım sadece kafa karışıklığını büyütüyor ve fiilen release’leri otomatik mirror eden fork’lar oluşturan otomasyonu zorunlu kılıyor. Zaten repoda buna uygun GitHub Actions da var
Alıntıladığın lisans maddesi sadece sana ilgili kodu kopyalama, değiştirme (veya derleme) ve dağıtma hakkı veriyor. Binary’leri mutlaka dağıtmak zorunda oldukları anlamına gelmiyor. Aslında bu yaklaşım oldukça yaygın. Açık kaynak lisansları çoğu zaman sadece kaynağa uygulanır. “Otomatik mirror/fork teşviki” eleştirisinde haklı bir yan var ama yazılım geliştiricileri için doğrudan clone edip build etmek zaten kolay ve doğal bir şey. Eskiden de kaynak kodu doğrudan kopyalayıp kullanmak temel yöntemdi; FOSS’un popüler olmasının nedenlerinden biri de buydu. Bu bir “açığı dolanma” değil, FOSS’un özünün kendisi
Kesinlikle katılıyorum. Ama pratikte durum öyle olmadı. Çoğu şirket bakım ücretimizin gayet makul olduğunu düşündü ve projeyi sürdürme/fork etme riskini almadan resmi desteği tercih etti
Bu konudaki “hype”ı neden anlayamadığımı bilmiyorum. Lisans değişmiyor ama bakım ücreti ödemezsen destek alamıyor musun? Biri bir güvenlik açığı bildirse, bildirimi yapan kişi bakım ücretini ödemeden WiX patch yayınlamıyor mu? Ya da kurumsal bir kullanıcı iyi bir özellik fikri sunduysa, bakım ücretini ödeyene kadar yok mu sayılıyor? Bana çok bariz geliyor. Açık kaynak yazarları zaten hangi PR’ları kabul edeceklerine, hangi issue’larla ilgileneceklerine kendileri karar verir. Desteğe ücret biçmeleri de zaten mümkündü. Bakım ücreti sisteminin neden yenilik olarak görüldüğünü anlamıyorum. Bunu kötülemek için söylemiyorum. Açık kaynak lisansla araç yapmak harika ve bunun için destek almak da tamamen meşru. Katkıcılar kendilerini dışlanmış hissederse her zaman fork’layabilir. Bu yeni bir kavram değil. Tabii fork etmek önemli miktarda para ve insan kaynağı gerektiren bir karar. Amazon ölçeğinde dev bir şirket için bile, ilgiyi çekmek adına asıl yazara para vermek daha verimli olabilir. LibreOffice, io.js, OpenTofu, neovim gibi örnekler de var. LibreCAD gibi düzgün bir ayrışma yaratabilmek de başlı başına bir başarı. io.js, nodejs’yi daha sağlıklı hale getirdiği için anlamlıydı. Topluluğun gücü açık kaynağın en büyük avantajlarından biri. Kod, dokümantasyon, fon, fikirler… herkes katkı verebilir. WiX’in de bu şekilde topluluğa katılması güzel; umarım bundan sonra da iyi gider
WiX installer karmaşık ve anlaşılması zor bir araç. Ben sadece ücretsiz olduğu için kullandım. Ücretli olsaydı, daha kolay ve daha iyi destek sunan ticari bir ürünü tercih ederdim. Rob Mensching yıllık $5,000’lık danışmanlık ve destek hizmetleriyle gelir yaratmaya çalışıyordu ama anlaşılan o da yeterli olmamış
“Tek avantajı ücretsiz olmasıydı” sözü, kurulum aracı için para harcamak istemeyen insanlar açısından doğru olabilir. Ama WiX’in en büyük değeri sadece ücretsiz olması değil. WiX Toolset, Windows Installer’ın potansiyelini başka hiçbir kurulum aracının sağlayamadığı şekilde kullanmanı mümkün kılıyor. Basit ihtiyaçlar için bu güç gereksizse gerçekten hantal ve yetersiz hissettirebiliyordu. Ama zor kurulum problemlerinde, bu keskin özellikler tam da gerekli olan şeydi. “Yıllık $5,000’lık danışmanlıkla gelir elde etme” konusuna gelince, ben sadece WiX’in kendisi üzerinden yılda $5,000 kazanmıyorum. Ekibimle birlikte onlarca yıl boyunca biriktirdiğimiz kurulum paketi uzmanlığını ve FireGiant’ın sunduğu gelişmiş araçları kullanan “WiX Developer Direct” programı üzerinden yüksek değerli özel hizmetler sunuyorum. Aylık office hour’lar, SLA garantisi, yıllık code review, gelişmiş araçlar gibi üst düzey hizmetler veriyoruz ve müşteriler de bunları çok değerli buluyor. Mesele bunun yetmemesi değil; yakın zamandaki XZ Utils olayını görünce açık kaynağın sürdürülebilirliğinin gerçekten ciddi bir mesele olduğunu iyice hissettim. Bu yüzden bir yol bulmaya çalıştım ve Open Source Maintenance Fee’nin benimki gibi projeler için oldukça iyi çözümlerden biri olduğunu düşünüyorum. WiX Toolset şu anda bu modeli ilk benimseyenlerden biri olarak, deneme-yanılmayla bunun pratikte nasıl işlediğini test eden bir saha görevi de görüyor. Şimdiye kadar gayet iyi gidiyor
WiX aslında Windows Installer’da kullanılan dahili veritabanı yapısını doğrudan XML olarak yazabilmeni sağlayan bir araç. MSI formatı ve Windows Installer zaten çok karmaşık olduğu için böyle anılıyor; sorun WiX’ten çok, MSI formatının baştan beri “karmaşık bir labirent” gibi olması
Lisansın MS’e ait olduğunu sanıyordum ama lisans metnine bakınca, “GitHub ve NuGet.org’da yayımlanan binary release’lere bakım ücreti ödemeyi zorunlu kılan bir EULA uygulanır” deniyor. Ben de avukat değilim ama bu durumda kendin derleyip dağıtırsan bakım ücretini dolaşmak mümkün olmuyor mu? Hatta o build’i ücretsiz dağıtmak da mümkün değil mi?
Kod Microsoft’un değil, .NET Foundation’ın mülkiyetinde (hikâyesi uzun). Kendin build edip bakım ücretini atlatman tamamen serbest. Artık 500 bin satırlık kodun sorumluluğu da sende. Gerçek bir fork’un tadını çıkar!
Repo README’sine göre kaynak kod açık kaynak, ama repodaki issue ve release özellikleri bakım ücreti ödemeyi gerektiriyor