Nhìn lại vụ việc Left-Pad sau 8 năm (2024)
(azerkoculu.com)- Vụ việc left-pad vẫn là một trường hợp tiêu biểu về phụ thuộc mã nguồn mở và quyền kiểm soát quản lý gói ngay cả sau 8 năm, và Azer Koçulu giải thích lại quyết định của mình khi đó
- Quyết định chuyển sang riêng tư không xuất phát từ tức giận hay lòng tham mà là một lựa chọn đến từ sự tự phản tỉnh, và bối cảnh cốt lõi là NPM đã phá vỡ các quy tắc do chính họ đặt ra
- Ông cho rằng dưới áp lực từ Kik Messenger, NPM đã ưu tiên những giá trị khác hơn cộng đồng mã nguồn mở, và phán đoán đó đã dẫn đến việc xóa toàn bộ gói
- Đối tượng bị xóa là hơn 350 gói, nhưng chỉ với thống kê sử dụng và hoạt động GitHub thì rất khó biết được phạm vi ảnh hưởng thực tế
- Sau khi chạy script của NPM khoảng 10 phút, nhiều dự án như React đã bị hỏng, nhưng trong vài giờ module đã được khôi phục và tình hình trở lại bình thường
Phán đoán vào thời điểm vụ việc left-pad xảy ra
- Đã 8 năm trôi qua kể từ khi vụ việc left-pad xảy ra, và Azer Koçulu cho rằng trong thời gian qua tốt hơn là tránh chủ đề này để tập trung vào công việc thực tế
- Ông đưa ra quyết định chuyển sang riêng tư vào năm 2016, trong giai đoạn dành phần lớn các cuối tuần để cắm trại ở nơi hẻo lánh không có sóng
- Ông giải thích rằng đó không phải là quyết định đến từ logic, tức giận hay lòng tham, mà là lựa chọn đến từ sự tự phản tỉnh giữa thiên nhiên và từ chính nội tâm
- Nguyên tắc phán đoán rất đơn giản
- Nếu NPM phá vỡ quy tắc của chính họ để gỡ bỏ một gói của ông, thì theo cùng tiêu chuẩn đó, toàn bộ các gói của ông cũng phải được gỡ bỏ
- Ông xem tinh thần đằng sau quy tắc còn quan trọng hơn bản thân quy tắc
- Ông thừa nhận rằng trong bối cảnh khác, có thể có lý do chính đáng để yêu cầu xóa gói mà không cần sự cho phép của chủ sở hữu
- Tuy nhiên trong trường hợp này, ông cho rằng Kik Messenger đã dùng những lời đe dọa như “we’ll bang on your door”, “take down your accounts” để áp đặt sức mạnh lên cộng đồng mã nguồn mở dựa trên NPM
- Nếu chỉ nhìn sự việc như “một người đang tức giận phản đối lợi ích doanh nghiệp”, thì sẽ bỏ lỡ ngày tháng email, dòng thời gian, tình huống phải chịu áp lực, và cách quyết định thay đổi trong một trạng thái ý thức khác
Quá trình xóa và tác động
- Theo quan điểm của ông, từ phía NPM, việc xóa không phải là điều đột ngột hay không thể dự đoán
- Trước tiên, ông đã yêu cầu NPM gỡ các module của mình và chờ phản hồi
- Vì không đặt ra hạn chót, ông cho rằng NPM đã có cơ hội điều chỉnh API và công cụ để quá trình chuyển đổi diễn ra êm hơn
- Thay vào đó, NPM cung cấp một script để xóa tất cả các gói cùng lúc
- Phần lớn công việc mã nguồn mở của ông là các gói nhỏ làm một việc tại một thời điểm, theo triết lý Unix
- Có hơn 350 gói và tất cả đều được tối ưu hóa và kiểm thử
- Bề ngoài chúng có vẻ không phổ biến, NPM không hiển thị thống kê sử dụng, và 90% gần như cũng không có nhiều hoạt động trên GitHub
- Từ góc nhìn của người dùng thông thường, rất khó biết việc chuyển sang riêng tư sẽ gây ra tác động gì
- Sau khi chạy script do NPM cung cấp, ông rời chỗ vài phút, và trong khoảng 10 phút một người bạn báo rằng nó đã trở thành chủ đề nóng trên Twitter
- Một trong hơn 350 gói đã làm hỏng React và nhiều dự án khác
- Sau đó ông viết một bài blog ngắn và chuyển giao công việc mã nguồn mở của mình, đồng thời chuyển quyền sở hữu các kho GitHub cho các tình nguyện viên
- Trong vòng vài giờ, module đã được khôi phục và mọi thứ trở lại bình thường
- Vài tháng sau, ông nghỉ việc và rời Mỹ vĩnh viễn, rồi dành một năm ở Morocco, Jordan, Türkiye, Indonesia
- left-pad là một khoảnh khắc giống như cái chết và sự tái sinh, khi một phần con người ông từng gắn bó sâu sắc với mã nguồn mở biến mất và điều mới mẻ xuất hiện; hiện tại ông có đam mê với việc xây dựng và vận hành công ty cũng nhiều như với lập trình
2 bình luận
Đâ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.
Ý kiến trên Hacker News
Tôi cảm thấy một nửa bài blog bị thiếu ngữ cảnh nên không hiểu rõ lắm, nhưng việc chính người trong cuộc của left-pad viết một bài phân tích hậu sự kiện là điều tốt
Tuy vậy, lập luận rằng “NPM lẽ ra nên kiểm tra xem module của tôi có được dùng rộng rãi không, và cân nhắc cách unpublish mà không làm hỏng mọi thứ” nghe có vẻ lạ. Đúng là thiết kế tính năng unpublish của NPM có vấn đề, nhưng nếu ý là mỗi khi ai đó unpublish thì kỳ vọng nhân viên công ty rà soát thủ công toàn bộ, thì có vẻ không hợp lý. NPM với tư cách một công ty không hẳn là curated registry, mà gần với việc host như một dịch vụ công cộng hơn
Dù vậy cũng khó trách tác giả quá nặng. Ngay cả nếu anh ấy không gây ra sự cố left-pad, chẳng bao lâu sau cũng sẽ có người khác làm nổ ra chuyện tương tự, và NPM đã sửa vấn đề bằng chính sách unpublish tốt hơn: https://docs.npmjs.com/policies/unpublish#packages-published...
Koçulu chỉ chạy lệnh đó vào ngày 22/3/2016 để gỡ bỏ tất cả các package mình đã phát hành, và về sau NPM lại đổ lỗi thất bại của họ cho tác giả
Với tư cách một người tránh JavaScript và hệ sinh thái của nó như né một thứ dịch Visual Basic của thế kỷ 21, phần thú vị nhất trong câu chuyện này là dù Koçulu đã có một thời gian giữ khoảng cách với giới công nghệ, đi hiking, camping và khám phá trail rất tuyệt, 8 năm sau anh ấy vẫn cảm thấy phải tự giải thích về mình
Công nghệ giống như một nàng thơ thất thường. Chúng ta, những nerd, bị ám ảnh bởi công nghệ và tự bào mòn mình khi phụng sự nó, nhưng rồi công nghệ luôn gọi ta trở lại ánh sáng
Là người từng có mặt lúc Morris worm xảy ra và đã làm việc vài tuần để giảm tác động của nó, tôi cho rằng có một vấn đề căn bản trong năng lực tạo ra công nghệ có thể thay đổi thế giới bằng các công cụ hiện nay. Càng ít nỗ lực hiểu các thất bại mang tính tổ chức và đạo đức của công nghệ, công nghệ càng khó tạo ra thay đổi có tính sản xuất trong những lĩnh vực mà nó được áp dụng
Có lẽ khoảng một tháng nữa, và thêm vài trăm lần compile thất bại nữa, tôi cũng sẽ nghỉ sabbatical, và tôi tự hỏi vài năm sau khi quay lại, không gian công nghệ mà tôi đã tạo ra ở một quy mô và bối cảnh khác để phù hợp với nhu cầu của mình sẽ trông như thế nào
Có lẽ việc các kỹ sư công nghệ nghỉ sabbatical thường xuyên hơn và nghiêm túc hơn nên trở thành một chuẩn mực ở mức nào đó. Như vậy chúng ta mới có được bối cảnh để hiểu các thế lưỡng nan đạo đức đang đè nặng lên năng lực kỹ thuật của mình
Một điểm nhỏ thôi, nhưng câu “phần lớn công việc mã nguồn mở tuân theo triết lý Unix, và mỗi package làm một việc” khá mơ hồ
Ví dụ obvious nhất là libc: thường không ai xem nó là đi ngược triết lý Unix. Tranh luận thường nằm ở chỗ một lệnh hay daemon có làm quá nhiều việc hay không, hoặc có composable hay không. Ví dụ tiêu biểu gần đây là systemd
libc hiện đại đi ngược khá nhiều với triết lý Unix. libc của Unix truyền thống đơn giản hơn nhiều, và nhiều hàm chỉ là system call. Một số phần của libc ngày nay từng được tách ra thành thư viện riêng như libm, còn những thứ như NSS hay framework phân giải DNS phức tạp thì hoàn toàn không có
Có thể nói Eclipse cũng “làm một việc là nền tảng IDE”, nhưng tôi không nghĩ các nhà phát triển Unix nói theo nghĩa đó. Tương tự, chắc họ cũng không có ý bảo hãy tạo một thư viện chỉ chứa một hàm 11 dòng
Lời khuyên thực tế nên là “chương trình hay thư viện không nên cố làm quá nhiều, cũng không nên làm quá ít”. Mức nào là quá nhiều hay quá ít cuối cùng, giống như nhiều chỉ dẫn lập trình khác, cần cảm giác và kinh nghiệm
Sau khi đọc Lions book hay APUE, rồi ở phía khác đọc manual pthreads hoặc đặc tả
setlocale()của ANSI C, có vẻ không thể kết luận rằng hai bên đại diện cho cùng một triết lý. Điều đó cũng giống như xem Ayn Rand là đại diện cùng một triết lý với Epicurus, tức là bạn không thật sự nghiêm túc tiếp xúc với bên nào trong hai bên đóĐiều đọng lại mạnh nhất từ sự kiện này là cộng đồng JavaScript đã phụ thuộc quá mức vào dependency
Chỉ là hủy công bố một package mã 11 dòng https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou... mà tôi không hiểu vì sao lại bị chỉ trích nhiều đến vậy. Bài viết cũng nói rằng anh ấy đã không hoàn toàn hiểu việc đó sẽ gây ra sự thất vọng lớn đến mức nào
NPM không có thống kê sử dụng và hoạt động trên GitHub cũng gần như không có, nên từ góc nhìn người dùng thì không thể biết tác động của việc hủy công bố package. Tôi cho rằng nguyên nhân gốc rễ không hẳn là việc akoculu gỡ package xuống, mà gần hơn với phụ thuộc quá mức, chính sách của npm, và các hệ thống build không cache hay vendor code
Azer Koçulu chưa từng là thảm họa của hệ sinh thái NPM. Không ai ép dùng left-pad, và lý do nó lọt vào nhiều dự án như vậy là do phụ thuộc bắc cầu lộn xộn
Ngược lại, Jon Schlinkert cố ý tạo ra những micro-library kiểu này, đưa chúng vào handlebars-helpers, một dự án bình thường được dùng rộng rãi, nhưng lại có vẻ hoàn toàn không có ý định tích hợp chúng vào dự án thực sự sử dụng. Nếu muốn bị câu thì dùng handlebars-helpers, còn không thì ngừng dùng thư viện đó là được
Vấn đề là NPM đã cưỡng ép lấy package của anh ấy, và cung cấp một script mà rõ ràng là nguy hiểm nếu chạy. Việc Azer Koçulu bị chỉ trích tự nó đã buồn cười
Jon Schlinkert trông như kiểu nhân vật gây phiền toái theo lối marketing điển hình, và cá nhân tôi nghĩ nên bị cấm khỏi NPM và Github
Lịch sử phiên bản của package kik khá lạ. Nó đã được thay thế bằng một package chiếm giữ vì mục đích bảo mật 9 năm trước: https://www.npmjs.com/package/kik?activeTab=versions
Kik lộ ra là một công ty bất cẩn và khá bẩn thỉu. Cũng có tranh cãi liên quan đến tiền mã hóa, nhưng điều cốt lõi tôi nhớ là trên Kik tràn lan nội dung khiêu dâm, đặc biệt là tài liệu bóc lột tình dục trẻ em, và tập Darknet Diaries này cũng đề cập đến việc đó: https://darknetdiaries.com/episode/93/
Nhìn từ góc độ đó, việc Azer Koçulu bảo họ biến đi khá là hả hê
Việc left-pad từng là một package tự nó đã khá buồn cười. Nó khiến tôi nghĩ xem đã có bao nhiêu byte đi qua CDN, proxy, pipeline build, v.v. chỉ để dùng một hàm tiện ích cực nhỏ
Tận dụng giải pháp có sẵn là tốt, nhưng khi cần padding chuỗi mà nghĩ “chắc là có package cho việc này” thì tôi không hiểu lắm
Cũng từng có văn hóa phát hành package để được nổi tiếng và nhận GitHub stars, và có những lập trình viên khăng khăng rằng tự hiện thực thứ có thể cài bằng NPM là “phát minh lại bánh xe”. Ngay cả bây giờ tôi vẫn làm việc nhiều với các lập trình viên thích micro-package cho cả những chức năng đơn giản, vì với họ điều đó có nghĩa là “giảm bảo trì”
Hai việc tất nhiên không giống nhau, nhưng nếu có công cụ đủ phát triển thì chúng cũng không xa đến mức không thể hiểu vì sao người ta muốn đối xử với chúng tương tự nhau
Chỉ là thêm một bước vào việc sao chép–dán mà thôi
Có đoạn nói rằng “từ phía NPM, tôi thấy một thái độ chung là coi thường lập trình viên, và điều đó dẫn đến một loạt quyết định phi lý, cuối cùng khiến mọi chi phí bị đổ lên đầu tôi”, nhưng có vẻ NPM không học được bao nhiêu sau sự kiện này
Thật tốt là sự kiện này đã xảy ra. Chiếm giữ tên là một vấn đề thực tế, và khi mơ hồ thì nên chọn phương án khiến người dùng ít bị bất ngờ nhất
Việc không có thống kê sử dụng cũng là vấn đề lớn, và việc có thể đơn giản hủy công bố cũng là vấn đề lớn. Việc hạ tầng phụ thuộc vào một đoạn code nhỏ 10 dòng do một cá nhân có lập trường mạnh tạo ra cũng là vấn đề thực tế, cả khi đó lẫn bây giờ. Trong tình huống này khó nói là thực sự có ai phải chịu trách nhiệm, và không ai nợ ai điều gì, nhưng mọi người đều có thể học được
Nhìn từ góc độ người duy trì vài gói npm nằm trong top 10, bài viết này hoàn toàn hợp lý
Từ một thời điểm nào đó, NPM đã không còn hợp tác với cộng đồng nữa. Việc Microsoft mua lại chỉ khiến điều đó trở nên chắc chắn, nhưng chuyện này đã rõ ràng từ rất lâu trước đó
Cách vận hành npm có rất nhiều rạn nứt, họ cũng không hợp tác tốt với cộng đồng hay đội ngũ Node mainline, và việc thúc ép hướng tới tính bền vững thương mại tạo cảm giác rất khó chịu và áp đặt. Một số thành viên trong đội ngũ cũng có tiếng là khá thô ráp
Tôi từng đến văn phòng ở Oakland, có vài tương tác khá thú vị, không đặc biệt tích cực, nhưng tôi sẽ không đi vào chi tiết
Khi đó, lỗ hổng hủy công khai đã được biết đến rộng rãi. Mọi người đều đổ lỗi rằng left-pad đã phá hỏng Internet, nhưng gần như không ai truy trách nhiệm của npm vì đã quản lý toàn bộ sự việc một cách nghiêm trọng sai lầm
Nếu tôi nhớ đúng, npm đã cưỡng ép khôi phục gói trái với ý muốn của người duy trì; nhẹ thì đó là sự tách rời khỏi những người mà họ tuyên bố phục vụ, nặng thì về mặt pháp lý cũng đáng ngờ. Ngay sau đó, họ cũng không còn mấy bận tâm đến việc lạm dụng nền tảng, đã xảy ra những chuyện như spam quảng cáo core.js, và họ cũng không hợp tác đúng mức với cộng đồng trong các vấn đề như tiêu chuẩn, khả năng tương thích, v.v.
Bản phát hành npm@5 là một thảm họa. Việc đưa vào file khóa gói không thể tệ hơn được nữa, và theo tôi nhớ thì có áp lực phải phát hành kịp với bản major tiếp theo của Node.js. Tôi có cảm giác đội ngũ Node đã không chờ npm sẵn sàng, nhưng xét việc npm là một công ty vì lợi nhuận, hoặc ít nhất hành xử như vậy, thì tôi cho rằng đó lại là điều tốt
Cách phản ứng với cộng đồng trong giai đoạn liên tiếp có những lỗi chí mạng không hồi kết, thái độ làm bẽ mặt cộng đồng đang gây áp lực, cùng kiểu tỏ ra đạo mạo, là bằng chứng cho thấy npm không còn là đại diện của phần mềm tự do và nguồn mở nữa. Tôi không nhớ left-pad xảy ra trước hay sau chuyện đó, nhưng trong đầu tôi, nó vẫn nằm trong cùng một dòng chảy suy thoái kéo dài của hệ sinh thái
Giờ đây các gói npm đã trở thành meme về những gói nhỏ làm các việc vụn vặt và bị mọi người chế giễu. Nhìn lại thì có thể đó không phải là lựa chọn tốt nhất. Nhưng bối cảnh rất quan trọng. npm là trình quản lý gói đầu tiên có khả năng tiếp cận rất cao dành cho một công nghệ mới nổi đang phổ biến, gần như hoàn toàn do cộng đồng quản lý, có hệ thống tìm kiếm tốt và được tích hợp chặt chẽ với tinh thần “social coding” của GitHub
Nó tồn tại vào những ngày đầu của Node, thời thậm chí ES5 còn chưa có, khi người ta còn dùng
varvàprototype. Các thực hành tốt nhất cho JavaScript cũng chưa thực sự có, đó là trước khi Joyent trao Node.js lại cho cộng đồng, và cũng trước khi thoát khỏi fork Io.js cùng giai đoạn đình trệ kéo dài của Node 0.10/0.12Không ai biết cách làm tốt nhất là gì
Tôi hoàn toàn hiểu tác giả. Từ góc độ bảo mật, tôi thật sự biết ơn vì left-pad đã xảy ra. Dù ý định của tác giả không phải như vậy, nó đã cho mọi người thấy rõ những rủi ro khi phụ thuộc vào lợi ích doanh nghiệp tách rời khỏi cộng đồng mà họ tuyên bố phục vụ. Nó đã khởi đầu nhiều cuộc thảo luận về bảo mật chuỗi cung ứng, tính dư thừa, v.v., và về lâu dài đã khiến ngành tốt hơn đôi chút
npm, và JavaScript nói chung, chủ yếu là nạn nhân của trào lưu