วิสัยทัศน์โอเพนซอร์สในยุคที่เอไอเขียนโปรแกรมให้

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

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

ในวันที่เอไอเขียนโปรแกรมให้ได้ สมการนี้เปลี่ยนไปอย่างมีนัยสำคัญ และในระยะถัดไปเร็วนี้ก็จะเรียกว่า “เปลี่ยนโดยสิ้นเชิงไปตลอดกาล”

สิ่งที่เปลี่ยนจริง ๆ ไม่ใช่ “ใครเขียนโค้ด”

สิ่งที่เปลี่ยนคือ ต้นทุนของการเข้าไปแก้ของที่มีอยู่แล้ว

เมื่อก่อน การจะแก้ซอฟต์แวร์โอเพนซอร์สสักตัว ต้องใช้คนที่อ่านโค้ดของคนอื่นเป็น เข้าใจโครงสร้างที่ตัวเองไม่ได้ออกแบบ และมีเวลามากพอจะลุยให้จบ (ส่วนมากด้วยคนที่เก่งที่สุดไม่กี่คน) นั่นคือคอขวดที่แท้จริง ไม่ใช่ค่าไลเซนส์

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

เมื่อแก้ไขและต่อยอดได้อย่างเป็นระบบ เราจะแพ้ยากขึ้น

ประเด็นนี้ผมอยากให้น้ำหนักมากที่สุด ไม่ว่าจะเรื่องส่วนตัว การงาน การเรียน หรือการพัฒนาองค์กร หลักการเดียวกันใช้ได้หมด

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

เป็นระบบ — ไม่ใช่แก้ตามอารมณ์ แต่มีวิธีทำงาน มีการทดสอบ มีร่องรอยว่าเปลี่ยนอะไรไปเพราะอะไร
ชาญฉลาด — เลือกแก้ในจุดที่สร้างความต่าง ไม่ใช่แก้ทุกอย่างที่แก้ได้
ต่อเนื่อง — ข้อได้เปรียบไม่ได้เกิดจากการแก้ครั้งเดียว แต่เกิดจากการทบต้นของการปรับปรุงเล็ก ๆ ที่ไม่หยุด

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

มีคนถามด้วยนะว่า ถ้าเอไอเก่งจริงๆเราต้องเอาโอเพนซอร์สซอฟต์แวร์มาทำไม ผมก็เลยตอบว่า มนุษย์อย่างพวกเรานี่แหละครับที่ทำงานที่ยากและเยอะมากไม่ได้ … ไหน ใครเขียน software spec เหล่านี้ฟรีๆให้ผมหน่อยครับ Data Mining, Logistics/Shipping/Freight Forwarder หรือ Computational Fluid Dynamics (CFD) ผมจะเอาไปสั่งเอไอ … หึหึ

เครื่องมือไม่ได้ทดแทนความรู้ความเข้าใจ

ผมไม่อยากให้ใครอ่านบทความนี้แล้วเข้าใจว่าเอไอจะจัดการให้ทั้งหมด

เอไอเขียนโค้ดได้ แต่มันไม่รู้ว่าลูกค้าของเรากำลังไม่พอใจอะไร มันไม่รู้ได้เองโดยไม่ hallucinate ว่าอะไรในธุรกิจของเราที่ห้ามพลาด และมันไม่รู้ว่าอะไรคือสิ่งที่ทำแล้วไม่มีใครสนใจ

เพราะฉะนั้นสิ่งที่ยังต้องลงทุนลงแรงเหมือนเดิม หรือมากกว่าเดิมด้วยซ้ำ คือ

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

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

แล้วไลเซนส์แบบไหนที่แก้และใช้ได้อย่างเสรีจริง

(ส่วนนี้ถ้ายังไม่ได้เริ่มงานจริง อ่านเอาความรู้ความคิด ข้ามไปก่อนได้ ไว้จะทำค่อยกลับมาอ่านก็ได้)

ส่วนนี้ผมเห็นความเข้าใจคลาดเคลื่อนบ่อยที่สุด และมันสำคัญขึ้นมากเมื่อเอไอเข้ามาแก้โค้ดให้เรา

กลุ่มที่ 1 — เสรีที่สุด (MIT, BSD, Apache 2.0, ISC)

แก้ได้ ใช้เชิงพาณิชย์ได้ ไม่ต้องเปิดโค้ดที่เราแก้ เอาไปรวมกับของปิดของเราได้

MIT / BSD — เงื่อนไขแทบมีข้อเดียว คือคงประกาศลิขสิทธิ์เดิมไว้
Apache 2.0 — เพิ่มสองเรื่องที่องค์กรควรสนใจ คือ การให้สิทธิ์ในสิทธิบัตรอย่างชัดเจน (ลดความเสี่ยงถูกฟ้องภายหลัง) และ ข้อกำหนดให้ระบุว่าได้แก้ไขอะไรไปบ้าง

สำหรับองค์กร ผมมองว่า Apache 2.0 เป็นตัวเลือกที่สมดุลที่สุด เพราะเรื่องสิทธิบัตรเป็นความเสี่ยงที่คนมักมองข้ามจนกระทั่งสายเกินไป

กลุ่มที่ 2 — เปิดบางส่วน (MPL 2.0, LGPL)

MPL 2.0 — ผูกพันระดับไฟล์ แก้ไฟล์ไหนก็เปิดไฟล์นั้น ไฟล์ใหม่ที่เราเขียนเองเก็บไว้ได้
LGPL — เรียกใช้เป็นไลบรารีได้โดยไม่ต้องเปิดโค้ดของเรา แต่ถ้าแก้ตัวไลบรารีเองต้องเปิด

กลุ่มที่ 3 — ต้องเปิดคืน (GPL, AGPL)

GPL — ถ้าเรา แจกจ่าย งานที่ต่อยอดออกไป ต้องเปิดโค้ดส่วนที่แก้ ภายใต้ไลเซนส์เดียวกัน
AGPL — เข้มกว่า เพราะนับ การให้บริการผ่านเครือข่าย เป็นการแจกจ่ายด้วย ถ้าทำ SaaS อยู่ ต้องอ่านข้อนี้ให้ละเอียด

จุดที่คนเข้าใจผิดบ่อยที่สุด

ภาระผูกพันของ GPL เกิดขึ้นตอน แจกจ่าย ไม่ใช่ตอน ใช้ภายใน องค์กรที่เอา GPL มาแก้ใช้เองภายใน ไม่ได้ถูกบังคับให้เปิดโค้ดออกสู่สาธารณะ ข้อยกเว้นสำคัญคือ AGPL ที่นับการให้บริการผ่านเครือข่ายด้วย

ความเข้าใจผิดข้อนี้ทำให้หลายองค์กรตัดโอเพนซอร์สทิ้งตั้งแต่ต้น ทั้งที่กรณีการใช้งานจริงของตัวเองไม่ได้ติดข้อจำกัดอะไรเลย

สองเรื่องที่ต้องระวังเพิ่ม เมื่อให้เอไอแก้โค้ด

หนึ่ง — เอไออาจนำโค้ดที่มีไลเซนส์เข้มเข้ามาโดยที่เราไม่รู้ตัว เราจะมั่วๆไม่ตรวจไม่ได้ ชีวิตง่ายขึ้น 99.9% แล้ว ขอเถอะครับ อย่าขี้เกียจกับ 0.1% เลย เมื่อโค้ดไหลเข้าโครงการเร็วขึ้น การตรวจสอบที่มาของโค้ดก็ต้องเป็นระบบ (ถ้าไม่คิดสร้างระบบนี้ มันก็จะไม่มี เพราะมันคือคัดของก่อนนำมาใช้)

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

วิสัยทัศน์ที่ผมอยากเห็นผู้นำทุกระดับในไทยมี

โอเพนซอร์สเคยเป็นเรื่องของ “ของฟรี” ต่อมาเป็นเรื่องของ “มาตรฐานเปิด” วันนี้ผมคิดว่ามันกำลังกลายเป็นเรื่องของ ความสามารถในการกำหนดชะตากรรมของตัวเอง

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

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

เครื่องมือถูกลงแล้ว ส่วนที่เหลือคือ “อยากให้เป็น เล่นให้จริง”