Left-Pad (2024)

• left-pad olayı, açık kaynak topluluğu, NPM ve şirketler arasındaki kurallar ve değerler çatışmasını gösteren temsili bir örnektir
• Paketleri silme kararı, mantık, öfke ya da açgözlülükten değil, samimiyet ve içsel ilkelerden doğan bir eylemdir
• NPM, Kik Messenger'ın taleplerine boyun eğip kendi kurallarını ihlal ettiği durumda, yazar tüm paketlerini silmeyi seçmiştir
• Olayın ardından açık kaynağa duyduğu tutku değişmiş, ilgisi iş, pazarlama, ekip yönetimi gibi yeni alanlara kaymıştır
• left-pad olayı, geliştiriciler ve startup dünyasının açık kaynağın özü ile karar alma süreçlerinin karmaşıklığını yeniden düşünmesine vesile olmuştur

---

Olayın arka planı ve karar

• left-pad olayının üzerinden 8 yıl geçtikten sonra, yazar kişisel deneyimlerini ve düşüncelerini paylaşmaktadır
• Olay sırasında zamanının çoğunu sinyalin ulaşmadığı doğanın içinde geçirerek öz değerlendirme yapmış, paketleri silme kararı da bu süreçte alınmıştır
• Bu karar mantıksal bir yargı, öfke ya da açgözlülükten değil, kendi iç ilkelerinden, yani "NPM kendi kurallarını ihlal ediyorsa, benim tüm paketlerim de silinmelidir" inancından doğmuştur
• Bu tutum, katı bir "kuralcı" olmaktan çok kuralların ruhuna daha fazla önem verme yaklaşımıdır
• Kik Messenger gibi şirketlerin açık kaynak topluluğuna tehdit savurup güç kullandığı bir durumda, NPM kendi koyduğu kuralları görmezden gelerek şirket çıkarlarını öncelemiştir

NPM ile topluluk arasındaki çatışma yapısı

• Yazar, Kik'in tehditlerinden korkmamıştır; ancak NPM, Kik'i kaybetmekten korkmuştur
• Olayı yalnızca "öfkeli bir adamın büyük şirkete direnişi" olarak yorumlamak, olayın bağlamını, zamansal akışını ve kararın ağırlığını göz ardı eden basitleştirici bir bakıştır
• NPM tarafı için bu durum ani ya da beklenmedik değildi; buna rağmen genel olarak geliştiricilere karşı tepeden bakan bir tavır sergilemiş ve birbiriyle uyuşmayan kararlar dizisiyle tüm sorumluluğu yazara yüklemiştir

Paket yapısı ve etkisi

• Yazarın açık kaynak çalışmaları çoğunlukla Unix felsefesine uygun küçük rollere ayrıldığı için 350'den fazla paketten oluşuyordu
• Yüzeyde neredeyse hiç kullanım izi görünmese de, NPM kullanım istatistiklerini açıklamadığı için etki alanını belirlemek mümkün değildi
• Kullanıcıların paket silmenin gerçek etkisini bilmesinin bir yolu yoktu; NPM de etkiyi araştırmak ya da düşüncesizce silmelerin yol açacağı sorunları önlemek için çaba göstermemişti

8 yıl sonraki değişim ve büyüme

• left-pad olayından birkaç ay sonra yazar asıl işini bırakıp ABD'den ayrılmış, Fas, Ürdün, Türkiye, Endonezya gibi yeni ortamlarda kendi yolunu aramaya koyulmuştur
• Açık kaynağa duyduğu tutkunun koptuğu, adeta ölüm gibi bir anı ve yeni ilgi alanlarıyla yeniden doğduğu bir dönemi deneyimlemiştir
• Şimdi ise iş, pazarlama, şirket ve ekip yönetimi gibi çeşitli alanlara programlamadakiyle aynı tutkuyla yaklaşmaktadır
• Hayatın devam ettiği mesajını verirken, left-pad olayı özgür kararlar, topluluk değerleri ve karar alma süreçlerinin karmaşıklığını yeniden düşünmeye imkân veren bir dönüm noktası olarak kalmıştır

[ndrgrd]

Etkisi büyük olan bir olaydı, ancak paket yazarının yazısını okumadan bile bunun onun hatasından çok, içine karışan şirketlerin ve sistemin hatası olduğunu düşünüyorum.

[GN⁺]

Hacker News görüşleri

• Dürüst olmak gerekirse bu blog yazısının yarısında ne anlatıldığını pek anlayamıyorum; sanki bir bağlamı kaçırmışım gibi hissettiriyor ama "left pad guy"ın olayı toparlaması hoşuma gidiyor.
  Ama şu iddia biraz tuhaf geliyor:

  Ama yine de NPM'in modüllerimin ne kadar yaygın kullanıldığını araştırmamasını ve hiçbir şeyi bozmadan unpublishing'i nasıl ele alacağını düşünmemesini anlayamıyorum
  Elbette NPM'in unpublish biçimi kötü tasarlanmıştı ama yazarın söylediği şey, sanki biri unpublish yaptığında her seferinde bunu elle kontrol etmelerini bekliyormuş gibi geliyor. Bu beklenti makul görünmüyor. Ben NPM'i registry'yi kürate eden bir organizasyon olarak değil, kamusal bir hizmet sunan bir yapı olarak görüyorum.
  Yine de yazarı suçlamak zor; bence "left-pad incident"ı yazar tetiklemeseydi çok geçmeden bunu başka biri yapacaktı. NPM sorunu düzeltti ve daha iyi bir unpublish politikası da getirdi.
  Bilgi amaçlı: NPM'in yeni unpublish politikası

  • Bu blog yazısının yarısını anlayamadığını söylemen
    bence henüz al-Ghazali okumamış olmandan kaynaklanıyor.
    (Bu da yazının en kibirli ve benmerkezci kısmı.)

  • Bağlam için bkz. Npm left-pad incident Wikipedia

  • 18 Mart 2016'da npm CEO'su Isaac Z. Schlueter, hem Kik Interactive'e hem de Koçulu'ya e-posta göndererek kik paketinin sahipliğini manuel olarak Kik Interactive'e devredeceğini bildirdi
    Koçulu npm'in kararından duyduğu hayal kırıklığını ifade edip artık platformda yer almak istemediğini söyleyince, Schlueter ona kayıtlı 273 modülünün tamamını silebileceği bir komut verdi
    Koçulu da 22 Mart'ta o komutu çalıştırarak yayımladığı tüm paketleri sildi
    Yazar sadece NPM tarafının bizzat verdiği komutu çalıştırdı ama sonrasında NPM bütün sorumluluğu yazarın üzerine yıktı

  • NPM adlı şirket NPM registry'sini kürate etmiyor
    Aslında ediyor; örneğin güvenlik açığı bildirimlerini alıp kullanıcıları uyarıyor ya da kötü niyetli paketleri kaldırıyor.

  • Eskiden Sourceforge kullandığımda projeyi silmeden önce mutlaka izin istemeyi gerektiren bir politika vardı.
    left-pad'den sonra bunun nedenini kesin olarak anladım.

• Küçük bir nokta ama

  Açık kaynak projelerimin çoğunda Unix felsefesini izleyerek paketlerin aynı anda yalnızca tek bir iş yapacak şekilde tasarladım
  Kimse libc'nin Unix felsefesine aykırı olduğunu iddia etmiyor. Tartışma genelde komutların ya da daemon'ların fazla fazla iş yapıp yapmadığıyla ilgilidir (systemd bunun tipik örneği) ya da ne kadar birleştirilebilir olduklarıyla.

  • Bence left-pad olayı, NPM paketlerinin atomizasyonunun aşırı küçülerek paketleri sadeleştirmenin faydasından çok daha büyük bir ek yük yarattığını gösteren bir örnekti.

  • Kimse libc'nin Unix felsefesine aykırı olduğunu söylemiyor
    Aksine bunu öneren çok kişi oldu ve bence de haklılar.
    Modern libc, geleneksel Unix felsefesinden tamamen farklı.
    Eski libc daha basitti; birçok özellik libm gibi ayrı kütüphanelere bölünmüştü ve karmaşık DNS gibi şeyler yoktu.

  • 'do one thing'e karşıt olan şey, 'tek bir şeyi eksiksiz yap' kısmıdır.
  • Unix felsefesi, 16 bitlik minibilgisayarlarda güçlü bir etkileşimli programlama ortamı oluşturmak için hazırlanmış bir rehberdi.
    Bugün telefonumda kullandığım libc 1MiB; yani geleneksel Unix'tekinin 16 katı.
    Sonuç olarak libc'nin en az %90'ı Unix felsefesine aykırı.
    Lions Book ya da APUE okuyup ardından pthreads kılavuzuna veya ANSI C setlocale() tanımına bakarsanız bunun bambaşka bir felsefe olduğunu görürsünüz.
    Bunların aynı olduğunu düşünüyorsanız, muhtemelen bu iki felsefenin hiçbirine gerçekten bağlı değilsinizdir.
  • "Unix felsefesi" işe yaramaz bir felsefe, hatta zararlı bile olabilir.
    Çünkü 'one thing'in ne anlama geldiği belirsiz; pratikte hiçbir işe yaramayıp sadece tartışma çıkarıyor.
    Eclipse'in de 'IDE diye tek bir iş' yaptığı söylenebilir ama Unix geliştiricilerinin kastettiği bu değildi.
    Bu, 11 satırlık fonksiyonlardan oluşan bir kütüphane yapın anlamına da gelmiyor.
    Asıl tavsiye daha çok "program ya da kütüphane ne çok fazla ne de çok az şey yapsın" olmalı.
    Nerede fazlanın, nerede azın başladığı ise sonuçta deneyim ve sezgi meselesi.

• Bu yazıyı yazdığı için akoculu'ya teşekkürler.
  Bence bu olay, JavaScript topluluğunun yani bağımlılıklara fazlasıyla yaslanan bir ekosistemin çok net bir örneği.
  İnsanların seni neden bu kadar suçladığını bilmiyorum.
  Sonuçta sadece 11 satırlık koda sahip bir paketi unpublish ettin ve bunun yaratacağı yan etkileri tam olarak öngörmüş olman da beklenemezdi.
  Yazar da yazıda doğrudan bunu söylüyor:

  NPM de kullanım istatistiklerini iyi göstermiyordu ve Github'da da neredeyse hiç aktivite yoktu
  Kullanıcı açısından paketi unpublish etmenin etkisini anlamak zordu
  Kök nedeni akoculu'nun unpublish etmesinde değil, aşırı bağımlılıkta, npm politikalarında ve build sistemlerinde caching/vendoring eksikliğinde arıyorum.
  Bkz. olayın arka planı Wikipedia

• kik paketinin sürüm geçmişi tuhaf görünüyor.
  9 yıl önce security holding package ile değiştirilmiş.
  kik paket sürüm geçmişi

  Bu olayın en büyük ironisi kik paketi.
  kik'in bu kadar sahip olmak istediği kik paketi sonuçta hiçbir işe yaramıyor.
  Üstelik Kik adlı şirketin dikkatsiz ve sorunlu bir yer olduğu da ortaya çıktı.
  Kriptoyla ilgili tartışmalar da vardı ve üstü kapalı biçimde çocuk pornosu gibi içeriklerin dağıtım platformu olarak da anılan bir şirketti.
  Bkz. Darknet Diaries 93. bölüm
  Bu yüzden Azer Koçulu'nun Kik'e çok net biçimde karşı çıkması ayrıca tatmin edici geliyor.

  Yani bütün bunların sonunda... her şey aslında tamamen anlamsız mı oldu?

• left-pad'in başlı başına bir paket olarak var olması bile epey komik.
  Tek bir string padding fonksiyonu için CDN, proxy, build pipeline vb. üzerinden muazzam miktarda byte taşındı.
  Mevcut çözümleri iyi kullanma fikrine katılıyorum ama sırf bir string'in başını dolduran fonksiyon için "muhtemelen bunun bir paketi vardır" diye düşünülür hale gelinmesini anlamakta zorlanıyorum.

  O dönemde tartışmanın bir kısmı, web geliştiricilerinin mikro paketlere yönelik kör tutkusu konusunda bir uyanış olmuştu.
  Popülerlik ya da GitHub star uğruna paket yayımlama kültürü de vardı.
  Öte yandan npm ile kurulabiliyorsa herhangi bir fonksiyonu kendin yazmaktan kaçınma kültürü de çok güçlüydü.
  Hâlâ birlikte çalıştığım birçok geliştirici bugün bile basit paketleri tercih etme eğiliminde.
  Onlara göre mantık şu: "bakım yükünü azaltıyor."
  Gerçekten ironik.

  Paketin asıl implementasyonu da O(n) değil O(n^2) türü verimsiz bir işlem yaratıyor gibi görünüyor.
  Wikipedia'ya bakın

  Başkasının projesindeki utility fonksiyonuna bakmakla, ekosistemin tamamına zaten yayılmış bir paketi kullanmak arasında kalite açısından gerçekten büyük bir fark var mı?
  Aynı şey değiller ama yeterince gelişmiş tooling'e sahip bir ortamda bu iki yaklaşımın pratikte o kadar da uzak olmadığını düşünüyorum.

  Mümkün olan en yüksek kod yeniden kullanımını kovalama hali; copy-paste artık demodeymiş gibi bir saplantı.

  Acaba bu biraz AI'a benzemiyor mu?
  Basit bir aramayla çözülebilecek bir şeyi sayısız prompt ile tekrar AI'a sormak gibi.
  C&P'ye gereksiz bir adım daha eklenmiş oluyor.

• Unix felsefesi "bir işi iyi yap" der.
  left-pad ikinci kısmı yani "iyi yap" tarafını kaçırdı.
  Bu kadar çok projenin bu saf implementasyonu olduğu gibi kullanması beni şaşırtmıştı.
  Daha optimize bir implementasyon hem daha hızlı hem daha küçük olabilirdi.

  JavaScript kültürünü çok iyi bilmiyorum ama npm download sayılarını rekabetçi biçimde artırma eğilimi vardı diye hatırlıyorum.
  left-pad haftada 1,4 milyon, is-even ise 160 bin indirmeye sahipti.
  Bazıları şaka olsun diye, bazıları da kütüphanelerinin popülerlik metriğini yükseltmek için bağımlılıklarına mikro paket ekliyordu.
  React tabanlı popüler bir kütüphanenin içine is-even gibi bir paketi koymaya karşı çıkanlar da olmuştu.
  Bunun nedeni, "kendin yazabiliyor olsan bile mutlaka dışarıdan al" türü katı bir ilkeydi.
  İlgili hikâye: is-odd paketi neden bir haftada 3 milyon kez yüklendi

  'nonnaive implementation' için bir örnek merak ediyorum.

• Popüler npm paketlerinden birinin maintainer'ıyım.
  Buna gerçekten katılıyorum.
  npm bir noktadan sonra topluluk işbirliğinden uzaklaşmaya başladı.
  Microsoft tarafından satın alınmasıyla bu durum daha da pekişti ama işaretler ondan önce de çoktu.
  npm'in çeşitli işleyiş biçimleri, toplulukla/Node ekibiyle işbirliğine açık olmaması, yalnızca ticarileşmeye odaklanması, bazı üyelerinin itibarı vb. birçok açıdan rahatsız ediciydi.
  Oakland ofislerini ziyaret ettiğimi hatırlıyorum ama o günkü etkileşim çok olumlu değildi; bu yüzden detaya girmeyeceğim.
  unpublish açığı o dönemde herkesin bildiği bir sorundu.
  Herkes suçu "left-pad interneti bozdu" diyerek yazara yıktı ama bence asıl büyük sorun npm'in kötü yönetimiydi.
  Doğru hatırlıyorsam paketi maintainer'ın iradesine rağmen zorla geri yüklediler ve bu, npm'in temsil ettiğini söylediği topluluk düzleminden tamamen kopuk bir hareketti; en azından hukuken de tuhaftı.
  Sonrasında npm abuse, spam vb. yönetimine neredeyse hiç ilgi göstermedi (core.js reklam spam'i gibi) ve toplulukla standartlar ya da uyumluluk üzerine neredeyse hiç konuşmadı.
  npm@5 sürümü de büyük bir fiyaskoydu, package lockfile'ın gelişi de tam bir kargaşaydı.
  (Node ekibinin npm hazır olana kadar beklemeyip yayımlaması da bence doğru bir karardı.)
  O dönemde toplulukla iletişim büyük bug'lar, topluluğu suçlama ve buyurgan tavırlarla perişan durumdaydı.
  Bu da npm'in artık açık kaynak ruhunun temsilcisi olmadığının bir göstergesiydi.
  left-pad bunun öncesi miydi sonrası mıydı tam hatırlamıyorum ama o sırada tüm ekosistem uzun bir durgunluk ve karmaşa dönemindeydi.
  npm paketleri küçük fonksiyonlar için bile bağımsız paketler olarak, hatta bir meme gibi görülüyor ama bağlamı düşününce npm, emergent popular technology için ilk erişilebilir package manager'lardan biriydi; topluluk güdümlüydü ve GitHub ile de organik biçimde entegreydi.
  Bu, Node'un ilk dönemleriydi; ES5 bile yoktu, herkes var ve prototype kullanıyordu, Joyent daha Node.js'i topluluğa devretmemişti ve Io.js fork'u ile Node 0.10/0.12'nin uzun durgunluk döneminden de önceydi.
  Kimsenin en iyi uygulamanın ne olduğunu tam bilmediği bir zamandı.
  Yazarın bakış açısına gerçekten empati duyuyorum.
  Güvenlik açısından bakarsak left-pad olayı, istemeden de olsa ekosistemdeki şirketler/topluluklar arasındaki ayrışma gerçeği ve tedarik zinciri güvenliği konusunda büyük bir uyanış yarattı.
  Yedeklilik ve güvenlik üzerine önemli tartışmalar başlattı.
  Sonuçta sektörün daha iyiye gitmesine vesile olduğunu düşünüyorum.
  Uzun zaman sonra tekrar okumak ilginçti.

  npm herhangi bir dilin ilk package manager'ı değildi ve bu kadar küçük paketlerin çokluğu konusunda zaten birçok kişi uyarıda bulunmuştu.
  Bence npm ve genel olarak JS ekosistemi trend olmanın kurbanı oldu.

• left-pad zamanındaki ilgili tartışma
  Hacker News tartışması

• Java'da Apache Commons ve Google Guava gibi güvenilir utility library'ler varken JS'de neden benzeri yok?

  JavaScript'te de Lodash gibi güvenilir utility library'ler var. Geçmişe kıyasla çoğu işlev artık standart kütüphaneye girmiş durumda.
  Hatta Lodash, left-pad olayından 3 ay önce pad/padStart/padEnd işlevlerini sunuyordu.
  Lodash pad dokümantasyonu

  En önemli nedenin sırasıyla kültür, iyi tasarlanmış bir standart kütüphane ve 300'den fazla gereksiz paketi bağımlılıklara tıkıştırmayı engelleyen araçların eksikliği olduğunu düşünüyorum.

  Maven gerçekten çok iyi tasarlanmış bir araçtı; ironik biçimde sürekli sövülse de Java'nın başarısındaki gizli unsurlardan biriydi.
  npm benzeri ticari tavizlerin daha az olmasının sebebi, Java'da iyi desteklenen, kâr amacı gütmeyen ve topluluk temelli Apache Foundation gibi bir yapının bulunmasıydı. Böyle yapılar çok nadirdir ve Java'nın karmaşık hukuki geçmişinin ürettiği şanslı sonuçlardan biridir.
  (JS'de de harika kütüphaneler var. Sorun, paket yönetiminin aşırı merkezileşmiş ve kötü yönetilmiş olmasıydı.)

  Google Guava, left-pad'den ziyade lodash'a daha yakındır.

  Eskiden bu rolü jQuery ve Underscore gibi kütüphaneler üstlenirdi.

• Build için gereken tüm bağımlılıkları şirket içinde mirror'lamayan şirketler bana çok tuhaf geliyor.
  Tüm build sürecini offline clean build olarak çalıştırabiliyor olmanız gerekir; yalnızca download cache'e güvenmek işi şansa bırakmak demektir.

  Ben projelerimde her zaman dependencies'i içeriye vendor ederim.
  Böylece öngörülebilir olur, offline build alınabilir ve depolama maliyeti de ucuzdur.