Lao động ‘vô hình’ trong hệ sinh thái mã nguồn mở — một nửa không được ghi nhận
Tác giả: John Meluso (Cornell Univ.), Amanda Casari & Katie McLaughlin (Google LLC), Milo Z. Trujillo (Northeastern Univ.)
Công bố: Tháng 1 năm 2024, bản tiền công bố bài báo ACM
Nguyên bản: arXiv:2401.06889v2
Tóm tắt
Phần mềm mã nguồn mở (OSS) không chỉ được tạo nên bằng việc viết code. Quản lý cộng đồng, viết tài liệu, vận hành sự kiện, quản lý tài chính, báo cáo lỗi, kiểm duyệt nội dung cùng vô số hoạt động không phải lập trình khác là những yếu tố giúp dự án được duy trì và phát triển. Tuy nhiên, phần lớn các hoạt động này vẫn là “lao động vô hình (invisible labor)”.
Nghiên cứu lần này của nhóm liên ngành từ Cornell, Google và Northeastern cho thấy khoảng một nửa (50%) lao động trong mã nguồn mở là vô hình, và hai phần ba công việc (khoảng 66%) không được người khác biết đến. Hơn một nửa số người trả lời cho biết phần đáng kể công việc họ thực hiện không được công nhận hoặc đền đáp.
Tổng quan nghiên cứu
- Phương pháp khảo sát: khảo sát 142 nhà phát triển OSS trên toàn thế giới trong giai đoạn từ tháng 1 đến tháng 6 năm 2022
- Cách khảo sát: áp dụng kỹ thuật nhận thức ‘anchoring’, được thiết kế để người tham gia tự đánh giá mức độ công việc của mình ‘được nhìn thấy’ hay ‘được công nhận’
- Câu hỏi cốt lõi:
- Lao động vô hình phổ biến đến mức nào trong hệ sinh thái mã nguồn mở?
- Những yếu tố nào làm gia tăng tình trạng ‘vô hình’ này?
Kết quả chính
- Đền đáp (Compensation): chỉ một nửa số người trả lời cho biết họ đã nhận được “credit” cho công việc mình làm.
- Mức độ hiển thị (Visibility): khoảng 2/3 công việc là không hiển thị hoặc chỉ được một số ít người biết đến.
- Các yếu tố gây ra tính vô hình:
- Các hoạt động ngoài code không được hệ thống tự động ghi lại (ví dụ: biểu đồ GitHub chỉ phản ánh hoạt động lập trình)
- Sự chênh lệch trong mức độ công nhận phát sinh theo các yếu tố xã hội (giới tính, khu vực, cấu trúc tổ chức, v.v.)
- Sự mất cân đối trong hệ thống đền đáp — có “lời cảm ơn” nhưng không có cơ hội thực chất hay thù lao
Hiệu ứng nhận thức: nói về “được nhìn thấy” trước thì thấy mình ít vô hình hơn
Điều thú vị là câu trả lời thay đổi theo thứ tự khảo sát (gợi nhớ trước về ‘mức độ hiển thị’ hay về ‘sự vô hình’).
Những người được gợi nhớ trước về ‘được nhìn thấy’ đánh giá lao động của mình là “hiển thị” hơn, đồng thời xem nhẹ hơn tầm quan trọng của việc được ghi nhận.
Ngược lại, những người được gợi nhớ trước về ‘sự vô hình’ trả lời rằng công việc của họ ít được biết đến hơn, và đánh giá cao hơn tầm quan trọng của việc được công nhận.
Điều này cho thấy hiệu ứng neo nhận thức (anchoring effect) cũng ảnh hưởng đến cách lao động mã nguồn mở được đánh giá.
Tiếng nói trực tiếp từ người tham gia
“Không ai để ý đến review code hay việc viết tài liệu.”
“Nhiều khi tên bị ghi sai, hoặc thậm chí bị bỏ sót hoàn toàn.”
“Đóng góp cho cộng đồng không được công nhận, chỉ commit code mới được xem là ‘cống hiến’.”
“Thống kê từ các công cụ tự động làm sai lệch nỗ lực thực tế.”
Các nhà nghiên cứu gọi những phản hồi này là “cross-purpose attribution”, và giải thích rằng khi động lực cá nhân (niềm vui, sự công nhận, cảm giác thuộc về, sự nghiệp, v.v.) xung đột với hệ thống đền đáp của cộng đồng, thì ‘lao động vô hình’ sẽ trở nên trầm trọng hơn.
Hàm ý của nghiên cứu
-
‘Mở’ không đồng nghĩa với ‘được nhìn thấy’.
Dù code được công khai, con người và quy trình phía sau vẫn dễ bị lãng quên. -
Đền đáp không chỉ là tiền bạc.
Việc được nhắc tên hoặc được ghi lại lịch sử đóng góp cũng là một hình thức ‘đền đáp’ quan trọng. -
Trách nhiệm trong thiết kế nền tảng.
Các nền tảng lớn như GitHub cần thể hiện được một cách định lượng các hoạt động ngoài code (quản lý issue, dịch thuật, vận hành cộng đồng, v.v.). -
Cần làm cho nhiều dạng đóng góp trở nên hiển thị hơn.
Cần đưa vào các hệ thống phân loại đóng góp như CRediT (tiêu chuẩn về đóng góp của nhà nghiên cứu) để các đóng góp ngoài phát triển như tài liệu kỹ thuật hay vận hành cộng đồng cũng được công nhận rõ ràng.
Kết luận
Nghiên cứu này đã đưa “lao động ngoài code” lên bề mặt khi bàn về tính bền vững của mã nguồn mở.
“Công khai” không bảo đảm “công bằng”. Nó nhắc rằng tính ‘mở (open)’ thực sự của mã nguồn mở phải được xây dựng trên sự minh bạch xã hội, nơi mọi hình thức đóng góp đều được nhìn thấy, chứ không chỉ riêng code.
4 bình luận
Ở công ty cũng vậy... T^T
Làm dự án cá nhân thì có quá nhiều phần việc phụ và lao động vô hình không nằm trong phân công công việc
(những việc lặt vặt đến mức phải thốt lên "Cái này cũng là việc à?", hoặc số lượng rất nhiều hay lặp đi lặp lại nhiều lần)
Đương nhiên với những việc như vậy thì cũng không được bổ sung nhân lực, nên việc tận dụng AI cho các việc lặt vặt này đã tăng lên
Tôi nghĩ một trong những nguyên nhân khiến người đi làm ở Hàn Quốc dùng AI nhiều là vì ngoài JD ra, họ còn có nhu cầu rất lớn muốn giải quyết những lao động vô hình như vậy (ở nước ngoài thì ít nhất họ còn ghi JD cụ thể và cố gắng tuân thủ nó)
Thực ra bây giờ, dù có làm rất nhiều việc thì cũng có vẻ sẽ bị nhận là do AI làm.
Vấn đề này thực ra có lẽ không hẳn chỉ là vấn đề của mã nguồn mở, mà dường như áp dụng cho mọi tổ chức. Có rất nhiều đóng góp bị chìm đi.