Left-Pad olayına 8 yıl sonra bakış (2024)

 (azerkoculu.com)
1 puan yazan GN⁺ 2025-06-12 | 2 yorum | WhatsApp'ta paylaş
  • left-pad olayı, 8 yıl sonra bile açık kaynak bağımlılıkları ve paket yönetimi yetkileri etrafında anılan başlıca örneklerden biri olmayı sürdürüyor; Azer Koçulu o dönemki kararını yeniden açıklıyor
  • Gizliye alma kararı öfke ya da açgözlülükten çok öz değerlendirme sonucu alınmış bir seçimdi; temel arka plan, NPM’in kendi koyduğu kuralları ihlal etmesiydi
  • Kik Messenger’ın baskısı altında NPM’in açık kaynak topluluğundan ziyade başka değerleri öncelediğini düşünüyor; bu yargı tüm paketlerin silinmesine yol açtı
  • Silinecekler 350’den fazla paketti, ancak kullanım istatistikleri ve GitHub etkinliği tek başına gerçek etki alanını anlamaya yetmiyordu
  • NPM betiği çalıştırıldıktan yaklaşık 10 dakika sonra React dahil birçok proje bozuldu; birkaç saat içinde modüller geri yüklendi ve durum normale döndü

left-pad olayı sırasındaki karar

  • left-pad olayının üzerinden 8 yıl geçti; Azer Koçulu, gerçek işlerine odaklanmak için bu konudan uzak durmanın daha iyi olduğunu düşünüyordu
  • 2016’da çoğu hafta sonunu sinyalin çekmediği ücra yerlerde kamp yaparak geçirdiği dönemde gizliye alma kararını verdi
    • Bunun mantık, öfke ya da açgözlülükten değil, doğanın içindeki öz değerlendirmeden ve içinden gelen bir seçim olduğunu açıklıyor
  • Kararın ilkesi basitti
    • NPM kendi kurallarını çiğneyip onun paketlerinden birini kaldırıyorsa, aynı ölçüte göre tüm paketlerini de kaldırmalıydı
  • Kuralların kendisinden çok, kuralların arkasındaki ruhun daha önemli olduğunu düşünüyordu
    • Başka bir bağlamda, iyi gerekçelerle sahibinin izni olmadan bir paketin silinmesini talep etmenin mümkün olabileceğini kabul ediyor
    • Ancak bu durumda Kik Messenger’ın “we’ll bang on your door”, “take down your accounts” gibi tehditlerle NPM tabanlı açık kaynak topluluğu üzerinde güç kullandığını düşünüyor
  • Olayı yalnızca “öfkeli bir kişi şirket çıkarlarını protesto etti” diye görmek; e-posta tarihlerini ve zaman çizelgesini, baskı altında direnme hâlini ve farklı bir bilinç durumunda kararların nasıl şekillendiğini gözden kaçırmak anlamına geliyor

Silme süreci ve etkisi

  • NPM açısından silmenin ani ya da beklenmedik bir olay olmadığını düşünüyor
    • Önce NPM’den modüllerini kaldırmasını istedi ve yanıt bekledi
    • Bir son tarih belirlemediği için NPM’in API’yi ve araçları ayarlayarak geçişi yumuşatma fırsatı olduğunu düşünüyor
    • Bunun yerine NPM, tüm paketleri tek seferde kaldıran bir betik sağladı
  • Kendi açık kaynak çalışmaları çoğunlukla Unix felsefesi gibi tek seferde tek iş yapan küçük paketlerden oluşuyordu
    • Paket sayısı 350’den fazlaydı ve hepsi optimize edilmiş ve test edilmişti
    • Dışarıdan bakıldığında popüler görünmüyorlardı; NPM kullanım istatistiklerini göstermiyordu ve %90’ında GitHub etkinliği de neredeyse yoktu
    • Sıradan bir kullanıcı açısından gizliye almanın nasıl bir etki yaratacağını bilmek zordu
  • NPM’in verdiği betiği çalıştırdıktan sonra birkaç dakikalığına yerinden ayrıldı; yaklaşık 10 dakika içinde bir arkadaşı Twitter’da gündem olduğunu haber verdi
    • 350’den fazla paket içinden biri React’i ve birçok projeyi bozdu
    • Ardından kısa bir blog yazısı yazdı ve açık kaynak çalışmalarını devretti; GitHub depo sahipliğini gönüllülere aktardı
    • Birkaç saat içinde modüller geri yüklendi ve durum normale döndü
  • Birkaç ay sonra işinden ayrıldı ve ABD’den kalıcı olarak çıktı; Fas, Ürdün, Türkiye ve Endonezya’da 1 yıl geçirdi
  • left-pad, açık kaynağa derinden bağlı olan bir parçasının yok olup yerine yeni bir şeyin geçtiği ölüm ve yeniden doğuş gibi bir andı; bugün programlama kadar şirket kurma ve işletmeye de tutkuyla bağlı

İlgili okumalar

2 yorum

 
ndrgrd 2025-06-12

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⁺ 2025-06-12
Hacker News yorumları

  • Blog yazısının yarısı bağlamı kaçırmış gibi geldiği için pek anlayamadım, ama left-pad’in doğrudan tarafı olan kişinin bir olay sonrası analiz yazması iyi olmuş
    Yine de “NPM modülümün yaygın kullanılıp kullanılmadığını kontrol etmeli ve bozmadan yayından kaldırmanın bir yolunu düşünmeliydi” iddiası tuhaf geliyor. NPM’in yayından kaldırma özelliğinin tasarımının hatalı olduğu doğru, ama biri her yayından kaldırma yaptığında şirket çalışanlarının hepsini elle incelemesini beklediği anlamına geliyorsa bu makul görünmüyor. NPM şirketi registry’yi kürate etmekten çok, onu kamu hizmeti gibi barındırmaya daha yakın
    Yine de yazarı çok suçlamak zor. O left-pad olayını başlatmamış olsaydı bile çok geçmeden başka biri bunu patlatacaktı ve NPM sorunu daha iyi bir yayından kaldırma politikasıyla düzeltti: https://docs.npmjs.com/policies/unpublish#packages-published...

    • 18 Mart 2016’da npm, Inc. CEO’su Isaac Z. Schlueter hem Kik Interactive’e hem de Koçulu’ya e-posta göndererek kik paketinin sahipliğini elle Kik Interactive’e devredeceğini söyledi; Koçulu hayal kırıklığını dile getirip platformdan ayrılacağını söyleyince Schlueter ona kayıtlı 273 modülü silen komutu sağladı
      Koçulu 22 Mart 2016’da bu komutu çalıştırıp yalnızca yayımladığı tüm paketleri kaldırdı; daha sonra NPM kendi başarısızlıklarını yazarın üzerine yıktı
    • Bağlam için https://en.wikipedia.org/wiki/Npm_left-pad_incident sayfasına bakılabilir
    • NPM registry’yi gerçekten kürate eder. Bunu çoğunlukla tüketicileri güvenlik açıkları konusunda bilgilendirerek ve kötü amaçlı paketleri kaldırarak yapar
    • Eskiden Sourceforge kullanırken bir projeyi silmek için önce izin alınmasını gerektiren bir politika vardı; left-pad’den sonra bunun nedenini anladım

  • JavaScript’ten ve ekosisteminden 21. yüzyılın Visual Basic vebasıymış gibi uzak duran biri olarak, bu hikâyenin en ilginç yanı Koçulu’nun bir süre teknoloji dünyasından uzaklaşıp harika yürüyüşler, kamp gezileri ve patika keşifleri yapmasına rağmen 8 yıl sonra bile hâlâ kendini açıklamak zorunda hissetmesi
    Teknoloji kaprisli bir ilham perisi gibi. Biz nerd’ler teknolojiye takıntılıyız ve ona hizmet ederken kendimizi yıpratıyoruz, ama teknoloji bizi her zaman yeniden ışığa çağırıyor
    Morris worm sırasında sahada olan ve etkilerini azaltmak için haftalarca çalışan biri olarak, mevcut araçlarla dünyayı değiştiren teknolojiler üretme becerimizde temel bir sorun olduğunu düşünüyorum. Teknolojinin örgütsel ve etik başarısızlıklarını anlamaya ne kadar az çaba harcarsak, teknoloji uygulandığı alanlarda üretken bir değişim yaratmakta o kadar zorlanıyor
    Ben de artık yaklaşık bir ay ve birkaç yüz derleme hatası sonra bir sabbatical’a çıkacak gibiyim; birkaç yıl sonra döndüğümde, ihtiyaçlarıma göre başka ölçek ve bağlamlarda kurduğum teknoloji alanının nasıl görüneceğini düşünüyorum
    Belki de teknologların daha sık ve daha ciddi biçimde sabbatical yapması bir ölçüde standart hâline gelmeli. Böylece teknik kapasitemizi ezen etik ikilemleri anlamak için bağlam kazanabiliriz

  • Küçük bir nokta ama “çoğu açık kaynak çalışması Unix felsefesini izliyordu ve paketler tek seferde tek bir iş yapıyordu” cümlesi muğlak
    En bariz örnek olarak, libc’nin Unix felsefesine aykırı olduğunu düşünen pek kimse yoktur. Tartışma, komutların ya da daemon’ların çok fazla iş yapıp yapmadığı veya birleştirilebilir olup olmadığı üzerinden döner. Yakın dönemin tipik örneği systemd’dir

    • left-pad yaygarası daha çok NPM paket parçalanmasının aşırı küçüldüğünü; paket sadeliğinin faydalarından çok paket yönetimi overhead’inin ağır bastığı noktaya gelindiğini gösterdi
    • libc’nin Unix felsefesine aykırı olduğunu düşünen epey kişi var. İsterseniz şu anda ben de bunu söyleyebilirim
      Modern libc, Unix felsefesine ciddi biçimde ters düşer. Geleneksel Unix’in libc’si çok daha basitti ve birçok fonksiyon sadece sistem çağrısıydı. Bugün libc’nin bazı parçaları libm gibi ayrı kütüphanelere bölünmüştü; NSS ya da karmaşık DNS çözümleme framework’leri ise hiç yoktu
    • “Tek bir iş yap” ilkesinin diğer tarafında, o tek işin tamamını yapması şartı vardır
    • Unix felsefesi işe yaramaz, hatta belki zararlı bile olabilir. Çünkü “tek bir şey” iyi tanımlanmamıştır; pratikte hiçbir şey katmayıp yalnızca tartışma doğurur
      Eclipse’in de “IDE platformu denen tek bir işi” yaptığı söylenebilir, ama Unix geliştiricilerinin bunu kastettiğini sanmıyorum. Aynı şekilde 11 satırlık tek bir fonksiyon içeren kütüphane yapın demek de değildi herhalde
      Asıl tavsiye “programlar ya da kütüphaneler ne çok fazla ne de çok az şey yapmaya çalışmalı” gibi bir şey olmalı. Neyin çok fazla ya da çok az olduğu ise nihayetinde pek çok programlama yönergesinde olduğu gibi sezgi ve deneyim gerektirir
    • Unix felsefesi, maksimum metin segmenti boyutunun 64KiB olduğu 16 bitlik minibilgisayarlarda güçlü bir etkileşimli programlama ortamı elde etmenin yolunu anlatan bir felsefedir. Bugün telefonda kullandığınız libc 1MiB ile 16 kat daha büyük olduğuna göre, en azından libc’nin %90’ı Unix felsefesine aykırıdır
      Lions book’u ya da APUE’yi okuyup, diğer yandan pthreads kılavuzunu veya ANSI C’nin setlocale() belirtimini okuduktan sonra bu ikisinin aynı felsefeyi temsil ettiği sonucuna varmak mümkün görünmüyor. Bu, Ayn Rand’ı Epicurus’la aynı felsefenin temsilcisi saymak düzeyinde; yani ikisinden hiçbirine ciddi biçimde temas etmemiş olmak demek

  • Bu olaydan geriye en güçlü kalan şey, JavaScript topluluğunun bağımlılıklara fazla bağımlı hale gelmiş olmasıydı.
    Yalnızca 11 satırlık bir kod paketi https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou... yayından kaldırılmışken neden bu kadar çok suçlama yöneltildiğini anlamıyorum. Yazıda, bunun ne kadar büyük bir hayal kırıklığı yaratacağını tam olarak kavramadığı da söyleniyor.
    NPM’de kullanım istatistikleri yoktu ve GitHub etkinliği de neredeyse yoktu; bu yüzden kullanıcı açısından paketi yayından kaldırmanın etkisini bilmek mümkün değildi. Temel nedenin akoculu’nun paketi kaldırması değil, daha çok aşırı bağımlılık, npm politikası ve kodu cache’lemeyen ya da vendor etmeyen build sistemleri olduğunu düşünüyorum.

  • Azer Koçulu, NPM ekosistemi için hiçbir zaman bir felaket olmadı. Kimse kimseyi left-pad kullanmaya zorlamadı; bu kadar çok projeye girmesinin nedeni dağınık geçişli bağımlılıklardı.
    Buna karşılık Jon Schlinkert bu tür mikro kütüphaneleri bilerek yapıyor, yaygın kullanılan düzgün bir proje olan handlebars-helpers’a koyuyor ama bunları gerçekten kullanan projelere entegre etme niyeti hiç yok gibi görünüyor. Tuzağa düşmek istiyorsanız handlebars-helpers kullanın; istemiyorsanız o kütüphaneyi kullanmayı bırakın.

    • Üstelik o sadece NPM’in doğrudan sağladığı script’i çalıştırdı. Mikro paket durumu saçmaydı, evet; ama Azer Koçulu’nun yaptığı yanlış bir şey yoktu.
      Sorun, NPM’in onun paketini zorla devralması ve çalıştırıldığında tehlikeli olacağı açık olan bir script sağlamasıydı. Azer Koçulu’nun suçlanmış olması başlı başına gülünç.
      Jon Schlinkert tipik pazarlama tarzı rahatsızlık veren biri gibi görünüyor; kişisel olarak NPM ve Github’dan yasaklanması gerektiğini düşünüyorum.

  • kik paketinin sürüm geçmişi tuhaf. 9 yıl önce güvenlik amaçlı rezerve edilmiş bir paketle değiştirilmiş: https://www.npmjs.com/package/kik?activeTab=versions

    • En büyük ironi, Kik’in o kadar umutsuzca istediği kik paketinin sonunda fiilen hiçbir şey olmaması.
      Kik dikkatsiz ve epeyce çirkin bir şirket olarak ortaya çıktı. Kripto para ile ilgili tartışmaları da vardı, ama hatırladığım asıl nokta Kik’te pornografinin, özellikle de çocukların cinsel istismar materyallerinin yaygın olduğuydu; bu Darknet Diaries bölümünde de ele alınıyor: https://darknetdiaries.com/episode/93/
      Bu açıdan bakınca Azer Koçulu’nun onlara defolup gitmelerini söylemesi oldukça iç rahatlatıcı.
    • Sonuçta bütün bunlar hiçbir şey uğruna yaşanmış gibi görünüyor.

  • left-pad’in bir paket olması başlı başına oldukça komik. Çok küçük bir yardımcı fonksiyonu kullanmak için CDN’ler, proxy’ler, build pipeline’ları vb. üzerinden kaç bayt gidip gelmiştir diye düşündürüyor.
    Mevcut çözümlerden yararlanmak iyi ama string padding gerektiğinde “muhtemelen bunun için bir paket vardır” diye düşünmeyi pek anlayamıyorum.

    • O dönemdeki tartışmaların bir kısmı, left-pad gibi mikro paketlere durmadan bağımlı olan web geliştiricileri için gerekli bir uyarı olduğu yönündeydi.
      Popülerlik kazanmak ve GitHub stars almak için paket yayımlama kültürü de vardı; NPM ile kurulabilen bir şeyi kendisi uygulayanlara “tekerleği yeniden icat ediyor” diye direten geliştiriciler de vardı. Bugün bile basit işlevler için mikro paketleri tercih eden birçok geliştiriciyle çalışıyorum; onlar için bu “bakım yükünün azalması” demek.
    • Paketin özgün implementasyonu https://en.wikipedia.org/wiki/Npm_left-pad_incident da istenen O(n) yerine O(n²) davranışa dönüşmüş gibi görünüyor.
    • Bir projede birinin zaten yazmış olduğu yardımcı fonksiyonu alıp kullanmakla, ekosistemde birinin zaten yayımladığı paketi alıp kullanmak arasındaki niteliksel fark gerçekten bu kadar büyük mü diye düşünüyorum.
      İkisi elbette aynı değil, ama yeterince gelişmiş araçlar varsa insanların ikisini benzer şekilde ele almak istemesini anlayamayacak kadar da birbirinden uzak görünmüyorlar.
    • Şimdiki yapay zeka da buna benzemiyor mu? Basit bir web aramasıyla çözülebilecek kaç prompt var?
      Kopyala-yapıştırın üzerine sadece bir adım daha eklenmiş hali.
    • Kod yeniden kullanımının en üst düzey gösterisi; kopyala-yapıştır ise kaybedenlerin işi.

  • “NPM tarafında geliştiricileri küçümseyen genel bir tavır gördüm; bu da bir dizi mantıksız karara yol açtı ve sonunda tüm maliyeti benim üstüme yıkmalarına neden oldu” gibi bir bölüm var; NPM’in bu olaydan sonra da pek bir şey öğrenmemiş olduğu anlaşılıyor.

  • Bu olayın yaşanmış olması iyi oldu. İsim kapma gerçek bir sorun ve tereddütlü durumlarda kullanıcıyı en az şaşırtacak taraf seçilmeli.
    Kullanım istatistiklerinin olmaması da büyük sorundu; paketin öylece yayından kaldırılabilmesi de büyük sorundu. Altyapının, güçlü görüşleri olan bir bireyin yazdığı önemsiz 10 satırlık koda bağımlı olması da hem o zaman hem bugün gerçek bir sorun. Bu durumda gerçekten birini sorumlu tutmak zor; kimsenin kimseye borcu yok, ama herkes bundan bir şey öğrenebilir.

  • En popüler 10 npm paketinden birkaçını bakımını yapan biri olarak bakınca bu yazı tamamen mantıklı geliyor
    Bir noktadan sonra NPM toplulukla iş birliği yapmamaya başladı. Microsoft’un satın almasıyla bu durum kesinleşti ama bundan çok daha önce zaten belliydi
    npm’in işleyiş biçiminde çok sayıda çatlak vardı; toplulukla ya da ana Node ekibiyle de iyi iş birliği yapmıyordu ve ticari sürdürülebilirliğe doğru bu zorlaması çok rahatsız edici ve dayatmacı hissettiriyordu. Ekip üyelerinden bazılarının da biraz sert bir itibarı vardı
    Oakland ofislerini de ziyaret etmiştim; oldukça ilginç etkileşimler olmuştu ve özellikle olumlu değildi, ama ayrıntılara girmeyeyim
    O dönemde yayından kaldırma açığı iyi biliniyordu. Herkes left-pad’in interneti bozduğunu söyleyerek suçladı, ama tüm bu süreci ciddi biçimde kötü yönetenin npm’in sorumluluğu olduğunu sorgulayan çok az kişi vardı
    Yanlış hatırlamıyorsam npm, bakımcısının isteğine rağmen paketi zorla geri getirdi; bu, iyi tarafından bakınca hizmet ettiğini iddia ettiği insanlardan kopuk olduğunu, kötü tarafından bakınca ise hukuken de şüpheli bir durum olduğunu gösteriyordu. Hemen sonrasında platform suistimaline de pek önem vermemeye başladılar; core.js reklam spam’i gibi şeyler yaşandı, standartlar ve uyumluluk gibi konularda da toplulukla düzgün iş birliği yapmadılar
    npm@5 sürümü bir felaketti. Paket kilit dosyalarının devreye alınışı daha kötü olamazdı; hatırladığım kadarıyla bunu bir sonraki büyük Node.js sürümüne yetiştirme baskısı vardı. Node ekibi npm’in hazır olmasını beklememiş gibi hissettirmişti; npm’in kâr amaçlı bir şirket olduğunu ya da en azından öyle davrandığını düşününce, bunun aslında iyi bir şey olduğunu düşünüyorum
    Bitmek bilmeyen kritik hataların yaşandığı dönemde topluluğa verilen tepki, baskı yapan topluluğu utandırma tavrı ve kendini erdemli gösterme hali, npm’in artık özgür ve açık kaynak yazılımın bir temsilcisi olmadığının kanıtıydı. left-pad’in bunun öncesinde mi sonrasında mı olduğunu hatırlamıyorum, ama zihnimde ekosistemin uzun süreli düşüşünün tek bir akışı olarak kaldı
    Bugün npm paketleri, önemsiz işler yapan küçük paketler mem’ine dönüştü ve herkes bununla dalga geçiyor. Geriye dönüp bakınca bu en iyi yol olmayabilir. Ama bağlam önemli. npm, yeni yükselen popüler bir teknoloji için ilk son derece erişilebilir paket yöneticisiydi; neredeyse tamamen topluluk tarafından yönetiliyordu, arama sistemi iyiydi ve GitHub’ın “sosyal kodlama” ruhuyla da yakından entegreydi
    Node’un ilk dönemlerinde vardı; ES5’in bile olmadığı, var ve prototype kullandığımız zamanlardı. JavaScript için doğru düzgün en iyi uygulamalar da yoktu; Joyent’ın Node.js’i topluluğa devretmesinden önceydi ve Io.js fork’u ile Node 0.10/0.12’nin uzun durgunluğundan çıkılmadan önceki dönemdi
    Kimse en iyi yöntemin ne olduğunu bilmiyordu
    Yazarı tamamen anlıyorum. Güvenlik açısından bakınca left-pad’in yaşanmış olmasına gerçekten minnettarım. Yazarın niyeti bu olmasa bile, hizmet ettiğini iddia ettikleri topluluktan kopuk şirket çıkarlarına bağımlı olunduğunda ne tür riskler doğduğunu insanlara çok net gösterdi. Tedarik zinciri güvenliği, yedeklilik ve benzeri konularda pek çok tartışma başlattı ve uzun vadede sektörü biraz daha iyi hale getirdi

    • Programlama dilleri için ilk paket yöneticisi de değildi ve bu kadar küçük paketlerin aptalca olduğu noktasını zaten pek çok kişi dile getirmişti
      npm ve genel olarak JavaScript esasen modanın kurbanı