ชะตากรรมของโอเพนซอร์ส "ขนาดเล็ก"

• ไลบรารียูทิลิตีขนาดเล็ก ของ JavaScript กำลังค่อย ๆ ไม่จำเป็นลง เพราะความสามารถของ LLM ในการสร้างโค้ด
• ตัวอย่างเช่น blob-util เป็นแพ็กเกจ npm อายุ 10 ปี ซึ่งเป็น ชุดเครื่องมือจัดการ Blob แต่ตอนนี้ AI สามารถสร้างโค้ดลักษณะคล้ายกันได้ทันที
• การเปลี่ยนแปลงนี้ทำให้ ลดการพึ่งพา dependency และพัฒนาได้เร็วขึ้น แต่ก็ทำให้ สูญเสียโอกาสในการเรียนรู้และทำความเข้าใจ
• ต่อเนื่องจากการขยายความสามารถในตัวของ Node.js และเบราว์เซอร์ ตอนนี้ LLM กำลัง เร่งการสิ้นสุดของไลบรารีขนาดเล็ก
• ต่อจากนี้ คุณค่าของโอเพนซอร์สน่าจะยังคงอยู่ใน งานที่สร้างสรรค์ ขนาดใหญ่ และเฉพาะทาง

---

การเสื่อมถอยของโอเพนซอร์สขนาดเล็กและผลกระทบของ LLM

• blob-util ที่สร้างไว้เมื่อ 10 ปีก่อน เป็น ชุดยูทิลิตีอย่างง่าย สำหรับแปลงอ็อบเจ็กต์ Blob ของ JavaScript ให้เป็นสตริงหรือ ArrayBuffer และมียอดดาวน์โหลดมากกว่า 5 ล้านครั้งต่อสัปดาห์
  • ผู้เขียนสร้างมันขึ้นมาเพราะเห็นว่าผู้ใช้ PouchDB สับสนกับการจัดการ Blob
• ปัจจุบันนักพัฒนาราว 80% ใช้ AI ในการทำงาน ทำให้ยูทิลิตีแบบง่าย ๆ สามารถถูกแทนที่โดย LLM ได้
  • ตัวอย่างคือ Claude สามารถสร้างฟังก์ชัน TypeScript สำหรับแปลง Blob เป็น ArrayBuffer ได้ทันที
• ผลลัพธ์จาก Claude คล้ายกับ blob-util แต่ พูดยืดยาวกว่าและตรวจสอบประเภทข้อมูลมากเกินไป ขณะที่การจัดการข้อผิดพลาดทำได้ดีขึ้น
• ผู้เขียนระบุว่าการเปลี่ยนแปลงนี้อาจดูเหมือนเป็น การลด dependency และเพิ่มความแข็งแรงของโค้ด

การสูญเสียคุณค่าของโอเพนซอร์สเพื่อการเรียนรู้

• README ของ blob-util มี บทสอนที่ใช้ตัวละคร Kirby รวมอยู่ด้วย โดยไม่ได้มีเป้าหมายแค่ให้ฟังก์ชันใช้งาน แต่ยังต้องการ ช่วยให้เรียนรู้ JavaScript
• ในสภาพแวดล้อมการพัฒนาที่ขับเคลื่อนด้วย LLM คำตอบที่ได้ทันทีจะมาก่อนความเข้าใจและการศึกษา ทำให้ความจำเป็นของโอเพนซอร์สแบบเน้นการเรียนรู้ลดลง
• ความพยายามอย่าง llms.txt สำหรับการทำเอกสารอัตโนมัติ ก็กำลัง นิยามความหมายของเอกสารใหม่ไปในตัว

ทิศทางใหม่ของโอเพนซอร์ส

• ผู้เขียนยังคงทำโอเพนซอร์สต่อไป แต่คิดว่า ยุคของไลบรารีขนาดเล็กที่มูลค่าต่ำได้จบลงแล้ว
  • ก่อนหน้านี้แนวโน้มนี้ก็เริ่มขึ้นแล้วจากการขยายความสามารถในตัวของ Node.js และเบราว์เซอร์ เช่น node:glob, structuredClone
  • และ LLM ก็ เร่งแนวโน้มนั้นอย่างชัดเจน
• แม้แต่ไลบรารีที่มีบทบาทด้านการศึกษา เช่น Underscore.js ก็มีความจำเป็นลดลง
  • ฟังก์ชันง่าย ๆ อย่างการจัดกลุ่มอาร์เรย์ ตอนนี้สามารถแก้ได้ด้วย API มาตรฐาน

เงื่อนไขของโอเพนซอร์สที่ยังมีคุณค่า

• คุณค่าจะไปกระจุกอยู่ใน โปรเจ็กต์ขนาดใหญ่ สร้างสรรค์ และเฉพาะทาง ที่ LLM สร้างตามได้ไม่ง่าย
  • ตัวอย่างเช่นโปรเจ็กต์ fuite และ งานวิจัยด้านการตรวจจับ memory leak เป็นงานสร้างสรรค์ที่ LLM เลียนแบบได้ยาก
• ต่อจากนี้ ความหมายของโอเพนซอร์สจะอยู่ที่ แนวคิดใหม่และความคิดสร้างสรรค์ของมนุษย์
  • ยกตัวอย่าง เฟรมเวิร์ก Ripple.js ที่ Dominic Gannaway พัฒนาขึ้น เพื่อเน้นย้ำถึงจิตวิญญาณแห่งการทดลองของมนุษย์

บทสรุป

• LLM ทำให้โอเพนซอร์สบางส่วน ล้าสมัยลง แต่ก็ยังมี โอกาสในการสร้างสรรค์โอเพนซอร์สรูปแบบใหม่ อยู่เสมอ
• ความคิดสร้างสรรค์และจิตวิญญาณแห่งการทดลองของนักพัฒนามนุษย์ถูกเสนอว่าเป็น ปัจจัยสำคัญต่อความยั่งยืนของระบบนิเวศโอเพนซอร์สในยุค AI

[savvykang]

ผมคิดว่าโอเค ถ้าสามารถป้องกันพฤติกรรมประหลาดของระบบนิเวศแบบ left-pad ได้

[shakespeares]

ดูเหมือนว่าเมื่อยุคสมัยยิ่งให้ความพึงพอใจน้อยลงเมื่อเทียบกับความพยายาม ยูทิลิตีขนาดเล็กก็คงจะถูกเมินมากขึ้น เพราะถูกมองว่าไม่มีคุณค่าคุ้มกับแรงที่ต้องใช้ในการบำรุงรักษา

[GN⁺]

ความคิดเห็นจาก Hacker News

• ทุกวันนี้นักพัฒนาราว 80% ใช้ AI ในการทำงาน
  ยูทิลิตีอย่าง blob-util ตอนนี้ส่วนใหญ่ให้ LLM สร้างได้ตรง ๆ เลย
  แต่แนวทางแบบนี้เป็น ดาบสองคม โค้ดที่ไม่ผ่านการตรวจสอบอาจทิ้งภาระด้านการบำรุงรักษาไว้ และอาจล้มเหลวใน edge case
  เพราะแบบนั้นใน ecosystem ของ Java จึงมีชุดยูทิลิตีมาตรฐานที่เชื่อถือได้อย่าง Apache Commons

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

• เรากำลังก้าวเข้าสู่ยุคที่ AI สร้างโค้ดและบทสอนออกมาจำนวนมหาศาล ทำให้ คุณภาพลดลงและสแปมเพิ่มขึ้น อย่างรวดเร็ว
  แรงจูงใจในการทำบล็อกส่วนตัวหรือไลบรารีขนาดเล็กกำลังลดลง

  • จริง ๆ แล้วเว็บก็เต็มไปด้วย สแปมบทสอนคุณภาพต่ำ มาตั้งนานแล้ว
    บทความที่ LLM สร้างก็อยู่ในระดับคล้ายกัน เลยรู้สึกว่ากลับกรองออกได้ง่ายขึ้นเสียอีก
    ฉันทดสอบคุณค่าที่แท้จริงของบทสอนด้วยการรันโค้ดใน devcontainer ถ้ามันทำงานก็คุ้มจะอ่าน ไม่งั้นก็ทิ้ง
  • วันนี้พอค้นหาหัวข้อหนึ่งบน YouTube ก็แปลกใจที่เจอแต่ วิดีโอที่ AI สร้าง โผล่มาไม่สิ้นสุด
  • คำพูดที่ว่า “ยุคของสแปมคุณภาพต่ำกำลังมา” นั้นได้กลายเป็นความจริงไปแล้ว
  • มีนักพัฒนาเว็บคนหนึ่งล้อว่า “ตอนนี้เร็วขึ้น 10 เท่า งั้นคงไม่เป็นผลเสียต่อมนุษยชาติหรอก”
  • บางคนประชดด้วยการโยนโค้ด assembly มาแล้วบอกว่า “ถ้าอธิบายสิ่งนี้ไม่ได้ก็ไม่ใช่นักพัฒนาตัวจริง”

• นรกของ micro-dependency ใน JS เคยเป็นฝันร้าย
  ตอนนี้ยุคนั้นกำลังจะจบลง และหวังว่านักพัฒนาจะกลับไปสู่ยุคที่เรียนรู้การเขียนโค้ดกันอีกครั้ง

  • การรวม ชุดยูทิลิตีเล็ก ๆ ไว้ในแพ็กเกจเดียวแบบ jQuery หรือ lodash ให้ผลลัพธ์ดีที่สุด
  • แต่ก็มีการตั้งคำถามกับคำพูดที่ว่า “ทุกอย่างจบแล้ว” เพราะมันอาจแย่ลงกว่าเดิมจาก กระแสโค้ดที่ AI สร้างถาโถม
  • เมื่อโค้ดจาก LLM เพิ่มขึ้น ฟังก์ชันที่ทำงานเหมือนกันก็จะกระจัดกระจายเป็นหลายเวอร์ชัน และการแก้บั๊กก็ต้องทำแยกกันเอง
  • การใช้ LLM ไม่ได้ทำให้คนเรียนรู้มากขึ้น เพราะถ้ามีปัญหาก็คงโยนให้ LLM รีแฟกเตอร์ต่ออยู่ดี
  • มีคนเสริมสั้น ๆ ว่า “ตอนนี้คือยุคของ vibe coder แล้ว”

• มีคำถามว่า “โจทย์กลับต้นไม้ทวิภาค” มีอยู่จริงหรือไม่

  • ดูเหมือนจะหมายถึงโจทย์ที่ผู้ก่อตั้ง Homebrew เคยทำไม่ผ่านในการสัมภาษณ์กับ Google
  • น่าจะเป็นการพลาดของผู้เขียนเองมากกว่า และถ้าจะทำจริงก็คงเป็นเพียง แบบฝึกหัดไร้ความหมาย ที่แค่สลับตัวดำเนินการเปรียบเทียบให้กลับด้าน

• มีคนเห็นด้วยกับข้ออ้างที่ว่า “ยุคของไลบรารีเล็ก ๆ ที่มูลค่าต่ำได้จบลงแล้ว”
  ภาษา Go นั้นแต่เดิมก็ ไม่มีนรกเรื่อง dependency อยู่แล้ว และปัญหาของ npm ก็มาจากปัจจัยด้านวัฒนธรรม
  ตอนนี้การสร้าง ผลิตภัณฑ์ที่ใช้งานได้จริง มีคุณค่าและสนุกกว่าการทำยูทิลิตี

  • ตามสุภาษิตของ Go ว่า “คัดลอกนิดหน่อย ดีกว่าพึ่งพา dependency นิดหน่อย” (Go Proverbs)
  • ยังมีคำถามด้วยว่าฟีเจอร์อะไรของ Go ที่ช่วยป้องกันปัญหา dependency แบบนี้ได้

• ฉันคิดว่า micro-dependency เองก็ไร้ความหมาย
  เขียนรายชื่อฟังก์ชันลงใน Markdown ให้คนคัดลอกไปใช้ยังจะดีกว่า
  แนวทางแบบไลบรารีขนาดเล็กที่อิง header file ของ C ใช้งานได้จริงกว่า

  • แล้วก็มีคนตอบแบบติดตลกว่า “ถ้าอย่างนั้นทำไมไม่รวม header library พวกนี้เข้าไปในมาตรฐานไลบรารีของ C เลยล่ะ”
  • แต่ก็มีข้อโต้แย้งที่เป็นจริงจังว่า “ถ้าใช้วิธีคัดลอกแปะ แล้วจะทำอัปเดตด้านความปลอดภัยอย่างไร”

• มีการตั้งคำถามว่า ตอนนี้ โอเพนซอร์ส แบบไหนกันแน่ที่ยังมีความหมาย
  เพราะโค้ดที่เผยแพร่ออกไปสุดท้ายก็ถูก ดูดซับเป็นข้อมูลฝึก AI อยู่ดี
  จึงมองว่าโมเดล source-available อาจเป็นทางเลือกแทน FOSS แบบเต็มรูปแบบ

  • มีคนโต้ว่า “ถ้าคนใช้ได้มากขึ้น นั่นก็เป็นข้อดีของโอเพนซอร์สไม่ใช่หรือ”
    ผู้เขียนเน้นว่า ความหมายของการมีส่วนร่วม นั้นใหญ่กว่าการถูกใส่ชื่อไว้เฉย ๆ
  • แต่ก็มีความเห็นเชิงสงสัยว่า “ต่อให้เป็น source-available สุดท้ายก็ถูกเอาไปใช้ฝึกอยู่ดี”
  • มีคนบอกว่า “เราไม่มีหน้าที่ต้องให้ความรู้ฟรีแก่โลก” และควรปฏิเสธ การแบ่งปันที่ไร้ความต่างตอบแทน
  • อีกความเห็นหนึ่งระบุว่า “การแจกจ่ายโค้ดที่ไม่เสรีเป็นสิ่งผิดจริยธรรม” และควรรักษา หลักการซอฟต์แวร์เสรี ไว้
  • บางคนบอกว่า “ตอนนี้หมดความสนใจกับโอเพนซอร์สแล้ว” และได้ เปลี่ยนทุกโปรเจ็กต์เป็นแบบปิด ไปแล้ว

• ฉันเชื่อว่าโอเพนซอร์สจะไม่หายไป แต่จะ แข็งแกร่งยิ่งขึ้น เสียด้วยซ้ำ
  นักพัฒนาที่มีความคิดสร้างสรรค์จริงจะใช้ AI เพื่อสร้าง นวัตกรรมที่บริษัททำไม่ได้
  โอเพนซอร์สยังคงเป็น พื้นที่พิสูจน์คุณค่าที่แท้จริง และเป็นพื้นที่เรียนรู้เพื่อก้าวข้ามขีดจำกัดผ่าน AI

  • นวัตกรรมที่แท้จริงจะออกมาจากโอเพนซอร์ส
    แต่ก็มีการคาดการณ์ว่ารัฐบาลและบริษัทยักษ์ใหญ่จะพยายาม กำกับดูแลระบบ AI แบบโลคัล และในไม่ช้าก็จะมีเส้นแบ่งว่า “AI แบบใดที่ประชาชนใช้ได้”
  • ในทางกลับกัน โปรเจ็กต์โอเพนซอร์สเองก็กำลังปวดหัวกับ การส่งโค้ดที่ AI สร้างเข้ามา
    มีการเสียเวลาไปกับการรีวิวและถกเถียงเรื่องนโยบายมากขึ้น และโดยเฉพาะใน สาขาซับซ้อนอย่างคอมไพเลอร์ AI ก็ไม่ได้ช่วยอะไรเลย

• มีคนย้ำว่า “ถึงจะไม่ได้ถูกเพิ่มเป็นแพ็กเกจ แต่การ เผยแพร่โค้ดนั้นเอง ก็ยังมีคุณค่า”

  • ฉันเองเวลาเจอโค้ดชิ้นเล็ก ๆ ก็จะคัดลอกมาแก้ให้เข้ากับมาตรฐานของตัวเอง รู้สึกเหมือนเป็น จิตวิญญาณแห่งการแบ่งปันทางวิทยาศาสตร์
    ถ้า LLM มาช่วยเขียนโค้ดแทน ก็ลดภาระในการเรียนรู้ลงและทำให้โฟกัสกับหัวข้อที่ลึกขึ้นได้
  • มองว่า ไลเซนส์ Copyleft ดีกว่า เพราะทำให้บริษัทหยิบไปใช้ตามใจไม่ได้ และต้องจ้างคนมาทำเองแทน
  • การอ่านโค้ดของคนอื่นเพื่อเรียนรู้แม้ไม่ได้นำไปรันก็มีคุณค่ามาก คิดว่า การแก้ปัญหาให้กันนั้นเองคือของขวัญ
  • แต่อย่างไรเสีย โอเพนซอร์สก็คือ การลงทุนลงแรงและเวลา
    ตัวอย่างเช่น มีคนเล่าว่าดูแล rubygems.org มา 14 ปี ก่อนจะจากไปเพราะผิดหวังกับ โครงสร้างที่กลายเป็นเชิงองค์กร

• มีข้อชี้ให้เห็นว่า “การเขียนโค้ดด้วย AI เองก็เป็น รูปแบบหนึ่งของ dependency”
  การคัดลอกแปะโดยไม่ตรวจสอบไม่ได้ต่างจากการเพิ่มไลบรารีภายนอก

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

[haytsir]

ตอนสร้างโปรเจ็กต์เล็ก ๆ เมื่อต้นปี 2024
ผมเคยขอให้ claude 3.5 สร้างโมดูล store state ที่ใช้ได้ใน pure javascript
แล้วก็จำได้ว่าตกใจที่มันเขียนโค้ดออกมาได้ทั้งกระชับและรองรับสถานการณ์การย้ายระบบได้ด้วย

ผมคิดว่านี่เป็นเรื่องที่เกิดขึ้นได้ตามธรรมชาติ เพราะยิ่งเป็นไลบรารีขนาดเล็ก ก็ยิ่งมีโค้ดที่คนซึ่งคิดคล้าย ๆ กันเผยแพร่ไว้จำนวนมาก และ AI ก็ยิ่งทำมันให้ออกมาเป็นโครงสร้างแบบแผนได้ง่าย

เหมือนกับ copyparty ที่ใคร ๆ ก็คิดได้ แต่ยากที่คนคนหนึ่งจะดูแลรักษาไปได้นาน ๆ
ก็เลยน่าเสียดายอยู่เหมือนกันตรงที่ ต่อจากนี้เราอาจได้เห็นโปรเจ็กต์ที่ผ่านการขัดเกลามาอย่างสะอาดเรียบร้อยจากการผลักดันโปรเจ็กต์แบบนั้นไปจนสุดทางได้ยากขึ้น