แรงงานที่มองไม่เห็นในระบบนิเวศโอเพนซอร์ส — ครึ่งหนึ่งไม่ได้ถูกบันทึก

แรงงานที่มองไม่เห็นในระบบนิเวศโอเพนซอร์ส — ครึ่งหนึ่งไม่ได้ถูกบันทึก

ผู้เขียน: John Meluso (Cornell Univ.), Amanda Casari & Katie McLaughlin (Google LLC), Milo Z. Trujillo (Northeastern Univ.)
เผยแพร่: มกราคม 2024, ฉบับเผยแพร่ล่วงหน้าของบทความ ACM
ต้นฉบับ: arXiv:2401.06889v2

---

สรุป

ซอฟต์แวร์โอเพนซอร์ส (OSS) ไม่ได้เกิดขึ้นจากการเขียนโค้ดเพียงอย่างเดียว การดูแลชุมชน การเขียนเอกสาร การจัดงาน การบริหารการเงิน การรายงานบั๊ก การตรวจทานคอนเทนต์ และกิจกรรม ที่ไม่ใช่การเขียนโค้ด อีกมากมาย ล้วนทำให้โครงการสามารถคงอยู่และพัฒนาต่อไปได้ แต่กิจกรรมเหล่านี้ส่วนใหญ่กลับกลายเป็น “แรงงานที่มองไม่เห็น (invisible labor)”

งานวิจัยครั้งนี้จากทีมนักวิจัยร่วมของ Cornell·Google·Northeastern แสดงให้เห็นว่า แรงงานในโอเพนซอร์สราวครึ่งหนึ่ง (50%) มองไม่เห็น และ งานราวสองในสาม (ประมาณ 66%) ไม่เป็นที่รับรู้ของผู้อื่น ผู้ตอบแบบสอบถามมากกว่าครึ่งระบุว่า งานที่ตนทำไปจำนวนมาก ไม่ได้รับการยอมรับหรือการตอบแทน

---

ภาพรวมการวิจัย

• วิธีสำรวจ: แบบสอบถามนักพัฒนา OSS 142 คนทั่วโลก ระหว่างเดือนมกราคม–มิถุนายน 2022
• รูปแบบการสำรวจ: ใช้เทคนิคเชิงการรับรู้แบบ ‘anchoring’ เพื่อออกแบบให้ผู้เข้าร่วมประเมินด้วยตนเองว่า งานของตน “มองเห็น” หรือ “ได้รับการยอมรับ” มากน้อยเพียงใด
• คำถามหลัก:
  1. แรงงานที่มองไม่เห็นพบได้บ่อยเพียงใดในระบบนิเวศโอเพนซอร์ส?
  2. ปัจจัยใดที่ทำให้ความ “มองไม่เห็น” นี้รุนแรงขึ้น?

---

ผลลัพธ์สำคัญ

• การตอบแทน (Compensation): มีเพียงครึ่งหนึ่งของผู้ตอบที่ระบุว่าตนได้รับ “เครดิต (credit)” สำหรับงานที่ทำ
• การมองเห็น (Visibility): งานประมาณ 2/3 ไม่มีการมองเห็น หรือเป็นที่รู้จักเพียงในวงจำกัด
• ปัจจัยที่ทำให้มองไม่เห็น:
  • กิจกรรมนอกเหนือจากโค้ดไม่ได้ถูกบันทึกอัตโนมัติในระบบ (เช่น กราฟของ GitHub สะท้อนเฉพาะงานโค้ด)
  • ปัจจัยทางสังคม (เพศ ภูมิภาค โครงสร้างองค์กร ฯลฯ) ทำให้เกิดความเหลื่อมล้ำในการได้รับการยอมรับ
  • ระบบตอบแทนไม่สมดุล — มีเพียง “คำขอบคุณ” แต่ไม่มีโอกาสหรือค่าตอบแทนที่เป็นรูปธรรม

---

ผลทางการรับรู้: เมื่อพูดถึง “การมองเห็น” ก่อน งานกลับดูมองเห็นน้อยลง

ที่น่าสนใจคือ ลำดับของแบบสอบถาม (ให้นึกถึง “การมองเห็น” ก่อน หรือ “การมองไม่เห็น” ก่อน) ทำให้คำตอบแตกต่างกัน
ผู้เข้าร่วมที่ถูกกระตุ้นให้นึกถึง “การมองเห็น” ก่อน ประเมินว่าแรงงานของตน “มองเห็น” มากกว่า และให้ความสำคัญกับ “ความสำคัญของเครดิต” ต่ำกว่า
ในทางกลับกัน ผู้เข้าร่วมที่ถูกกระตุ้นให้นึกถึง “การมองไม่เห็น” ก่อน ตอบว่างานของตนเป็นที่รับรู้น้อยกว่า และ ให้ความสำคัญกับการได้รับการยอมรับมากขึ้น
สิ่งนี้ชี้ว่า ‘anchoring effect’ ในการรับรู้ส่งผลต่อการประเมินแรงงานในโอเพนซอร์สด้วยเช่นกัน

---

เสียงสะท้อนจากผู้เข้าร่วม

“ไม่มีใครเห็นงานรีวิวโค้ดหรือการทำเอกสาร”
“หลายครั้งชื่อถูกเขียนผิด หรือไม่ก็หายไปเลย”
“การมีส่วนร่วมกับชุมชนไม่ได้รับการยอมรับ แต่มีแค่ code commit ที่ถูกมองว่าเป็น ‘ผลงาน’”
“สถิติจากเครื่องมืออัตโนมัติบิดเบือนความพยายามที่เกิดขึ้นจริง”

นักวิจัยเรียกปฏิกิริยาเหล่านี้ว่า “cross-purpose attribution” และอธิบายว่า เมื่อแรงจูงใจส่วนบุคคล (ความสนุก การยอมรับ ความรู้สึกเป็นส่วนหนึ่ง เส้นทางอาชีพ ฯลฯ) ขัดแย้งกับระบบตอบแทนของชุมชน ปัญหา ‘แรงงานที่มองไม่เห็น’ ก็จะยิ่งรุนแรงขึ้น

---

นัยสำคัญของงานวิจัย

1. ความเป็น ‘โอเพน’ ไม่ได้หมายความว่าจะ ‘มองเห็น’ เสมอไป
   แม้โค้ดจะเปิดเผย แต่ผู้คนและกระบวนการเบื้องหลังก็ถูกลืมได้ง่าย

2. การตอบแทนไม่ได้มีแค่เงินเท่านั้น
   การถูกเอ่ยชื่อ หรือการมีบันทึกการมีส่วนร่วม ก็เป็น “การตอบแทน” ที่สำคัญเช่นกัน

3. ความรับผิดชอบของการออกแบบแพลตฟอร์ม
   แพลตฟอร์มหลักอย่าง GitHub ควรแสดงกิจกรรมนอกเหนือจากโค้ด (การจัดการ issue การแปล การดูแลชุมชน ฯลฯ) ในเชิงปริมาณด้วย

4. จำเป็นต้องทำให้การมีส่วนร่วมที่หลากหลายมองเห็นได้
   ควรนำระบบจัดหมวดหมู่การมีส่วนร่วมอย่าง CRediT (มาตรฐานบทบาทผู้มีส่วนร่วมในงานวิจัย) มาใช้ เพื่อให้การมีส่วนร่วมในด้านที่ไม่ใช่การพัฒนา เช่น การจัดทำเอกสารเชิงเทคนิคหรือการดูแลชุมชน ได้รับการยอมรับอย่างชัดเจน

---

บทสรุป

งานวิจัยนี้ทำให้การถกเถียงเรื่องความยั่งยืนของโอเพนซอร์สหันมามอง “แรงงานนอกเหนือจากโค้ด” อย่างจริงจัง
“การเปิดเผย” ไม่ได้การันตี “ความเป็นธรรม” คุณค่าความเป็น ‘โอเพน (open)’ ที่แท้จริงของโอเพนซอร์สควรถูกสร้างขึ้นบน ความโปร่งใสทางสังคมที่ทำให้การมีส่วนร่วมทุกรูปแบบมองเห็นได้ ไม่ใช่แค่ตัวโค้ดเท่านั้น

[kimjoin2]

ในบริษัทก็เหมือนกัน... T^T

[kgh1379]

มีงานจุกจิกและงานที่มองไม่เห็นซึ่งไม่ได้อยู่ในขอบเขตหน้าที่หลัก เยอะเกินไปจนเหมือนเป็นโปรเจกต์ส่วนตัว
(กรณีที่มีงานเล็กๆ น้อยๆ มากจนถึงขั้นรู้สึกว่า "นี่มันนับเป็นงานด้วยเหรอ?" หรือเป็นงานที่ต้องทำซ้ำบ่อยมาก)
แน่นอนว่างานแบบนี้ก็มักไม่มีการเพิ่มคนให้ เลยเห็นการนำ AI มาใช้กับงานจุกจิกเหล่านี้มากขึ้น
ผมเลยคิดว่าสาเหตุหนึ่งที่พนักงานออฟฟิศเกาหลีใช้ AI กันมาก อาจเป็นเพราะนอกจาก JD แล้ว ยังมีความต้องการแก้ปัญหาแรงงานที่มองไม่เห็นเหล่านี้ด้วยก็ได้ (ต่างประเทศอย่างน้อยก็มักเขียน JD ไว้ค่อนข้างชัดเจนและพยายามยึดตามนั้น)

[shakespeares]

ตอนนี้ดูเหมือนว่าไม่ว่าจะทำงานหนักมากแค่ไหนก็จะถูกมองว่าเป็น AI ไปเสียหมดแล้วครับ

[alex00728]

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