Left-Pad (2024)

• vụ việc left-pad là một ví dụ tiêu biểu cho thấy xung đột giữa quy tắc và giá trị trong cộng đồng mã nguồn mở, NPM và các doanh nghiệp
• Quyết định xóa gói không xuất phát từ lý trí, cơn giận hay lòng tham, mà là hành động bắt nguồn từ sự chân thành và các nguyên tắc nội tâm
• Trong bối cảnh NPM phá vỡ chính các quy tắc của mình khi nhượng bộ yêu cầu từ Kik Messenger, tác giả đã chọn xóa toàn bộ các gói của mình
• Sau sự việc, đam mê dành cho mã nguồn mở đã thay đổi, và sự quan tâm chuyển sang những lĩnh vực mới như kinh doanh, marketing và vận hành đội ngũ
• vụ việc left-pad trở thành dịp để các lập trình viên và giới startup suy ngẫm lại về bản chất của mã nguồn mở và tính phức tạp của việc ra quyết định

---

Bối cảnh sự việc và quyết định

• Ở thời điểm đã 8 năm trôi qua kể từ vụ việc left-pad, tác giả chia sẻ trải nghiệm và suy nghĩ cá nhân của mình
• Vào thời điểm đó, ông dành phần lớn thời gian giữa thiên nhiên, nơi không có sóng liên lạc để tự nhìn lại bản thân, và quyết định xóa gói cũng được đưa ra trong quá trình này
• Quyết định này không bắt nguồn từ phán đoán logic, cơn giận hay lòng tham, mà từ nguyên tắc bên trong của bản thân, tức niềm tin rằng: "Nếu NPM phá vỡ các quy tắc của chính họ, thì tất cả các gói của tôi cũng nên bị xóa"
• Thay vì là một người theo "chủ nghĩa quy tắc" cứng nhắc, đó là thái độ coi trọng tinh thần của quy tắc hơn bản thân quy tắc
• Trong tình huống các doanh nghiệp như Kik Messenger đe dọa cộng đồng mã nguồn mở và sử dụng quyền lực, NPM đã phớt lờ các quy tắc do chính mình đặt ra và ưu tiên lợi ích doanh nghiệp

Cấu trúc xung đột giữa NPM và cộng đồng

• Tác giả không sợ những lời đe dọa từ Kik, nhưng NPM lại sợ mất Kik
• Việc diễn giải sự việc một cách đơn giản là "một người đàn ông tức giận chống lại tập đoàn lớn" là cái nhìn giản lược, bỏ qua bối cảnh, diễn tiến theo thời gian và sức nặng của quyết định
• Phía NPM, dù đây không phải chuyện đột ngột hay ngoài dự đoán, vẫn nhìn chung thể hiện thái độ trịch thượng với lập trình viên, đồng thời đẩy toàn bộ trách nhiệm sang tác giả thông qua một loạt quyết định thiếu nhất quán

Cấu trúc gói và tác động

• Công việc mã nguồn mở của tác giả chủ yếu được chia thành những vai trò nhỏ theo triết lý Unix, nên được cấu thành từ hơn 350 gói
• Bề ngoài hầu như không có nhiều dấu vết sử dụng, nhưng vì NPM không công khai thống kê sử dụng, nên không thể xác định phạm vi ảnh hưởng
• Người dùng không có cách nào biết tác động lan tỏa thực sự của việc xóa gói, và bản thân NPM cũng không nỗ lực điều tra mức độ ảnh hưởng hay ngăn chặn các vấn đề do việc xóa bừa bãi gây ra

Thay đổi và trưởng thành sau 8 năm

• Vài tháng sau vụ việc left-pad, tác giả nghỉ công việc chính, rời Mỹ và bắt đầu tìm con đường của riêng mình trong những môi trường mới như Morocco, Jordan, Türkiye và Indonesia
• Ông trải qua khoảnh khắc như cái chết khi đam mê dành cho mã nguồn mở bị đứt gãy, rồi lại được tái sinh thành những mối quan tâm mới
• Hiện tại, ông dành cho kinh doanh, marketing, vận hành công ty và đội ngũ cùng nhiều lĩnh vực khác niềm đam mê tương đương với lập trình
• Gửi gắm thông điệp rằng cuộc sống vẫn tiếp diễn, tác giả xem vụ việc left-pad là dịp để nhìn lại những quyết định tự do, các giá trị của cộng đồng và tính phức tạp của quá trình ra quyết định

[ndrgrd]

Đây là một sự kiện có ảnh hưởng rất lớn, nhưng ngay cả khi không đọc bài viết của tác giả gói đó, tôi vẫn nghĩ lỗi nằm ở các công ty và hệ thống liên quan nhiều hơn là ở bản thân anh ấy.

[GN⁺]

Ý kiến trên Hacker News

• Nói thật thì tôi có cảm giác không hiểu rõ một nửa bài blog này đang nói gì, như thể đã bỏ lỡ mất ngữ cảnh nào đó, nhưng tôi thích điểm là "left pad guy" tự mình sắp xếp lại toàn bộ sự việc
  Tuy nhiên, những tuyên bố như sau lại có vẻ hơi kỳ lạ

  Nhưng tôi vẫn không hiểu vì sao NPM không xem xét các module của tôi được dùng nhiều đến mức nào, và không nghĩ cách xử lý việc unpublishing sao cho không làm hỏng gì cả
  Dĩ nhiên cách unpublish của NPM khi đó đúng là được thiết kế tệ, nhưng điều tác giả nói nghe như thể anh ấy mong ai đó sẽ kiểm tra thủ công mỗi lần có người unpublish. Kỳ vọng như vậy không có vẻ hợp lý. Tôi xem NPM không phải là một tổ chức đi tuyển chọn registry, mà là một bên cung cấp dịch vụ công cộng
  Dù vậy, cũng khó mà trách tác giả; tôi nghĩ nếu tác giả không gây ra "left-pad incident" thì sớm muộn gì cũng sẽ có người khác làm điều đó. NPM đã sửa vấn đề và cũng đưa ra chính sách unpublish tốt hơn
  Tham khảo thêm: chính sách unpublish mới của NPM

  • Việc bạn nói rằng mình không hiểu một nửa bài blog này
    là vì bạn vẫn chưa đọc al-Ghazali.
    (Đây là phần ngạo mạn và lấy mình làm trung tâm nhất trong bài)

  • Có thể xem thêm bối cảnh tại Wikipedia về vụ Npm left-pad incident

  • Vào ngày 18 tháng 3 năm 2016, CEO của npm là Isaac Z. Schlueter đã gửi email cho cả Kik Interactive lẫn Koçulu để thông báo rằng quyền sở hữu gói kik sẽ được chuyển thủ công sang Kik Interactive
    Khi Koçulu bày tỏ sự thất vọng với quyết định của npm và nói rằng không còn muốn tham gia vào nền tảng nữa, Schlueter đã cung cấp cho anh ta một lệnh để xóa toàn bộ 273 module đã đăng ký
    Koçulu đã chạy lệnh đó vào ngày 22 tháng 3 và xóa toàn bộ các package mình từng đăng
    Tác giả chỉ đơn giản là chạy lệnh mà phía NPM trực tiếp chỉ cho, nhưng sau đó NPM lại đổ toàn bộ trách nhiệm lên đầu tác giả

  • Công ty NPM không tuyển chọn registry NPM
    Thực tế là có, ví dụ như họ nhận báo cáo lỗ hổng bảo mật rồi cảnh báo người dùng, hoặc xóa các package độc hại

  • Hồi trước khi dùng Sourceforge, họ có chính sách là phải xin phép trước khi xóa project
    Sau vụ left-pad thì tôi đã hiểu rất rõ vì sao lại như vậy

• Một chuyện nhỏ thôi nhưng

  Các project mã nguồn mở của tôi hầu hết đi theo triết lý Unix, tức các package được thiết kế để mỗi cái chỉ làm một việc tại một thời điểm
  Không ai nói libc đi ngược triết lý Unix cả. Tranh cãi thường chỉ nổ ra khi command hay daemon có quá nhiều chức năng hay không (systemd là ví dụ tiêu biểu), hoặc liệu chúng có kém khả năng kết hợp hay không

  • Tôi nghĩ vụ left-pad là một ví dụ cho thấy sự phân mảnh package trong NPM đã đi quá xa, đến mức overhead lớn hơn rất nhiều so với lợi ích của việc đơn giản hóa package

  • Không ai nói libc đi ngược triết lý Unix
    Thực ra đã có rất nhiều người nói như vậy, và bản thân tôi cũng cho là đúng
    libc hiện đại hoàn toàn khác với triết lý Unix truyền thống
    libc ngày xưa đơn giản hơn nhiều, nhiều chức năng được tách sang các thư viện riêng như libm, và cũng không có những thứ phức tạp như DNS

  • Điều đối lập với 'do one thing' là, 'hãy làm trọn vẹn hẳn một việc'
  • Triết lý Unix là bộ hướng dẫn để tạo ra một môi trường lập trình tương tác mạnh mẽ trên các minicomputer 16-bit
    libc tôi đang dùng trên điện thoại hiện nay có kích thước 1MiB, tức lớn gấp 16 lần Unix truyền thống
    Kết luận là ít nhất 90% của libc đi ngược triết lý Unix
    Sau khi đọc Lions Book hay APUE rồi xem manual của pthreads hoặc đặc tả ANSI C của setlocale(), bạn sẽ thấy đó là những triết lý hoàn toàn khác nhau
    Nếu coi chúng là một, thì đó là bằng chứng rằng bạn không thực sự đồng cảm nghiêm túc với bất kỳ triết lý nào trong hai bên
  • "Triết lý Unix" là một triết lý vô dụng, thậm chí có thể có hại
    Vì ý nghĩa của 'one thing' không rõ ràng nên trên thực tế nó chẳng giúp ích gì, chỉ gây tranh cãi
    Eclipse cũng có thể bị xem là chỉ làm 'một việc là IDE', nhưng rõ ràng đó không phải điều các nhà phát triển Unix muốn nói tới
    Nó cũng không có nghĩa là hãy tạo ra thư viện chỉ có các hàm dài 11 dòng
    Lời khuyên thực sự nên là: "đừng để chương trình hay thư viện làm quá nhiều nhưng cũng đừng quá ít"
    Còn thế nào là nhiều, thế nào là ít thì rốt cuộc vẫn là vấn đề của kinh nghiệm và cảm giác

• Cảm ơn akoculu đã viết bài này
  Tôi nghĩ đây là một ví dụ rất rõ ràng cho cộng đồng JavaScript, tức một hệ sinh thái phụ thuộc quá nhiều vào dependency
  Tôi không hiểu vì sao nhiều người lại đổ lỗi cho bạn đến vậy
  Bạn chỉ unpublish một package có 11 dòng code, và có lẽ cũng không thể lường hết toàn bộ tác dụng phụ của việc đó
  Chính tác giả cũng nói rõ trong bài

  NPM cũng không hiển thị thống kê sử dụng tốt, mà trên Github thì gần như không có hoạt động nào
  Từ góc nhìn người dùng, rất khó biết việc unpublish package sẽ có mức ảnh hưởng lớn đến đâu
  Tôi cho rằng nguyên nhân gốc rễ không nằm ở hành động unpublish của akoculu mà ở việc lạm dụng dependency, chính sách npm, và việc build system thiếu caching/vendoring
  Tham khảo: wiki về bối cảnh sự cố

• Lịch sử version của package kik trông rất kỳ lạ
  Nó đã bị thay bằng một package giữ chỗ bảo mật từ 9 năm trước
  Lịch sử version của package kik

  Sự mỉa mai lớn nhất của vụ này chính là package kik
  Package kik mà phía kik cố giành cho bằng được rốt cuộc lại chẳng có ích gì
  Và công ty Kik cũng lộ ra là một nơi cẩu thả và đầy vấn đề
  Từng có tranh cãi liên quan đến crypto, và còn bị nhắc đến âm thầm như một nền tảng phát tán nội dung như ấu dâm
  Tham khảo: Darknet Diaries tập 93
  Vì vậy việc Azer Koçulu cứng rắn từ chối Kik lại khiến tôi thấy khá hả dạ

  Vậy rốt cuộc toàn bộ chuyện này... cuối cùng lại chẳng có ý nghĩa gì sao?

• Việc left-pad tồn tại dưới dạng một package tự nó đã khá buồn cười
  Chỉ vì một hàm padding chuỗi mà phải có một lượng byte khổng lồ di chuyển qua CDN, proxy, build pipeline v.v.
  Tôi đồng ý với chuyện tận dụng tốt các giải pháp sẵn có, nhưng thật khó hiểu khi người ta lại nghĩ "chắc sẽ có package cho việc này" chỉ để điền thêm vào đầu chuỗi

  Một phần tranh luận hồi đó đã trở thành lời cảnh tỉnh trước sự ám ảnh mù quáng của dân web với các micro-package
  Cũng từng có văn hóa phát hành package để lấy độ nổi tiếng, lấy GitHub star
  Mặt khác, cũng có một văn hóa rất mạnh là hễ thứ gì cài được qua npm thì bất kỳ hàm nào cũng không muốn tự triển khai nữa
  Nhiều lập trình viên hiện đang làm việc với tôi đến giờ vẫn thích cả những package rất đơn giản
  Lý lẽ của họ là "giảm gánh nặng bảo trì"
  Một thực tế thật mỉa mai

  Có vẻ như ngay cả implementation gốc của package này cũng gây ra thao tác kém hiệu quả O(n^2) chứ không phải O(n)
  Xem thêm trên wiki

  Liệu có khác biệt lớn về chất lượng giữa việc tham khảo một hàm tiện ích trong project của người khác và việc dùng một package đã lan rộng khắp hệ sinh thái không?
  Chúng không giống hệt nhau, nhưng trong một môi trường có tooling đủ trưởng thành, tôi nghĩ hai cách tiếp cận này trên thực tế không cách nhau xa lắm

  Hiện tượng cố tái sử dụng code tối đa, như thể copy-paste là phương pháp đã lỗi thời

  Chẳng phải chuyện này hơi giống AI sao?
  Những việc chỉ cần search đơn giản cũng lại mang đi hỏi AI với vô số prompt
  Một cấu trúc chỉ là chồng thêm một bước không cần thiết lên C&P

• Triết lý Unix là "làm tốt một việc"
  left-pad đã bỏ lỡ điều kiện thứ hai (làm cho tốt)
  Tôi ngạc nhiên khi nhiều project đến vậy lại dùng nguyên một implementation ngây thơ như thế
  Một implementation tối ưu hơn có thể vừa nhanh hơn vừa nhỏ hơn

  Tôi không hiểu rõ văn hóa JavaScript lắm, nhưng tôi nhớ từng tồn tại xu hướng cạnh tranh tăng số lượt tải npm
  left-pad có 1,4 triệu lượt tải mỗi tuần, còn is-even là 160 nghìn
  Có người thêm micro-package vào dependency để đùa vui, có người làm vậy để nâng chỉ số phổ biến của thư viện
  Cũng từng có ý kiến phản đối việc nhét các package như is-even vào bên trong những thư viện nổi tiếng dùng React
  Vì tồn tại kiểu nguyên tắc cứng nhắc rằng "code tự viết được thì cũng cứ kéo về dùng"
  Câu chuyện liên quan: vì sao package is-odd được cài gần 3 triệu lần trong một tuần

  Tôi tò mò về ví dụ của 'implementation không ngây thơ'

• Tôi là maintainer của một package npm phổ biến
  Tôi thực sự đồng cảm
  Từ một thời điểm nào đó, npm bắt đầu rời xa sự cộng tác của cộng đồng
  Sau khi được Microsoft mua lại thì điều đó càng trở nên cố định hơn, nhưng ngay trước đó cũng đã có nhiều dấu hiệu
  Nhiều cách vận hành của npm, thái độ thiếu hợp tác với cộng đồng/đội Node, sự tập trung quá mức vào thương mại hóa, danh tiếng của một số thành viên, v.v. đều khiến người ta khó chịu theo nhiều cách
  Tôi nhớ có lần ghé văn phòng ở Oakland, và vì trải nghiệm tương tác hôm đó không mấy tích cực nên tôi sẽ không kể chi tiết
  Lỗ hổng unpublish là vấn đề mà ai khi đó cũng biết
  Mọi người đều đổ hết cho tác giả theo kiểu 'left-pad đã phá hỏng internet', nhưng thực ra tôi nghĩ vấn đề lớn hơn nằm ở việc npm vận hành tệ
  Nếu tôi nhớ không nhầm, package đã bị khôi phục cưỡng ép trái với ý muốn của chính maintainer, và đó là một động thái hoàn toàn tách rời khỏi mức độ cộng đồng mà npm tự nhận là đại diện (ít nhất xét về mặt pháp lý cũng khá kỳ quặc)
  Sau đó npm gần như không còn quan tâm đến việc quản lý abuse, spam, v.v. nữa (như quảng cáo spam của core.js), và cũng hầu như không tham gia thảo luận với cộng đồng về chuẩn hay khả năng tương thích
  Việc phát hành npm@5 cũng là một thất bại lớn, và chuyện đưa lockfile vào package cũng đầy hỗn loạn
  (Tôi thậm chí còn cho rằng đội Node đã đúng khi không chờ npm sẵn sàng rồi mới phát hành)
  Giao tiếp với cộng đồng vào thời điểm đó là một mớ hỗn độn với bug lớn, đổ lỗi cho cộng đồng, và thái độ bề trên
  Đó là bằng chứng cho thấy npm không còn là đại diện của tinh thần mã nguồn mở nữa
  Tôi không nhớ rõ left-pad xảy ra trước hay sau giai đoạn đó, nhưng khi ấy toàn bộ hệ sinh thái đang ở trong thời kỳ trì trệ và hỗn loạn kéo dài
  Package npm thường bị coi như những package độc lập cho các hàm vặt vãnh, gần như thành meme, nhưng nếu nhìn lại bối cảnh thì npm là package manager đầu tiên dễ tiếp cận dành cho một công nghệ đang nổi lên, được vận hành theo kiểu cộng đồng, và còn tích hợp hữu cơ với GitHub
  Đó là giai đoạn đầu của Node, khi còn chưa có ES5 và vẫn dùng var, prototype, thậm chí trước cả lúc Joyent giao Node.js cho cộng đồng, trước cả đợt fork Io.js và thời kỳ Node 0.10/0.12 đình trệ quá lâu
  Khi ấy không ai thực sự biết best practice nên là gì
  Tôi thật sự đồng cảm với góc nhìn của tác giả
  Nếu nhìn từ góc độ bảo mật, vụ left-pad là một cú thức tỉnh lớn về thực tế rằng các doanh nghiệp/cộng đồng trong hệ sinh thái bị tách rời nhau ngoài ý muốn, cũng như về bảo mật chuỗi cung ứng
  Nó đã khơi mào cho những cuộc thảo luận quan trọng về tăng cường tính dư thừa và an ninh
  Tôi nghĩ xét cho cùng đó là một bước ngoặt giúp ngành đi lên theo hướng tốt hơn
  Đọc lại sau thời gian dài vẫn thấy thú vị

  npm không phải package manager đầu tiên của bất kỳ ngôn ngữ nào, và cũng đã có nhiều người cảnh báo về việc tồn tại quá nhiều package nhỏ kiểu này
  Tôi nghĩ npm và toàn bộ hệ sinh thái JS nói chung là nạn nhân của xu hướng nhất thời

• Các thảo luận liên quan vào thời điểm left-pad
  Thảo luận trên Hacker News

• Vì sao Java có các thư viện tiện ích đáng tin cậy như Apache Commons, Google Guava mà JS lại không có?

  JavaScript cũng có các thư viện tiện ích đáng tin như Lodash. So với trước đây thì phần lớn chức năng giờ đã có trong thư viện chuẩn
  Thực tế Lodash đã cung cấp pad/padStart/padEnd từ 3 tháng trước khi vụ left-pad xảy ra
  Tài liệu Lodash pad

  Tôi nghĩ nguyên nhân quan trọng nhất lần lượt là văn hóa, rồi đến một thư viện chuẩn được thiết kế tốt, rồi đến việc có hay không có công cụ ngăn người ta nhét hơn 300 package vô dụng vào dependency

  Maven thực sự là một công cụ được thiết kế rất tốt (một cách mỉa mai là lúc nào cũng bị chửi), và là một trong những bí quyết thành công của Java
  Lý do Java không phải chấp nhận những thỏa hiệp thương mại kiểu npm là vì họ có Apache Foundation, một tổ chức phi lợi nhuận dựa trên cộng đồng được hỗ trợ rất tốt (kiểu cấu trúc này cực kỳ hiếm, và là kết quả may mắn nhờ lịch sử pháp lý phức tạp của Java)
  (JS cũng có nhiều thư viện tuyệt vời. Vấn đề là việc quản lý package bị tập trung hóa quá mức và quản trị lại kém)

  Google Guava gần với lodash hơn, chứ không giống left-pad

  Ngày trước các thư viện như Jquery, Underscore từng đảm nhiệm vai trò đó

• Tôi thật sự thấy khó hiểu khi có quá nhiều công ty không mirror toàn bộ dependency cần cho build trong nội bộ
  Toàn bộ quá trình build đáng lẽ phải có thể clean build trong môi trường offline, còn chỉ dựa vào download cache thì chẳng khác nào phó mặc cho may rủi

  Trong project của tôi, tôi luôn vendor các dependency vào nội bộ
  Như vậy sẽ dự đoán được, build được cả khi offline, mà chi phí lưu trữ cũng rẻ