Postgres: คนรุ่นถัดไป - การลงทุนกับคอมมิตเตอร์รุ่นถัดไป

 (redmonk.com)
3 คะแนน โดย GN⁺ 2023-10-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • PostgreSQL ที่เปิดตัวในปี 1986 กำลังเผชิญปัญหาเรื่อง ความยั่งยืน เมื่อกลุ่มคนที่ดูแลโค้ดแกนหลักจริง ๆ มีอายุมากขึ้น และเกิดคำถามว่าอีก 20 ปีข้างหน้าใครจะสานต่องานนี้
  • ณ ปี 2022 มีนักพัฒนาที่เป็น ผู้เขียนหลัก ของคอมมิตอย่างน้อยหนึ่งรายการจำนวน 192 คน และเป็นโครงสร้างที่ กระจุกตัวอยู่ในคนส่วนน้อย โดย 66% ของโค้ดใหม่เขียนโดย 14 คน และ 90% เขียนโดย 40 คน
  • ชุมชนนักพัฒนาหลักมีอายุเฉลี่ยราว 50 ปี และ Tom Lane ในวัย 68 ปียังคงเป็นแกนกลางของโครงการ
  • Neon เลือกลงทุนแบบตั้งใจใน การสร้างคนรุ่นถัดไป โดยจ้างจูเนียร์มาพัฒนาจาก contributor ไปเป็น committer และ maintainer แทนการดึงตัวท็อปทาเลนต์ที่มีอยู่แล้ว
  • เพื่อให้โครงการได้รับการบำรุงรักษาอย่างต่อเนื่อง จำเป็นต้องมี ความตั้งใจ เงินทุน และผลประโยชน์ตนเองแบบรู้เท่าทัน (enlightened self interest)

ปัญหาอายุเฉลี่ยที่สูงขึ้นของ PostgreSQL และกำลังคนด้านการบำรุงรักษา

  • PostgreSQL ที่เปิดตัวในปี 1986 ได้กลายเป็นตัวเลือกพื้นฐานในงานพัฒนาซอฟต์แวร์สมัยใหม่จำนวนมาก แต่เมื่อเวลาผ่านไปยาวนานหลังการเปิดตัว ก็เกิดคำถามเรื่องความต่อเนื่องของคนที่เป็นผู้สร้างฐานข้อมูลนี้จริง ๆ
  • มีคำถามว่าพวกเขาจะยังทำ งานหนัก (heavy lifting) ในการดูแลโค้ดเบสสำคัญที่ผู้คนจำนวนมากพึ่งพาได้อีกนานแค่ไหน
  • Postgres เป็นทั้งชุมชนและโครงการที่มีขนาดเล็กและผูกพันกันอย่างใกล้ชิด

สถิติผู้มีส่วนร่วมในปี 2022

  • Robert Haas หัวหน้านักวิทยาศาสตร์ด้านฐานข้อมูลของ EnterpriseDB และ Postgres committer เปิดเผยตัวเลขไว้ในบทความสรุปการมีส่วนร่วมประจำชื่อ "Who Contributed to PostgreSQL Development in 2022?"
    • ในปี 2022 มีคน 192 คนที่เป็น ผู้เขียนหลัก (principal author) ของคอมมิต PostgreSQL อย่างน้อยหนึ่งรายการ
    • 66% ของบรรทัดโค้ดใหม่เขียนโดยหนึ่งใน 14 คน
    • 90% ของบรรทัดโค้ดใหม่เขียนโดยหนึ่งใน 40 คน

โครงสร้างอายุของชุมชนแกนหลัก

  • ชุมชนนักพัฒนาหลักมีอายุเฉลี่ยค่อนข้างสูง โดยอยู่ที่ประมาณ 50 ปี
  • Tom Lane แห่ง Crunchy Data ในวัย 68 ปี ยังทำหน้าที่เป็นจุดหมุนสำคัญ (fulcrum) ของโครงการ Postgres

Open governance และคำถามในอีก 20 ปีข้างหน้า

  • Open governance ของ Postgres เป็นรากฐานที่พึ่งพาได้ และเป็นตัวอย่างที่สดใหม่ในยุคที่มีการเปลี่ยนไลเซนส์โอเพนซอร์สเชิงพาณิชย์แบบหักหลังกันบ่อยครั้ง
  • ในมุมมองเรื่องความยั่งยืนของโอเพนซอร์ส หากสมมติว่า Postgres ยังแข็งแรงดีในอีก 20 ปี ก็จะเกิดคำถามว่า แล้วในปี 2043 ใครจะเป็นคนทำงานนี้

Neon และบทสนทนากับ Nikita Shamgunov

  • จากบทสนทนากับ Nikita Shamgunov ซีอีโอของ Neon มีการพูดถึงการที่โครงการเทคโนโลยีมีอายุเฉลี่ยสูงขึ้น และความเกี่ยวข้องของเรื่องนี้กับความยั่งยืนของโครงการ

  • แนะนำ Neon

    • Neon คือฐานข้อมูล Postgres แบบ fully managed ที่เหมาะกับแอป serverless โดยแยก storage ออกจาก compute และยึดหลักการออกแบบว่า "database is a URL"
    • รองรับ branching ที่ทำให้ deploy แบบ preview ได้ และจากจุดนี้จึงเกิดความร่วมมือกับ Vercel
    • มีแนวทางว่าอยากทำให้เป็น "ใช้งานง่าย ทันสมัย และเป็น zero config API"
    • มีพนักงาน 62 คน ระดมทุนสะสมได้ 108 ล้านดอลลาร์ ($108m) และแข่งขันกับ Supabase เป็นต้น

  • ความต่างระหว่าง committer กับ contributor

    • Shamgunov กล่าวว่า "ชั้น committer ของ Postgres อยู่ในวัย 50, 60 และ 40 เป็นหลัก ส่วนวัย 30 มีน้อย"
    • การจะเป็น committer ต้องใช้ความพยายามมาก แต่การเป็น contributor นั้น แค่เขียนโค้ดดี ๆ ก็พอ

การลงทุนเพื่อสร้างคอมมิตเตอร์รุ่นถัดไป

  • Neon ลงทุนอย่างตั้งใจใน คนรุ่นถัดไป ของ contributor, committer และ maintainer
  • สำหรับหลายบริษัท ทางเลือกที่เกิดขึ้นเองตามธรรมชาติคือการดึงตัวท็อปทาเลนต์ที่มีอยู่แล้ว แทนการปั้นคนใหม่
    • Shamgunov กล่าวว่า "เราเคยคุยกันว่าจะไปหาจ้าง Postgres committer เพิ่มดีไหม แต่ก็ไม่ชัดว่ามันเป็นการใช้เงินที่ดีที่สุดหรือเปล่า"
    • "การสร้างคนใหม่อาจดีกว่า และด้วยวิธีนั้นเราก็สามารถขยายทีม Postgres ต่อไปได้"
  • Shamgunov เน้นว่าการจ้างและฝึกจูเนียร์ให้เติบโตเป็น committer และต่อไปเป็น maintainer มีความสำคัญต่อ วิวัฒนาการอย่างต่อเนื่องของเอนจิน Postgres

ไลเซนส์และผลประโยชน์ตนเองแบบรู้เท่าทัน

  • IP ของ Neon ปัจจุบันใช้ ไลเซนส์แบบ permissive แต่ Shamgunov ไม่ใช่พวกยึดหลักโอเพนซอร์สแบบสุดโต่ง
  • ในอนาคต Neon ยังมีสิทธิ์ relicense แบบเดียวกับ Redis, MongoDB และ Elastic เพื่อเปลี่ยนไปใช้เงื่อนไขที่เข้มงวดกว่า
    • อย่างไรก็ตาม โค้ดที่เคยมีส่วนร่วมกับ Postgres ไปแล้วจะไม่ได้รับผลจากการตัดสินใจนั้น
  • การมี Postgres maintainer หลักอยู่ภายในบริษัทเป็นตัวอย่างของ ผลประโยชน์ตนเองแบบรู้เท่าทัน (enlightened self interest) ซึ่งเป็นกลไกที่ช่วยให้บริษัทยังคงซื่อสัตย์ และไม่ว่าจะตัดสินใจอย่างไร ชุมชนกับโค้ดเบสแกนหลักก็ยังได้ประโยชน์

ความเป็นสากลของปัญหากลุ่มคนมีอายุสูงขึ้น

  • ปัญหากลุ่มคนในชุมชนมีอายุสูงขึ้นไม่ได้จำกัดอยู่แค่ Postgres เท่านั้น เช่นเดียวกับกรณี Y2K ในอดีต ชุมชนและระบบนิเวศก็มีอายุมากขึ้น และอาจก่อให้เกิดปัญหาในด้านเทคโนโลยี กำลังคน และการผลัดเปลี่ยนรุ่น
  • IBM เป็นตัวอย่างของความสำเร็จในการดึงนักพัฒนารุ่นใหม่เข้าสู่สายเมนเฟรมผ่านโครงการฝึกอาชีพร่วมกับมหาวิทยาลัย เป็นต้น
  • ยังมีอีกหลายโครงการที่มีผู้ใช้ระดับหลายล้านคน แต่ดำเนินงานโดยคนเพียงหนึ่งหรือสองคนโดยไม่มีการสนับสนุนจากบริษัทแบบ Postgres หรือ Kubernetes

บทสรุป — ความตั้งใจในการบำรุงรักษา

  • Postgres ไม่มีปัญหาเลยในการได้ผู้ใช้ใหม่ และทุกวันนี้แม้แต่นักพัฒนาอายุ 22 ปีก็ยังเลือกใช้เป็นค่าเริ่มต้น จึงเป็น แพลตฟอร์มที่ได้รับความนิยมอย่างมาก
  • แต่หากต้องการรับประกันการบำรุงรักษาโครงการอย่างต่อเนื่อง ก็จำเป็นต้องมี ความตั้งใจ (intentionality) เงินทุน และผลประโยชน์ตนเองแบบรู้เท่าทัน

การเปิดเผยข้อมูล (Disclosure)

  • Neon ไม่ใช่ลูกค้าของ RedMonk ส่วน Crunchy Data, IBM และ Vercel ต่างเป็นลูกค้าของ RedMonk และบทความนี้เผยแพร่อย่างเป็นอิสระโดยไม่เกี่ยวข้องกับความสัมพันธ์ทางธุรกิจดังกล่าว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-12
ความคิดเห็นบน Hacker News

  • แม้จะอายุ 46 แล้ว แต่ก็อยากเข้าไปเป็นส่วนหนึ่งของ รุ่นถัดไป และคิดว่าน่าจะมีคนที่อายุน้อยกว่านี้อีกแน่นอน
    งานนำเสนอครั้งสุดท้ายที่ PGCon คือเรื่องช่องว่างที่ต้องรู้หากจะ hack Postgres โดยเฉพาะขั้น executor และความพยายามในการเติม TupleTableSlot
    แม้จะไม่ใช่คนที่เหมาะที่สุด แต่บางครั้งคนที่กำลังเรียนรู้อาจรู้ดีกว่าว่าผู้เรียนต้องการอะไร
    ไม่นานมานี้ผมลองเขียนสารบัญหนังสือเกี่ยวกับวิธี contribute ให้ Postgres ด้วย และคิดว่าน่าจะขายได้อย่างน้อย 10 เล่ม
    การทำเป็นซีรีส์ออนไลน์อาจดีกว่าก็ได้ แต่ไม่ว่าจะเป็นแบบไหนก็อยากรู้ว่าจะมีคนสนใจไหม
    ตอนนี้ Postgres ใกล้เคียงกับงานอดิเรกมากกว่า แต่ถ้ามีที่ไหนกำลังมองหาคนทำ การ contribute ให้ Postgres แบบโอเพนซอร์ส เต็มเวลา ก็ยินดีคุยด้วย

    • จำได้ว่า Paul ตื่นเต้นมากตอนส่งแพตช์แรกและได้รับอีเมลตอบกลับ
      รุ่นถัดไป จำนวนไม่น้อยในตอนนี้ก็เข้ามาใน Postgres ค่อนข้างช้าเหมือนกัน
      Tom เองก็คงพูดถ่อมตัว แต่เขาทำงานด้านภาพมาหลายปี และมีส่วนเกี่ยวข้องไม่ทางใดก็ทางหนึ่งกับกระบวนการสร้าง tiff, jpg, png แต่ละแบบ ก่อนจะพบ Postgres และเริ่มทำงานกับมัน
    • ถ้ายังไม่ได้ติดต่อ ลองติดต่อ Andrey Borodin ผู้ contribute ให้ PG ดูก็น่าจะดี
      เขาทำคอนเทนต์ไว้มากมายเกี่ยวกับวิธีเริ่ม contribute ให้ Postgres และยังเปิดกว้างในการพูดคุยกับผู้ใช้ PG ตัวยงคนอื่น ๆ
      อาจร่วมมือหรือขอคำแนะนำได้ด้วย: https://www.youtube.com/watch?v=rihfAnd_leM
      ติดต่อได้ทางอีเมล x4mmm@.ru หรือ Twitter @x4mmmmmm
    • เคยเห็น วิศวกรระดับท็อป หลายคนที่ทำงานต่อไปจนเลยวัย 70 เพราะที่บ้านทำเรื่องเจ๋ง ๆ ไม่ได้
      เมื่อกำแพงในการเข้าร่วมต่ำลง ก็หวังว่าจะมีคนเกษียณเร็วมากขึ้นและเข้ามามีส่วนร่วมกับโอเพนซอร์ส
    • การเปิดเผยต้นฉบับที่กำลังเขียนอยู่ทางออนไลน์น่าจะช่วยทำการตลาดหนังสือได้ ตัวอย่าง: https://www.cl.cam.ac.uk/~rja14/book.html
      สำนักพิมพ์บางแห่งอนุญาตให้ผู้อ่านแบบ early access รายงานข้อผิดพลาดได้: https://nostarch.com/early-access-program

  • น่าสนใจถึงขั้นมีเป้าหมายว่าอยากเกษียณเร็วให้ได้ เพื่อจะได้ hack Postgres เต็มเวลา
    ในนั้นมีทั้ง networking, storage, data, algorithms และอื่น ๆ
    พูดตรง ๆ C เป็นปัญหาที่เล็กกว่า ส่วน Postgres มี code style ที่ดีและค่อนข้างสม่ำเสมอ
    สิ่งที่ยากคือความซับซ้อนของโครงสร้างภายใน และถ้าชุมชนมีขนาดเล็กก็อาจส่งผลต่อความเร็วในการขอความช่วยเหลือด้วย

    • อยากให้มีองค์กรแบบ NSF สำหรับ การ contribute ให้ซอฟต์แวร์เสรีและโอเพนซอร์ส
    • สามารถถูกจ้างให้ทำงานเต็มเวลาในฐานะ committer ของ Postgres ได้

  • สงสัยว่าในอนาคต codebase ภาษา C จะมีปัญหาในการหาผู้ดูแลหรือไม่
    Postgres มีการสนับสนุนเชิงพาณิชย์และแรงเฉื่อยอยู่ แต่ดูเหมือนช่องทางที่นักพัฒนา C ฝีมือดีจะไหลเข้ามายังมีไม่พอ

    • สักวันอาจเป็นอย่างนั้น แต่อนาคตนั้นน่าจะอยู่ห่างออกไปอีกหลายสิบปี
      C ยังเป็นภาษาที่ยังมีชีวิต และไม่ได้ขาดผู้ใช้งานที่ active อีกทั้งสำหรับคนที่ทำ system programming ด้วยภาษาอื่น learning curve ก็ไม่ได้ชันมากนัก
      สำหรับนักพัฒนาเว็บและแอปในปัจจุบัน อาจรู้สึกว่า C น่าเกรงขาม เพราะมีม่านทึบกั้นระหว่างตัวเองกับสถาปัตยกรรมระบบระดับล่าง แต่ system programmer ที่ใช้ C++ หรือ Rust ก็ทำงานอยู่หลังม่านนั้นอยู่แล้ว แค่สวมถุงมือที่หนากว่า
      คนเหล่านี้มักเคยสัมผัส C มาแล้ว อย่างน้อยก็ในแง่การศึกษาในอดีตหรือการทดลอง และหากต้องรับผิดชอบอย่างมืออาชีพ ก็สามารถตั้งใจศึกษาและปรับตัวให้เข้ากับ หลุมพรางอันตรายต่าง ๆ ได้
      มีเหตุผลที่จะคัดค้านการเลือก C สำหรับโปรเจกต์ระบบใหม่ แต่ถ้าไม่นับปัญหาการขาดแคลน system programmer เอง ก็ยังไม่เห็นว่าน่ากังวลมากนักในตอนนี้สำหรับการหาผู้ดูแลโค้ดเดิม
    • จากมุมมองของแฮ็กเกอร์ Postgres คิดว่าสุดท้ายก็น่าจะเป็นแบบนั้น
      ไม่ได้วัดอย่างเป็นวิทยาศาสตร์ แต่ดูเหมือน ทักษะ C เฉลี่ยของผู้ contribute รายใหม่จะต่ำกว่าเมื่อก่อน และแน่นอนว่านี่อาจเป็นแค่เสียงจากเคราสีเทาของผมก็ได้
      จนถึงตอนนี้ผู้คนก็ใช้วิธี “เรียนไประหว่างทำ” แต่ยังไม่แน่ใจว่าช่องว่างนั้นกว้างแค่ไหน
      สักวันคงต้องทำให้บางส่วนของระบบ เช่น การ implement data type ใน core สามารถใช้ภาษาอื่นได้ง่ายขึ้น แต่ในทางปฏิบัติก็ดูเหมือนยังอีกค่อนข้างไกล
    • การเข้ามาพัฒนา Postgres เป็นเรื่องยากก็จริง แต่เรื่องนั้นไม่ค่อยเกี่ยวกับ ความเชี่ยวชาญภาษา C เท่าไร
      ส่วนที่ยากคือการมี domain knowledge ที่ถูกต้อง และต้องใช้เวลานานกว่าจะคุ้นเคยกับทั้งระบบ
    • คิดว่าไม่น่าจะเป็นปัญหาใหญ่
      แทบไม่รู้จักนักพัฒนา Rust หรือ C++ ฝีมือดีที่ไม่ชำนาญ C ด้วย
      แต่ก็สงสัยว่าเมื่อไหร่ codebase ภาษา C จำนวนมากขึ้นจะเริ่มแยกโมดูลออกมาแล้ว แทนที่ด้วย Rust
      เรื่องนี้เกิดขึ้นแล้วใน Linux, curl, โปรเจกต์ C++ อย่าง Chrome, ผลิตภัณฑ์หลายตัวของ MS, Amazon S3 ฯลฯ
      กรณีที่ยืนกรานอย่างชัดเจนที่สุดเท่าที่ผมรู้คือ OpenBSD เพราะต้องการรักษา bootstrap และ toolchain ของการติดตั้งพื้นฐานให้เล็ก
    • อาจเป็นความคิดโง่ ๆ ก็ได้ แต่ผมรู้สึกว่า C เรียนง่ายกว่าและเรียบง่ายกว่า Rust ไม่ใช่หรือ
      แม้แต่ type system ของ TypeScript ก็ยังซับซ้อนกว่า C พอสมควร
      หรือไม่อย่างนั้นก็คงเป็นการเผยให้เห็นว่าผมไม่รู้ว่า C ซับซ้อนแค่ไหน

  • มีเรื่องให้คิดมากเกี่ยวกับหัวข้อนี้
    คอมมูนิตี้มีการขยายและหดตัวสลับกันมานาน และผมขอพูดบางอย่างด้วยเจตนาที่จะแชร์เกี่ยวกับคอมมูนิตี้ PG ให้มากขึ้นอีกหน่อย
    หลายปีที่ผ่านมาไม่มี committer ใหม่เลย และช่วงหลังทีมก็พยายามเพิ่ม committer ใหม่อย่างตั้งใจมากขึ้น รวมถึงจัดการรายชื่อคนที่ไม่ได้มีส่วนร่วมแล้ว
    ประมาณ 15 ปีก่อนเคยมีช่วงที่คนอายุน้อยจำนวนไม่น้อยได้ สิทธิ์ commit และผมจำได้ว่ามีสามคนที่ได้ก่อนอายุ 25 ปี หรืออาจจะทั้งหมดก่อนอายุ 22 ปีด้วยซ้ำ
    หนึ่งในนั้นย้ายออกจากคอมมูนิตี้ Postgres ไม่นานหลังจากนั้น อีกคนเงียบไปยุ่งกับงานอื่นกว่าสิบปีก่อนจะกลับมา และอีกคนยังคงมีส่วนร่วมอย่างต่อเนื่อง
    ดูเหมือนว่าความไม่สบายใจกับกรณีคนที่ได้สิทธิ์ commit แล้วหายไป ทำให้การเพิ่มคนใหม่ช้าลงไปหลายปี
    สรุปคือ หมายความว่าการได้สิทธิ์ commit ของ Postgres ทันทีหลังเรียนจบมหาวิทยาลัยนั้นเป็นเรื่องยาก
    ข้อมูลที่น่าสนใจแต่เก็บยากคือ ผู้คนได้เป็น committer ของ Postgres ตอนอายุเท่าไร
    ผมคงไม่แปลกใจถ้าโดยเฉลี่ยแล้วอายุที่ได้รับสิทธิ์ commit จะใกล้ 45 ปี
    ผู้มีส่วนร่วมจำนวนมากย้ายมาที่ Postgres หลังจากผ่านงานกับระบบอื่นมาแล้ว หรือไม่ก็รู้สึกว่าการส่งแพตช์เข้า mailing list เป็นเรื่องน่ากดดัน จึงเพิ่งพิจารณาจะมีส่วนร่วมหลังมีประสบการณ์การทำงานสะสมระดับหนึ่ง

    • ผมมีเกียรติที่ได้ทำงานร่วมกับผู้มีส่วนร่วมของ Postgres คนหนึ่งซึ่งเริ่มมีส่วนร่วมครั้งแรกตอนอายุเลย 25 ไปเล็กน้อย
      เรื่อง commit แรกของคนนั้นยอดเยี่ยมมาก
      ระหว่างทดสอบพฤติกรรม SQL ที่ Materialize เขาพยายามตรวจสอบว่าสองระบบจัดการฟังก์ชัน interval แบบเดียวกันหรือไม่ และลองทำอย่างละเอียดถึงขนาดใช้ select interval '0.5 months 2147483647 days';
      ลองด้วยตัวเองได้ที่ dbfiddle: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
      Postgres ส่งค่าผิดเป็น {"days":-2147483634} แทนที่จะเกิดข้อผิดพลาด และอ่านเหตุผลได้ที่นี่: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
      ดังนั้นจึงแก้ใน Postgres อย่างเป็นธรรมชาติ และเพราะเหตุนี้เวอร์ชัน 15 ขึ้นไปจึงจัดการได้ถูกต้อง: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
    • การจะเป็นผู้มีส่วนร่วมของ PG มี กำแพงการเข้าสู่ระบบ ค่อนข้างสูง
      ผมชอบ Postgres มากจนถึงขั้นสักลาย PG แต่เส้นทางการมีส่วนร่วมทั้งสองทางก็ไม่ง่าย
      ต่อให้พยายามมีส่วนร่วมในเวลาว่างในฐานะผู้ใช้ทั่วไป ก็ไม่ได้มี ticket ประเภท “issue ที่เหมาะสำหรับมือใหม่” มากนัก และถ้าไม่รู้บริบทกับเหตุผลทางประวัติศาสตร์ของหลายส่วนในสถาปัตยกรรม PG อย่างน้อยบ้าง ก็เริ่มต้นได้ยาก
      การให้คนอย่าง Tom หรือ Andres รีวิวแพตช์ก็อาจทำให้รู้สึกกดดันได้
      เส้นทางการเข้าไปเป็นนักพัฒนาของบริษัท PG แบบมีรายได้อย่าง EDB, PG Pros, Crunchy ก็คล้ายปัญหาไก่กับไข่
      ถ้าไม่มีประสบการณ์แฮ็ก PG มาก่อนก็ยากที่จะถูกจ้างในตำแหน่ง junior แต่เส้นทางสำหรับสะสมประสบการณ์นั้นเองก็ไม่ง่าย
      ถ้าไม่ใช่บริษัทปัจจุบัน ผมก็อยากทำงานในที่ที่ทำงานเกี่ยวกับ PG แต่ในความเป็นจริงมีช่องทางเข้าที่เป็นไปได้ไม่มากนัก
    • แม้จะไม่มีข้อมูลอายุเฉลี่ย แต่เมื่อไม่นานมานี้เคยคุยกันเรื่อง เวลาที่ใช้กว่าจะได้เป็น committer หลังจากเริ่มเกี่ยวข้องกับ Postgres และเขียนโค้ด
      สำหรับ 10 คนที่เพิ่งได้เป็น committer เมื่อเร็ว ๆ นี้ ผมลองใช้คำสั่ง git ประมาณนี้หลายคำสั่ง เพื่อเปรียบเทียบช่วงเวลาที่ชื่อปรากฏครั้งแรกในข้อความ commit กับช่วงเวลาที่ทำ commit แรกในฐานะ committer
      ระยะเวลามีส่วนร่วมโดยเฉลี่ย เมื่อเทียบแค่เดือน/ปี อยู่ที่ประมาณ 8.9 ปี และกรณีที่สั้นที่สุดก็ประมาณ 6.5 ปี
      น่าจะวิเคราะห์ให้ดีกว่านี้ได้ แต่เป้าหมายคือการได้ความรู้สึกคร่าว ๆ
      git log --grep 'Name' --format=%cs | sort | head -1
      git log --author 'Name' --format=%cs | sort | head -1
    • ผมสงสัยว่าตอนนี้ Postgres ใหญ่ขึ้นแค่ไหนเมื่อเทียบกับ 15 ปีก่อนในแง่จำนวนบรรทัดโค้ด
      ตอนนั้นอาจเข้าถึงง่ายกว่าสำหรับคนอายุ 22 ปี และอาจทำความเข้าใจส่วนต่าง ๆ ได้มากกว่า
      อีกอย่าง ตอนนั้น C เป็นภาษามาตรฐาน แต่เด็กรุ่นใหม่ในปัจจุบันมีแนวโน้มจะเขียนโปรแกรมด้วย Rust มากกว่า C
    • อย่างที่ Craig สรุปไว้ บริบทเรื่องการขึ้นลงและประวัติของคอมมูนิตี้มีประโยชน์มาก
      ผมไม่เคยรู้เลยว่ามีกลุ่มคนที่ได้สิทธิ์ commit ก่อนอายุ 22 ปีอยู่ด้วย

  • เป็นผู้มีส่วนร่วมหน้าใหม่ที่เริ่ม contribute ให้ Postgres ตั้งแต่ 5 เดือนก่อน และจะอายุครบ 27 ปีปลายเดือนนี้
    แม้ยังไม่ได้มี contribution ที่มีคุณค่ามากนัก แต่ก็มี commit อยู่บ้าง และต่อไปอยากทำให้ การ build extension ของ Postgres ด้วย Meson ง่ายขึ้น รวมถึงถ้าเป็นไปได้ก็อยากช่วยเลิกใช้ build แบบ autotools ให้เร็ว
    เร็ว ๆ นี้อาจได้เห็นผมใน repository ของ pgbouncer หรือ pgvector ด้วย
    จุดเริ่มต้นที่ทำให้มา contribute คือผมเหนื่อยล้ากับบริษัทที่ปรึกษาซอฟต์แวร์ที่ทำงานมา 3 ปี
    เดิมทีผมอยากใช้ชีวิตเป็นคนสายซอฟต์แวร์ระบบโอเพนซอร์ส และได้เจองานเกี่ยวกับ storage engine แบบโอเพนซอร์สที่ Micron
    พูดตรง ๆ ว่าโชคดี แต่ประกาศรับสมัครดูเหมือนเขียนมาเพื่อผม จึงสมัครไป และทำงานในโปรเจกต์นั้นอย่างสนุกอยู่ 2.5 ปี
    น่าเสียดายที่ปลายเดือนกุมภาพันธ์ Micron เลิกจ้างทั้งทีม และหลังจากนั้นผมได้รับข้อเสนองานทำ C/C++ driver ที่ MongoDB แต่ข้อเสนอนั้นถูกถอนกลับ
    จากนั้นผมเริ่มพึ่งพาเครือข่ายคนรู้จักมากขึ้น และถามคนที่รู้จักจาก #mesonbuild บน Libera.Chat/Matrix ซึ่งทำงานเกี่ยวกับ Postgres อยู่ ว่ามีตำแหน่งที่เกี่ยวข้องกับ Postgres ที่เหมาะกับพื้นหลังของผมหรือไม่
    เขาบอกว่า Neon กำลังรับคนอยู่ ผมสมัครเข้าทีม storage engine แต่ในการสัมภาษณ์รอบแรก คนที่จะมาเป็นผู้จัดการของผมในภายหลังเห็นว่าผมน่าจะเหมาะกับทีม Postgres ที่เพิ่งตั้งขึ้นใหม่มากกว่า ซึ่งเป็นทีมที่ contribute กลับไปยัง upstream Postgres
    ผมขอบคุณ Neon มากที่ให้โอกาสผม
    หัวข้อของบทความนี้น่าสนใจ เพราะเป็นเรื่องที่เพิ่งโผล่ขึ้นมาตอนคุยกับผู้มีส่วนร่วม Postgres รุ่นใหม่คนอื่น ๆ ที่ PGConf NYC
    แม้แต่ patch เล็ก ๆ ก็ยังยากที่จะมีคนมาดูให้ และยิ่งชื่อเป็นที่รู้จักใน community ก็เหมือนจะยิ่งได้รับ review มากขึ้น กลายเป็นปัญหาวนลูป
    โครงสร้าง mailing list ของ Postgres ก็ไม่ดีนัก เพราะต้องดื่มจากสายฉีดดับเพลิงที่ชื่อ pgsql-hackers เข้าไปตรง ๆ ขณะที่ LKML แบ่งออกเป็น subsystem หลายส่วน
    code forge สมัยใหม่มีคุณค่าตรงที่สามารถ subscribe tag เฉพาะของ PR/issue ได้ แต่ใน pgsql-hackers ตอนนี้ไม่มีวิธีแบบนั้น
    การเพิ่มรายการเข้า commitfest ก็ค่อนข้างยุ่งยาก และถ้าต้องการให้ผ่าน CI ทั้งหมดของ Postgres ก็ต้องใส่เข้า commitfest จากนั้นยังต้องไปตรวจเอง หรือหวังว่า committer จะบอกให้ดูว่า CI fail
    bug report ก็ไปที่ mailing list pgsql-bugs และ Postgres ไม่มีสิ่งเทียบเท่า Linux bugzilla
    patch ถูกส่งเป็นไฟล์แนบอีเมล และไม่จำเป็นต้องเป็นรูปแบบ git-format-patch ด้วย ขณะที่ LKML ดูเหมือนจะใช้ git-send-email แทบจะอย่างเดียว
    โดยรวมแล้วเครื่องมือของ community ผู้มีส่วนร่วม Postgres ดูจะเหมาะที่สุดกับคนที่ฝังตัวอยู่ในนั้นลึก ๆ มานานกว่า 15 ปี
    ไม่ได้อยากทำให้เป็นบทความแนว “มาใช้ GitHub/GitLab กันเถอะ” และกลับคิดว่าอีเมลเหมาะกว่าสำหรับการถกเรื่อง patch แต่เครื่องมือรอบ ๆ mailing list ยังปรับปรุงได้
    ทุกอย่างแยกกันมากเกินไป และผมมองว่า SourceHut ทำได้ดีในการทำให้การพัฒนาที่อิง mailing list เข้าถึงได้ง่ายขึ้นสำหรับ contributor ทั่วไป
    issue, mailing list, CI/CD และ repository ทั้งหมดเชื่อมกัน ไม่ได้แยกเป็นบริการต่างหากเหมือน Postgres ในปัจจุบัน
    comment นี้เองสักวันอาจกลายเป็น blog post แยกต่างหากได้ แต่ขอจบไว้ตรงนี้
    ถ้าเป็นคนที่เพิ่งเริ่ม contribute ให้ Postgres ก็น่าจะมาแลกเปลี่ยนประสบการณ์กันได้ ส่งอีเมลมาได้ที่ tristan neon.tech หรือ tristan partin.io
    ผู้มีส่วนร่วม Postgres อีกคนมองว่าการมี meetup รายเดือนระหว่าง contributor ที่ไม่ใช่ committer เพื่อพูดคุยเรื่อง patch ที่กำลังทำอยู่หรือเผยแพร่แล้ว และรับ peer review กัน อาจมีประโยชน์

    • ไอเดียสุดท้ายนั้นดีมากจริง ๆ และน่าจะได้รับความสนใจ
      Tristan น่าจะเป็นคนขับเคลื่อน online meetup ได้
      Melanie Plageman ก็สนใจไอเดียลักษณะนั้น และเคยคุยกันสั้น ๆ เรื่อง office hours ในรูปแบบต่าง ๆ
    • กระบวนการที่คุณเจอ Neon หรือ Neon เจอคุณนั้นยอดเยี่ยม
      เรื่องนี้น่าจะพัฒนาเป็นบทความที่ดีได้ และดูเหมือนเป็นส่วนที่ community Postgres สามารถปรับปรุงได้ค่อนข้างง่ายในแง่องค์กรและกระบวนการ
    • เห็นด้วยว่าการที่แม้แต่ patch เล็ก ๆ ก็ยังยากที่จะมีคนมาดูให้เป็นปัญหาใหญ่
      แต่เรื่อง “การเป็นที่รู้จักของชื่อ” ยังไม่ค่อยมั่นใจนัก และดูเหมือนว่าปลายอีกด้านหนึ่งก็มีการหลุดหายไปเยอะเช่นกัน
      ปัญหาที่ pgsql-hackers ให้ความรู้สึกเหมือนสายฉีดดับเพลิงนั้นจริง และผมคิดว่ามันแย่ลงมากในช่วงไม่กี่ปีที่ผ่านมา
      สามารถเปิด CI ใน repository ได้แม้ไม่ใส่เข้า commitfest: https://github.com/postgres/postgres/blob/master/src/tools/c...
      นี่คือ CI เดียวกับที่รันสำหรับรายการใน commitfest
      ผมไม่ชอบจริง ๆ ที่ bug report ไปอยู่ใน mailing list และผมก็พลาดมันอยู่เรื่อย ๆ
      ผมมองว่า kernel bugzilla ก็แทบไม่มีประโยชน์เหมือนกัน แต่การทำให้ดีกว่านั้นไม่ได้ยาก
      ผมก็ไม่คิดว่าวิธีจัดการ patch แบบ LKML ดี โดยเฉพาะการที่ patchset ทุก revision สร้าง thread ใหม่ ทำให้ไม่ได้ติดตามง่ายขึ้นมากนัก
      แม้จะมีส่วนร่วมในการพัฒนามาราว 15 ปี ผมก็ไม่กล้าพูดว่าเครื่องมือปัจจุบันทำงานได้ดีเป็นพิเศษ
      กระบวนการพัฒนามีวิวัฒนาการขึ้นบ้างในช่วงที่ผ่านมา แต่ยังไม่ถึงระดับที่จำเป็น
      การเปลี่ยนแปลง community ที่มี “เคราสีเทา” จำนวนมากอย่าง PG ต้องใช้ความพยายามมาก และไม่ใช่ว่าเป็นไปไม่ได้ แต่ก็ไม่ง่าย
      โดยส่วนตัวผมไม่ชอบใช้ GitHub หรือ GitLab กับงานซับซ้อนอย่างมาก แต่ก็คิดว่าควรรับ PR/MR ผ่านหนึ่งในสองอย่างนี้เพื่อให้ contributor หน้าใหม่เข้ามาได้ง่ายขึ้น
      อย่างไรก็ตาม เรื่องนั้นไม่ได้ขึ้นอยู่กับการตัดสินใจของผมคนเดียว
      ผมคิดว่าคงมีคนไม่เกิน 2–3 คนที่คัดค้านแนวคิดว่าอีเมลดีกว่าสำหรับการถกเรื่อง patch แต่ควรปรับปรุงเครื่องมือรอบข้าง
      ปัญหาคือคนจำนวนมากอยากใช้เวลาไปกับการ hack Postgres มากกว่าทำเครื่องมือหรือ integration สำหรับกระบวนการพัฒนา

  • ได้ลองทำงานกับ Postgres อยู่บ้างด้วยความช่วยเหลือของ pgrx และแนะนำได้ว่าเป็น แพลตฟอร์มสำหรับสร้าง data solution
    ช่องของ CMU ก็เป็นแหล่งข้อมูลที่ดี: https://www.youtube.com/@CMUDatabaseGroup

    • น่าเสียดายที่ pgrx แทบไม่มีเอกสารหรือตัวอย่างเกี่ยวกับวิธีใช้สำหรับงานนอกเหนือจาก extension เลย
      เช่น ถ้าอยากเขียน handler สำหรับ Table Access Method ใหม่ แม้ core pg-sys SDK จะมี binding ที่เกี่ยวกับ TableAM แต่ไม่มีเอกสารหรือตัวอย่างว่าจะใช้งานใน Rust อย่างไร

  • ช่วงนี้สังเกตได้ว่าคนส่วนใหญ่ที่เข้ามาในวงการ IT สนใจแต่เงิน และคนที่มีแพสชันก็แทบไม่ค่อยมีแล้ว
    น่าเศร้ามาก และดูเหมือนว่าโปรเจกต์โอเพนซอร์สจำนวนมากกำลังค่อย ๆ ตายไปเพราะเรื่องนี้
    เป็นแนว “คัดลอกจาก Stack Overflow แล้วรับเงินเดือน” โดยไม่มีการมีส่วนร่วมตอบแทนหรือช่วยเหลือใด ๆ
    ไม่ได้หมายความว่าทุกคนเป็นแบบนั้น แต่จากสัดส่วนที่ได้สังเกตใกล้ชิดและพูดคุยระหว่างทำงานในหลายบริษัท อยู่ประมาณ 19:1
    สำหรับข้อมูลเพิ่มเติม ฉันทำงานเสร็จเร็วเกินมาตรฐานมาก จึงมักเสียเวลาไปกับการรอประชุม ทำให้ทุกวันนี้ทำงานให้สองบริษัททุกวัน
    ฉันยังรับงานเสริมหลายอย่างเพื่อทำสิ่งที่น่าสนใจ และหลายครั้งก็ทำฟรีเพื่อได้ลองฮาร์ดแวร์ใหม่ ๆ หรือทดลองอะไรบางอย่าง

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

  • เห็นด้วยว่า Postgres ไม่ได้ลำบากในการดึงดูดผู้ใช้ใหม่
    ฉันเองก็ใช้ Postgres กับ แอปแบบ self-hosting หลายตัวอยู่
    แต่สำหรับแอปพลิเคชัน PHP ก็ยังใช้ MariaDB ต่อไป เพราะเป็นค่าเริ่มต้นหรือเป็นฐานข้อมูลเดียวที่รองรับ

  • สรุปคือ ดูเหมือนว่าเนื้อหาพูดถึงฐานผู้มีส่วนร่วมของ PostgreSQL ที่กำลังมีอายุมากขึ้น ขณะที่ Neon กำลังขยายฐานนักพัฒนาโดย จ้างและฝึกอบรมจูเนียร์ แทนที่จะพึ่งคอมมิตเตอร์เดิม

  • ในฐานะโปรแกรมเมอร์ที่แม้ไม่มีประสบการณ์ C/C++ แต่สนใจ ถ้ามี ซีรีส์วิดีโอ ที่อธิบายโค้ดอย่างละเอียด ก็น่าจะช่วยให้เริ่มมีส่วนร่วมได้จริง ๆ