GitHub: ค้นหาโค้ดไม่ได้หากไม่เข้าสู่ระบบ
(github.com/orgs)- ในการพูดคุยบน GitHub Community มีการตั้งประเด็นว่าตอนนี้แม้แต่ การค้นหาโค้ด ในรีโพสาธารณะก็ใช้งานไม่ได้หากไม่เข้าสู่ระบบ โดยผู้ตั้งคำถามวิจารณ์ว่าเรื่องนี้กระทบต่อการเข้าถึงโค้ดสาธารณะและการใช้งานโอเพนซอร์ส
- ผู้ดูแล GitHub ตอบว่า การค้นหาทุกรีโพแบบครอบคลุมทั้งแพลตฟอร์มนั้นต้องเข้าสู่ระบบมานานแล้ว และเมื่อต้นปี 2023 ที่มีการปรับปรุงความสามารถการค้นหา ก็ได้ขยายข้อกำหนดให้ การค้นหาในรีโพเดี่ยว ต้องเข้าสู่ระบบด้วย
- เหตุผลจากฝั่ง GitHub คือเพื่อรองรับภาระงานของระบบค้นหาสำหรับนักพัฒนา และลดสถานการณ์ที่เซิร์ฟเวอร์ถูกถาโถมด้วย คำขอแบบไม่ระบุตัวตน จากบอตและแหล่งอื่น ๆ
- ผู้ร่วมสนทนาตั้งข้อสงสัยว่า ในเมื่อรีโพสาธารณะยัง clone แล้วค้นหาในเครื่องได้อยู่ การบังคับให้เข้าสู่ระบบเพื่อต้านบอตนั้นเพียงพอจริงหรือไม่ และได้ยกทางเลือกอย่าง rate limit, CAPTCHA หรือการจำกัดการค้นหาแบบง่ายมาเปรียบเทียบ
- ในทางปฏิบัติ ผู้ใช้ที่ไม่ได้เข้าสู่ระบบจะเปิดลิงก์ค้นหาโค้ดสาธารณะโดยตรงไม่ได้ ทำให้มีการพูดถึง วิธีอ้อม อย่าง grep.app, github1s,
grepบนเครื่อง, เสิร์ชเอนจินทั่วไป และการทำมิเรอร์ไปยัง Git forge หลายแห่ง
มีการบังคับให้เข้าสู่ระบบสำหรับการค้นหาโค้ดสาธารณะ
- GitHub Community Discussion #77046 ใช้หัวข้อ “Can no longer search code without being logged in” ว่าด้วยสถานการณ์ที่ ไม่สามารถค้นหาโค้ดได้หากไม่เข้าสู่ระบบ
- ผู้ตั้งคำถามอธิบายว่าตนพยายามค้นหาบางอย่างในรีโพของตัวเองจากอุปกรณ์เก่า แต่ทำต่อไม่ได้เพราะระบบบังคับให้เข้าสู่ระบบ
- เขาต้องเข้าถึงตัวจัดการรหัสผ่าน และต้องใช้ 2FA กับ YubiKey อีกทั้งโน้ตบุ๊กเก่าไม่มีพอร์ต USB-C จึงติดขัด
- เขาระบุว่าต้องการให้ผู้คนสามารถใช้การค้นหาโค้ดในรีโพสาธารณะได้
- ผู้ตั้งคำถามวิจารณ์ว่า หากเป็นรีโพสาธารณะก็ยังสามารถ clone แล้วใช้เครื่องมือเฉพาะทางค้นหาและวิเคราะห์ได้อยู่ จึงยากจะเข้าใจเหตุผลของการบังคับให้เข้าสู่ระบบสำหรับการค้นหาโค้ดบนเว็บ
- การสนทนานี้ถูกทำเครื่องหมายเป็น Answered ด้วยคำตอบจากฝั่ง GitHub และในหน้าดังกล่าวแสดง 19 คอมเมนต์กับ 58 คำตอบย่อย
คำตอบจาก GitHub และเหตุผลอย่างเป็นทางการ
- martinwoodward ผู้ดูแล GitHub กล่าวขออภัยในความไม่สะดวก และตอบว่าการค้นหาแบบครอบคลุมทุกรีโพนั้นต้องเข้าสู่ระบบมานานแล้ว
- เขาอธิบายว่าเมื่อต้นปี 2023 ที่มีการปรับปรุงความสามารถการค้นหา ก็ได้ขยายข้อกำหนดการเข้าสู่ระบบไปยังการค้นหาในรีโพเดี่ยวด้วย
- เขาแนบลิงก์การเปลี่ยนแปลงที่เกี่ยวข้องคือ Code search now requires login
- เขาระบุว่าเป้าหมายหลักคือรองรับภาระของระบบค้นหาสำหรับนักพัฒนา GitHub และป้องกันไม่ให้เซิร์ฟเวอร์ถูกถาโถมด้วย คำขอแบบไม่ระบุตัวตน จากบอตและแหล่งอื่น ๆ
- ระหว่างการสนทนา มีผู้ร่วมสนทนาอีกคนแนบลิงก์ The technology behind GitHub’s new code search ซึ่งอธิบายการทำงานของระบบค้นหาโค้ดแบบใหม่ของ GitHub
แกนหลักของกระแสคัดค้าน: รีโพสาธารณะและการเข้าถึงโอเพนซอร์ส
- ผู้ร่วมสนทนาหลายคนมองว่า ในเมื่อโค้ดในรีโพสาธารณะยัง clone ได้โดยไม่ต้องเข้าสู่ระบบ การปิดกั้น การค้นหาโค้ดสาธารณะ ด้วยการบังคับเข้าสู่ระบบจึงเป็นมาตรการที่เกินไป
- ผู้ร่วมสนทนาคนหนึ่งอธิบายว่ารู้สึกไม่สะดวกที่ผู้ใช้ภายนอกต้องถูกบังคับให้ล็อกอิน GitHub เพียงเพื่อดูซอร์สสาธารณะของตน
- เขายกตัวอย่างว่าเดิมอยากแชร์คำค้นอย่าง
repo:USER/REPO,path:...,AND NOT path:**/_externalsผ่าน URL เดียวหรือปุ่มเดียว - แต่เพราะมีข้อบังคับให้เข้าสู่ระบบ จึงต้องเปลี่ยนไปใช้รายการลิงก์ไฟล์โดยตรงหลายรายการแทน
- เขายกตัวอย่างว่าเดิมอยากแชร์คำค้นอย่าง
- ผู้ร่วมสนทนาคนอื่นชี้ให้เห็นความตึงเครียดระหว่างการที่ GitHub โปรโมตตัวเองเป็น “world's largest open source community” กับการจำกัดการค้นหาโค้ดสาธารณะ
- บางความเห็นแย้งว่าเคยมีข้อจำกัดลักษณะใกล้เคียงกันมาตั้งแต่ก่อน Microsoft เข้าซื้อกิจการ ดังนั้นเรื่องนี้ไม่ใช่ของใหม่ทั้งหมด
ประเด็นถกเถียงเรื่องการกันบอตและต้นทุน
- แม้ฝั่ง GitHub จะให้เหตุผลเรื่องภาระจากคำขอของบอตที่ไม่ระบุตัวตน แต่ผู้ร่วมสนทนาบางคนมองว่าการบังคับให้เข้าสู่ระบบไม่ได้หยุดผู้ให้บริการบอตเฉพาะทางได้ง่ายนัก
- มีข้อเสนอว่าควรใช้ rate limit ก่อน และค่อยบังคับ CAPTCHA หรือการเข้าสู่ระบบเมื่อถึงขีดจำกัด
- ยังมีข้อโต้แย้งด้วยว่า เนื่องจากรีโพสาธารณะสามารถ clone แบบไม่ระบุตัวตนได้ บอตก็อาจหันไปค้นหาในเครื่องแทน
- ต่อข้อโต้แย้งนี้ มีผู้ร่วมสนทนาอีกคนตอบว่าการ clone ไม่ได้ใช้ทรัพยากรคอมพิวต์ของระบบค้นหา GitHub จึงช่วยลดช่องทางการโจมตีแบบปฏิเสธการให้บริการ
- อีกทั้งยังมีการชี้ว่าข้อมูลที่ clone มาแล้วอาจ stale ได้อย่างรวดเร็ว
- ยังมีข้อเสนอเพิ่มเติมว่า หากต้นทุนการค้นหาสูง ควรเปิดให้ผู้ใช้ที่ไม่เข้าสู่ระบบใช้คำค้นแบบง่ายผ่านระบบที่เรียบง่ายกว่า และสงวนคำค้นที่ซับซ้อนให้กับผู้ใช้ที่เข้าสู่ระบบ
ข้อจำกัดของฟังก์ชันค้นหาเองและกรณีเปรียบเทียบ
- ผู้ร่วมสนทนาคนหนึ่งระบุว่า แม้จะอยู่ในสถานะล็อกอิน เมื่อค้นหาทั่วทั้งรีโพสาธารณะด้วย
path:contributing.mdก็ยังเห็นผลลัพธ์เพียง 5 หน้า- ผู้ร่วมสนทนาอีกคนตอบว่านี่ไม่ใช่ปัญหาของคำค้นเฉพาะนี้เท่านั้น แต่เป็นข้อจำกัดของระบบค้นหาในปัจจุบัน โดยอ้างถึง GitHub Community Discussion #9868
- ผู้ร่วมสนทนาอีกคนเปรียบเทียบพฤติกรรมการค้นหาของ SourceForge, Google Code archive, GitLab และ Bitbucket
- ระบุว่า SourceForge และ Google Code archive ไม่มีฟังก์ชันค้นหา
- GitLab ต้องเข้าสู่ระบบสำหรับการค้นหาทั่วทั้งระบบ แต่ค้นหาแยกตามรีโพได้
- ส่วนการค้นหาของ Bitbucket จะรีไดเร็กต์ไปหน้าล็อกอิน แต่หากหารายการรีโพเจอแล้วก็สามารถค้นหาได้โดยไม่ต้องเข้าสู่ระบบ
วิธีอ้อมและบริการทดแทน
- มีการเสนอขั้นตอนใช้
grepหลัง clone ลงเครื่อง เพื่อค้นหาอย่างรวดเร็วในรีโพเดียวขณะไม่ได้เข้าสู่ระบบ- ย้ายไปที่
/dev/shm git clone https://github.com/user/repo- เข้าไปในรีโพแล้วรัน
grep -r "pattern" . - ค้นหาเสร็จแล้วลบรีโพทิ้ง
- ย้ายไปที่
- สำหรับการค้นหารูปแบบข้อความใน GitHub ทั้งหมด มีการกล่าวถึงวิธีใช้เสิร์ชเอนจินทั่วไปด้วย
"pattern" site:github.com- อย่างไรก็ตาม มีข้อจำกัดว่ามันไม่ทรงพลังเท่าระบบค้นหาในตัวของ GitHub และโค้ดบางส่วนอาจไม่ถูกทำดัชนี
- มีการพูดถึง grep.app เป็นเครื่องมือทางเลือกหรือเสริม โดยระบุว่าสามารถค้นหาในรีโพได้โดยไม่ต้องเข้าสู่ระบบ
- ยังมีการแชร์ทริกว่า หากแทน
github.comใน URL ด้วยgithub1s.comก็จะเปิดรีโพในรูปแบบ VS Code ออนไลน์ได้- มีการเปรียบเทียบตัวอย่าง
https://github.com/libretro/px68k-libretro/กับhttps://github1s.com/libretro/px68k-libretro/
- มีการเปรียบเทียบตัวอย่าง
- นอกจากนี้ยังมีการกล่าวถึง Git forge ทางเลือกอย่าง GitLab, Framagit, Gitea, Forgejo, Codeberg และ Gogs โดยบางตัวสามารถเปิดใช้การค้นหาโค้ดได้หากโฮสต์เอง
คำแนะนำเกี่ยวกับแนวทางโฮสต์โปรเจกต์
- ผู้ร่วมสนทนาคนหนึ่งแนะนำว่าไม่ควรมอง GitHub เป็น code forge เพียงแห่งเดียวของโปรเจกต์ แต่ให้มองเป็น หนึ่งในมิเรอร์
- เขาอธิบายว่า Git เป็นระบบควบคุมเวอร์ชันแบบกระจาย ดังนั้นหากใช้ GitHub เพียงแห่งเดียวก็จะกลายเป็นจุดล้มเหลวเพียงจุดเดียว
- เขายกตัวอย่างวิธีเพิ่ม remote หลายตัวเพื่อ push ไปยัง GitHub, Codeberg, Framagit และรีโพส่วนตัวแยกกัน
git remote add github https://github.com/user/repo.gitgit remote add codeberg https://codeberg.org/user/repo.gitgit remote add framagit https://framagit.org/user/repo.gitgit remote add private https://example.com/user/repo.git
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ถ้ามองเรื่องนี้ในแง่ดีที่สุด GitHub Code Search ตัวใหม่พอได้ลองใช้จริงแล้วถือว่ายอดเยี่ยมมาก และอาจเป็นฟีเจอร์ที่กินทรัพยากรสูง เพราะภายในทำงานมากกว่าเสิร์ชเอนจินทั่วไปหลายอย่าง
หากจำกัดให้ใช้ได้เฉพาะบัญชีที่ล็อกอิน ก็จะประหยัดทรัพยากรเซิร์ฟเวอร์ที่เคยต้องใช้รับมือกับครอว์เลอร์ได้มาก จุดแลกเปลี่ยนตรงนี้ดูเหมือนจะอยู่ระหว่างการใช้ต้นทุนโครงสร้างพื้นฐานการค้นหาเพิ่มขึ้น 3–4 เท่าหรือมากกว่า กับการโดนด่าเพราะบังคับให้ล็อกอิน ผมเคยทำเครื่องมือค้นหาโค้ดสำหรับรีโพซิทอรี GitHub เอง แต่ Code Search พื้นฐานของ GitHub มีประโยชน์มากจนแทบไม่ได้ใช้ของตัวเองแล้ว: https://simonwillison.net/2020/Nov/28/datasette-ripgrep/
ในทางกลับกัน ผู้ใช้เดิมก็อาจโกรธที่ค้นหาไม่ได้หากไม่ล็อกอิน ในสถานการณ์อย่างใช้พีซีของคนอื่น พีซีสาธารณะ แท็บไม่ระบุตัวตน หรือเวลาที่เสียไปกับการยืนยันตัวตนสองขั้นตอน เรื่องนี้ค่อนข้างยุ่งยาก GitHub อาจคงการค้นหาพื้นฐานราคาถูกและรวดเร็วไว้ให้ผู้ใช้ที่ไม่ได้ล็อกอินก็ได้ แต่ก็ไม่ได้ทำ
ผลลัพธ์คือ ตอนนี้คุณไม่สามารถมีส่วนร่วมกับ “โอเพนซอร์สที่โฮสต์บน GitHub” ได้ หากไม่สมัคร GitHub
grep เป็นเครื่องมืออายุ 50 ปี และไม่จำเป็นต้องเขียนโค้ดเองเพื่อค้นหาข้อความด้วยซ้ำ ใช้ซอฟต์แวร์เสรีก็พอ นี่ไม่ใช่สตาร์ทอัพสมัครเล่นที่มีแอป CRUD หนึ่งตัวกับนักพัฒนา 3 คน แต่เป็นหนึ่งในบริษัทเทคโนโลยีที่ใหญ่และร่ำรวยที่สุดในโลก การที่ค้นหาข้อความให้ถูกต้องโดยไม่ล็อกอินยังทำไม่ได้เป็นเรื่องน่าสมเพช ถ้ามีคำอธิบายที่สามก็อยากฟัง
คำอธิบายของ GitHub ฟังดูเหมือนพูดไร้สาระเป็นส่วนใหญ่ การบังคับยืนยันตัวตนกับเอนด์พอยต์สาธารณะไม่ใช่วิธีแก้ที่ตรงกับปัญหาที่พวกเขาอ้าง คนทำบ็อตที่สนใจเอนด์พอยต์นี้ก็แค่ให้บ็อตล็อกอินด้วยบัญชีฟรีเท่านั้นเอง จึงไม่ได้ช่วยลดโหลดเซิร์ฟเวอร์อย่างมีนัยสำคัญ
เริ่มมาอย่างน้อย 6 เดือนแล้ว และมีประกาศใน changelog ด้วย: https://github.blog/changelog/2023-06-07-code-search-now-req...
กระทู้ HN: https://news.ycombinator.com/item?id=36230929
จากมุมมองธุรกิจ ผมเข้าใจเต็มที่ว่าทำไมถึงทำแบบนั้น เพราะมันทำให้ผู้คนกลายเป็นผู้ใช้จริง ๆ และเพิ่ม การมีส่วนร่วมของผู้ใช้
ตอนนี้ควรเลิกปฏิบัติกับ GitHub ราวกับเป็น แพลตฟอร์มเปิด ได้แล้ว
GitHub ก็เป็นสวนปิดมีกำแพงล้อมเหมือนบริการอื่น ๆ การที่มันโฮสต์โปรเจกต์โอเพนซอร์สจำนวนมากที่เราใช้ ไม่ได้ทำให้มันดีกว่าเดิม และอาจทำให้แย่ลงด้วยซ้ำ เพราะเราช่วยผลักดันโครงสร้างพื้นฐานสำหรับการมีส่วนร่วมของโปรเจกต์เหล่านี้บางส่วนเข้าไปอยู่หลังแม่กุญแจของบัญชีบริษัท
ผมกลับคิดว่าในบรรดานั้น บัญชี GitHub ยังดีกว่า เพราะสามารถมีส่วนร่วมกับโปรเจกต์จำนวนแทบไม่จำกัดได้โดยไม่ต้องสร้างบัญชีใหม่เรื่อย ๆ หรือไม่ต้องล็อกอินใหม่ ยากที่จะบอกว่า GitHub ได้ปิดกั้นอะไรในทางปฏิบัติแตกต่างจากตัวเลือกอื่นในพื้นที่นี้ GitHub สร้างซอฟต์แวร์ที่ดีและให้ใช้ฟรี รักษาให้ค่อนข้างเปิดและเข้าถึงได้ ทำตามมาตรฐานในจุดที่มีมาตรฐาน ส่วนที่เหลือก็มี API ให้ และให้พื้นที่จัดเก็บกับคอมพิวต์จำนวนมหาศาลฟรีแก่โปรเจกต์โอเพนซอร์สมาโดยตลอด
มีทั้ง Git hosting, โฮสต์วิกิ, issues, GitHub Actions, GitHub Pages และ API ที่ใช้ได้ดี มีเหตุผลมากมายที่ควรนำโปรเจกต์โอเพนซอร์สไปไว้บน GitHub
ในปี 2023 เว็บปิดตัวลงจริง ๆ StackOverflow, Reddit, GitHub, Twitter ต่างก็เริ่มเบรก การ scraping และการเข้าถึง API กันทั้งหมด
จุดชนวนคือการผสมกันระหว่างการกันไม่ให้ AI นำไปฝึก กับแรงกดดันด้านความสามารถในการทำกำไร ยังมีความเป็นจริงเชิงพาณิชย์อย่างภาวะชะลอตัวของวงการเทค เจ้าของใหม่ของ Stack และ X รวมถึงการผลักดัน IPO ของ Reddit ด้วย ในระยะยาวคิดว่าตลาดข้อมูลผูกขาดจะขยายตัวขึ้น เสิร์ชเอนจิน เครื่องมือ AI หรือใครก็ตามที่ต้องการข้อมูลจะต้องจ่ายค่าฟีดข้อมูลต้นทางหรือค่าเข้าถึง API และถ้ามีเพียงบริษัทที่ร่ำรวยที่สุดเท่านั้นที่ซื้อข้อมูลนั้นได้ ก็อาจนำไปสู่ประเด็นต่อต้านการผูกขาด
ถ้าบางสิ่งเป็นข้อมูลผูกขาดจริง ๆ ค่าตอบแทนควรไปถึง เจ้าของ ไม่ใช่ผู้ให้บริการเซิร์ฟเวอร์ Git รายใดรายหนึ่ง ราคาและเงื่อนไขก็ควรถูกกำหนดโดยเจ้าของ ไม่ใช่ผู้ให้บริการเซิร์ฟเวอร์ ถ้าเซิร์ฟเวอร์จำเป็นต้องทำเงิน ก็คิดค่าบริการพื้นฐานไปเลยได้ ในทางกลับกัน ถ้าใครบางคนสร้างบางอย่างขึ้นมาเพื่อจะแบ่งปัน และในเวลานั้นแพลตฟอร์มก็ให้ช่องทางที่มีประสิทธิภาพสำหรับการเผยแพร่แบบนั้น พร้อมทั้งโปรโมตตัวเองว่าเหมาะกับการเผยแพร่ การเปลี่ยนกฎกลางคันก็เป็นการละเมิดผลงานของคนคนนั้นในเชิงศีลธรรม เนื้อหาจำนวนมากบนแพลตฟอร์มเหล่านี้มีความเป็นไปได้สูงว่าเจ้าของตัวจริงคงไม่อัปโหลดตั้งแต่แรก หากคาดว่าจะมีข้อจำกัดตามใจแพลตฟอร์มและมีค่าธรรมเนียมเข้าถึง ถ้าจะเขียนกฎใหม่แบบพลิกโฉม ควรขายคอนเทนต์เดิมได้ก็ต่อเมื่อผู้สร้างต้นฉบับยินยอมอย่างชัดเจนเท่านั้น แต่ Reddit ถึงกับกู้คืนโพสต์ที่ผู้เขียนลบเป็นจำนวนมากอย่างจริงจัง เพื่อกันไม่ให้เกิดการใช้งานในทางนั้น
https://theoatmeal.com/comics/reaching_people
เพียงแต่ rate limit เข้มกว่ามากเท่านั้น การสร้างบัญชี GitHub ฟรีและก็ไม่ได้ล่วงล้ำมากนัก ต่อให้ล็อกอินแล้ว API ทั้งหมดก็มี rate limit อยู่ดีเพื่อไม่ให้ทำเซิร์ฟเวอร์ล่ม ดังนั้นเครื่องมืออย่าง https://gitstar-ranking.com/ จึงลำบากเมื่อพยายาม scrape ดาว GitHub ของทุก repository ด้วยบัญชีฟรี ข้อมูลที่สำคัญจริง ๆ อย่างซอร์สโค้ดสามารถ clone แบบไม่ระบุตัวตนผ่าน HTTPS endpoint ได้ แล้วค่อยค้นหาโค้ดข้างในนั้น เว็บไซต์บุคคลที่สามอย่าง https://grep.app/ ก็ทำได้ด้วยวิธีนี้เช่นกัน ในกรณีของ Reddit/Twitter ข้อมูลต้นทางอย่างโพสต์ คอมเมนต์ การโหวตแนะนำ และทวีต ไม่ได้ถูกให้ผ่าน API อีกต่อไป ทำให้สร้างเครื่องมือบุคคลที่สามได้ยากหรือเป็นไปไม่ได้ แต่ GitHub ต่างออกไปมาก เพราะข้อมูลต้นทางยังเข้าถึงได้ง่าย และมีเพียงชั้นเสริมอย่างการค้นหาที่ถูกปิดสำหรับผู้ใช้ที่ไม่ล็อกอิน
จำได้ว่าตอน StackOverflow เปิดตัว มีการเอาไปเทียบกับ expertsexchange แต่ก็ถูกมองว่า “เปิด” ตอนนี้ถึงเวลาย้ายจากบริการรวมศูนย์ไปสู่โครงสร้างที่กระจายศูนย์มากขึ้นและอิง ไมโครทรานแซกชัน มากขึ้นแล้ว หลายคนใน HN คงไม่ชอบ แต่ฟอรัมถามตอบ การรวบรวมลิงก์ข่าวและคอมเมนต์ โฮสติ้ง Git พร้อม flow การอนุมัติ วิกิ และระบบ ticket สามารถและควรถูกทำในแบบกระจายศูนย์อย่างสมบูรณ์ได้ วิธีอย่างเทคโนโลยี Kademlia/BitTorrent, IPFS, CryptoTokens สำหรับการชำระเงินแบบไมโครทรานแซกชัน ล้วนเป็นไปได้ การไปสู่การกระจายศูนย์ 100% เท่านั้นที่จะทำให้สิ่งเหล่านี้ยังคง “เปิด” อยู่ได้ และปลอดจากความโลภของบริษัท ต่อให้ผู้ก่อตั้งเริ่มต้นด้วยเจตนาดี ในระยะยาวเราก็เห็นซ้ำ ๆ ว่าผลิตภัณฑ์ถูกขายต่อ และฝ่ายบัญชีเข้ามากุมบังเหียน
ถ้ามองในแง่ดี การค้นหาต้องใช้คอมพิวต์ค่อนข้างมาก และจึงอาจเป็น เวกเตอร์โจมตีแบบปฏิเสธการให้บริการ ขนาดใหญ่ได้
ไม่แน่ใจว่า GitHub สามารถเก็บข้อมูลพฤติกรรมจากผู้ใช้ที่ล็อกอินได้มากแค่ไหน และข้อมูลนั้นมีประโยชน์แค่ไหนเมื่อเทียบกับโค้ดที่เปิดเผยอยู่แล้ว อาจใช้ระบุได้ว่าส่วนไหนของโค้ดสำคัญ แต่ก็คงเรียกได้ยากว่าเป็นข้อมูลเฉพาะรายผู้ใช้
ทราฟฟิกเสิร์ชเอนจินของผมมีเพียงประมาณ 0.5% เท่านั้นที่เป็นมนุษย์ ผมไม่ค่อยรู้จักเสิร์ชเอนจินที่ไม่มีสถิติคล้าย ๆ กัน
ผมมองว่านับตั้งแต่วันที่ MS ซื้อกิจการ ก็ไม่มีเหตุผลอันชอบธรรมใดที่โปรเจกต์โอเพนซอร์สจะยังอยู่บนแพลตฟอร์มนั้น ไม่ใช่ว่าไม่มีทางเลือกที่ดี แค่
git cloneครั้งเดียวก็ย้ายได้แล้วดังนั้นจึงมีคำอธิบายได้หลายอย่างว่าทำไมจึงควรล็อก API
ตอนที่ไม่ได้ล็อกอิน ผมใช้ Sourcegraph อยู่ ข้อดีก็คือมันดีกว่าการค้นหาแบบเดิมมาก
ใช้ง่ายแค่เอา URL repository ที่ขึ้นต้นด้วย github.com ไปแปะ เช่น สามารถลองค้นหา
unitใน repository นี้ได้ที่ sourcegraph.com/github.com/rust-lang/rust/ส่วนหนึ่งของ คูเมือง AI ของ Microsoft อยู่ที่การควบคุมความสามารถของคู่แข่งในการใช้ข้อมูลของ GitHub
ต่อไปถ้าเริ่มจำกัด
git cloneด้วยก็คงไม่แปลกใจgit cloneผมคงแปลกใจ เพราะจะมี ระบบ CI จำนวนมากเกินไปที่พังคงต้องบอกลา NPM ส่วนใหญ่ การจัดการแพ็กเกจของ Go สคริปต์ Jenkins และอื่น ๆ
เท่าที่จำได้ GitHub มี rate limit อยู่แล้วเพื่อชะลอการ clone หรือการใช้ API ที่มากเกินไป
แม้จะเห็นด้วยกับมุมมองของคนที่ตั้งคำถาม ก็ไม่แน่ใจว่าจำเป็นต้องพูดแบบนั้นหรือไม่
ผมก็ไม่ได้เห็นด้วยกับจุดยืนนั้นทั้งหมด เพราะการค้นหาไม่ได้มีต้นทุนต่ำเสมอไป และอาจถูกใช้ในการโจมตีแบบ DoS ได้ คำพูดอย่าง “แค่ทำเงินจากทุกครั้งที่ถ่ายยังไม่พอ ตอนนี้จะมาติดตามด้วยหรือว่าฉันกำลังดูบรรทัดโค้ดไหน” มันช่วยอะไรได้ตรงไหนก็ไม่รู้ ควรใจเย็นลงหน่อย ข้อโต้แย้งหลักเองก็ไม่ได้ดีนัก ตัว repository เองไม่ได้ถูกกั้นด้วยการล็อกอิน ดังนั้น repository สาธารณะยังเข้าถึงได้แบบสาธารณะ รวมถึงการ clone ด้วย หากผู้เขียนต้องการให้ repository และโค้ดของตนเป็นประโยชน์ต่อสาธารณะ พอเลยจากการดาวน์โหลดและการค้นหาไปถึงจุดที่สร้าง issue หรือส่ง PR ผู้ร่วมพัฒนาก็ต้องล็อกอินอยู่ดี
จำเป็นเวลาจะทำความเข้าใจว่าบางอย่างทำงานอย่างไร หรือเวลาคุยกันในที่อื่นที่ไม่ใช่ GitHub issue โดยปกติการ clone จะเร็ว แต่ไม่ใช่กับ repository ขนาดใหญ่มาก และบางทีเครื่องที่ใช้อยู่ก็อาจไม่มีพื้นที่พอสำหรับ clone อีกทั้งถ้าคนจำนวนมากเปลี่ยนจากการล็อกอินมาเป็นการ clone ทุกครั้ง โดยเฉพาะเมื่อการล็อกอิน GitHub ยุ่งยากเพราะ การยืนยันตัวตนแบบ 2 ขั้นตอน ก็ยังน่าสงสัยว่าจะช่วยลดภาระของระบบได้จริงหรือไม่ และไม่ใช่ทุกคนที่อยากมีบัญชี GitHub
HackerNews: ตอนนี้เปิดหน้าแรกไม่ได้โดยไม่เห็นคนบ่นว่าไม่มีบริการฟรีและไม่มีโฆษณาสำหรับผู้ใช้ที่ไม่ได้ล็อกอิน
ในกรณีนี้ โค้ดของคุณถูกนำไปใช้ฝึก Copilot และอื่น ๆ อยู่ ต่อให้ไม่ใช่แบบนั้น และบริการนั้นมีเจตนาดีจริงอย่างที่คุณเชื่อ คุณจะปรบมือให้ได้ไหมเมื่อเห็นว่าบริการแย่ลงสำหรับผู้ใช้จำนวนไม่น้อย? นั่นเป็นเรื่องน่าสนใจและน่าตื่นเต้นหรือ?
ตัวอย่างเดียวที่นึกออกคือการเปลี่ยน API ของ Reddit ซึ่งก็นานพอสมควรแล้ว และเกี่ยวข้องกับการล็อกอินแค่หลวม ๆ เท่านั้น
ถ้ายังอยากค้นหาโอเพนซอร์สต่อ https://sourcegraph.com/search ไม่ต้องล็อกอิน และยังรวมโปรเจกต์หลัก ๆ ที่ไม่ได้อยู่บน GitHub ด้วย
ขอแจ้งไว้ก่อนว่าผมเป็น CTO ของ Sourcegraph
เมื่อก่อนเคยหวังว่าการค้นหาของ GitHub จะเทียบกับ
git clone + grepได้ แต่ไม่คิดว่าจะต้องแลกกับกำแพงล็อกอิน เท่าที่จำได้ กำแพงล็อกอินมีเพราะยังเป็นฟีเจอร์เบต้าเท่านั้น และคาดว่าพอการค้นหาหลักใช้งานได้แล้วก็คงเอาออก