Açık kaynak direnişi: Mesai saatlerinde açık kaynağı koruyalım

• Open Source Resistance, şirketlerin bağımlı olduğu açık kaynak yazılımların bakımını mesai saatleri içinde sessizce ve profesyonelce yapmak gerektiğini savunan bir doğrudan eylem manifestosu
• Tüm şirketler açık kaynak olmadan işlerini yürütemezken, bakımcıların ayrı izin, bağış düğmesi ya da cuma öğleden sonrası zamanı dilenmek zorunda bırakıldığı yapıyı reddediyor
• Daha önce de Open Source Pledge (geliştirici başına yıllık 2.000 ABD doları ödeme çağrısı) ve Open Source Friday (her cuma en az 2 saat katkı) gibi alternatifler vardı, ancak bu hareket daha doğrudan uygulamayı savunuyor
• “Zaman hırsızlığı” itirazına karşı, şirketlerin zaten uzun süredir ücretsiz OSS sübvansiyonundan yararlandığı ve bağımlı olunan OSS’nin bakımının ortak altyapı işi olduğu söylenebilir
• İş sözleşmesindeki fikri mülkiyet devri maddelerini mutlaka kontrol etmek ve açık kaynak istisnasını yazılı olarak müzakere etmek gerekiyor

---

Manifesto: Zaten gerekli olan işi düzeltmek için izin istemeyin

• Open Source Resistance, şirketin bağımlı olduğu açık kaynak yazılımların (OSS) bakımını gece ve hafta sonu hobisine itmek yerine, sessiz ve profesyonel biçimde mesai saatlerinde yapmayı öneren bir doğrudan eylem çağrısıdır
• Açık kaynak yazılım boş zamanlarda yapılan bir "hobi" değildir; şirketler her saat açık kaynaktan değer çekerken bakımcılara ancak bir cuma öğleden sonrası, bir bağış düğmesi ya da tüm ekip toplantısında bir teşekkür sunuyor
• Bakımcılar, şirket içinde zaten bağımlı olunan OSS kodu üzerindeki çalışmayı evrak işi, iç programlar veya yönetici onayı olmadan mesai saatlerinde yapmalıdır
• Bu yeni bir fikir değil; çoğu açık kaynak çalışmasının zaten her zaman nasıl yapıldığını açıkça dile getirmekten ibaret
• Bakımcılar toplantıları, sprintleri ya da ürün yöneticisinin onayını beklemeden interneti ayakta tuttu

Temel eylem ilkeleri

• Kendinizi koruyun

  • İş sözleşmenizi kontrol edin, gizli bilgileri şirket içinde tutun ve yayımladığınız açık kaynak IP’nin mülkiyetini güvenceye alın

• İşi yapın

  • PR incelemesi, bağımlılık güncellemeleri ve zaten OSS olan bölümlerde hata düzeltmeleri yapın

• Düşüncesiz davranmayın

  • Mesai saatlerinin %100’ünü OSS’ye ayırıp işten atıldıktan sonra başkalarını suçlamak yok; anahtar nokta denge

Mevcut alternatifler

• Open Source Pledge: Şirketlerden bakımcılara ödeme yapmalarını ister (geliştirici başına yıllık 2.000 ABD doları)
• Open Source Friday: Şirketlerden zaman bağışı ister (her cuma en az 2 saat)
• Önce işvereni ikna etmeyi hedefleyen nazik yol da vardır ve bunların hepsi olumlu, desteklenmeye değer yaklaşımlardır
• Open Source Resistance ise bunun bir sonraki adımı olarak, bağımlılık zincirinin bakımının yönetici böyle adlandırmasa bile zaten işin bir parçası olduğunu ilan eder
• Şirketin bütçe dağılımı kontrolünüz dışında olabilir, ama kendi mesai zamanınızı nasıl kullandığınız sizin kontrolünüzdedir

Beklenen itirazlar ve yanıtlar

• "Bu zaman çalmaktır / hissedarlardan çalmaktır"

  • Şirketler zaten her gün açık kaynak bakımcılarından değer çekiyor ve hissedarlar on yıllardır ücretsiz açık kaynak sübvansiyonu alıyor
  • İşveren OSS’ye bağımlıysa, bunun bakımını yapmak kamusal altyapı işidir, hırsızlık değil

• "İzin istemek gerekir"

  • İzin istemek, güç dengesizliğini sürdürmenin bir yoludur
  • İşverenin zaten bağımlı olduğu altyapıyı korumak için yöneticinin kutsamasına ihtiyaç yoktur

• "Bu quiet quitting ile aynı"

  • Quiet quitting iş yükünü azaltır; burada ise internetin üzerine kurulduğu OSS altyapısı üretiliyor
  • Sorun işin kendisi değil, şirketin bunu iş olarak sınıflandırmayı reddetmesi

• "İyi işverenler de zarar görür"

  • İyi işverenler, mesai saatlerinde açık kaynak bakımına izin vererek, bakımcılara fon sağlayarak ya da Open Source Pledge’e katılarak bu sorundan kaçınabilir

Mike McQuaid'in deneyimi

• Open Source Friday ve GitHub Sponsors’ın ortak kurucusu, ayrıca Homebrew projesinin lideri (2009’dan beri bakımcı)
• Çalıştığı hiçbir yerde Homebrew gibi açık kaynak projelerdeki çalışması ana işi olarak maaşlandırılmadı
• Buna rağmen tüm işverenlerinde bunu yaptı; IP sözleşmelerini müzakere ederek yasal zemine oturttu ve iş taahhütlerini de yerine getirdi
• Çocuk sahibi olduktan sonra açık kaynak çalışmalarının %90’ından fazlasını mesai saatlerinde yaptı
• Open Source Maintainers Owe You Nothing yazısında olduğu gibi, bir şirketin iş modeli kendi koduna dayanıyor diye hiç kimsenin bakımcıların ücretsiz gece, hafta sonu ve aile zamanını talep etmeye hakkı olmadığını savunuyor

Uyarılar ve yasal bildirim

• Hukuki tavsiye değildir

  • Bunun hukuki tavsiye olmadığı; sözleşmeler, işveren, göçmenlik statüsü, lisans yükümlülükleri veya kişisel durumlara dair öneri sunmadığı açıkça belirtiliyor
  • Risk büyükse, harekete geçmeden önce yetkin biriyle görüşmek gerekir
  • Çoğu açık kaynak lisansı gibi hiçbir garanti vermez, “olduğu gibi” sunulur

• Sözleşmeler, politikalar, mülkiyet

  • İş sözleşmeleri, el kitaplarındaki politikalar ve buluş devri maddeleri; istihdam sırasında üretilen işler, işveren ekipmanında yapılan işler veya görev alanı içindeki işler üzerinde hak iddia edebilir
  • Bazı eyaletlerde kişisel zamanda ve kişisel ekipmanla yapılan işler üzerindeki bu tür hak iddiaları sınırlandırılır, ancak ayrıntılar önemlidir
  • Harekete geçmeden önce iş sözleşmesini okuyup yayımlamayı düşündüğünüz açık kaynak IP’nin işverene ait olmadığını doğrulamak gerekir
  • Cihaz, ağ veya hesap sahipliği riski değiştiriyorsa kendi araçlarınızı kullanmalısınız

• IP sözleşmesi müzakeresi

  • IP devri çoğu zaman müzakereye açıktır; iş teklifi aldığınızda imza atmadan önce açık kaynak istisnasını yazılı olarak istemeniz tavsiye edilir
  • Önce çalışan IP sözleşmelerini okuyarak hangi kısımlara itiraz etmeniz gerektiğini öğrenmelisiniz
  • Mike McQuaid, neredeyse tüm işverenleriyle standart sözleşmeden sapmalar müzakere ettiğini ve çoğunun beklediğinden çok daha az itiraz ettiğini söylüyor
  • GitHub’ın Balanced Employee IP Agreement metnini potansiyel işverenlere gösterebilirsiniz
  • Bu sözleşme CC0 olarak açık kaynaklaştırıldı, büyük halka açık şirketler tarafından gerçekten kullanıldı ve işverenin ücretini ödediği şeyi elinde tutarken çalışanın işle rekabet etmeyen açık kaynak çalışmalarını koruması için tasarlandı

• Gizlilik ve güvenlik

  • Özel depolar, kimlik bilgileri, olaylar, müşteri verileri, yol haritaları, henüz açıklanmamış güvenlik açıkları ve şirket içi tartışmalar ifşa edilmemelidir
  • Güvenlik kontrollerini atlatmamalı veya yetkisiz erişim haklarını kullanmamalısınız
  • Doğrudan eylem, şirket sırlarını ifşa etmek için bahane değil; kamusal işi kamusal tutmak ve bunu ticari sırlarla net biçimde ayırmaktır

• Sessizlik dikkatsizlik demek değildir

  • Politikalar, sözleşmeler, müşteri yükümlülükleri veya güvenlik kuralları riski değiştiriyorsa kendi muhakemenizi kullanmanız gerekir
  • Kendi cihazınız, hesabınız ve ağınız üzerinde çalışmanız gerekebilir
  • Şirketten "çalmak" değil, şirketin açık kaynaktan aldığı ile sizin verebileceğiniz arasındaki dengeyi kurmaktır
  • İş arkadaşlarınıza göre daha düşük performans değerlendirmesi alabilirsiniz; ama sürdürülebilir bir B notu, yarın sizi işten çıkarabilecek bir şirkette A notu için hayatınızı tüketmekten daha sağlıklıdır

• Uygulama sınırları

  • Zamanın belirli müşterilere, hibelere, devlet kurumlarına, savunma projelerine veya düzenlemeye tabi ortamlara faturalandığı durumlarda bu argüman en zayıf hale gelir
  • Olumsuz sonuçları göğüsleyecek gücü olmayan genç ya da güvencesiz mühendisler için de en zayıf durumdadır
  • İşverenin zaten kullandığı kamusal bağımlılıkları düzelten kıdemli bakımcılar için en güçlü halini alır
  • En temiz biçimi, “mesai saatinde istediğini yap” demek değil, açık kaynak bakımını mühendislik işinin bir parçası olarak ele almaktır
  • Zaten bakımını yaptığınız projeleri sürdürmeli, işinizin dokunduğu ortak araçları iyileştirmeli; alakasız işler, kapalı kaynak kod veya gerçek taahhütlerinizi aksatacak şeylerden kaçınmalısınız

Kaynak ve proje

• Mike McQuaid tarafından oluşturuldu ve kaynak kodu GitHub üzerinde açık olarak yayımlandı

[roxie]

Genel olarak... bence "resistance" ifadesi uygun görünüyor.

[GN⁺]

Hacker News yorumları

• Şirketlerin belirli bir açık kaynak projeye katkı verilmesi konusunda kapsamlı izin vermesi aslında oldukça yaygındı
  Burada ifade biçimi önemli. “Biraz iyi hissedelim diye hayır işi yapabilir miyim?” demek yerine, “Bu alandaki uzmanlardan ücretsiz ve sıkı bir inceleme alıp, düzeltmeleri upstream açık kaynak projeye yansıtarak şirketin gelecekteki bakım maliyetini ortadan kaldırabilir miyiz?” demek gerekir
  Özünde mesele gerçekten buydu ve bu şekilde anlattığımda reddeden bir işveren olmadı. Şirketin çıkarıyla tamamen uyumlu, sadece bunun görünür olmasına yardımcı olmak gerekiyor

  • Eski işimden çıkarılmış olmaktan çeşitli nedenlerle hâlâ üzüntü duyuyorum; büyük nedenlerden biri de Kafka Streams kütüphanesine yaptığım oldukça büyük bir değişikliği açık kaynak olarak yayımlamayı tartışıyor olmamızdı
    API büyük ölçüde uyumlu kalırken pek çok kısmı yeniden yazdım; gerektiğinde backpressure semantiğini kullanabilen non-blocking I/O’yu öne çıkaran bir yöndeydi. State store ile blocking/non-blocking I/O’yu karıştırarak da gayet iyi performans korunabiliyordu; bu da ilginç şeyleri mümkün kılıyordu. Ayrıca çok görünmeyen çeşitli noktalarda performans kazanımı sağlayan bir projeydi, bu yüzden özellikle gurur duyuyordum
    Bunu GitHub’da yayımlamama ya da upstream Kafka Streams projesine PR göndermeme izin verilmesi için bastırdım ama ondan önce işten çıkarmalar oldu; sonrasında da bunu savunacak bir destekçi kalmayınca özel mülkiyetli kod olarak kilitli kaldı
    Hâlâ bunu sıfırdan yeniden yapıp özgür açık kaynak olarak yayımlamayı düşünüyorum. Aradan epey zaman geçtiği için yeniden yazıp yayımlamamda sorun olmayacaktır diye düşünüyorum; patent gibi bir durum da yoktu. Ayrıca Vert.x bağımlılığını kaldırmak gibi değiştirmek istediğim şeyler de var. Bir gün bir haftalığına boş kalırsam belki yaparım
  • Buna izin verilen yerlerde çalıştığım günleri özlüyorum
    Bazı şirketlerde sırf hukuk inceleme süreci bile işi kilitlemeye yetiyor
    Bir keresinde belli bir projeye bir yama gönderebilir miyim diye izin istedim ve ilginç bir e-posta zinciri çıktı. Sonunda soru şuydu: Müşteriye fatura edilen zaman içinde, teslim edilen üründeki bir hatayı düzeltmek için yazılmış bir yamaysa; yamalanmış kütüphane yeniden derlenip kaynak kodla birlikte teslim edilmek zorundaysa; ve sözleşmede ürünle ilgili tüm çıktıların ve fikri mülkiyetin müşteriye devredileceği yazıyorsa, bu yamayı kamu malı olarak yayımlama hakkımız var mı?
    Hukuk ekibi buna cevap vermek istemedi
  • Bu genel olarak iyi bir yaklaşım ve işi profesyonelce çerçevelemenin harika bir örneği. Yine de sorunun özünü çözmüyor. Özellikle mühendislik odaklı şirketlerde liderliğin bu faydayı hemen anlaması gerekir; anlamıyorsa bu zaten başlı başına bir sorun
    Buna nasıl yaklaşabileceğin büyük ölçüde işveren şansına da bağlı
  • “Tamam, bunu bir de uyumluluk ekibine gönderelim. Sadece fikri mülkiyet ihlali olmadığını doğrulamak istiyoruz. Tam olarak hangi repo ve hangi issue?”

• “Ve dağıttığınız açık kaynak fikri mülkiyetine gerçekten sahip olun” sözüne gelirsek, benim çalıştığım yargı alanlarında çalışma saatlerinde yazılıp dağıtılan kod bana değil işverene aitti
  Çalışma saatlerinde katkı verip vermemeye tek başıma karar veremezdim; açık kaynak kod üzerinde çalışmak için resmî bir anlaşma gerekirdi. Her talepte hukuk departmanından geçmek aylar sürerdi; sonunda ya vazgeçerdim ya da o arada başka bir katkıcı PR’ı çoktan göndermiş olurdu ve istemenin anlamı kalmazdı

  • Muhtemelen kastedilen şey, “Sana ait olmayan bir çalışmayı kafana göre bağışlamaya kalkma” idi. Aşağıda buna ayrılmış bir bölüm var ama yukarıdaki madde tek başına okununca kafa karıştırıyor
    Deneyimli geliştiriciler için bariz olabilir ama bazı şirketlerdeki junior geliştiriciler için gerçekten sorun olmuştu. Şirket içeride havalı bir şey yapıyorsa, bunu bir açık kaynak projeye katkı olarak vermenin iyi olacağını düşünüyorlar; ama özel kod bilgilerini kullanarak fiilen benzer kod göndermek ya da bazen doğrudan kopyala-yapıştır yapmak gibi bir sorun olduğunu hesaba katmıyorlar
  • Bunu bizzat araştırmadım ama Almanya’da varsayılan olarak çalışma saatlerinde yazılan tüm kaynak kodun işverene ait olduğunu sanıyordum
    BT odaklı olmayan işverenlerin çoğu muhtemelen açık kaynakın ne olduğunu ve nasıl çalıştığını bile anlamıyordur. Bu yüzden pek çok kişi için izin almaya çalışmak umutsuz olabilir
    Bağlantısı verilen sitenin, önce işverenlere açık kaynağın faydalarını anlatmaya ve işverenlere yönelik hukuki yönergeleri savunmaya odaklanması daha iyi olurdu
  • Şirket, üretime giren kısımlar dışında kodu izin verici lisanslarla yayımlamaya izin vermiyorsa öyle bir işe girmezdim. Benim için heves kırıcı olurdu ve zihinsel olarak sınırıma kadar iterdi. Gerekirse daha az parayı seçerim

• İyi bir fikir, hatta harika bir fikir; ama bunu direniş olarak konumlandırmanın iyi olup olmadığından emin değilim
  Bir işin amacı genelde belli bir hedefe ulaşmaktır. O hedefe nasıl ulaşılacağına, uzman olan geliştirici karar verebilir. Bu karar açık kaynak yazılımı içeriyorsa, onu bakımda tutmak da bu kararın bir parçası olmalıdır
  Bu radikal bir şey değil; sadece işini yapıp, işinin dayandığı şeylerin gelecekteki istikrarını ve bakım yapılabilirliğini korumaktır

  • Bu aynı zamanda düpedüz iyi bir iş sezgisidir. Açık kaynak üzerinden işbirliğini teşvik eden şirketler, kendi işlerini besleyen ekosistemi de büyütmüş olur
  • Söylenenlerin hepsine katılıyorum ama günümüz teknoloji şirketlerinin çoğundaki gerçeklik, benim yaşadığım kadarıyla farklı. Zorunlu tutulmadıkça kendi altyapılarına ve kütüphanelerinin bakımına bile zaman ayırmıyorlar; açık kaynağa ayırmaları daha da zor
    Metriğe oynamak için yapılan işe yaramaz özellikler, enshittification, dark pattern’ler ve neredeyse zararlı yazılım gibi duran moda entegrasyonlar; temel altyapı ya da kütüphane yatırımının önüne geçiyor
  • Katılıyorum. Böyle sunmak, birinin sosyal medyada daha fazla ilgi çekmeye çalışıyormuş gibi görünmesine yol açıyor. Her şeyin abartılması gereken bir noktaya gelmiş olmamız üzücü

• Genel ilke olarak tamamen katılıyorum ama bunu fiilen hayata geçirmek zor olabilir. Avukat değilim ama genel olarak fikri mülkiyet işverene ait olduğu için açık kaynak olarak yayımlamak için açık izin gerektiğini biliyorum
  Ve bu izni alma süreci çoğu zaman zor; bitmek bilmeyen prosedürlerden ve hukuk departmanından geçmek gerekiyor
  “ABD, Birleşik Krallık ve çeşitli yargı alanlarında, bir çalışan işinin parçası olarak bir eser üretirse işveren hukuki yazar ya da ilk telif hakkı sahibi sayılır”
  https://en.wikipedia.org/wiki/Work_for_hire
  Yine de açık kaynak işleri, yani bakım ve geliştirme, bağış dilenen gönüllüler tarafından değil maaş alan profesyoneller tarafından yapılmalı diye düşünüyorum. Esas soru bunu nasıl gerçekleştireceğimiz ve şirketlerin açık kaynak katkısını tek tek pazarlık edilmesi gereken bir istisna değil, standart uygulama olarak benimsemesini nasıl sağlayacağımız

  • Anlattığın sorunlar “pratik sorunlar”dan çok teorik sorunlara benziyor
    Pratikte ise insan çoğu zaman bunu yapar geçer. Bilgisayarın içinde git push işlemini engelleyen bir alt yordam yok. Gerçekte işverenler sözleşmelere her şeyi yazar. Her yönden sorumluluktan kaçmak için olabildiğince fazla madde koyarlar. Onlar istediklerini yazabiliyorsa, biz neden sadece yapamayalım? Hiçbir şeyin önemi yok
    Gerçekte bu tür teknik gerekçelerle fikri mülkiyet nedeniyle itiraz edilen açık kaynak proje sayısı neredeyse sıfıra yakın
  • İş, görev tanımınla ilişkiliyse fikri mülkiyetin işverene ait olduğu doğru
    İlişkili değilse durum eyalete göre değişir. Pek çok eyalette işverenin kendi fikri mülkiyeti olarak ileri sürebileceği şeylerin kapsamına sınır konur. Tipik sözleşmeler ifadeyi olabildiğince geniş tutup her şeyi sahiplenmeye çalışır; ama yasa çoğu zaman işverenle ilgisi olmayan, boş zamanda yapılan çalışmaları şirketin alamayacağını söyler
    Bunu çalışma saatlerinde yaparsan ya da şirket dizüstü bilgisayarı kullanırsan, şirketin hak iddia etmesi için alan açarsın. Çoğu şirket umursamaz ama bir anlaşmazlık çıkarsa elini temiz tutmak istiyorsan gevşek davranmamalısın
    Kişisel zamanında, kişisel ekipmanla çalış ve bunun işe alındığın işle ya da şirkette maruz kaldığın şeylerle çakışmamasına dikkat et
  • Avukat değilim ama bir kopyayı bir iş arkadaşına çalıştırması için verdiysen, bunun kendisi zaten bir açık kaynak lisansı kullanmak olmuyor mu diye düşünüyorum. O iş arkadaşı, lisansın verdiği yasal haklara kavuşmuş olmaz mı ve değişiklikleri yeniden dağıtma hakkına da sahip olmaz mı?
    Değişiklikleri upstream’e göndermek bakımın güvence altına alınmasının en iyi yolu; bütün bunlar bu yüzden bana çok gülünç geliyor. İçeride özel bir fork’u yaşatmanın yarattığı hukuki belirsizlik de öyle
  • Yazı sanki en az dirençli yolu izlemeyi öneriyor. Şirket zamanında çalış, fazla dalga çıkarma. Yakalanırsan af dile. Şirket açısından affetmek kolay yoldur. Avukatları devreye sokmak çok pahalıya gelir ve bir halkla ilişkiler kâbusuna dönüşebilir
  • Programlamanın bugünkü hâli bize bir şey gösterdiyse, o da fikri mülkiyet ve telif hakkı hukukunun artık fiilen var olmadığıdır

• Oldukça büyük bir şirkette çalışıyorum. Bizim şirketin açık kaynak politikası kabaca şöyle özetlenebilir: “Önce yöneticine sor, şirket adına yapma ve gizli bilgileri ifşa etme.”
  Hiç sorun çıkmadı ve genel çerçevede tamamen makul geliyor

• Çalışma saatlerinde üçüncü taraf açık kaynak projelere hata düzeltmesi gibi katkılar yapmakta sorun görmüyorum ama kendi açık kaynağın söz konusu olduğunda bunun nasıl ele alınması gerektiğinden emin değilim
  Mesela kişisel olarak yaptığın küçük bir kütüphane var diyelim; şirket bunu kullanıyor ve sen çalışma saatlerinde bir hata buluyorsun. O çalışma saatinde katkı yapmak gri alan gibi geliyor
  Bunu mülakat sırasında pazarlık eden oldu mu? Nasıl yaptığını merak ediyorum

  • Bunu gerçekten önemseyen bir şirkette hiç çalışmadım. Sadece yapılması gerekeni yaptım. Bunu “doğru şekilde” yapmak için ne yapılmalı diye sorduğumda da hiç cevap alamadım

• Büyük şirketlerde çalışırken genelde, şirketin kod tabanına doğrudan kod yazmanın dışındaki iş taleplerine, gerekçe sunsam bile, doğrudan yöneticim “boş zamanında yap” diye cevap verirdi
  Kâr odaklı ortamda sadece anlık değer üreten işler yapılmaya değer görülüyor. Bu tutum oldukça asalakça ve yukarıdan gelen daha yüksek verimlilik ile metrik yarışı bunu böyle yapıyor

• İşle ilgili bir sorunu çözmek için bir fork açıp düzeltme yaptığım, ardından sonucu upstream’e PR olarak gönderdiğim kesinlikle oldu
  Açık kaynağı kullanabilmenin ve ona erişebilmenin güzel yanlarından biri de bu. package.json ve cargo.toml içinde git’in neredeyse birinci sınıf bir seçenek olmasının nedenlerinden biri de bu; çünkü değişiklik upstream’e alınana kadar doğrudan fork’u işaret edebiliyorsun

• Senior seviyeye geldiğinde, mülakat sürecinde “Bize sormak istediğiniz bir şey var mı?” aşamasına gelindiğinde, “Bu şirketin bağımlı olduğu açık kaynak projelere zamanımın bir kısmını ayırıp katkı yapmam konusunda yaklaşımınız nedir?” diye sorarım
  Cevaba bakıp devam edip etmeyeceğine karar verebilirsin