Thay đổi cách phát triển Ladybird
(ladybird.org)- Ladybird sẽ ngừng nhận pull request công khai để chuẩn bị cho bản alpha đầu tiên và việc ra mắt trình duyệt cho người dùng thực tế; từ nay chỉ các maintainer của dự án mới đưa thay đổi mã vào
- Khi các công cụ AI giúp tạo ra những đóng góp trông có vẻ nghiêm túc nhanh hơn và rẻ hơn, mô hình tin cậy trước đây rằng các bản vá lớn thể hiện thiện chí hoặc nỗ lực đáng kể đã suy yếu
- Trình duyệt chạy toàn bộ đầu vào không đáng tin cậy từ Internet trên máy của người dùng, nên chỉ cần một lỗ hổng được ngụy trang khéo léo cũng đã đủ cho kẻ tấn công
- Tất cả PR công khai hiện đang mở sẽ bị đóng, và dự án cũng sẽ không tạo quy trình nộp bản vá riêng qua issues, comments, email hay forks, cũng không xây dựng hệ thống đóng góp bóng tối
- Ladybird sẽ vẫn là mã nguồn mở, và sự tham gia từ bên ngoài sẽ được định hướng sang báo cáo lỗi rõ ràng, tái hiện tối giản, kiểm thử website, thảo luận tiêu chuẩn và thiết kế, báo cáo bảo mật, cùng phản hồi kỹ thuật thay vì gửi mã trực tiếp
Điểm cốt lõi của thay đổi quy trình phát triển
- Từ nay Ladybird sẽ không nhận pull request công khai nữa và chuyển sang mô hình chỉ các maintainer của dự án mới đưa thay đổi vào codebase
- Trong giai đoạn chuẩn bị cho bản alpha đầu tiên, dự án cần một quy trình phát triển nghiêm ngặt hơn, một mô hình bảo mật rõ ràng hơn, và một nhóm nhỏ hơn chịu trách nhiệm cho mã được đưa vào trình duyệt
- Trước đây, một bản vá đáng kể từng là tín hiệu thay thế hợp lý cho thấy có nhiều công sức và thiện chí, nhưng giả định đó không còn đúng khi có các công cụ AI
- Trình duyệt chạy các đầu vào không đáng tin cậy từ Internet trên máy của người dùng, và chỉ một lỗ hổng được ngụy trang kỹ cũng đủ tạo điều kiện cho kẻ tấn công
- Trong thế giới mã nguồn mở, đã từng có những chiến dịch kiên nhẫn và có nguồn lực nhằm giành được lòng tin của maintainer rồi lạm dụng nó; điều thay đổi là giờ đây có thể tạo ra các đóng góp trông nghiêm túc nhanh hơn và rẻ hơn nhiều
- Mọi thay đổi đi vào Ladybird phải phù hợp với kiến trúc, chịu được các đợt refactor trong tương lai, tương tác đúng với phần còn lại của trình duyệt, và phải là thứ các maintainer có thể hiểu được
- Việc mã có được viết thủ công hay không không phải điểm cốt lõi; điều quan trọng là ai sẽ chịu trách nhiệm cho nó sau khi nó được đưa vào trình duyệt
Các biện pháp chuyển đổi và những cách vẫn có thể tham gia
- Tất cả pull request công khai hiện đang mở sẽ bị đóng; nếu vẫn giữ hàng đợi hiện tại thì trên thực tế con đường đóng góp công khai vẫn sẽ tiếp tục mở, nên dự án quyết định chuyển đổi ngay bây giờ
- Từ nay, pull request sẽ chỉ dành cho các maintainer của dự án
- Dự án sẽ không tạo quy trình nộp bản vá riêng qua issues, comments, email hay forks, và cũng không coi fork hay các patch dump là review queue của upstream Ladybird
- Mã từ bên ngoài vẫn có thể tồn tại tùy theo các điều kiện giấy phép
- Ladybird sẽ vẫn là mã nguồn mở, và mã nguồn sẽ tiếp tục được công khai theo giấy phép mã nguồn mở
- Sự tham gia từ bên ngoài vẫn giúp ích cho dự án thông qua các bug report rõ ràng, reductions, website testing, thảo luận về tiêu chuẩn, thảo luận thiết kế, báo cáo bảo mật và phản hồi kỹ thuật
- Ở giai đoạn chuẩn bị phát hành trình duyệt cho người dùng thực tế, quy trình phát triển cũng phải tương xứng với trách nhiệm đó
2 bình luận
Ý kiến trên Hacker News
Gần đây tôi đọc khá nhiều PR của các dự án mã nguồn mở lớn như Godot, và số PR mà cả mã lẫn phần mô tả đều do AI tạo ra đang tăng lên đáng kể
Theo chính sách của dự án thì điều đó bị cấm, nên người gửi thường chỉ bị nhắc nhở nhẹ, nhưng trong khi nhiều người tiếp nhận khá bình thường thì một số lại nổi giận vì maintainer không tỏ ra biết ơn
Có vẻ ngay cả những người đã hoàn toàn lao theo AI cũng vẫn chưa thật sự thấm rằng bản thân việc tạo ra một cục mã đồ sộ không có giá trị nội tại
Dù công sức họ bỏ ra đã giảm đi rất nhiều, họ vẫn mong đợi phản ứng hay lời cảm ơn giống như thời trước AI khi gửi một PR lớn
Trong bối cảnh đó, tôi không kỳ vọng những kẻ có thái độ tệ hại vốn đã quá nhiều trong ngành này sẽ thay đổi cách hành xử sau AI
Nhân tiện, nhân viên không thuộc khối kỹ thuật ở chỗ làm của tôi đã bắt đầu gửi PR do AI tạo vào kho nội bộ mà tôi quản lý, chất lượng rất tốt, và họ cũng tiếp thu phản hồi review tốt rồi chỉnh sửa rất nhanh. Đây không phải vấn đề do không phải dân kỹ thuật, mà là vấn đề thái độ
Điều đó lộ ra không chỉ trong cách họ đóng góp mà cả trong lời ăn tiếng nói hằng ngày. Kiểu “tôi đã làm ra X”, khăng khăng rằng việc “tuyển chọn” của mình có ảnh hưởng cực lớn đến kết quả, khó nói ra phần đóng góp của LLM, thái độ “tôi tập trung vào việc tạo ra còn người khác thì lãng phí thời gian vào chi tiết”, và sự từ chối đối diện với các lỗi tiềm ẩn
Nó khác đến đáng kinh ngạc so với các lập trình viên senior luôn nghi ngờ rằng thứ mình làm ra có thể đầy lỗi và chắp vá. Cảm giác như hội chứng kẻ mạo danh bị đảo ngược
Vấn đề ở đây thuộc về những người gửi các PR đó 100%. Nếu ai đó có tiền sử thản nhiên phá vỡ quy tắc của dự án, thậm chí còn ngạo mạn về chuyện đó, thì với nhà tuyển dụng tiềm năng hay những người có thể cộng tác trong tương lai đang xem hồ sơ của họ, đây phải là một dấu hiệu rủi ro cực lớn
Tôi không hiểu tại sao họ lại cố tình phá hỏng danh tiếng của mình. Hồ sơ không có hoạt động gì còn tốt hơn nhiều so với việc để lại dấu vết hành vi xấu
Chẳng hạn kiểu như: “Đây không phải là để bảo vệ ranh giới của dự án hay đảm bảo chất lượng mã. Đây là cơ chế gác cổng do những kẻ theo chủ nghĩa truyền thống cảm thấy bị đe dọa trước những nhà sáng tạo hướng tới tương lai như bạn, những người thật sự làm chủ hiệu suất của AI”
“Một bản vá đáng kể từng đồng nghĩa với một lượng nỗ lực đáng kể, và lượng nỗ lực đó là một chỉ dấu thay thế hợp lý của thiện chí. Giờ thì giả định đó აღარ đúng nữa.”
Tôi nghĩ câu này là cốt lõi của bài viết và đúng với phần lớn các dự án
Dù vậy, vẫn cần một cơ chế để đánh giá liệu một người có thể đủ cam kết lâu dài để trở thành maintainer hay không. Đóng góp mã nguồn giờ khó còn đáng tin như một tín hiệu đó nữa, và tôi không biết sau này người ta sẽ dùng tín hiệu gì. Đây sẽ là một vấn đề khá khó
Nhưng nếu AI thật sự giúp năng suất lập trình viên tăng vọt, có lẽ các dự án mã nguồn mở thành công cũng không cần một đội ngũ maintainer quá lớn
Một mặt, nếu bạn lớn lên trong bazaar, việc chuyển sang cathedral có thể khiến bạn thấy như đó là “cái chết của mã nguồn mở”. Dù trên thực tế, có khi nó chỉ là quay lại một cách làm việc còn lâu đời hơn
Mặt khác, nếu không nhận đóng góp mã từ bên ngoài thì tư thế an ninh chắc chắn sẽ tốt hơn, nhưng sẽ khó hơn để tìm ra nên mời ai vào hàng giáo sĩ
Trước khi GitHub nổi lên, các dự án mã nguồn mở gần giống như những khu vườn có tường rào chắc chắn. Bước vào là bạn ở trong những câu lạc bộ nhỏ nơi mọi người nhìn chằm chằm vào bạn. GitHub đã hàng hóa hóa sự tiếp xúc, đồng thời hạ thấp rào cản về công sức hay mức độ quan tâm cần bỏ ra trước khi có thể đóng góp
Giờ thời kỳ đó đã kết thúc, và trước khi đóng góp vào bất cứ thứ gì, trước hết bạn phải xây dựng được niềm tin
Đây không phải cái chết của mã nguồn mở, mà là cái chết của ngôi làng toàn cầu nơi ai cũng tự do đi lại và dễ dàng tương tác. Đó là sự hồi sinh của những cộng đồng nhỏ, mang tính xã hội và dựa trên niềm tin, và tôi mong xu hướng này sẽ lan ra toàn bộ Internet
Không biết giờ mọi người còn biết phép ẩn dụ đó hay cuốn sách của Raymond không nữa. Đây là một thế giới nơi Microsoft là một trong những nhà cung cấp mã nguồn mở lớn, và nắm nền tảng vận hành phần lớn hoạt động lập trình mã nguồn mở trên Trái Đất. Hãy thử giải thích điều đó cho một người du hành thời gian đến từ cuối thập niên 90 xem
Ngoài ra, như bình luận bên cạnh có ngụ ý, ngay cả một “bazaar” điển hình như nhân Linux giờ cũng trông khá cathedral nếu so với mô hình hỗn loạn mở toang không giới hạn của GitHub
Vì vậy tôi không xem quyết định của Ladybird là một vấn đề. Ngược lại, tôi xem đó là quyết định củng cố khía cạnh con người của phát triển phần mềm và phanh lại những kẻ ăn theo AI
Có thể không lý tưởng, nhưng việc xây dựng danh tiếng vốn dĩ nên là thứ cần thời gian
Đọc mấy chuyện như thế này lại khiến tôi nghĩ giá như AI hoàn toàn không tồn tại thì tốt hơn
Thật quá thất vọng khi các dự án mã nguồn mở đang mất đi khả năng tìm và cố vấn cho những người bảo trì mới
“Sẽ không có quy trình nào để gửi bản vá bằng bất kỳ cách nào” nhưng lại nói “sự tham gia từ bên ngoài vẫn quan trọng: báo lỗi rõ ràng”
Vậy nghĩa là có thể tìm và sửa lỗi, nhưng lại không được nói chính xác mình đã sửa như thế nào sao?
Thay vào đó, đội ngũ phải tự tìm ra lại. Chắc hẳn cả đội sẽ rất hào hứng khi phải làm lại điều mà người khác đã lặp đi lặp lại làm được
Với tư cách vừa là người dùng vừa là lập trình viên, tôi không hiểu vì sao mình phải dành thời gian cho một dự án đặt ra những rào cản như vậy với phần mềm có thể cải thiện cuộc sống của mình. Có vẻ dùng Firefox hay Chromium, nơi bản sửa của tôi thực sự có thể được chấp nhận, sẽ dễ hơn nhiều
Trước đây khi một phiên bản Chromium mới làm sản phẩm của tôi bị crash, việc tôi có thể đề xuất bản sửa cho V8 và nó được đưa vào bản phát hành Chromium tiếp theo để sản phẩm hoạt động trở lại là một trải nghiệm rất hữu ích(https://github.com/v8/v8/commit/4f8a70adca01c)
Nếu không có con đường đó, có thể các nhà phát triển Chromium đã không đủ thời gian để xác định nguyên nhân và sửa nó
Họ nói “pull request không còn cho biết nhiều về người gửi như trước nữa”, nhưng lẽ ra chẳng ai cần phải biết gì về người gửi PR cả
Tôi muốn mã đi vào Firefox hay Chromium được quyết định dựa trên tính đúng đắn của mã, đã được xác nhận qua review, chứ không phải “nỗ lực” hay “thiện chí” của người gửi
Review một bản sửa mã rõ ràng dễ hơn việc tự nghĩ ra nó. Nếu không phải vậy thì cứ tự viết mã là xong
Về phía dự án, họ luôn có thể phớt lờ hoặc đóng những PR không mong muốn. Nhưng chặn luôn cả lựa chọn review đóng góp bên ngoài, hoặc dùng chúng làm đầu vào cho bản viết lại của mình, thì có vẻ không khôn ngoan
Chia sẻ phần phân tích tinh vi đó mới là cách tối đa hóa đóng góp. Mã cùng lắm chỉ gần như một phần thưởng tùy chọn
Bản sửa lỗi của bạn có thể có giá trị, nhưng giá trị đó chưa chắc lớn hơn chi phí để review và chấp nhận nó
Câu “review bản sửa mã rõ ràng dễ hơn tự nghĩ ra” hoàn toàn sai với những dự án đủ phức tạp. Bản sửa có thể chỉ là một dòng, nhưng hệ quả có thể lan rất xa
Với tư cách người dùng và lập trình viên, nếu bạn không muốn dành thời gian cho một dự án có những quy tắc như vậy thì đừng dành. Bạn không nợ dự án gì, và dự án cũng không nợ bạn gì. Chỉ đơn giản vậy thôi
Firefox và Chromium được vận hành bởi những đội ngũ lớn hơn nhiều, chưa kể Linux kernel. Có lẽ họ có dư sức để tiếp nhận đóng góp của bạn
Không chỉ trải nghiệm của tôi và ví dụ trong bài gốc, mà còn của vô số maintainer đã chia sẻ những bài viết tương tự
Bạn có thể chia sẻ liên kết đến một dự án mã nguồn mở mà bạn đã duy trì nhiều năm và review đóng góp, thứ làm cơ sở cho chuyên môn của bạn về vấn đề này không?
Chỉ cần viết bằng mô tả ngôn ngữ tự nhiên để maintainer có thể hiểu cách tiếp cận giải quyết
Nhưng ưu tiên và nhu cầu của họ thì khác. Trong trường hợp này, họ đã đánh giá và kết luận rằng nó không hữu ích. Nghĩa là chi phí lớn hơn lợi ích
Thật thú vị khi ít nhất ở một khía cạnh quan trọng, Chromium/Gecko/WebKit giờ trông còn như các engine trình duyệt “mở” hơn cả Ladybird
Servo có thể được xem là nằm đâu đó ở giữa vì họ vẫn nhận đóng góp từ bên ngoài miễn là không dùng AI
Tôi hiểu một đội ngũ không có nhiều kinh phí phải đóng contributions để tiết kiệm chi phí lao động. Nhưng tôi cũng có cảm giác mọi người chưa đánh giá đúng mức các nguồn lực kinh tế mà Google/Mozilla/Apple bỏ vào để làm cho tính mở trở nên khả thi
Để nói rõ thiên kiến và trải nghiệm cá nhân của mình, giờ tôi đã nghỉ hưu nhưng trước đây từng làm Chrome ở Google. Tôi đã thấy nhiều đồng nghiệp nuôi dưỡng các contributor bên ngoài, và bản thân tôi cũng từng làm điều đó ở mức không chính thức hoặc qua các chương trình như internship
Tôi không nghĩ chúng ta phải mãi mãi biết ơn việc xây dựng độc quyền
Tôi có thể hiểu vì sao họ đưa ra quyết định đó. Nếu phần lớn pull request là mã do AI viết, thì người bảo trì cũng có thể tự đưa prompt trực tiếp vào Claude Code
Dù là mã nguồn mở hay không, tôi nghĩ toàn bộ cuộc chơi của kỹ nghệ phần mềm đã thay đổi hoàn toàn. Một khối mã không còn mang ý nghĩa hay hàm ý như cách đây 2 năm nữa
Vài năm trước, nếu tôi gửi một PR phức tạp có thể biên dịch và vượt qua kiểm thử, điều đó có nghĩa là tôi đã bỏ ra từng ấy thời gian và đầu tư nhận thức. Nếu tôi không hiểu codebase, tính năng hoặc lỗi, thì rất có thể tôi đã không thực hiện khoản đầu tư đó
Giờ đây, chi phí để có được sự hiểu biết đó phần lớn vẫn gần như trước kia, nhưng AI đã làm giảm mạnh chi phí tạo ra mã có thể biên dịch và vượt qua kiểm thử
Những thành viên cộng đồng có lẽ xuất phát từ thiện chí sẵn sàng đóng góp thứ rẻ, tức là token Claude Code, nhưng vì nó đã trở nên quá rẻ, nên không còn là chỉ dấu tốt cho việc họ đã đóng góp thứ đắt giá là sự hiểu biết của con người
Tôi đang làm side project bằng OpenCode, và tôi dành khá nhiều thời gian để viết prompt, thiết lập các tệp phù hợp, và mô tả sản phẩm cùng lộ trình mình muốn xây dựng
Tôi lặp lại sau khi thiết lập một vòng lặp xác minh chặt chẽ để có thể chạy rất nhiều kiểm tra tự động sau mỗi thay đổi, rồi kiểm thử thủ công nhiều trường hợp biên mà tính năng được tạo ra có thể làm hỏng. Đây là một kiểu công việc khác, nhưng tôi có thể tiến nhanh hơn so với khi tự viết mã bằng tay. Thành phần cốt lõi là vòng lặp xác minh
Theo kinh nghiệm vài tháng gần đây của tôi, lập trình với AI cũng là một kỹ năng; bạn học kỹ thuật mới khi thử nghiệm và sẽ dần giỏi hơn. Điều đó cũng có nghĩa là nếu làm tốt thì có thể tạo ra kết quả có giá trị
Vì vậy tôi không đồng ý với câu đầu tiên, nhưng hoàn toàn đồng ý với câu thứ hai. Điều chúng ta đã mất là khả năng dễ dàng phân biệt giữa kết quả của suy nghĩ sâu sắc và kết quả được tạo ra mà không cần suy nghĩ. Ở đây, tập trung vào xác minh giá rẻ sẽ giúp ích rất nhiều
Tôi nghĩ mọi dự án rồi sẽ đi theo hướng này. Cùng nhau tinh chỉnh kế hoạch có lẽ hợp lý hơn
Khi AI mới xuất hiện, tôi từng sợ một ngày nào đó sẽ mất việc. Tôi may mắn, nhưng nhiều người thực sự đã mất, và điều đó rất đau lòng
Khi ai đó mất đi điều gì đó vì tự động hóa, bất kể logic kinh tế ra sao, người ta vẫn muốn đứng về phía con người, hoặc ít nhất là mong xã hội tiếp tục công bằng với những người chịu ảnh hưởng nặng nề nhất
Giờ tôi thấy cộng đồng đang bị tác động. Nếu giết chết PR, không chỉ đóng góp mã mà cả những đóng góp vô hình như ý tưởng, thêm nhiều góc nhìn vào mã, cũng sẽ bị lung lay mạnh. Điều đó còn khiến tôi thấy tệ hơn nhiều
Tôi thấy mâu thuẫn, bối rối và sợ hãi. Vậy mà tôi vẫn dùng Claude, DeepSeek, đủ loại công nghệ, các harness phức tạp và MCP các kiểu. Nhưng lúc này mọi thứ đều giống như một giai đoạn chuyển tiếp. Chỉ là tôi không biết đang chuyển sang cái gì
Nhiều câu hỏi không thể trả lời nếu không gán ý nghĩa cho cuộc sống. Dấu ấn con người ư? Đã quá muộn rồi sao? Ngoài ra, có một bài hát tôi từng thích, nhưng hóa ra là của Suno. Sau khi biết điều đó, tôi đã bỏ thích. Tôi thấy mình quá thường xuyên thật ngu ngốc
Xin lỗi vì đã lan man lạc đề. Tôi thích Ladybird, thậm chí còn dán sticker của nó lên laptop. Mong nó sẽ thành công
Cảm giác như đang ở giữa một cơn lốc xoáy. Dù vậy, tắt màn hình đi, ngồi xuống bàn, bình tĩnh nhớ lại nguyên lý đầu tiên và suy nghĩ chậm rãi vẫn có ích
Mượn lời Obama thì “thực tại cuối cùng sẽ đuổi kịp”
Nói thì nhiều, nhưng iOS đâu có mỗi năm tung ra lượng tính năng và bản sửa lỗi tương đương 10 năm. Theo nghĩa đen là không ai làm được như vậy, và ngược lại người ta còn phàn nàn rằng các tính năng cũ đang bị hỏng. Vì thế, việc nói rằng chúng ta đã đạt năng suất gấp 10 lần không thể là sự thật, và thực tế này rồi sẽ bắt kịp chúng ta
Chúng ta phải suy nghĩ như con người. Cũng cần nhớ rằng nhiều người đang bị ràng buộc về mặt cảm xúc. Những người junior muốn đây là cơ hội để tỏa sáng trong một thị trường đã từ chối họ. Các CEO đã đặt cược vào AI và không muốn quay đầu. Những người senior muốn gửi tín hiệu rằng họ chưa trở nên vô dụng. Các công ty AI sẽ làm ô nhiễm diễn ngôn. Nhưng rồi làn khói này cũng sẽ tan đi
Đa phần nó kết thúc bằng những ý kiến không mong muốn, các nỗ lực thâu tóm mang tính thù địch, khai thác giá trị, drama nói chung, và gánh nặng vận hành tổng thể đè thêm lên công việc đơn thuần là viết mã
Không phải lúc nào cũng vậy, nhưng mô hình phát triển mã nguồn mở tự do kiểu GitHub và việc loại bỏ mọi ma sát rõ ràng đã tạo ra một mặc định mới
Mô hình đó vốn dĩ không bền vững, nhưng tốc độ kiệt sức đủ thấp để nó có thể cầm cự bằng cách thay những người mệt mỏi bằng nhiều con người khác hơn
AI đã đẩy tốc độ kiệt sức vượt quá tốc độ thay thế. Vì vậy rất có thể sẽ có thêm nhiều dự án chọn lập trường này hoặc một lập trường tương tự
Tôi là một người sáng tạo và cũng là lập trình viên, tôi không thích nhìn những gì đang diễn ra trong vài cộng đồng, nhưng vẫn dùng agent trong phát triển. Cũng như khi Google và Stack Overflow mới xuất hiện rất khó để tránh né, LLM dường như cũng có một khoảnh khắc trước và sau rất rõ ràng
Tôi không có gì đặc biệt hữu ích để bổ sung, nhưng tôi muốn nói rằng bạn không hề cô đơn khi cảm thấy xung đột như thế. Những thứ mới mẻ thường là như vậy. Ở một số lĩnh vực chúng mang lại lợi ích khổng lồ, nhưng ở nơi khác lại như đang lột bỏ tính người; một số người tạo ra sự phô trương và rác rưởi, còn những người khác có được năng lực mới để làm ra thứ tốt hơn. Đáng tiếc là có lẽ không tồn tại một chân lý phổ quát
Đọc bài này xong vẫn thấy hơi lấn cấn. Vì tác giả thường tạo các PR không hề nhỏ, thường vượt quá 1.000 dòng, đôi khi còn tạo nhiều PR trong một ngày và gộp ngay trong ngày mà không qua review.
Ngay cả khi bỏ qua khía cạnh LLM thì vẫn vậy. Tôi không biết trong số đó bao nhiêu phần trăm có nhận hỗ trợ, nhưng kể cả là 0% thì đây vẫn không phải tốc độ phát triển khiến tôi thấy thoải mái
“Điều cốt lõi không phải là mã có được gõ bằng tay hay không. Điều quan trọng là sau khi mã được đưa vào trình duyệt thì ai là người chịu trách nhiệm. Ladybird đang trở thành một trình duyệt dành cho người dùng thực sự. Người đưa thay đổi vào phải là người quyết định thay đổi đó thuộc về dự án, và cũng phải là người chịu trách nhiệm về hệ quả của nó.”
Ở công ty có một nền tảng mã nguồn mở mà chúng tôi đã dùng nhiều năm, và đang sử dụng bản Enterprise trả phí. Một lỗ hổng bảo mật khá kỳ quặc đã lọt vào nền tảng đó, và khi xem kỹ thì có thể thấy AI đã chiếm lĩnh dự án.
Dù có ghi rõ hay không thì chỉ cần nhìn commit log cũng thấy rất rõ qua số lượng và tần suất. Thật sự rất thất vọng
[1] https://github.com/awesomekling
LLM có thể là một trong những lý do dẫn Ladybird tới quyết định này, nhưng không phải lý do duy nhất có thể. Ví dụ, SQLite hầu như đã luôn được phát triển theo cách này ngay từ đầu.
Có vẻ mỗi nơi có một cách riêng
Dùng giấy phép MIT và các maintainer luôn cảm kích trước các báo cáo lỗi, nhưng toàn bộ mã của dự án chỉ do đúng 3 người viết
Đây là một bước đi hoàn toàn hợp lý để bảo vệ thời gian và dự án của họ
Ý kiến trên Lobste.rs
Gần đây việc review đóng góp trên clang thật sự quá thảm hại. Hàng đống PR rác đổ về không dứt, mọi người ngày càng che giấu dấu vết khéo hơn nhưng phần lớn vẫn có thể nhận ra, và việc sàng lọc chúng tốn rất nhiều thời gian
Ngay cả với những người thừa nhận có dùng AI và ghi rõ đã dùng thế nào, vẫn phải kiểm tra lại xem họ có nói thật không hay đang giảm nhẹ mức độ sử dụng để cố đẩy một PR tệ qua được
Từ trước đến nay tôi đã thấy rất nhiều PR kiểu này, nhưng hình như chưa từng thấy một PR vibe coding nào thực sự tốt. Một số ở mức “tạm được” và tác giả tự mình bắt đầu công việc, nhưng phần lớn thì biến mất, còn số còn lại thì rõ ràng sai từ những khái niệm lập trình cơ bản, ngay cả khi không cần kiến thức nội bộ về clang cũng thấy được
Tệ hơn nữa là các script tự động hóa pipeline fuzzer→bug→LLM→PR, vốn hiểu sai nghiêm trọng bug thực tế, “sửa” theo cách làm hỏng mọi thứ, rồi gắn thêm test dở tệ hoặc thậm chí không đưa vào cả case gốc từng bị fail
Cuối cùng điều đó còn làm giảm cả mong muốn bỏ thời gian giúp người đóng góp mới nâng cao năng lực. Khi một cái tên lạ lần đầu gửi PR sửa crash, trước tiên tôi lại nghi ngờ đây có phải là phí thời gian hay là một người thật sự có thể trở thành người đóng góp
Những ai chỉ đơn giản ném rác vào dự án thì không quan tâm đến việc đóng góp hay học hỏi, và phần lớn trông như chỉ muốn thêm mục kiểu “đã đóng góp cho clang” vào CV
Sau đó họ còn tiếp tục quay lại hỏi “Sao danh sách chưa cập nhật nhỉ? Sao vẫn chưa có tên tôi?”, và sau khi website được cập nhật thì biến mất
Dù vậy, hồi nhỏ tôi cũng từng ngốc nghếch theo kiểu tương tự. Tôi từng nghe nói có thể mirror website của một nhân vật mã nguồn mở nổi tiếng, nên đã dựng một bản mirror rồi gửi mail xin thêm vào danh sách, và tôi cũng từng đăng ký mailing list phát triển của nmap vì muốn trở thành 1337 hax0r, nhưng chưa từng gửi bản vá nào
Việc xác định vấn đề thì ai cũng thấy rõ. Suốt nhiều thập kỷ, các dự án mã nguồn mở đã học cách biết nên tin ai thông qua các đóng góp code; mọi người làm việc, chịu trách nhiệm cho các thay đổi và gắn bó lại, còn sự tin cậy nảy sinh từ chính công việc đó
Nhưng tôi cho rằng giải pháp này là một phiên bản còn tệ hơn và nghiêm ngặt hơn so với cấm đóng góp bằng LLM mà dự án Zig đã chọn
Khi các công cụ AI đang nhanh chóng thay đổi tính kinh tế, giờ đây một PR không còn nói lên nhiều về người gửi như trước nữa. Những bản vá lớn trước đây đồng nghĩa với nỗ lực lớn và là một chỉ dấu gián tiếp thiện chí, nhưng giờ giả định đó không còn đúng
Điều đáng lo là mã nguồn mở vốn đã là một mô hình khó khăn, nên cần tận dụng tối đa các lợi thế quý giá của nó; người đóng góp trên thực tế mang lại giá trị khổng lồ gần như miễn phí (contributor poker), đồng thời cũng cực kỳ quan trọng như một kênh tuyển dụng. Vậy mà từ chối tất cả chuyện này thì có vẻ là một lựa chọn điên rồ
Có thể ai đó sẽ lập luận rằng LLM có thể lấp chỗ trống đó, nhưng thứ nhất là hoàn toàn có thể chỉ cấm dùng LLM trong PR từ những người đóng góp chưa được tin cậy; thứ hai là ngay cả LLM tốt nhất cũng tốn tiền, giá token thì tăng, code đằng nào cũng phải review, và cuối cùng nó cũng không thể trở thành một cộng tác viên nòng cốt đáng tin cậy chịu trách nhiệm cho một phần codebase
Nếu loại bỏ luồng code đi vào từ PR, theo thời gian một số ít người đóng góp sẽ sở hữu toàn bộ code, khiến dự án dễ thực hiện license rugpull hơn. Nếu quyền sở hữu bản quyền được phân tán tốt thì chuyện như vậy sẽ khó hơn nhiều
Nhìn chung là không ổn. Nó khiến mã nguồn mở trở thành một mô hình còn nhiều vấn đề hơn một cách không cần thiết, làm việc tuyển người đóng góp nòng cốt khó hơn, và tập trung quyền sở hữu code vào tay một số ít người. Đây rõ ràng là công thức dẫn tới thảm họa, đến mức khiến tôi nghi ngờ không biết đây chỉ là một sai lầm đơn thuần hay có phải một số nhà tài trợ của Ladybird đang chơi trò gì đó kỳ quặc
Tôi thực sự tò mò về bối cảnh của thay đổi này. Một dự án từng khoe ở đầu báo cáo trạng thái hằng tháng về số lượng người đóng góp mới đa dạng lại đột ngột đổi hướng như vậy là một cú chuyển cực gắt. Ít nhất thì phần giải thích hiện tại có vẻ chưa đầy đủ
Cả Zig lẫn Ladybird đều đang cố tìm cách tiến lên trong một tương lai mà chúng ta vốn không mong muốn. Tôi đã chẳng biết gì suốt vài năm và thành thật mà nói tôi không nghĩ tương lai kiểu này sẽ đến. Giờ thì hoàn toàn không còn rõ “điều đúng đắn” là gì nữa
Điều tôi muốn hỏi Zig là: không thể phân biệt PR do LLM tạo ra và PR do con người tự làm. Có thể lọc được rác ít nỗ lực, nhưng để thực thi “cấm AI” thì bạn phải vượt qua một kiểu bài test Turing nào đó, và với tôi cùng một giấy phép Claude Pro thì hoàn toàn vượt qua được
Điều mà “cấm AI” thực sự làm là cho phép tấn công một người và danh tiếng của họ nếu họ gửi code từ LLM rồi nói đó là làm thủ công và bị phát hiện. Có ai thực sự muốn tiêu thời gian cho việc này không? Kiểu như sẽ xuất hiện một Karl Jobst chuyên đi bắt người dùng LLM nhưng giả vờ là đang code tay
Nó không chặn được PR dùng LLM, mà chỉ biến cuộc chơi thành “bắt được thì bắt”. Khi thấy Andreas ở Ladybird đưa ra một quyết định gần như rugpull, ban đầu tôi lạnh sống lưng, rồi sau đó lại nghĩ là cũng khá gan. LLM hỗ trợ và vấn đề niềm tin thật sự là chuyện lớn, nên tôi muốn thấy cả Zig lẫn Ladybird suy nghĩ vượt ra ngoài khuôn khổ
Thực tế ông ấy là Designator, và theo cách tôi hiểu thì vị thế này được đảm bảo suốt đời trừ khi từ chức hoặc rơi vào tình trạng mất năng lực. Các Designator quyết định theo đa số, nhưng nếu chỉ có 2 người thì phải cả hai cùng đồng ý; họ chỉ định và bãi nhiệm Directors, đồng thời việc sửa đổi điều lệ cũng cần sự đồng thuận của họ
Tức là ông ấy trên thực tế có quyền phủ quyết không bị kiểm soát đối với tổ chức phi lợi nhuận này. Andreas cũng vậy, nhưng Andreas là người đã tạo ra phần lớn công việc, có tham gia vào dự án và không phải tỷ phú. Wanstrath thì là tỷ phú, chỉ cam kết quyên góp một phần cực nhỏ tài sản của mình, không tham gia vận hành mà vẫn có cùng quyền lực
Trừ khi tôi đã bỏ sót một lý do pháp lý chính đáng nào đó, thì điều này nghe không giống một cấu trúc quản trị tốt cho một dự án mã nguồn mở
Tôi lo các dự án gần đây đã đóng cửa đóng góp sẽ ra sao về dài hạn. Đến một thời điểm nào đó, một số nhân sự nòng cốt đáng tin cậy sẽ rời đi, và nếu không có những người đóng góp lâu dài đã được kiểm chứng thì có thể sẽ không có người kế nhiệm rõ ràng
Con đường mặc định có thể dẫn đến kiệt sức và dự án bị bỏ bê, nên tôi hy vọng họ tìm ra cách vượt qua chuyện này
Tôi không xem đây là bất kỳ dạng lãnh đạo nào. Đây không phải là một bước đi theo hướng đúng, cũng không phải là một ý tưởng về cách chúng ta có thể cùng chung sống
Tôi hiểu áp lực là có thật, nhưng phản ứng này khiến tôi thất vọng vì nó mang cảm giác hoài nghi và đầu hàng, chứ không phải năng động và đầy hy vọng
Phần “Là một phần của thay đổi này, chúng tôi sẽ đóng tất cả pull request công khai hiện đang mở” thật sự gây sốc
Vài năm trước, từng có một dự án đóng PR của tôi vì họ quyết định không có đủ nguồn lực để review PR, và điều đó khá đau, đồng thời không công bằng với người đóng góp đã bỏ công làm PR đó
Tôi hiểu lý do được đưa ra, nhưng quyết định này vẫn đáng lo. Không hẳn là chắc chắn tệ; nếu chỉ là tạm thời và sau này tìm được một điểm dung hòa khác thì có thể vẫn ổn, nhưng tôi vẫn thấy lo ngại
Đây cũng không phải dấu hiệu cảnh báo đầu tiên. Vụ viết lại Rust có LLM hỗ trợ cũng cho tôi cảm giác tương tự. Không giống Bun, cách làm này có phần thận trọng hơn, với các thành phần có kích thước đủ để review, đầu vào và đầu ra rõ ràng, và chạy song song với thành phần hiện có để bắt các điểm không khớp. Dù vậy, đây vẫn không phải kiểu cách tôi muốn thấy trong một engine trình duyệt
Tôi mong Ladybird sẽ thành công. Tôi muốn một engine trình duyệt mới thách thức cấu trúc độc quyền nhóm hiện tại. Nhưng khi nghĩ đến khả năng Ladybird đi chệch hướng, việc Servo vốn đã đình trệ nhiều năm nay cũng đang có tiến triển tốt là điều đáng mừng
Dùng mớ mã rác AI cho bản triển khai Rust, lại còn đứng về phía DHH, tức có vẻ nghiêng về chủ nghĩa thượng đẳng da trắng và chống LGBT, đồng thời trông cũng khá hiếu chiến. Tôi không nghĩ dự án này sẽ đi được xa
Nếu không có con đường tiếp cận để người ngoài trở thành người đóng góp, thì họ sẽ bỏ lỡ rất nhiều. Kể cả khi điều đó đòi hỏi một cam kết nghiêm túc hơn là chỉ tiện tay ghé qua rồi gửi một PR
Làm vậy sẽ giúp mở rộng nguồn nhân lực đã hiểu codebase khi họ muốn bổ sung thêm lập trình viên, và các tổ chức bên ngoài cũng có thể giải quyết những nhu cầu mà đội ngũ nòng cốt không ưu tiên. Điều này cũng giúp tăng mức độ chấp nhận và giảm bớt khối lượng công việc
Tôi không nghĩ gắn thẻ vibecoding cho bài này là phù hợp. Việc gom nạn nhân của vibe coding vào cùng một thẻ với những người cổ xúy hành vi đó về cơ bản là rất kỳ quặc