- แม้ว่า โชคจะดูเหมือนเป็นปัจจัยภายนอกที่ควบคุมไม่ได้ แต่เราสามารถเพิ่มโอกาสที่จะได้พบโอกาสดี ๆ ได้ด้วยการ เผยแพร่ผลงานของเรา
- Luck Surface Area ถูกนิยามว่าเป็นผลคูณของระดับการ “ลงมือทำสิ่งต่าง ๆ (Doing Things)” และ “บอกให้ผู้คนรู้ (Telling People)”
- การลงมือทำงานและการเผยแพร่ เป็นกระบวนการสำคัญสำหรับผู้สร้างสรรค์อย่างนักพัฒนาและนักออกแบบ และเป็นวิธีแสดงให้เห็นถึง ความอยากรู้อยากเห็นและความเชี่ยวชาญ ของแต่ละคน
- แทนที่จะรอผลงานที่สมบูรณ์แบบ การ แบ่งปันกระบวนการ การเรียนรู้ และการลองผิดลองถูกไปพร้อมกัน เป็นสิ่งสำคัญ และยังช่วยสร้างแรงบันดาลใจให้ผู้อื่น
- งานที่เผยแพร่ออกไปสามารถสร้างโอกาสที่ไม่คาดคิด เช่น งานใหม่ ความร่วมมือ การบรรยาย และการเชื่อมต่อกับชุมชน ซึ่งไม่ใช่แค่เรื่องดวง แต่เป็น ผลลัพธ์เชิงความน่าจะเป็นที่เกิดจากการแบ่งปัน
แนวคิดเรื่อง Luck Surface Area
- โชคถูกนิยามว่าเป็น “การที่เรื่องดี ๆ ที่ไม่คาดคิดเกิดขึ้น”
- ตัวอย่าง: ความสำเร็จของไลบรารี OSS, การได้รับเชิญไปงานคอนเฟอเรนซ์, ข้อเสนองานใหม่, การได้ลูกค้า, การไปออกรายการพอดแคสต์, การสร้างคอนเนกชันในชุมชน เป็นต้น
- ตามนิยามของ Jason Roberts, Luck Surface Area แปรผันตามผลคูณของ “ระดับที่คุณลงมือทำบางสิ่งด้วยความหลงใหล” และ “จำนวนคนที่คุณสื่อสารสิ่งนั้นไปถึงได้อย่างมีประสิทธิภาพ”
- หากเขียนเป็นสมการจะได้ว่า Luck = [Doing Things] × [Telling People]
- ยิ่งทำมากขึ้นและยิ่งบอกให้คนรู้มากขึ้น Luck Surface Area ก็ยิ่งใหญ่ขึ้น
การลงมือทำงาน (Doing the work)
- ก่อนจะเผยแพร่ ต้องมี การลงมือทำงานจริง ก่อน
- นักพัฒนา นักออกแบบ และครีเอเตอร์ ล้วนเป็นคนที่สร้างบางสิ่งเป็นแก่นแท้ และนี่คือพื้นฐานของโชค
- มีคนอยู่สองประเภท
1. คนที่ทำสิ่งต่าง ๆ ไว้อยู่แล้วมากมาย แต่ คิดว่างานของตัวเองไม่มีคุณค่าพอที่จะแชร์
2. คนที่ อยากเริ่มทำอะไรบางอย่าง แต่ยังลงมือไม่ได้
- กลุ่มแรกมักประเมินค่าความรู้ของตัวเองต่ำเกินไป และถ้าสังเกตสิ่งที่ถูกแบ่งปันในชุมชน ก็จะพบว่ามีหลายอย่างที่ตัวเองทำได้อยู่แล้ว
- สำหรับกลุ่มที่สอง สิ่งที่จำเป็นคือ เริ่มจากสิ่งเล็ก ๆ
- อย่ารอไอเดียที่สมบูรณ์แบบ แต่ควรเริ่มจาก โปรเจกต์เล็ก ๆ หรือการทดลองเล็ก ๆ
- “การเคลื่อนไหวก่อให้เกิดการเคลื่อนไหว”
การแสดงความอยากรู้อยากเห็นและความเชี่ยวชาญ
- โปรเจกต์ส่วนตัว เป็นพื้นที่ที่ดีสำหรับสำรวจความอยากรู้อยากเห็น
- เช่น การสร้างเครื่องพิมพ์ใบเสร็จที่พิมพ์ GitHub issue, การดัดแปลงโรงเก็บของสำเร็จรูปให้เป็นออฟฟิศ, การพัฒนาเครื่องมือวาด SVG, การเขียนจดหมายข่าวเชิงลึกเกี่ยวกับโครงสร้างพื้นฐานทางการเงิน เป็นต้น
- โปรเจกต์ในงานประจำ เป็นพื้นที่ที่เหมาะกับการแสดงความเชี่ยวชาญ
- ปัญหาที่แก้ได้ในที่ทำงานหรือสิ่งที่เรียนรู้ สามารถต่อยอดเป็น บล็อก งานนำเสนอ หรือโปรเจกต์โอเพนซอร์ส ได้
- แม้รายละเอียดจะเปิดเผยไม่ได้ แต่ก็ยังแชร์ แนวคิด บทเรียน หรือแพตเทิร์น ได้
- หากจดบันทึกปัญหาหรือแพตเทิร์นที่น่าสนใจระหว่างทำงานไว้สักหนึ่งเดือน ก็จะมีไอเดียสำหรับการแบ่งปันเพิ่มขึ้นมาก
การกดปุ่มเผยแพร่ (Hitting the publish button)
- หลายคนรู้สึก กลัวในขั้นตอนการแบ่งปัน
- สาเหตุเช่น ความกลัวต่อคำวิจารณ์ ความสมบูรณ์แบบนิยม หรือความรู้สึกต่อต้านการตลาด
- แต่ การแบ่งปันไม่ใช่ความหลงตัวเอง หากเป็นการกระจายการเรียนรู้ เป็นกระบวนการที่ช่วยสร้างแรงบันดาลใจและการเรียนรู้ให้ผู้อื่น
- แพลตฟอร์มสำหรับการเผยแพร่จะเป็น Twitter, GitHub, บล็อก, จดหมายข่าว, YouTube ฯลฯ ที่ไหนก็ได้ ขอเพียง “ไม่ใช่ในฮาร์ดไดรฟ์”
- การแบ่งปันเป็นทักษะที่ต้องฝึกฝน และสิ่งสำคัญคือไม่ใช่แค่ผลงานที่เสร็จสมบูรณ์ แต่รวมถึง กระบวนการที่กำลังดำเนินอยู่ ความล้มเหลว และกระบวนการคิด ด้วย
- ช่วงแรกอาจรู้สึกแปลก ๆ แต่ถ้าทำต่อเนื่องก็จะเป็นธรรมชาติขึ้น
การคว้าโชคไว้ (Capturing the luck)
- เมื่อเผยแพร่งาน โอกาสที่จะเกิด ผลลัพธ์เชิงบวกที่ไม่คาดคิด ก็จะเพิ่มขึ้น
- เช่น การถูกมองว่าเป็นผู้เชี่ยวชาญในหัวข้อหนึ่ง ๆ, การได้รับฟีดแบ็กจากผู้อ่าน, ข้อเสนอในการหางาน, การติดต่อจากลูกค้า, คำเชิญไปบรรยาย, การสร้างคอนเนกชันในชุมชน, หรือการเพิ่มการรับรู้ต่อโปรเจกต์ OSS
- ตัวอย่างเหล่านี้เป็นสิ่งที่ผู้เขียนได้ประสบมาจริง และเป็น ผลจากการขยาย Luck Surface Area ผ่านการแบ่งปัน
- สูตรสำคัญนั้นเรียบง่าย
- Do the work. Tell people.
- ลงลึกกับความอยากรู้อยากเห็นและความเชี่ยวชาญของคุณ แล้วแบ่งปันสิ่งที่เรียนรู้ออกไปอย่างเปิดเผย
- แม้จะหลีกเลี่ยงคำวิจารณ์บนออนไลน์ไม่ได้ แต่ ยังมีผู้คนที่คอยสนับสนุนอยู่เงียบ ๆ มากกว่าคนวิจารณ์อย่างมาก
- และท้ายที่สุด ในหมู่คนเหล่านั้น อาจมีสักคนที่มอบโอกาสซึ่งเปลี่ยนชีวิตคุณได้
3 ความคิดเห็น
สิ่งหนึ่งที่ผมเน้นย้ำกับรุ่นน้องเสมอคือ
"พอแก้ปัญหาได้แล้ว ให้สรุปออกมาให้ดีและเก็บไว้เป็นโพสต์สาธารณะ"
อย่างแรกคือระหว่างที่เรียบเรียง เราจะได้ทบทวนกระบวนการทั้งหมดอีกครั้ง เลยจำได้ง่ายขึ้น
และต่อให้เจอปัญหาเดิมอีก พอค้นใน Google ก็จะเจอบทความของตัวเอง ทำให้แก้ได้เร็วขึ้น (ขอบคุณตัวเองในอดีต!)
อีกทั้งยังอาจเป็นประโยชน์กับคนอื่นได้ด้วย เลยช่วยเพิ่มชื่อเสียงให้เราได้เหมือนกัน
ความคิดเห็นจาก Hacker News
ในฐานะคนที่ทำงานอยู่ในวงการโอเพนซอร์ส (OSS) มาตลอด ฉันหวังจากใจจริงว่า โปรเจกต์ GitHub ของฉันจะไม่โด่งดัง
ฉันมีโปรเจกต์ทดลองที่ได้ดาวเกิน 50 ดาวอยู่หลายตัว แต่ก็ดีแล้วที่มันไม่ได้พัฒนาไปเป็น OSS แบบ ‘จริงจัง’
ฉันเคยเสียวันหยุดสุดสัปดาห์ไปกับการแก้บั๊กในโปรเจกต์เก่า ๆ หรือรีวิว PR ที่ฉันไม่ได้สนใจ
การดูแล OSS แทบจะเป็น งานพาร์ตไทม์ที่ไม่มีค่าตอบแทน ชื่อเสียงก็มีอย่างจำกัด และแม้แต่นักพัฒนา OSS ที่เก่งมาก ๆ ก็ยังหางานที่เหมาะสมในอุตสาหกรรมได้ยาก
ฉันคิดว่าผู้ดูแล OSS คือ นักบุญ ที่ค้ำจุนซอฟต์แวร์ของทั้งโลกไว้
น่าจะเพิ่ม สถานะแบดจ์ ใน GitHub README แบบ “ยินดีรับ PR”, “แก้เฉพาะบั๊กด้านความปลอดภัย·บั๊กร้ายแรง”, “กำลังหาผู้ดูแลใหม่” ได้
เลยทำให้ทุกวันนี้เกิดคำถามว่า “แล้วทำไมเราต้องไปทำสัญญาทางสังคมแบบนี้ด้วย?”
ทางเลือกหนึ่งคือการบริหารโปรเจกต์อย่างอิสระผ่าน Git community ที่โฮสต์เอง วิธีแบบนี้ไม่ทำให้ความพยายามของผู้ดูแลถูกทำให้เป็นสินค้า และอาจทำให้โอเพนซอร์สกลับมาสนุกอีกครั้ง
ตัวอย่างเช่น ถ้ามี PR เข้ามาใน repo ที่ไม่ได้แตะมา 5 ปี ก็ควรมีสรุป code review ให้อัตโนมัติ หรือมีฟีเจอร์กรองคอมเมนต์ที่เสียมารยาท
ถ้าไม่เปิดโค้ดก็ยากที่จะสร้าง ความไว้วางใจจากชุมชน และแนวทางแบบ “ทิ้งอีเมลไว้แล้วจะได้ whitepaper PDF” ใช้ไม่ได้แล้วในปี 2025
100% ของ 0 ดอลลาร์ก็ยังเป็น 0 อยู่ดี แต่ 0.001% ของตลาดขนาดมหึมา ก็ยังเป็นโอกาสที่ใหญ่พอสมควร
ถ้ามองแก่นของบทความนี้ สุดท้ายมันคือโครงสร้างที่ ใครบางคนอื่น (มักจะเป็นบริษัท) ได้ประโยชน์มากที่สุดจากการเอาโอเพนซอร์สออกมาเผยแพร่
นี่จึงเป็นเหตุผลที่ GitHub (=Microsoft) ถูกมองว่าเป็น “เครื่องสกัดแรงงานฟรี” ได้อย่างหลีกเลี่ยงไม่ได้
ถ้าเป็นบทความที่สมดุลกว่านี้ ก็ควรเตือนถึง ผลประโยชน์ทับซ้อน แบบนี้ด้วย
บริษัทต่าง ๆ ชอบแรงงานฟรีของเรา แต่ไม่ยอมจ้าง “ขอบคุณนะ ใช้งานดีมาก แต่เราไม่รับคุณเข้าทำงาน” ประมาณนั้น
ตอนนี้โค้ดของพวกเรายังถูก ดูดซึมไปเป็นข้อมูลฝึก LLM โดยไม่เหลือแม้แต่ชื่อด้วยซ้ำ
ฉันรู้สึกเหมือนโยนข้อความลงทะเลแล้วไม่ได้ยินเสียงตอบกลับอะไรเลย
แพลตฟอร์มต่าง ๆ กระซิบว่า “โพสต์อีกครั้งเดียวก็จะสำเร็จแล้วนะ” แต่ฉันก็เริ่มสงสัยว่ามันจริงหรือเปล่า
บางคนประสบความสำเร็จใน 3 ปีด้วย product-led marketing ขณะที่อีกคนใช้เวลา 5 ปีสร้างผู้ชมผ่านบล็อกก่อนจะทำเงินจาก OSS ได้
ท้ายที่สุดแล้วคำว่า “เพิ่มโชคของตัวเอง” ก็ใกล้เคียงกับ สโลแกนสร้างแรงจูงใจ มากกว่า แต่ในความเป็นจริงต้องอาศัยความพยายามอย่างสม่ำเสมออย่างน้อย 5-6 ปี
สิ่งที่เราเขียนถูกดูดเข้าไปเป็นข้อมูลฝึกของบริษัทต่าง ๆ คนอ่านก็จ่ายเงินให้บริษัทเหล่านั้น ส่วนเรา ไม่ได้แม้แต่คำขอบคุณ
ข้อยกเว้นมีแค่ ชุมชนปิด ที่ยังมีปฏิสัมพันธ์กันโดยตรงระหว่างมนุษย์
ฉันเห็นด้วยกับบทความนี้มาก
เพราะ OSS ฉันได้รับข้อเสนอจากหลายบริษัท โดยไม่ต้องมีเรซูเม่หรือทำ coding test
ครั้งหนึ่งฉันช่วยดีบั๊กบั๊กร่วมกับฝ่ายซัพพอร์ตของ GitHub แล้วก็ได้รับการแนะนำตัวต่อไปยัง Microsoft MD และกับ Cloudflare ก็มีประสบการณ์คล้ายกัน
สุดท้ายแล้ว OSS คือเครื่องมือที่ช่วยสร้าง เครือข่ายที่ตั้งอยู่บนความไว้วางใจ
การเขียนหนังสือและเซ็นหนังสือตามงานคอนเฟอเรนซ์ทำให้โอกาสเกิดขึ้นเองตามธรรมชาติ
สำหรับฉัน ขั้นตอนของโอเพนซอร์สเป็นแบบนี้
1. หา จุดเจ็บปวด จากงานของตัวเอง
2. สร้างเครื่องมือมาแก้ปัญหานั้น
3. แชร์มันอย่างเป็นธรรมชาติใน Reddit, HN, Bluesky ฯลฯ
โอเพนซอร์สคือ วิธีส่งสัญญาณ ถ้าไปได้ดี มันก็จะกลายเป็นนามบัตรและต่อยอดไปสู่โอกาสด้านคอนซัลต์หรืองานได้
ตัวอย่างเช่น ในเดือนเมษายน 2023 ฉันเห็น LangChain แล้วเลยสร้าง Langroid LLM agent framework ขึ้นมา และ
ตอนนี้ก็ยังดูแลชุดเครื่องมือ CLI ชื่อ Claude Code Tools อยู่ด้วย
กระบวนการแบบนี้ทำให้โอเพนซอร์สกลายเป็น วิธีสะสมความน่าเชื่อถือที่คล้ายกับการตีพิมพ์งานวิชาการ
(เสียดสี) “สวัสดีเหล่าทาสติดที่ดินแห่งโอเพนซอร์ส! ช่วย ส่งข้อมูลเพิ่ม ให้เรา เพื่อที่ AI ของเราจะได้มาแทนที่งานของพวกคุณ!”
ฉันเขียนหนังสือคณิตศาสตร์มาหลายเล่ม และถึงแม้ โชคจะเพิ่มขึ้นมาบ้าง แต่แรงงาน 1200 ชั่วโมงก็ยังไม่ได้รับค่าตอบแทนแม้แค่ในระดับค่าแรงขั้นต่ำ
ฉันเองก็เคยได้ งานดี ๆ หลายครั้งจากการปล่อยผลงานอะไรบางอย่างออกมา แม้จะไม่ได้รวย แต่ก็ช่วยเรื่องอาชีพมาก
(ผู้เขียน) ฉันเขียนโพสต์นี้ไว้เมื่อหลายปีก่อน และดีใจที่ได้เห็นมันกลับมาบน HN อีกครั้ง
ใน เธรดตอนนั้น ก็มีการถกเถียงแบบคล้าย ๆ กัน
หลายคนบอกว่านี่เป็น “บทความที่เอาไว้ป้อนเครื่องจักร” แต่ บทความนี้เปลี่ยนชีวิตฉันจริง ๆ ฉันหวังว่ามันจะช่วยคนอื่นได้ด้วย
ตำแหน่งของผู้เขียนคือ “Aaron Francis, Marketing Engineer” ซึ่งก็ทำให้ฉันสงสัยว่าเดี๋ยวนี้ การตลาดก็เรียกว่า engineering กันแล้วเหรอ
โปรไฟล์ GitHub ของฉัน
> Luck = [Doing Things] × [Telling People]
เหมือนผมจะเคยเห็นสูตรนี้เมื่อหลายปีก่อนเหมือนกัน แต่ก็ทำตามได้ไม่ค่อยดีเท่าไรตลอดช่วงที่ผ่านมา