Obsidian ตั้งค่าค่าหัว $5000 สำหรับการพัฒนา Notion API importer และตัวแปลง Databases to Bases
(github.com/obsidianmd)- Obsidian Importer ปัจจุบันแปลง HTML จาก Notion เป็น Markdown ได้ แต่ไม่สามารถกู้คืน Databases ได้
- ตัวนำเข้าใหม่ต้องออกแบบให้ใช้ Notion API เพื่อแปลงฐานข้อมูลเป็นไฟล์ .base (YAML)
- ระหว่างการแปลงต้องรองรับ Obsidian Markdown, ตาราง, เช็กลิสต์, ไฟล์แนบรูปภาพ เป็นต้น
- โครงการนี้มี เงินรางวัล $5,000 และกำหนดเวลาพัฒนา 30 วัน
- จำเป็นต้องวิเคราะห์และกำหนดวิธีการรองรับ บางส่วนและข้อจำกัด ของ database views และ properties
- มีข้อเสนอเงินรางวัลสำหรับการพัฒนา Notion API importer ที่จะแปลงข้อมูล Databases ของ Notion ให้เป็น Bases ของ Obsidian (ไฟล์ .base, ฟอร์แมต YAML) ในปลั๊กอิน Obsidian Importer
- ปลั๊กอิน Importer เดิมรองรับเฉพาะการส่งออก HTML จาก Notion และไม่สามารถกู้คืนข้อมูลฐานข้อมูลได้
- ตัวนำเข้าใหม่มีเป้าหมายเพื่อแก้ข้อจำกัดนี้ด้วยการใช้งาน Notion API โดยตรง
เนื้อหาหลักและข้อกำหนด
- เงินรางวัล (Bounty): เงินรางวัลสำหรับการพัฒนาฟังก์ชันนี้คือ $5,000 และมีกำหนดเวลาพัฒนา 30 วัน
- ขอบเขตการใช้งาน:
- ใช้ Notion API (integration token) และรองรับ data source object ใหม่ของ 2025-09
- รองรับการแปลงโครงสร้างต่าง ๆ ของ Notion เช่น databases, tables, checklists ให้เป็นฟอร์แมต Obsidian Markdown
- รองรับการฝังรูปภาพหรือไฟล์แนบอัตโนมัติ และการบันทึกไฟล์แนบไปยังตำแหน่งที่ผู้ใช้กำหนด
- ลิงก์ใน Markdown, พาธของไฟล์แนบ ฯลฯ ต้องถูกจัดการตามการตั้งค่าของ Obsidian
- กรณีทดสอบ: เพื่อการตรวจสอบที่ชัดเจน จำเป็นต้องมีข้อมูลทดสอบของ Notion ที่ทำซ้ำได้หรือบัญชีทดสอบ
กลยุทธ์การแปลง Databases to Bases
- เนื่องจากโครงสร้าง Database ของ Notion และ Base ของ Obsidian แตกต่างกัน จึงต้องมี การวิเคราะห์โครงสร้างล่วงหน้าและการวางกลยุทธ์
- Notion Database: เริ่มต้นเป็นค่าว่าง แต่ Obsidian Base จะรวมไฟล์ทั้งหมดก่อนแล้วค่อยกรองให้แคบลง
- หัวข้อที่ต้องวิเคราะห์:
- ความสามารถของ database ที่นำเข้าได้: views, columns, groups, summaries, formulas ฯลฯ
- รายการที่นำเข้าไม่ได้และวิธีทดแทน (fallback) ที่เหมาะสม: เช่น calendar view, kanban เป็นต้น
- จำเป็นต้องอธิบายวิธีการนำเข้าและข้อจำกัดของฟังก์ชันให้ชัดเจน
แนวทางการมีส่วนร่วมและการเข้าร่วม
- การสำรวจโค้ดของ Importer และโครงสร้างของ Notion API ล่วงหน้ามีความสำคัญ
- ข้อเสนอต้องรวมวิธีการพัฒนาโดยละเอียดและข้อจำกัดต่าง ๆ (ภายในขอบเขตของปลั๊กอิน Obsidian)
- รายละเอียดเพิ่มเติมเกี่ยวกับการมีส่วนร่วมให้ดูที่ Contribution guideline
เมตาดาตาอื่น ๆ และบันทึกกิจกรรม
- issue นี้ติดป้ายกำกับว่า "bounty" และ "notion"
- มีการเพิ่มเงินรางวัลจากเดิม ($2,000 → $5,000)
4 ความคิดเห็น
นี่เป็นเงินรางวัลหรือเป็นการจ้างงานภายนอกกันแน่... เห็นพาดหัวแล้วถึงกับขยี้ตาสองรอบเลยครับ
ช่วงหลังเห็นว่าที่ civit.ai มีฟีเจอร์ bounty ตอนแรกนึกว่าเป็น bug bounty แต่ปรากฏว่าเขาเปิดโพสต์งานพัฒนาฟีเจอร์พร้อมค่าตอบแทนแบบสาธารณะได้เลยเหมือนกัน เป็นแนวคิดที่แปลกใหม่ดี ถ้ามีเงินแต่ขาดศักยภาพภายในองค์กร แบบนี้ก็ดูอาจใช้ได้เหมือนกัน
เพราะจำนวนเงินเหรอ?
ความเห็นจาก Hacker News
ผมเคยลองตั้งบาวน์ตี้ให้โปรเจ็กต์ของตัวเองแล้วพบว่าค่อนข้างเวิร์กทีเดียว
ถ้าดูจากเธรดนี้ ผมน่าจะจ่ายเป็นบาวน์ตี้ไปราว ๆ 50,000-60,000 ดอลลาร์ (ไม่ใช่ตัวเลขเป๊ะ ๆ เพราะบางส่วนผมแก้เองเลยไม่ได้จ่าย และบางงานใหญ่กว่าที่คาดก็มีการเพิ่มเงินให้)
และก็มีงานเสร็จออกมามากพอ ๆ กับเงินที่จ่ายไป
แน่นอนว่ามีทั้งงานคุณภาพไม่ดี ใช้เวลารีวิวพอสมควร และไม่ใช่ทุกงานที่จะเหมาะกับบาวน์ตี้
แต่ถ้ามีผู้ใช้หรือผู้ร่วมพัฒนาที่สนใจอยู่แล้ว แค่มีเงินสด 500-1000 ดอลลาร์ก็เพียงพอจะเปลี่ยนความอยากรู้อยากลองให้กลายเป็นการลงมือทำได้
ถ้าจ่าย 500-1000 ดอลลาร์แล้วช่วยประหยัดเวลาผมได้หนึ่งสัปดาห์ (รวมถึงต้นทุนจากการสลับบริบท) ผมว่าก็คุ้มแล้ว
มันไม่ใช่เงินระดับเลี้ยงชีพได้แน่นอน และเทียบไม่ได้กับเพื่อนร่วมวงการที่ทำงาน FAANG แล้วได้เงินปีละล้านดอลลาร์
มันเป็นแค่การแสดงความขอบคุณ ซึ่งให้ความรู้สึกต่างจากเงินเดือนโดยสิ้นเชิง
ผมสงสัยว่าวิธีจัดการบาวน์ตี้แบบนี้ถือว่าปกติไหม
คือเปิดรับคนแล้วเลือกมาหนึ่งคนให้ทำ หรือโดยทั่วไปจะระบุ requirement กับบาวน์ตี้ให้ชัด แล้วค่อยเลือกผู้ชนะจากงานที่ส่งเข้ามา
แบบแรกดูเหมือนจะไม่ใช่การขอ spec work มากนัก เลยคิดว่าอาจเป็นเหตุผลที่เลือกวิธีนั้น
ตอนผมเข้าไปดูโปรเจ็กต์คร่าว ๆ มันไม่ได้ดูเป็นเชิงพาณิชย์หรือเป็นส่วนหนึ่งของธุรกิจ
เลยอยากรู้แรงจูงใจว่าทำไมถึงยอมจ่ายเงินตั้งบาวน์ตี้กับงานแบบนี้
ปกติผมเข้าใจว่าบาวน์ตี้ลักษณะนี้มักถูกใช้โดยบริษัทที่ต้องการฟีเจอร์โอเพนซอร์สเพื่อการทำงานร่วมกันหรือการเชื่อมต่อระบบ
หลายปีก่อนผมเคยทำสคริปต์แปลงจาก Notion ไป Obsidian
ตอนนั้นยังไม่มี Bases เลยแปลงฐานข้อมูลออกมาเป็น csv เฉย ๆ
มันเป็นสคริปต์ Python แบบไม่มี dependency ต้อง export โน้ตจาก Notion เป็น markdown zip แล้วค่อยไล่แก้ลิงก์กับชื่อแปลก ๆ ทั้งหมด (ซึ่งน่าเสียดายตรงที่ Notion ไม่ได้ export ทุกลิงก์เป็นลิงก์ markdown)
วันนี้เพิ่งรู้ว่า Obsidian มี API แล้ว
แต่ผมก็ยังคิดว่าการใช้ฟีเจอร์ “ดาวน์โหลดหน้าเป็น markdown” ของ Notion น่าจะง่ายกว่าอยู่ดี
Notion คงไม่ค่อยอยากมี API ที่ช่วยให้ผู้ใช้ย้ายออกจากแพลตฟอร์ม และอาจถึงขั้นพยายามขัดขวางด้วย
แต่การ “ดาวน์โหลดโน้ตเป็น markdown” เป็นบริการสำหรับผู้ใช้ เลยไม่น่าจะถูกถอดออกง่าย ๆ (ดูจากการที่โหมดออฟไลน์เพิ่งมาช้ามากก็พอบอกได้)
ถ้ามีการซิงก์สองทางระหว่าง Notion กับ Obsidian ได้จริงคงยอดเยี่ยมมาก
Notion เด่นเรื่องการทำงานร่วมกันออนไลน์ ส่วน Obsidian เด่นเรื่องการปรับแต่งซอฟต์แวร์ส่วนตัวบนฐานไฟล์ ดังนั้นทั้งคู่ต่างก็มีจุดแข็งของตัวเอง
ไม่จำเป็นว่าทั้งสองเครื่องมือต้องเชื่อมกันได้สมบูรณ์แบบ แต่ถ้าใช้ร่วมกันก็น่าจะเสริมพลังกันได้โดยไม่เหลือจุดอ่อน
สิ่งที่ผมอยากเห็นคือให้การ export markdown ของ Notion มีตัวเลือก YAML frontmatter มาด้วย
ถ้ามีเวลาวันนี้ผมอาจลองทำดู
แต่การซิงก์สองทางแบบสมบูรณ์จริง ๆ ต้องมีโครงสร้างซับซ้อนอย่าง change tracking กับ merge ซึ่งหนักเกินกว่าจะเป็นโปรเจ็กต์ทำเล่นช่วงสุดสัปดาห์
หลายคนมองลบกับการพัฒนาโดยใช้ LLM แต่ผมคิดว่านี่เป็นเคสที่ค่อนข้างเหมาะ
ความต่างระหว่าง Notion API กับ Obsidian มีเยอะ เลยไม่น่าจะทำให้เสร็จได้ในครั้งเดียวแบบง่าย ๆ
แต่ LLM เก่งในการไล่เรียง edge case ต่าง ๆ และเครื่องมืออย่าง Codex หรือ Claude Code ก็มีความสามารถที่เหมาะกับงานแบบนี้
ผมแนะนำอย่างยิ่งให้ทีม Obsidian หรือผู้ดูแลลอง implement ด้วย LLM
จากประสบการณ์ผม ต้นทุนอยู่ราว 100-1000 ดอลลาร์ และบริบทเพิ่มเติมอย่างเทสต์หรือเอกสารก็จะช่วยได้มากเมื่อ API เปลี่ยนในอนาคต
จากประสบการณ์ส่วนตัว ผมเคยเขียนสคริปต์ซิงก์ฐานข้อมูลระหว่าง Obsidian กับ Notion เองเมื่อไม่กี่เดือนก่อน
ตอนแรกก็ได้ AI ช่วยอยู่บ้าง แต่ไม่นานก็พบว่า Notion API รุงรังแค่ไหน และ LLM ติดขัดกับการจัดการ edge case ได้ง่ายเพียงใด
AI เหมาะสำหรับช่วยฝ่าด่านแรกของ API แต่ท้ายที่สุดถ้าอยากได้ผลลัพธ์ที่น่าพอใจ มนุษย์ก็ยังต้องลงมือเก็บงานเอง
LLM ยอดเยี่ยมมากสำหรับการย้ายข้อมูล และดีในการสำรวจ API หลายแบบ
เมื่อเดือนก่อนผมย้ายเว็บไซต์บริษัทกับบล็อกจาก Framer ไป Astro โดยมี LLM ช่วย
ส่วนช่วงสุดสัปดาห์ที่ผ่านมา ผมก็ใช้ LLM สรุปข้อมูลจากแดชบอร์ด Grafana
LLM มีประสิทธิภาพแบบไร้ขีดจำกัดกับงานอย่างการทดสอบสมมติฐาน การรันโค้ดซ้ำ ๆ และการตรวจผลลัพธ์
แต่สิ่งที่ยากเสมอคือการตรวจว่าผลลัพธ์ครบถ้วนจริง ไม่มีส่วนที่แต่งขึ้นหรือใส่ค่าเริ่มต้นมามั่ว ๆ และการรักษาคุณภาพโค้ด
เวลาใช้ Claude Code ผมมักหมดเวลาไปกับการรีแฟกเตอร์เป็นหลัก
รู้สึกว่างานแบบนี้ต้องอาศัยความรู้เรื่อง tooling และ abstraction ที่ค่อนข้างเฉพาะ
มีคนกำลังลองทำอยู่จริง:
https://github.com/obsidianmd/obsidian-importer/pull/424
ผมไม่ค่อยเข้าใจตรรกะการโฆษณา LLM เท่าไร
ถ้าคิดว่าใช้แค่พรอมป์ต์แล้วทำเงินได้ 50,000 ดอลลาร์ ผมก็อยากบอกว่าให้ทำให้ดูเองเลย
มันไม่ต่างจากพวกเทรดหุ้นที่ขายคอร์สพร้อมบอกว่า ‘คุณก็รวยได้’
ทุกคนต่างก็ใช้ LLM กันในระดับหนึ่ง แต่ Hacker News ดูเหมือนเต็มไปด้วย prompt engineer ที่มองโลกในแง่ดีเกินไป
อยากให้แข่งกันที่ผลลัพธ์ และเลิกวนอยู่กับ PoC แล้วทำของจริงออกมาให้เห็น
ผมรู้สึกว่าน่าจะมีคนสร้างเอเจนต์ไว้กวาด GitHub bounty อัตโนมัติ แล้ว push โซลูชันอัตโนมัติกันอยู่แล้ว
เลยกังวลนิดหน่อยว่ามันอาจกลายเป็นแหล่งสแปมขนาดใหญ่สำหรับคนที่ตั้งบาวน์ตี้ด้วยเจตนาดี
คำอธิบาย PR ละเอียดมากและจัดโครงสร้างดี จนตอนแรกผมคาดหวังไว้สูง
แต่การเปลี่ยนแปลงจริงกลับกระจัดกระจายไปทั่ว
ถ้าเป็นคนมีประสบการณ์และเขียนคำอธิบายได้ระดับนี้ ก็น่าจะรู้จักแยก PR ให้เล็กลง แต่นี่ไม่ใช่แบบนั้น
โค้ดดูเหมือนจะใช้ได้อยู่พักหนึ่ง ก่อนจะเจอว่ามันคอมเมนต์โค้ดสร้าง UI component ทิ้งแล้วเหลือแค่ข้อความว่า “ตอนนี้ต้องมี X”
component นี้ห่อการตั้งค่าระดับแอปทั้งหมดไว้ แต่กลับถูกคอมเมนต์ทิ้งเฉย ๆ ทำให้ฟังก์ชันหายไปทั้งก้อน
ถึงอย่างนั้น บางส่วนของ PR ก็ยังพอใช้ได้อยู่ เลยทำให้นักพัฒนาต้องมานั่งต่อยอดและเก็บงานด้วยมือเอง
ที่สำคัญที่สุด ผมอยากให้เกิดวัฒนธรรมที่ยอมรับกันตรง ๆ ว่า “โค้ดส่วนใหญ่ทำโดย AI”
ผมไม่ได้ต่อต้านเครื่องมือพวกนี้ แต่แนวทางการรับมือกับโค้ดแบบนี้ต่างออกไปชัดเจน
งานที่ง่ายสำหรับคนอาจยากสำหรับ AI และในทางกลับกันก็เหมือนกัน
ผมเคยใช้ Notion API สร้างตัวสร้างเอกสาร OpenAPI มาก่อน
จากประสบการณ์นั้น ถ้าใครจะลองชิงบาวน์ตี้นี้ก็ขอส่งความเห็นใจให้
Notion API ทั้งเชื่อมยากและมีข้อจำกัดเยอะ แถมยังห่างจากความสามารถของ UI จริงของ Notion มาก
ผมเองก็เขียนโค้ดกับ Notion API มาเยอะ แต่บาวน์ตี้ 5,000 ดอลลาร์ยังไม่พอหรอก (พูดเล่นครึ่งหนึ่ง)
ถึงอย่างนั้นผมก็อยากเห็นบาวน์ตี้โอเพนซอร์สมากขึ้น
Obsidian ไม่ได้เป็นโอเพนซอร์ส แต่บรรยากาศของชุมชนกลับให้ความรู้สึกต่อต้านบิ๊กเทคมาก
แต่ผมรู้สึกว่าการ exploit ฐานผู้ใช้ในลักษณะนี้เริ่มมีมากขึ้นเรื่อย ๆ
อาจเป็นเพราะผมไม่คุ้นกับโลกของบาวน์ตี้เลยตีความผิดก็ได้ แต่มันดูแปลก ๆ
comma.ai ก็เปิดบาวน์ตี้แบบสาธารณะอยู่เหมือนกัน และดูเหมือนวิธีนี้กำลังกลายเป็นเรื่องปกติมากขึ้น
https://github.com/orgs/commaai/projects/26/views/1
https://tinygrad.org/#worktiny
ผมอยากรู้ว่าวิธีที่ง่ายที่สุดในการแปลง dataview ทั้งหมดใน Obsidian vault ที่มีอยู่ให้เป็น Bases คืออะไร
DataView ทรงพลังกว่า Bases มากในแง่ฟีเจอร์ เพราะงั้นการ “แปลง dataview ทั้งหมด” แทบเป็นไปไม่ได้เลย
มีสคริปต์ Dataview to Bases ที่ชุมชนทำไว้
https://github.com/Quorafind/Bases-Toolbox
พอเห็นเงื่อนไขว่า "กรุณาสมัครเฉพาะกรณีที่ได้สำรวจ codebase ของ Importer และ Notion API ล่วงหน้าแล้ว"
มันทำให้บาวน์ตี้ 5,000 ดอลลาร์ดูไม่น่าดึงดูดเท่าไร
ถ้ามีประสบการณ์กับทั้งสองอย่างอยู่แล้ว มันอาจไม่ได้เป็นเรื่องใหญ่อะไรมากก็ได้
ถ้าใครมีเวลา ก็น่าจะเป็นผู้สมัครที่เหมาะสุด
อยากรู้ว่าทำไมถึงรู้สึกแบบนั้น
ผมมองว่าไม่ได้หมายถึงต้องมีประสบการณ์กว้างขวางอะไรหรอก แค่ต้องการคัดคนสมัครที่ยังไม่รู้ล่วงหน้าว่างานนี้จะยากแค่ไหนออกไปมากกว่า