Açık Kaynağın Geleceği

 (blog.gitbutler.com)
19 puan yazan xguru 2024-08-12 | 5 yorum | WhatsApp'ta paylaş
  • COO’muz ve kurucu ortaklarımızdan Anne, Alman gıda şirketi Delinero’nun CEO’suyken dava edildi. Bunun nedeni, bir tedarikçinin sağladığı ahududu reçelinin "Himbeermarmelade" olarak etiketlenmesiydi; çünkü Almanya’da marmelatın "marmelat" olarak etiketlenebilmesi için en az %20 narenciye içermesi gerektiğini söyleyen bir 'Konfitürenverordnung (reçel düzenlemesi)' vardı
  • Bu, yaygın olarak kullanılan kelimenin anlamıyla çelişen bir düzenlemeydi, ancak uzun zaman önce az sayıdaki çıkar sahibinin yaptığı bir yasa olduğu için buna uyulması gerekiyordu
  • Bugünkü "açık kaynak" da benzer bir durumda görülebilir. OSI, Konfitürenverordnung gibi, genel kullanımdan farklı şekilde evrilmiş bir terimi hâlâ sıkı biçimde düzenliyor
  • Peki yapıcı bir yönde nasıl ilerleyebiliriz?

"Açık kaynak" nasıl yapılmaz

  • GitButler istemci kodunu "Fair Sourcing" yaklaşımıyla, OSI onaylı olmayan bir lisansla yayımladığında, bunu nasıl duyuracağımızı düşündük
  • Çoğu insan "açık kaynak"ı "GitHub’da herkese açık olan" ile eş anlamlı görüyor; ayrıca GPL/copyleft lisanslarının biraz riskli çağrışımı nedeniyle insanlar hangi lisansın uygulandığını kontrol etmeye oldukça alışkın
  • Yine de "Source Available'd" gibi muğlak bir ifade kullanmak istemedik ve karışıklığı önlemek için "open" kelimesini kullandık, ama saldırıya uğradık
  • Az sayıdaki, ama sesi çok çıkan insanların bu terimi korumaya ve somutlaştırmaya çalıştığını fark ettik
  • "Açık kaynak", "kapalı kaynak"ın mantıksal olumsuzu değil. GitHub’da herkese açık ve katılıma açık olmak ile OSI’nin kendi kendine düzenlediği "açık kaynak"ın teknik 10 maddelik tanımı arasında kamusal anlayış açısından bir uçurum var

Açık kaynağın kısa tarihi

  • 1950’ler ve 60’lardaki erken bilişim döneminde yazılım donanıma bağlıydı; bu yüzden ayrı bir kategori olarak ayırmaya gerek yoktu ve donanım şirketleri bunu serbestçe dağıtıyordu
  • 1970’ler ve 80’lerde donanım metalaştıkça, yazılım kendi başına değer kazandı ve IBM, AT&T gibi büyük şirketler maliyetle geliştirdikleri kaynak koda erişimi kısıtlamaya başladı
  • Buna karşılık Richard Stallman ve diğerleri, şirket çıkarlarından korunmuş kendi işletim sistemlerini ve araçlarını geliştirmeye başladı; GPL gibi karşılıklılık esaslı lisanslarla IBM ve AT&T’nin bunları kullanması hâlinde kendi yazılımlarını da özgür yazılım yapmak zorunda kalmalarını sağladılar

    "Bizim oyuncaklarımızla oynayamıyorsanız, siz de bizim oyuncaklarımızla oynayamazsınız."

    • Bu harekete "özgür yazılım" adını verdiler ve Emacs ile GNU derleyici sistemi gibi birçok harika araç ürettiler. Bunlar bugün hâlâ modern bilişimin büyük kısmının temel araçları
    • Özgür yazılım hareketinin temel odağı, kullanıcıların yazılımı çalıştırma, kopyalama, dağıtma, inceleme, değiştirme ve geliştirme özgürlüğünü güvence altına almaktı. O dönemde onları çevreleyen kurumsal çıkarların ellerinden aldığı özgürlükler bunlardı
  • 1990’ların başında Linus Torvalds’ın Linux çekirdeğiyle birlikte tam bir işletim sistemi ortaya çıktı ve LAMP stack gibi özgür yazılım ekosistemleri büyüyerek şirketlerin de kullandığı ve bağımlı olduğu yapılara dönüştü
  • 1997’de Eric Raymond, özgür yazılım geliştirme modelinin kapalı modele üstün olduğunu savunan "Katedral ve Çarşı" denemesini yayımladı; bu metin Netscape’in Navigator Suite kaynak kodunu açmasını gerekçelendirmek için alıntılandı
    • Netscape kaynak kodunu açmaya karar verdiğinde, Palo Alto’da yapılan bir strateji oturumunda Raymond ve birkaç önde gelen Linux ve özgür yazılım geliştiricisi "open source" adında yeni bir terim üretip kullanma konusunda anlaştı

    "Toplantı katılımcıları, Netscape’i kodunu yayımlamaya motive eden pratik ve iş odaklı gerekçenin, potansiyel yazılım kullanıcıları ve geliştiricileriyle iletişim kurmak ve topluluğu kaynak kodu üretmeye ve iyileştirmeye katılmaya ikna etmek için değerli bir yol olduğuna inanıyordu. Toplantı katılımcıları ayrıca bu yaklaşımı tanımlayan ve onu felsefi ve politik odaklı ‘özgür yazılım’ etiketinden ayıran tek bir etiketin faydalı olacağına inanıyordu."

  • Önemli olan, "özgür yazılım" ile "açık kaynak" arasında kayda değer bir hukuki ya da pratik fark olmaması
    • Çoğu lisans her iki tanım altında da uyumlu ve kabul ediliyor
    • "Açık kaynak", sadece Netscape gibi daha fazla şirketin profesyonel kaynak kodunu açmayı benimsemesini sağlamak için, Stallman ve hareketinin politik hedefleriyle yazılım açıklığının pratik faydalarını birbirinden ayıran, iş dostu bir yeniden markalamaydı
  • Ya da özgür yazılım tarafındakilerin dediği gibi

    "Açık kaynak bir geliştirme metodolojisidir, özgür yazılım ise toplumsal bir harekettir."

Açık kaynak ve GitHub çağı

  • "Açık kaynak" ifadesinin tanımı ve pazarlaması 1998’de yapıldı; yani bugünden bakıldığında 25 yıldan daha uzun zaman önce. Peki bilişimin son 25 yılında açık kaynak ve yazılım geliştirme alanında neler oldu?
  • Özellikle son 10 yılda GitHub ve GitHub tarzı yazılım geliştirme, açık kaynak üzerinde muazzam bir etki yarattı
  • 1998’de şirketleri açık yazılımı benimsemeye ikna etmeye çalışıyorduk, bugün ise neredeyse tüm açık kaynak yazılımlar şirketler tarafından yazılıyor ya da destekleniyor
  • En büyük değişimlerden biri, özellikle GitHub’ın öncülük ettiği şekilde, "geliştirme iş akışlarının standartlaşması" oldu
  • Eskiden açık yazılım projeleriyle şirket içi projeler arasında büyük farklar vardı, ama artık neredeyse hiç fark yok
    • Herkes Git kullanıyor
    • Neredeyse herkes pull request’leri (veya merge request’leri ya da bu özelliği kopyalayan başka yöntemleri) kullanıyor
    • Çoğu ekip GitHub Flow’un (Trunk tabanlı geliştirme, GitLab Flow vb.) bir türünü kullanıyor
  • Artık tek fark deponun herkese açık olup olmaması. 25 yıl önce süreçte çok fazla sürtünme vardı, ama bugün açık kaynak hâline getirmek neredeyse hiç süreç değişikliği gerektirmiyor

Açık kaynağın bir sonraki adımı ne?

  • Artık neredeyse tüm şirketler açık kaynak yazılımı kullandığına ve ürettiğine göre açık kaynak (özgür yazılım) hareketi başarılı oldu mu?
  • Açık kaynak dünyasında şu anda iki büyük sorun var: "geliştirici sürdürülebilirliği" ve "ticari açık kaynak uygulanabilir mi"

Geliştirici sürdürülebilirliği sorunu

  • Açık kaynağa büyük ölçüde bağımlı hâle geldikçe sürdürülebilirlik ve bakım sorunları ortaya çıkıyor. XZ Utils arka kapı istismarı olayı bunun yakın dönemde öne çıkan bir örneği
  • Neredeyse tüm bakımcılar tükenmişlik ve tacizle mücadele ediyor. Açık kaynak yazılım yazıp bakımını yaparken para kazanmak neredeyse imkânsız
  • Açık kaynak geliştiricilerinin ve bakımcılarının çoğu artık büyük şirketlerin sponsorluğuna dayanıyor
    • Linux, Git, Ruby, React gibi örneklere baktığınızda, önemli açık kaynak projelerindeki katkıcıların çoğunun GitHub, Microsoft, Red Hat gibi şirket sponsorları tarafından profesyonel olarak istihdam edildiğini görürsünüz
  • Bir geliştiricinin XZ Utils gibi projeleri sürdürürken düzgün bir geçim sağlaması zor
    • İdeal olan, tek bir şirketin geliştiriciye ödeme yapması yerine binlerce şirketin profesyonel bakımcılara küçük miktarlarda ödeme yapması olurdu
  • Temel sorun, şu anda bunu yapmanın iyi bir yolunun olmaması
    • GitHub Sponsors, Thanks.dev, Liberapay, Tidelift gibi umut verici girişimler var, ancak şirketlerin bağış yapması için doğru teşvik meselesini hâlâ çözebilmiş değiller
  • Sentry, OSS Pledge adlı yeni bir girişimi teşvik ediyor ve GitButler da ekimde piyasaya çıktığında buna katılmayı planlıyor
  • Ancak bunun gibi yaklaşımların açık kaynak ekosistemindeki geliştirici sürdürülebilirliği gibi büyük ve giderek büyüyen sorunu çözüp çözemeyeceği henüz bilinmiyor

Ticari açık kaynak sorunu

  • Geliştiriciler uzun süre açık kaynak ve açık toplulukları severek büyüdü; bu yüzden şirket ve proje kurduklarında varsayılan olarak açık olmak istiyorlar
    • Ancak bireysel bakımcılarda olduğu gibi, açık kaynakta da şirketler açısından bir sürdürülebilirlik sorunu var
  • Elasticsearch ve Redis örneklerinde görüldüğü gibi, yazılımı profesyonel olarak geliştirmek için zaman ve para yatırdığınızda Amazon gibi büyük şirketlerin sizin emeğinizi kullanarak sizinle doğrudan rekabet etme riski var
  • Birçok profesyonel üretici, yazılıma yatırım yapmak ve sonrasında bunun kendi aleyhlerine kullanılmamasını sağlamak istiyor
    • Bu da lisanslama konusunda yaratıcı olmayı ya da kaynak kodu kapatmayı gerektiriyor
  • Ben Fair Source hareketinin bu büyüyen soruna yönelik harika ve gerekli bir çözüm olduğuna, ayrıca son birkaç yılda giderek daha fazla sorun ve kafa karışıklığı yaratan açık kaynak ekosistemindeki boşluğu doldurduğuna inanıyorum
    • Bu; büyük ölçüde izin verici, kaynak kodu erişilebilir ve GitHub topluluğunun katkıda bulunduğu profesyonel projeleri tanımlayan yeni bir terim ve daha önce özel yürütülen daha fazla projenin kamuya açılmasını teşvik etmek için çok ihtiyaç duyulan bir çözüm olduğunu düşünüyorum

İşbirliğinin geleceği

  • Açık kaynağın geleceği yalnızca "Open Source" ve OSI’nin 10 maddelik Konfitürenverordnung’u değil
  • Herkes için mümkün ve değerli olan Open Source, güvenli yatırım için gereken Fair Source ve önemli temel açık kütüphaneler ile projeler için büyük ölçekli ortak fonlamanın birleşimi
  • Kritik açık kaynak kütüphanelerinin bakımını sürdürülebilir hâle getirmeli ve sürdürülebilir, ticari, kaynak kodu erişilebilir lisans sınıfını kabul edip normalleştirmeliyiz
  • Mümkün olduğunda her şeyi izin verici OSI lisanslarıyla açık kaynak yapmalı ve her şeyden önce kapalı kaynağı geçmişte kalmış bir şey hâline getirmeliyiz
  • Şu anda yapabilecekleriniz:
    • Kapalı yazılımları Fair Source yapın
    • Açık kaynağa bağımlıysanız OSS Pledge’e katılın

İlgili okumalar

5 yorum

 
bus710 2024-08-13

Kapitalist bir dünyada yaşarken yalnızca açık kaynağa odaklanamamak ne yazık ki gerçeğin ta kendisi. Öte yandan, gerçekten önemli kütüphaneler ya da yardımcı araçlar söz konusuysa şirketlerden daha fazla sponsorluk gelse iyi olur diye düşünüyorum.

Özellikle kullanıcı alanındaki masaüstü/terminal yardımcı araçlarının böyle bir destek alması zor. Çekirdek tarafında büyük şirketler ciddi destek veriyor, mobilde App Store üzerinden ticarileşme iyi işlemiş durumda, web ya da firmware gibi alanlarda ise belli ölçüde pazar analizi yapılarak geliştirildiği için kaygı daha az; ama sıradan kullanıcıların farkında olmadan kullandığı yazılımlar ve kütüphaneler için eşik belirlemek de zor olduğundan para kazanmak gerçekten çok zor görünüyor. Açık kaynak epey canlı olsa da bunun ötesine sıçraması kolay olmuyor.
 
bus710 2024-08-13

Açık kaynağı sevip keyifle kullandığımız kadar, görünmeyen yerlerde büyük çoğunluk için özveriyle geliştirme yapan insanların da uygun lisans tercihleri sayesinde karşılığını almasının iyi olacağını düşünüyorum.
 
chabulhwi 2024-08-13

Drew Devault’un yazdığı "So you want to compete with or replace open source (açık kaynakla rekabet etmek veya açık kaynağın yerini almak istiyorsunuz, öyle mi?)" başlıklı yazıda şu ifade geçiyor.

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

Özgür ve açık kaynaklı yazılımda, farklı kuruluşlara bağlı katkıcılar iş birliği yaptığında ortak fayda ortaya çıkar; ancak fair source yazılımda, tekel benzeri bir konumdan yararlanan kişi ya da kuruluş için diğer katkıcıların bedavaya iş birliği yapması için pek az, hatta hiç neden yoktur.

Her hâlükârda ben de fair source’un kapalı kaynaktan daha iyi olduğunu düşünüyorum ve açık kaynak yazılımın bakımını yapan kişilerin emeklerinin karşılığını almak istemesine rağmen bunu alamamasını ben de istemem.

Yine de fair source’un, açık kaynakta olduğu gibi ücretsiz geliştirme katkılarından yararlanıp yararlanamayacağı konusunda şüpheliyim. Ayrıca biri yazılımını açık kaynak olarak dağıttığında, hiçbir kullanıcıdan maddi bir karşılık alamayabileceğini ve o yazılımın büyük bulut şirketleri için bir "bedava öğle yemeği"ne dönüşebileceğini aklında tutmalıdır.