มองย้อนเหตุการณ์ Left-Pad หลังผ่านมา 8 ปี (2024)

• เหตุการณ์ left-pad แม้ผ่านไป 8 ปีแล้ว ก็ยังคงเป็นกรณีตัวอย่างสำคัญเกี่ยวกับ dependency ของโอเพนซอร์สและสิทธิ์ในการจัดการแพ็กเกจ โดย Azer Koçulu ได้อธิบายการตัดสินใจในตอนนั้นอีกครั้ง
• การตัดสินใจทำให้เป็นส่วนตัวไม่ได้มาจากความโกรธหรือความโลภ แต่มาจาก การทบทวนตนเอง และบริบทสำคัญคือสถานการณ์ที่ NPM ละเมิดกฎที่ตนเองสร้างขึ้น
• เขามองว่า ภายใต้แรงกดดันจาก Kik Messenger นั้น NPM ให้ความสำคัญกับคุณค่าอื่นมากกว่าชุมชนโอเพนซอร์ส และการตัดสินนี้นำไปสู่การลบแพ็กเกจทั้งหมด
• สิ่งที่ถูกลบคือ แพ็กเกจกว่า 350 รายการ แต่เป็นเรื่องยากที่จะรู้ขอบเขตผลกระทบจริงจากสถิติการใช้งานและกิจกรรมบน GitHub เพียงอย่างเดียว
• หลังรันสคริปต์ของ NPM ประมาณ 10 นาที โปรเจกต์หลายตัวรวมถึง React ก็พัง และภายในไม่กี่ชั่วโมงโมดูลถูกกู้คืน สถานการณ์จึงกลับสู่ปกติ

---

การตัดสินใจในช่วงเหตุการณ์ left-pad

• ผ่านมา 8 ปี นับตั้งแต่เหตุการณ์ left-pad เกิดขึ้น และ Azer Koçulu เห็นว่าตลอดเวลาที่ผ่านมา การหลีกเลี่ยงหัวข้อนี้น่าจะดีกว่า เพื่อจะได้มุ่งกับงานจริง
• เขาตัดสินใจทำให้เป็นส่วนตัวในช่วงที่ใช้เวลาช่วงสุดสัปดาห์ส่วนใหญ่ของปี 2016 ไปกับการตั้งแคมป์ในพื้นที่ห่างไกลที่ไม่มีสัญญาณ
  • เขาอธิบายว่า นั่นไม่ใช่การเลือกที่มาจากตรรกะ ความโกรธ หรือความโลภ แต่เกิดจาก การทบทวนตนเอง และความรู้สึกภายในท่ามกลางธรรมชาติ
• หลักการตัดสินใจนั้นเรียบง่าย
  • ถ้า NPM ละเมิดกฎของตนเองและลบแพ็กเกจหนึ่งของเขาออกไป ตามมาตรฐานเดียวกันก็ควรลบแพ็กเกจทั้งหมดของเขาด้วย
• เขามองว่า เจตนารมณ์ เบื้องหลังกฎสำคัญกว่าตัวกฎเอง
  • เขายอมรับว่า ในบริบทอื่น อาจมีเหตุผลที่ดีในการเรียกร้องให้ลบแพ็กเกจโดยไม่ต้องได้รับอนุญาตจากเจ้าของ
  • แต่ในกรณีนี้ เขามองว่า Kik Messenger ใช้คำขู่เช่น “we’ll bang on your door”, “take down your accounts” เพื่อใช้อำนาจต่อชุมชนโอเพนซอร์สที่พึ่งพา NPM
• หากมองเหตุการณ์นี้แค่ว่า “คนโกรธคนหนึ่งประท้วงผลประโยชน์ของบริษัท” ก็จะพลาดประเด็นเรื่องวันที่ในอีเมลและไทม์ไลน์ สถานการณ์ที่ต้องยืนหยัดภายใต้แรงกดดัน และวิธีที่การตัดสินใจเปลี่ยนไปในสภาวะจิตสำนึกที่แตกต่างออกไป

กระบวนการลบและผลกระทบ

• เขามองว่า สำหรับ NPM แล้ว การลบไม่ใช่เรื่องกะทันหันหรือคาดไม่ถึง
  • ก่อนอื่น เขาขอให้ NPM ลบโมดูลของเขาออก และรอคำตอบ
  • เนื่องจากไม่ได้กำหนดเส้นตาย เขามองว่า NPM มีโอกาสปรับ API และเครื่องมือเพื่อให้การเปลี่ยนผ่านราบรื่นขึ้น
  • แต่ NPM กลับจัดเตรียม สคริปต์ ที่ลบแพ็กเกจทั้งหมดในคราวเดียว
• งานโอเพนซอร์สของเขาส่วนใหญ่เป็นแพ็กเกจขนาดเล็กที่ทำหน้าที่อย่างเดียวในแต่ละครั้ง ตามแนวคิดแบบ Unix philosophy
  • มีแพ็กเกจ มากกว่า 350 รายการ และทั้งหมดได้รับการปรับแต่งประสิทธิภาพและทดสอบแล้ว
  • จากภายนอกดูเหมือนไม่ได้รับความนิยม NPM ไม่ได้แสดงสถิติการใช้งาน และ 90% แทบไม่มีกิจกรรมบน GitHub
  • ในมุมของผู้ใช้ทั่วไป จึงยากที่จะรู้ว่าการทำให้เป็นส่วนตัวจะส่งผลอย่างไร
• หลังจากรันสคริปต์ที่ NPM ให้มา เขาออกไปจากที่นั่งไม่กี่นาที และภายในราว 10 นาที เพื่อนก็บอกเขาว่าเรื่องนี้กำลังเป็นประเด็นบน Twitter
  • หนึ่งในแพ็กเกจกว่า 350 รายการทำให้ React และโปรเจกต์หลายตัวพัง
  • หลังจากนั้นเขาเขียนบล็อกสั้น ๆ และส่งมอบงานโอเพนซอร์สของตน โดยโอนความเป็นเจ้าของ repository บน GitHub ให้กับอาสาสมัคร
  • ภายในไม่กี่ชั่วโมง โมดูลถูกกู้คืน และสถานการณ์กลับสู่ปกติ
• ไม่กี่เดือนต่อมา เขาลาออกจากงานและออกจากสหรัฐฯ อย่างถาวร โดยใช้เวลา 1 ปีใน Morocco, Jordan, Türkiye และ Indonesia
• สำหรับเขา left-pad เป็นช่วงเวลาเหมือน ความตายและการเกิดใหม่ ที่ส่วนหนึ่งของตัวตนซึ่งเคยผูกพันลึกซึ้งกับโอเพนซอร์สหายไป และมีสิ่งใหม่เข้ามาแทนที่ ปัจจุบันเขามีความหลงใหลในการสร้างและบริหารบริษัทพอ ๆ กับการเขียนโปรแกรม

[ndrgrd]

แม้จะเป็นเหตุการณ์ที่มีผลกระทบมาก แต่ถึงไม่ต้องอ่านบทความของผู้เขียนแพ็กเกจก็ยังคิดได้ว่าความผิดไม่ได้อยู่ที่เขาเป็นหลัก แต่อยู่ที่บริษัทและระบบที่พัวพันกันมากกว่า

[GN⁺]

ความคิดเห็นบน Hacker News

• ผมรู้สึกว่าครึ่งหนึ่งของบทความบล็อกพลาดบริบทไปเลยไม่ค่อยเข้าใจนัก แต่ก็ดีที่ ผู้เกี่ยวข้องกับ left-pad โดยตรง เป็นคนเขียนบทวิเคราะห์ย้อนหลัง
  อย่างไรก็ตาม ข้ออ้างที่ว่า “NPM ควรตรวจสอบว่าโมดูลของผมถูกใช้อย่างแพร่หลายหรือไม่ และควรพิจารณาวิธี unpublish โดยไม่ทำให้ของพัง” ฟังดูแปลก ๆ จริงอยู่ว่าการออกแบบฟีเจอร์ unpublish ของ NPM มีปัญหา แต่ถ้าหมายความว่าเขาคาดหวังให้พนักงานบริษัทมาตรวจสอบทุกอย่างด้วยมือทุกครั้งที่มีใคร unpublish ก็ดูไม่สมเหตุสมผลนัก บริษัท NPM ไม่ได้ทำหน้าที่คัดสรร registry แต่ใกล้เคียงกับการโฮสต์แบบบริการสาธารณะมากกว่า
  ถึงอย่างนั้นก็โทษผู้เขียนมากเกินไปได้ยาก ต่อให้เขาไม่ได้ก่อ เหตุการณ์ left-pad ขึ้น ไม่นานก็คงมีคนอื่นทำให้ปะทุอยู่ดี และ NPM ก็แก้ปัญหาด้วยนโยบาย unpublish ที่ดีกว่าเดิม: https://docs.npmjs.com/policies/unpublish#packages-published...

  • วันที่ 18 มีนาคม 2016 Isaac Z. Schlueter ซีอีโอของ npm, Inc. ส่งอีเมลถึงทั้ง Kik Interactive และ Koçulu ว่าจะโอน ความเป็นเจ้าของแพ็กเกจ kik ให้ Kik Interactive ด้วยมือ และเมื่อ Koçulu แสดงความผิดหวังพร้อมบอกว่าจะออกจากแพลตฟอร์ม Schlueter ก็ให้คำสั่งสำหรับลบโมดูล 273 รายการที่เขาลงทะเบียนไว้
    Koçulu เพียงแค่รันคำสั่งนั้นในวันที่ 22 มีนาคม 2016 เพื่อลบแพ็กเกจทั้งหมดที่ตนเคยเผยแพร่ และภายหลัง NPM ก็โยนความผิดจากความล้มเหลวของตัวเองไปให้ผู้เขียน
  • ดูบริบทได้ที่ https://en.wikipedia.org/wiki/Npm_left-pad_incident
  • จริง ๆ แล้ว NPM คัดสรร registry อยู่ โดยหลักคือแจ้งผู้บริโภคเกี่ยวกับช่องโหว่และลบแพ็กเกจอันตราย
  • สมัยก่อนตอนใช้ Sourceforge มีนโยบายว่าถ้าจะลบโปรเจกต์ต้องได้รับอนุญาตก่อน และ หลัง left-pad ผมก็เข้าใจเหตุผลนั้น

• ในฐานะคนที่หลีกเลี่ยง JavaScript และ ecosystem ของมันเหมือนโรคระบาด Visual Basic แห่งศตวรรษที่ 21 ส่วนที่น่าสนใจที่สุดในเรื่องนี้คือ Koçulu เคยเว้นระยะจากวงการเทคโนโลยีไปพักหนึ่ง ออกไปเดินป่า แคมป์ปิ้ง และสำรวจเทรลเจ๋ง ๆ แต่ ผ่านไป 8 ปี ก็ยังรู้สึกว่าต้องอธิบายตัวเองอยู่
  เทคโนโลยีเหมือนมิวส์ที่เอาแน่เอานอนไม่ได้ พวกเรา nerd หมกมุ่นกับเทคโนโลยีและบั่นทอนตัวเองในการรับใช้มัน แต่เทคโนโลยีก็มักเรียกเรากลับออกมาสู่แสงสว่างเสมอ
  ในฐานะคนที่อยู่ในเหตุการณ์ตอน Morris worm และทำงานอยู่หลายสัปดาห์เพื่อลดผลกระทบของมัน ผมคิดว่ามีปัญหาพื้นฐานในความสามารถของเราที่จะสร้างเทคโนโลยีซึ่งเปลี่ยนโลกด้วยเครื่องมือปัจจุบัน ยิ่งเราพยายามทำความเข้าใจความล้มเหลวเชิงองค์กรและจริยธรรมของเทคโนโลยีน้อยลง เทคโนโลยีก็ยิ่งสร้างความเปลี่ยนแปลงเชิงผลิตภาพในพื้นที่ที่มันถูกนำไปใช้ได้ยากขึ้น
  ผมเองก็คงจะได้ลาพักแบบ sabbatical ในอีกราวหนึ่งเดือน และหลังจากคอมไพล์ล้มเหลวอีกสักหลายร้อยครั้ง แล้วก็อดคิดไม่ได้ว่าเมื่อกลับมาในอีกไม่กี่ปี พื้นที่เทคโนโลยีที่ผมสร้างไว้ตามความต้องการ ในสเกลและบริบทที่ต่างออกไป จะมีหน้าตาเป็นอย่างไร
  บางทีการที่นักเทคโนโลยีลาพักแบบ sabbatical บ่อยขึ้นและจริงจังขึ้นควรกลายเป็นมาตรฐานในระดับหนึ่ง เพื่อให้เราได้บริบทสำหรับทำความเข้าใจภาวะกลืนไม่เข้าคายไม่ออกทางจริยธรรมที่กดทับศักยภาพทางเทคนิคของเรา

• เป็นเรื่องเล็กน้อย แต่ประโยคที่ว่า “งานโอเพนซอร์สส่วนใหญ่ทำตามปรัชญา Unix และแพ็กเกจทำงานอย่างเดียวในแต่ละครั้ง” นั้นคลุมเครือ
  ตัวอย่างที่ obvious ที่สุดคือโดยทั่วไปไม่มีใครมองว่า libc ขัดกับปรัชญา Unix ประเด็นถกเถียงมักอยู่ที่คำสั่งหรือ daemon ทำงานมากเกินไปหรือไม่ หรือ composable ไม่พอหรือไม่ ตัวอย่างเด่นช่วงหลังคือ systemd

  • ความวุ่นวายของ left-pad กลับแสดงให้เห็นว่า การแบ่งแพ็กเกจของ NPM ให้ย่อยมาก ๆ เล็กเกินไป จนมาถึงจุดที่ overhead ของการจัดการแพ็กเกจมีมากกว่าประโยชน์จากความเรียบง่ายของแพ็กเกจ
  • มีคนจำนวนไม่น้อยที่มองว่า libc ขัดกับปรัชญา Unix ถ้าต้องการ ผมจะพูดแบบนั้นตอนนี้ก็ได้
    libc สมัยใหม่ขัดกับปรัชญา Unix อยู่มาก libc ของ Unix แบบดั้งเดิมเรียบง่ายกว่านี้มาก และหลายฟังก์ชันก็เป็นเพียง system call ทุกวันนี้บางส่วนของ libc เคยถูกแยกเป็นไลบรารีต่างหากอย่าง libm และไม่มีสิ่งอย่าง NSS หรือเฟรมเวิร์กการ resolve DNS ที่ซับซ้อนเลย
  • อีกด้านของ “ทำสิ่งเดียว” คือเงื่อนไขที่ว่า ต้องทำสิ่งเดียวนั้นให้ครบทั้งหมด
  • ปรัชญา Unix อาจไร้ประโยชน์ หรือบางทีอาจเป็นอันตรายด้วยซ้ำ เพราะ “สิ่งเดียว” ไม่ได้ถูกนิยามไว้อย่างชัดเจน จึงไม่ได้เพิ่มอะไรจริง ๆ และมีแต่ก่อให้เกิดการถกเถียง
    Eclipse ก็อาจพูดได้ว่าทำ “สิ่งเดียวคือแพลตฟอร์ม IDE” แต่ผมไม่คิดว่านักพัฒนา Unix ตั้งใจหมายความแบบนั้น เช่นเดียวกันก็คงไม่ได้หมายความให้สร้างไลบรารีที่มีแค่ฟังก์ชัน 11 บรรทัดเดียว
    คำแนะนำที่แท้จริงควรเป็นประมาณว่า “โปรแกรมหรือไลบรารีไม่ควรพยายามทำมากเกินไปหรือน้อยเกินไป” ส่วนแค่ไหนเรียกว่ามากหรือน้อยเกินไป สุดท้ายก็ต้องอาศัย เซนส์และประสบการณ์ เหมือนแนวทางการเขียนโปรแกรมจำนวนมาก
  • ปรัชญา Unix เป็นปรัชญาที่บอกวิธีสร้างสภาพแวดล้อมการเขียนโปรแกรมแบบโต้ตอบที่ทรงพลังบนมินิคอมพิวเตอร์ 16 บิตซึ่งมีขนาด text segment สูงสุด 64KiB แต่ libc ที่ใช้บนโทรศัพท์ทุกวันนี้มีขนาด 1MiB ใหญ่กว่า 16 เท่า ดังนั้นอย่างน้อย 90% ของ libc ก็ขัดกับปรัชญา Unix
    หลังจากอ่าน Lions book หรือ APUE แล้วอีกด้านหนึ่งไปอ่านคู่มือ pthreads หรือสเปก setlocale() ของ ANSI C ดูแล้ว ไม่น่าจะสรุปได้ว่าสองอย่างนี้เป็นตัวแทนของปรัชญาเดียวกัน การมองแบบนั้นก็ประมาณกับบอกว่า Ayn Rand เป็นตัวแทนปรัชญาเดียวกับ Epicurus ซึ่งแปลว่าไม่ได้มีส่วนร่วมอย่างจริงจังกับฝ่ายใดฝ่ายหนึ่งเลย

• สิ่งที่ทิ้งร่องรอยชัดที่สุดจากเหตุการณ์นี้คือ คอมมูนิตี้ JavaScript พึ่งพา dependency มากเกินไป
  แค่ยกเลิกการเผยแพร่แพ็กเกจโค้ด 11 บรรทัด https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou... เอง แต่ไม่เข้าใจว่าทำไมถึงถูกตำหนิมากขนาดนั้น ในบทความก็พูดไว้เช่นกันว่าเขาไม่เข้าใจอย่างเต็มที่ว่ามันจะสร้างความสะดุดเสียหายใหญ่แค่ไหน
  NPM ไม่มีสถิติการใช้งาน และกิจกรรมบน GitHub ก็แทบไม่มี ดังนั้นจากมุมของผู้ใช้จึงไม่อาจรู้ได้ว่าการยกเลิกเผยแพร่แพ็กเกจจะมีผลกระทบเพียงใด ผมมองว่าสาเหตุรากฐานไม่ได้อยู่ที่ akoculu ถอนแพ็กเกจลงมา แต่ใกล้เคียงกับเรื่อง การพึ่งพา dependency มากเกินไป, นโยบายของ npm และฝั่งระบบ build ที่ไม่ cache หรือ vendor โค้ดไว้มากกว่า

• Azer Koçulu ไม่เคยเป็นภัยพิบัติของ ecosystem NPM ไม่มีใครบังคับให้ใช้ left-pad และเหตุผลที่มันเข้าไปอยู่ในโปรเจกต์จำนวนมากขนาดนั้นก็เพราะ transitive dependency ที่ยุ่งเหยิง
  ในทางกลับกัน Jon Schlinkert ดูเหมือนจะจงใจสร้างไมโครไลบรารีแบบนี้ ใส่มันเข้าไปใน handlebars-helpers ซึ่งเป็นโปรเจกต์ปกติที่ถูกใช้อย่างแพร่หลาย แต่กลับดูไม่มีความตั้งใจเลยที่จะรวมเข้าไปในโปรเจกต์ที่ใช้งานจริง ถ้าอยากโดนหลอกก็ใช้ handlebars-helpers ไป ไม่อย่างนั้นก็เลิกใช้ไลบรารีนั้นเสีย

  • แถมเขาแค่รันสคริปต์ที่ NPM เป็นผู้จัดหาให้โดยตรงเท่านั้น สถานการณ์ไมโครแพ็กเกจนั้นไร้สาระจริง แต่ Azer Koçulu ไม่ได้ทำอะไรผิด
    ปัญหาคือ NPM ยึดแพ็กเกจของเขาไปโดยบังคับ และจัดหาสคริปต์ที่ชัดเจนว่ามีอันตรายหากรัน การที่ Azer Koçulu ถูกตำหนินั้นเป็นเรื่องน่าขันเอง
    Jon Schlinkert ดูเหมือนคนสร้างความเดือดร้อนแบบสายการตลาดทั่วไป และโดยส่วนตัวคิดว่าควรถูกแบนจาก NPM และ Github

• ประวัติเวอร์ชันของ แพ็กเกจ kik ดูแปลก มันถูกแทนที่ด้วยแพ็กเกจยึดชื่อเพื่อความปลอดภัยเมื่อ 9 ปีก่อน: https://www.npmjs.com/package/kik?activeTab=versions

  • เรื่องย้อนแย้งที่สุดคือแพ็กเกจ kik ที่ Kik อยากได้อย่างยิ่งยวดนั้น สุดท้ายแทบไม่มีอะไรเลย
    Kik ปรากฏตัวว่าเป็นบริษัทที่สะเพร่าและค่อนข้างสกปรก มีประเด็นถกเถียงเรื่องคริปโทเคอร์เรนซีด้วย แต่แก่นที่จำได้คือใน Kik มีสื่อลามก โดยเฉพาะสื่อแสวงหาประโยชน์ทางเพศจากเด็ก แพร่ระบาด และมีพูดถึงในตอนนี้ของ Darknet Diaries ด้วย: https://darknetdiaries.com/episode/93/
    มองจากมุมนั้น การที่ Azer Koçulu บอกให้พวกเขาไปไกล ๆ ก็ค่อนข้างสะใจ
  • สุดท้ายแล้วเรื่องทั้งหมดนี้คงเกิดขึ้นเพื่อสิ่งที่ไม่มีอะไรเลยจริง ๆ

• การที่ left-pad เป็นแพ็กเกจนั้นก็น่าขำพอสมควร ทำให้นึกว่ามีไบต์จำนวนเท่าไรที่วิ่งผ่าน CDN, proxy, build pipeline ฯลฯ เพียงเพื่อใช้ฟังก์ชันยูทิลิตี้เล็กจิ๋วตัวหนึ่ง
  การใช้ประโยชน์จากวิธีแก้ปัญหาที่มีอยู่แล้วเป็นเรื่องดี แต่เวลาต้องการ padding สตริง แล้วคิดว่า “น่าจะมีแพ็กเกจสำหรับเรื่องนี้แหละ” นั้นไม่ค่อยเข้าใจเท่าไร

  • ส่วนหนึ่งของการถกเถียงในตอนนั้นมีแนวโน้มว่า นี่เป็นสัญญาณเตือนที่จำเป็นอย่างยิ่งสำหรับเว็บดีเวลลอปเปอร์ที่พึ่งพา ไมโครแพ็กเกจ อย่าง left-pad ไม่รู้จบ
    ยังมีวัฒนธรรมการปล่อยแพ็กเกจเพื่อให้ได้รับความนิยมและ GitHub stars และก็มีนักพัฒนาที่ยืนกรานว่าถ้าเขียนเองในสิ่งที่ติดตั้งผ่าน NPM ได้คือ “การประดิษฐ์ล้อขึ้นใหม่” ทุกวันนี้ก็ยังทำงานกับนักพัฒนาจำนวนมากที่ชอบไมโครแพ็กเกจแม้กับฟังก์ชันเรียบง่าย สำหรับพวกเขาแล้วมันหมายถึง “ลดภาระบำรุงรักษา”
  • implementation ดั้งเดิมของแพ็กเกจ https://en.wikipedia.org/wiki/Npm_left-pad_incident ก็ดูเหมือนจะมีพฤติกรรมเป็น O(n²) ไม่ใช่ O(n) ตามที่ต้องการ
  • ผมสงสัยว่าความแตกต่างเชิงคุณภาพระหว่างการหยิบฟังก์ชันยูทิลิตี้ที่ใครสักคนเขียนไว้แล้วในโปรเจกต์มาใช้ กับการหยิบแพ็กเกจที่ใครสักคนเผยแพร่ไว้แล้วใน ecosystem มาใช้นั้นใหญ่ขนาดนั้นจริงหรือ
    แน่นอนว่าสองอย่างนี้ไม่เหมือนกัน แต่ถ้ามีเครื่องมือที่พัฒนามากพอ ก็ดูไม่ได้ห่างไกลกันจนถึงขั้นไม่เข้าใจว่าทำไมคนถึงอยากจัดการทั้งสองอย่างให้คล้ายกัน
  • ตอนนี้ AI ก็คงคล้ายกันไม่ใช่หรือ มี prompt มากแค่ไหนที่แก้ได้ด้วยการค้นเว็บธรรมดา
    ก็แค่เพิ่มขั้นตอนจากการ copy-paste เท่านั้นเอง
  • เป็นการอวดการ reuse โค้ดขั้นสุด และ copy-paste เป็นสิ่งที่พวก loser เท่านั้นทำ

• มีตอนหนึ่งที่ว่า “ฝั่ง NPM แสดงท่าทีโดยรวมที่ดูถูกนักพัฒนา และสิ่งนั้นก่อให้เกิดการตัดสินใจไร้เหตุผลเป็นชุด ก่อนจะโยนค่าใช้จ่ายทั้งหมดมาให้ผมรับผิด” แต่ดูเหมือนว่าแม้หลังเหตุการณ์นี้ NPM ก็ไม่ได้เรียนรู้อะไรมากนัก

• ดีแล้วที่เหตุการณ์นี้เกิดขึ้น การจองชื่อไว้ก่อน เป็นปัญหาจริง และเมื่อกำกวม ควรเลือกทางที่ทำให้ผู้ใช้ประหลาดใจน้อยที่สุด
  การไม่มีสถิติการใช้งานก็เป็นปัญหาใหญ่ และการที่สามารถยกเลิกเผยแพร่ได้เฉย ๆ ก็เป็นปัญหาใหญ่เช่นกัน การที่ infrastructure ต้องพึ่งพาโค้ดเล็ก ๆ 10 บรรทัดที่สร้างโดยปัจเจกบุคคลที่มีความเห็นแรงก็เป็นปัญหาจริง ทั้งในตอนนั้นและตอนนี้ ในสถานการณ์นี้คงพูดยากว่ามีใครต้องรับผิดจริง ๆ และไม่มีใครติดหนี้ใคร แต่ทุกคนสามารถเรียนรู้ได้

• จากมุมมองของคนที่ดูแลแพ็กเกจ npm ระดับ top-10 อยู่หลายตัว บทความนี้สมเหตุสมผลอย่างยิ่ง
  ตั้งแต่จุดหนึ่งเป็นต้นมา NPM ก็เลิกทำงานร่วมกับชุมชนไปแล้ว เรื่องนี้ยิ่งชัดขึ้นหลัง Microsoft เข้าซื้อ แต่จริง ๆ แล้วเห็นได้ชัดมาก่อนหน้านั้นนานแล้ว
  วิธีดำเนินงานของ npm มีรอยร้าวอยู่มาก ไม่ค่อยทำงานร่วมกับชุมชนหรือทีม Node สายหลัก และการผลักดันไปสู่ความยั่งยืนเชิงพาณิชย์ก็ให้ความรู้สึกน่ารำคาญและกดดันมาก สมาชิกในทีมหลายคนก็มีชื่อเสียงที่ค่อนข้างแข็งกร้าว
  เคยไปเยี่ยมสำนักงานที่ Oakland ด้วย มีปฏิสัมพันธ์ที่ค่อนข้างน่าสนใจหลายอย่าง และไม่ได้เป็นแง่บวกเป็นพิเศษ แต่ขอละรายละเอียดไว้
  ตอนนั้นช่องโหว่เรื่องการยกเลิกการเผยแพร่เป็นที่รู้กันดี ทุกคนกล่าวโทษว่า left-pad ทำอินเทอร์เน็ตพัง แต่แทบไม่มีใครเอาผิด ความรับผิดชอบของ npm ที่บริหารจัดการเรื่องทั้งหมดอย่างผิดพลาดร้ายแรง
  ถ้าจำไม่ผิด npm บังคับกู้คืนแพ็กเกจโดยขัดกับเจตนาของผู้ดูแล ซึ่งถ้ามองในแง่ดีก็คือการตัดขาดจากคนที่พวกเขาอ้างว่ารับใช้ และถ้ามองในแง่ร้ายก็ยังน่าสงสัยทางกฎหมายด้วย หลังจากนั้นไม่นาน พวกเขาก็แทบไม่ใส่ใจการใช้แพลตฟอร์มในทางที่ผิด มีเรื่องอย่างสแปมโฆษณา core.js และไม่ได้ทำงานร่วมกับชุมชนอย่างเหมาะสมในเรื่องมาตรฐาน ความเข้ากันได้ ฯลฯ
  รีลีส npm@5 เป็นหายนะ การนำไฟล์ล็อกแพ็กเกจเข้ามาใช้คงจะแย่ไปกว่านั้นไม่ได้แล้ว และเท่าที่จำได้มีแรงกดดันให้ปล่อยออกมาให้ทันกับเมเจอร์รีลีสถัดไปของ Node.js รู้สึกเหมือนทีม Node ไม่ได้รอให้ npm พร้อม ซึ่งเมื่อคิดว่า npm เป็นบริษัทแสวงหากำไร หรืออย่างน้อยก็ทำตัวแบบนั้น ผมกลับคิดว่านั่นเป็นเรื่องดีเสียอีก
  การตอบสนองต่อชุมชนในช่วงที่มีบั๊กวิกฤตร้ายแรงไม่รู้จบ ท่าทีที่ทำให้ชุมชนที่กดดันต้องรู้สึกอับอาย และท่าทางทำตัวเหมือนเคร่งศีลธรรม เป็นหลักฐานว่า npm ไม่ได้เป็นตัวแทนของซอฟต์แวร์เสรีและโอเพนซอร์สอีกต่อไปแล้ว จำไม่ได้ว่า left-pad เกิดก่อนหรือหลังเรื่องนั้น แต่ในหัวผม มันยังคงเป็นส่วนหนึ่งของกระแสการเสื่อมถอยยาวนานของระบบนิเวศ
  ตอนนี้แพ็กเกจ npm กลายเป็นมีมของแพ็กเกจเล็ก ๆ ที่ทำงานจิ๊บจ๊อย และทุกคนก็ล้อเลียนมัน มองย้อนกลับไป มันอาจไม่ใช่สิ่งที่ดีที่สุด แต่บริบทเป็นเรื่องสำคัญ npm เป็น package manager ตัวแรกที่เข้าถึงได้ง่ายมากสำหรับเทคโนโลยียอดนิยมที่กำลังเกิดใหม่ แทบทั้งหมดถูกดูแลโดยชุมชน มีระบบค้นหาที่ดี และเชื่อมโยงอย่างใกล้ชิดกับจิตวิญญาณ “social coding” ของ GitHub
  มันมีอยู่ตั้งแต่ยุคแรก ๆ ของ Node ตอนที่แม้แต่ ES5 ก็ยังไม่มี เป็นยุคที่ใช้ var กับ prototype กัน แนวปฏิบัติที่ดีของ JavaScript ก็ยังไม่มีจริง ๆ ยังเป็นช่วงก่อนที่ Joyent จะส่งมอบ Node.js ให้ชุมชน และก่อนจะหลุดพ้นจาก fork อย่าง Io.js รวมถึงช่วงหยุดชะงักยาวนานของ Node 0.10/0.12
  ไม่มีใครรู้ว่าวิธีที่ดีที่สุดคืออะไร
  ผมเข้าใจผู้เขียนอย่างเต็มที่ จากมุมมองด้านความปลอดภัย ผมรู้สึกขอบคุณจริง ๆ ที่เกิด left-pad ขึ้น แม้ผู้เขียนอาจไม่ได้ตั้งใจเช่นนั้น แต่มันแสดงให้ผู้คนเห็นอย่างชัดเจนว่าอันตรายอะไรเกิดขึ้นได้เมื่อพึ่งพา ผลประโยชน์ขององค์กร ที่แยกขาดจากชุมชนที่พวกเขาอ้างว่ารับใช้ มันเริ่มบทสนทนามากมายเกี่ยวกับความปลอดภัยของซัพพลายเชน ความซ้ำซ้อนสำรอง และเรื่องอื่น ๆ และในระยะยาวก็ทำให้อุตสาหกรรมดีขึ้นเล็กน้อย

  • npm ไม่ใช่ package manager ตัวแรกสำหรับภาษาโปรแกรม และหลายคนก็ชี้ให้เห็นอยู่แล้วว่าแพ็กเกจที่เล็กขนาดนั้นเป็นเรื่องโง่
    npm และ JavaScript โดยรวม ส่วนใหญ่เป็น เหยื่อของกระแสแฟชั่น