Forgejo: ฟอร์จซอฟต์แวร์แบบโฮสต์เองที่มีน้ำหนักเบา
(forgejo.org)- Forgejo คือ ฟอร์จซอฟต์แวร์แบบโฮสต์เองที่มีน้ำหนักเบา สำหรับทีมที่ต้องการดูแลแพลตฟอร์มพัฒนาด้วยตนเอง โดยมุ่งลดภาระด้านการติดตั้งและการบำรุงรักษา
- ดำเนินงานโดยชุมชนภายใต้ Codeberg e.V. และทั้งโครงการกับกระบวนการพัฒนาต่างยึดพื้นฐานของ ซอฟต์แวร์เสรี
- ออกแบบมาให้ผู้ใช้ควบคุมความเป็นเจ้าของแพลตฟอร์มและประสิทธิภาพการทำงานร่วมกันได้ด้วยตนเอง พร้อมมอบสภาพแวดล้อมที่ย้ายมาจาก GitHub ได้ง่ายสำหรับผู้ใช้ที่คุ้นเคย
- มอบฟังก์ชันที่ครบถ้วน ขณะเดียวกันยังคง ความต้องการของเซิร์ฟเวอร์ต่ำ และระบุว่าใช้ทรัพยากรน้อยกว่าฟอร์จอื่น ๆ ในระดับเลขหลักเดียว
- ให้ความสำคัญกับความปลอดภัย การขยายระบบ การเชื่อมแบบเฟเดอเรชัน และความเป็นส่วนตัว โดยมุ่งสู่ การพัฒนาร่วมกันแบบกระจายศูนย์
ตำแหน่งของ Forgejo และรูปแบบการดำเนินงาน
- Forgejo เป็น ฟอร์จซอฟต์แวร์แบบโฮสต์เองที่มีน้ำหนักเบา ที่ทำให้สามารถรันแพลตฟอร์มพัฒนาซอฟต์แวร์บนเซิร์ฟเวอร์ของตนเองได้
- มุ่งให้ติดตั้งและดูแลรักษาได้ง่าย พร้อมลดภาระการดูแลระบบ
- สามารถสร้างบัญชีบน Codeberg หรือ อินสแตนซ์สาธารณะอื่น ๆ ได้ หรือจะดาวน์โหลดไปโฮสต์เองก็ได้
- ผู้ดูแลคือชุมชนแบบเปิดกว้างภายใต้ Codeberg e.V.
- Codeberg e.V. ถูกอธิบายว่าเป็นองค์กรไม่แสวงหากำไรแบบประชาธิปไตย
- Forgejo ระบุว่าสามารถเชื่อถือได้เพราะเป็น ซอฟต์แวร์เสรี โดยสมบูรณ์
- จุดเน้นของผลิตภัณฑ์อยู่ที่ ความปลอดภัย การขยายระบบ การเชื่อมแบบเฟเดอเรชัน และความเป็นส่วนตัว
- ความแตกต่างจากฟอร์จซอฟต์แวร์อื่น ๆ ดูได้ที่ หน้าการเปรียบเทียบ
ทิศทางด้านฟังก์ชันและพื้นที่การมีส่วนร่วม
- Forgejo มีเป้าหมายเพื่อทวงคืนการควบคุมกระบวนการพัฒนาซอฟต์แวร์ โฮสต์โครงการด้วยตนเอง และช่วยให้ผู้มีส่วนร่วมมุ่งเน้นร่วมกันไปที่การส่งมอบซอฟต์แวร์คุณภาพสูง
-
การใช้งานและภาระในการดูแลระบบ
- ชูจุดเด่นเรื่อง การจัดการโครงการที่เรียบง่าย และให้ความสำคัญกับประสบการณ์ผู้ใช้เพื่อการทำงานร่วมกันและประสิทธิภาพการทำงาน
- มอบสภาพแวดล้อมที่คุ้นเคยสำหรับผู้ใช้ GitHub เพื่อให้ย้ายไปยังแพลตฟอร์มที่ผู้ใช้เป็นเจ้าของได้
- ลดภาระด้านการติดตั้งและการบำรุงรักษา เพื่อให้สามารถรันซอฟต์แวร์ฟอร์จของตนเองได้แม้ไม่มีทักษะเฉพาะทาง
-
ซอฟต์แวร์เสรีและการทำงานร่วมกันแบบกระจายศูนย์
- คงไว้ซึ่งโปรไฟล์การใช้เซิร์ฟเวอร์ที่ต่ำ แม้จะมีฟังก์ชันหลากหลาย
- ทั้งตัว Forgejo เองและกระบวนการพัฒนาโครงการต่างใช้ ซอฟต์แวร์เสรี
- เสนอแนวทางที่ทำให้การพัฒนาซอฟต์แวร์แบบร่วมมือกันเป็นไปได้ผ่านแพลตฟอร์มแบบกระจายศูนย์
-
พื้นที่ที่สามารถมีส่วนร่วมได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตาม FAQ ออกเสียงว่า forˈd͡ʒe.jo และสำหรับหูแบบคนมิดเวสต์ของสหรัฐฯ จะฟังคล้าย “4 Jay yo” ว่ากันว่าในภาษา Esperanto แปลว่า Forge
ถึงจะเป็น fork ของ Gitea แต่ดำเนินงานแบบไม่แสวงหากำไร และดีตรงที่เป็นไลเซนส์เสรีทั้งหมด(GPL) ไม่มีการ upsell แบบพรีเมียม ชอบด้วยที่การสื่อสารกับชุมชนใช้ Matrix และ Mastodon
ดูเหมือน Codeberg จะใช้สิ่งนี้ และมองเผิน ๆ ก็คล้าย Gitea/GitHub ซึ่งไม่มีปัญหาอะไร ซอร์สโค้ดดูได้จากไอคอน branch เล็ก ๆ มุมขวาบน และโฮสต์อยู่บน Codeberg สิ่งที่เพิ่งรู้วันนี้คือ Codeberg เองก็เป็นอินสแตนซ์ของ Forgejo
https://forgejo.org/2024-02-forking-forward/
https://v10.next.forgejo.org/explore/repos
https://codeberg.org/forgejo/forgejo
เท่าที่เข้าใจ การ fork เกิดขึ้นเพราะ Gitea ตั้งบริษัทที่ทำ ฟีเจอร์ตามสั่ง ให้เมื่อมีคำขอจากบริษัทต่าง ๆ และไม่ได้มีสัญญาณมากมายว่าจะกลับลำเรื่องไลเซนส์
ว่ากันว่า Fedora Project กำลังย้ายมาทางนี้: https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/
ผมสงสัยว่าทำไม Forgejo ถึงแยกออกมาจาก Gitea เลยลองค้นดู แล้วก็ดูเหมือนจะเป็นอีกกรณีหนึ่งที่ผู้สร้าง/ผู้ดูแลโอเพนซอร์สเสรีที่ไม่มีเงินถูกเล่นงานจากข้างบน และอาจจากข้างล่างด้วย
ถ้าดูประกาศการจัดตั้งนิติบุคคลของ Gitea จะเห็นว่าแค่โอเพนซอร์สเสรีอย่างเดียวไม่พอจะแบกรับค่าใช้จ่าย และดูเหมือนว่ามีผู้ใช้ฟรีไรเดอร์ฐานะดีที่ไลเซนส์ MIT อนุญาตให้อยู่ด้วย
ประเด็นสำคัญคือข้อความที่ว่า “ตลอดหลายปีที่ผ่านมา เราได้ลองหลายวิธีเพื่อสนับสนุนผู้ดูแลและโครงการ เช่น เงินรางวัล การสนับสนุนโดยตรง และเงินทุนอุดหนุน มีบุคคลที่ยอดเยี่ยมจำนวนมากและบริษัทบางแห่งที่ใจกว้างมาก แต่บางบริษัทมีรายได้มากกว่า GDP ของบางประเทศเสียอีก แต่กลับใช้ Gitea ในผลิตภัณฑ์หลักของตนโดยไม่ส่งการปรับปรุงกลับคืนมา”
ผมไม่ได้ชอบ Bruce Perens นัก แต่คำพูดที่ว่า “เรามี โครงการสวัสดิการองค์กร ที่ยอดเยี่ยม และผู้ใช้คือบริษัทที่ร่ำรวยที่สุดในโลก ในทางกลับกัน ถ้านักพัฒนาไม่ได้ทำงานให้บริษัทเหล่านั้น ก็แทบไม่ได้รับค่าตอบแทนเลย” นั้นจี้ปัญหาได้ตรงจุด
ในทางกลับกัน เมื่อผู้ก่อตั้งตั้งบริษัทขึ้นมา ชุมชนก็ต่อต้าน แต่ดูเหมือนว่าไม่ได้เป็นเพราะการตั้งบริษัทเองเท่าไร แต่เป็นเพราะบริษัทนั้นถือครองโดเมนและเครื่องหมายการค้าอยู่ ฟังดูเหมือนเหตุผลเล็กน้อย แต่ผมก็ไม่รู้รายละเอียดเบื้องลึก
อย่างไรก็ตาม ดูเหมือนเป็น กรณีที่ FOSS ล้มเหลว #187 นอกเหนือจากนักพัฒนางานอดิเรกและคนที่อยู่ใน FAANG
ซอฟต์แวร์เสรีเดิมทีเป็นขบวนการเชิงจริยธรรม และไม่จำเป็นต้องให้แหล่งรายได้มาก่อน เพราะเป้าหมายไม่ใช่การพัฒนาที่ยั่งยืน แต่คือเสรีภาพของผู้ใช้ ในคำกล่าวที่ว่า “ผู้ใช้ควรมีเสรีภาพที่จะทำสิ่งที่ต้องการกับซอฟต์แวร์” ไม่มีตรงไหนที่บอกว่า “และต้องสามารถจ่ายเงินเดือนให้นักพัฒนาบางคนที่ทำงานเพื่อเป้าหมายทางจริยธรรมนั้นได้”
ตามประวัติของ OSI เอง มีช่วงหนึ่งที่ผู้คนเริ่มคิดว่าโมเดลการพัฒนาแบบเปิดนั้นดีต่อธุรกิจโดยเนื้อแท้ Netscape เข้ามาร่วม และคนบางกลุ่มรวมตัวกันรีแบรนด์ซอฟต์แวร์เสรีเป็น โอเพนซอร์ส
http://web.archive.org/web/20071115150105/https://opensource.org/history/
คำว่า FOSS ให้ความรู้สึกคล้ายพุทธแบบองค์กรอเมริกัน เหมือนกับที่ mindfulness และการทำสมาธิถูกแยกออกจากบริบททางศาสนาอันลึกซึ้งเดิม แล้วกลายเป็นโปรแกรมพัฒนาตนเอง จนอยู่ในรูปที่ผู้ปฏิบัติเดิมแทบจำไม่ได้ ซอฟต์แวร์เสรีไม่ใช่เรื่องการพัฒนาที่ยั่งยืน แต่เป็นเรื่องการทำสิ่งที่ถูกต้อง คือเสรีภาพของผู้ใช้ ส่วนที่เหลือเป็นเพียงเครื่องมือเพื่อเป้าหมายนั้น แต่เมื่อถึงจุดหนึ่ง เครื่องมือกลับกลายเป็นเป้าหมาย แล้วเราก็เริ่มสงสัยว่าทำไม FOSS ถึงไม่จ่ายค่าใช้จ่ายให้เป็นเรื่องปกติ
ที่อ่านกระแสได้ถูกต้องคือ GitLab พวกเขาหาจุดสมดุลได้ระหว่างการนำเสนอผลิตภัณฑ์ในแบบโอเพนซอร์สกับการแบกรับค่าใช้จ่ายในการดำเนินงาน และได้รับทั้งความเชื่อมั่นและรายได้ จึงถือว่าทำได้ดี
หากต้องการเลี้ยงชีพจากงานโอเพนซอร์ส ก็ต้องดำเนินการเหมือนธุรกิจและใช้กลไกทางธุรกิจที่เหมาะสม ไม่เช่นนั้นความพยายามของตัวเองอาจย้อนกลับมาเหมือนการเอาเปรียบตนเองในสักวันหนึ่ง ผมไม่ได้พูดถึงเจตนาร้าย แต่ความเป็นธรรมเป็นเรื่องของสมดุล และถ้างานที่ทุ่มเททำไม่ปฏิบัติต่อตัวคุณอย่างเหมาะสม นั่นก็ไม่เป็นธรรมเช่นกัน
การปฏิเสธที่จะใส่เงื่อนไข copyleft เพิ่มเติมในไลเซนส์ แต่ท้ายที่สุดกลับหวังว่าบริษัทต่าง ๆ จะทำตัวโดยสุจริตราวกับมีเงื่อนไขนั้นอยู่ เป็นเรื่องที่เข้าใจยาก
บริษัทอย่าง Google ชอบไลเซนส์แบบ permissive และถึงกับสนับสนุนเงินให้สิ่งทดแทนที่ใช้ไลเซนส์ MIT/BSD ของคอมโพเนนต์ทั่วไป เช่น toybox
Forgejo ตั้งแต่ v9 ขึ้นไปดูเหมือนจะใช้ไลเซนส์ GPL จริง ๆ
เรื่องเล่าหลอกผีเกี่ยวกับบิ๊กเทคนั้นมีประโยชน์เวลาอยากอ้างความชอบธรรมให้โครงการโอเพนซอร์สพลิกไลเซนส์ แต่กรณีนี้ไม่เข้ากัน ปกติก็ไม่ค่อยสมเหตุสมผลอยู่แล้ว แต่ในกรณีนี้ ดูเหมือนแม้แต่ผู้ดูแลเองก็ไม่เคยพูดแบบนั้น
โปรเจกต์อย่าง MongoDB, ElasticSearch, Redis ได้รับความนิยมเพราะเป็นโอเพนซอร์ส และเพราะแข่งขันกับของฟรีได้ยาก จึงอาจจำกัดการแข่งขันไว้ได้เป็นเวลาหลายปี แล้วภายหลังก็เหมือนหันหลังให้ผู้ใช้ ถ้า MongoDB 1.0 เป็นผลิตภัณฑ์เชิงพาณิชย์ ก็คงไม่มีใครใช้ ดังนั้นเงินที่พวกเขาหามาได้ก็เกิดขึ้นตั้งแต่แรกเพราะมันเป็นโอเพนซอร์สนั่นเอง
จุดที่น่าสนใจของ Forgejo คือกำลังมีงานเกี่ยวกับ federation ของ forge อยู่
https://codeberg.org/forgejo/forgejo/issues/59#issuecomment-1652830
ในโลกอุดมคติ GitHub และ GitLab ก็คงรองรับ federation ด้วย แต่ดูท่าคงไม่น่าเป็นไปได้
ทางเลือกอื่นในพื้นที่ปัญหาเดียวกันก็มีแบบ P2P อย่าง https://radicle.xyz/
federation ที่มีประโยชน์ระหว่างอินสแตนซ์ Forgejo สามารถแก้ได้เพียงพอด้วย OIDC กับ webhook ไม่กี่ตัว เช่น การทำงานร่วมกันข้ามอินสแตนซ์, fork, pull request เป็นต้น ผมไม่เข้าใจว่าทำไมต้องมี federation ระหว่าง Forgejo กับ Mastodon และก็ไม่ชัดด้วยว่ามันหมายความว่าอะไร
เมื่อก่อนเคยมีรายงานความคืบหน้าประจำปีจนถึงปี 2023 แต่ดูเหมือนเว็บไซต์นั้นก็เข้าไม่ได้แล้วเช่นกัน: https://web.archive.org/web/20240830030315/https://forgefriends.org/blog/2023/06/21/2023-06-state-forge-federation/
ถึงอย่างนั้น federation ถูกกล่าวถึงครั้งล่าสุดในอัปเดตรายเดือนเดือนตุลาคม และตอนนั้นย้ำว่า federation เป็น “ลำดับความสำคัญสูงสุด” ของโปรเจกต์ Forgejo และจะเป็นเช่นนั้นต่อไป
https://forgejo.org/2024-10-monthly-update/#:~:text=Forgejo%20federation%20is%20and%20will%20always%20be%20the%20highest%20priority%20of%20the%20Forgejo%20project
การเปิด Git repository ให้ใช้งานผ่านเครือข่ายทำได้ง่ายมากผ่าน HTTP หรือ SSH และยังรองรับ workflow การรีวิวโค้ดผ่านอีเมลด้วย อย่างไรก็ตาม ผมค่อนข้างชอบวิธีแบบ git-appraise ที่เก็บรีวิวไว้ใน repository
https://github.com/google/git-appraise
CI/CD pipeline ก็ผสานรวมได้อย่างเรียบง่ายถ้าสามารถ trigger ด้วยการ push ได้ แต่เรากลับสร้าง UI แบบรวมศูนย์ไว้บน Git แล้วตอนนี้พยายามให้ UI เหล่านั้นผสานรวมกันเอง เมื่อคิดว่า Git นั้นกระจายศูนย์อยู่แล้ว มันจึงดูเหมือนเดินย้อนทาง
เนื้อหาที่เกี่ยวข้อง: https://gitlab.com/groups/gitlab-org/-/epics/11247#why
ตอนนี้ผม mirror ข้าม Forgejo ที่โฮสต์เอง, github.com และ gitlab.com อยู่ และอินสแตนซ์ Forgejo เป็นส่วนหนึ่งของงานอดิเรก self-hosting มากกว่าจะเป็น infrastructure ที่จำเป็น
GitLab Cells ก็ดูเหมือนจะไปในทิศทางเดียวกันได้ และมีการพูดถึง federation ในเอกสารออกแบบ
https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/
ผมย้ายจาก Gogs ไป Gitea แล้วก็มา Forgejo ตลอดหลายปีที่ผ่านมา และมันเป็นซอฟต์แวร์ที่ยอดเยี่ยมจริง ๆ
90% ของกรณี แค่เอารีโพซิทอรี Git ส่วนตัวไปไว้บนเซิร์ฟเวอร์ SSH ก็เพียงพอแล้ว ถ้าแค่ต้องการวางรีโพซิทอรี Chezmoi ไว้ในที่ที่เข้าถึงได้จากคอมพิวเตอร์ทุกเครื่อง ตระกูล Forgejo ก็ไม่ได้เพิ่มอะไรให้มากนัก
แต่ในอีก 10% ของกรณี คือเวลาที่อยากแชร์โค้ดแบบส่วนตัวกับเพื่อนบางคน มันยอดเยี่ยมมาก ฟรีดีกว่าแพ็กเกจเสียเงินของ GitHub และถ้าจะรันมันอยู่แล้วเพื่อโปรเจกต์ 10% นั้น ก็ใช้ที่เหลือเป็น รีโพซิทอรี Git อ้างอิงส่วนตัว ไปด้วยจะดีกว่า
มีทั้งคัมบังและตัวแก้ไขโค้ดด้วย
พอเปลี่ยนเป็น Gitea ก็เหมือนได้หายใจโล่งขึ้น และพอ Fedora เลือก Forgejo เป็นเซิร์ฟเวอร์รีโพซิทอรี Forgejo ก็มาอยู่ในสายตาผม
ความต้องการของผมเรียบง่าย แค่เป็นที่เก็บไฟล์กลางสำหรับโน้ตและซอร์สโค้ด ผมทดสอบไมเกรตจาก Gitea 1.21 ไป Forgejo 9 แล้วไม่มีสะดุด
กำลังพิจารณาจะย้ายจริงจัง แต่ยังลังเลว่าในระยะยาวฝั่งไหนจะได้รับการสนับสนุนดีกว่าและเหมาะกับการใช้ฟรีมากกว่า
พูดตามตรง จุดหมายถัดไปของผมน่าจะเป็น Forgejo ที่ต่อ Forgejo Actions(https://forgejo.org/docs/next/user/actions/) สำหรับ CI/CD หรือไม่ก็ไปทางสายลึกเลยแล้วกลับไปใช้ Jenkins
แท็กไลน์ไม่ได้อธิบายอะไรมากนัก ต้องเลื่อนหน้าแรกหนึ่งหรือสองครั้งถึงจะเข้าใจว่าจุดประสงค์คืออะไร นั่นคือ ทางเลือกแทน GitHub แบบโฮสต์เอง
ในวงการซอฟต์แวร์ คำว่า “forge” ตีความได้หลายความหมาย น่าจะพูดให้ชัดตั้งแต่ช่วงต้นกว่านี้
ในเชิงเทคนิค ระบบยุคนั้นอย่าง Redmine ก็น่าจะเรียกว่า forge ได้เหมือนกัน แต่หลังจากนั้นคำนี้คงเริ่มลงหลักปักฐาน
อ้างอิง: https://en.wikipedia.org/wiki/Forge_(software)
พอพูดว่า “forge” ก็จะนึกถึงเครื่องมือที่เปลี่ยนวัตถุดิบให้เป็นสินค้าสำเร็จรูป เช่น เครื่องมือในโรงตีเหล็กที่เปลี่ยนเหล็กให้เป็นเกือกม้า
ถ้าเป็นอุปมาในซอฟต์แวร์ สิ่งที่เหมาะกว่าน่าจะเป็นการเปลี่ยนซอร์สโค้ดที่เป็นข้อความให้เป็นไบนารีที่รันได้ หรือก็คือคอมไพเลอร์หรืออินเทอร์พรีเตอร์
GitHub กับ SourceForge ย้ายซอร์สโค้ดจากที่หนึ่งไปอีกที่หนึ่ง ถ้าจะฝืนขยายอุปมา ก็น่าจะใกล้เคียงกับการผสมกันระหว่างร้านค้าและบริการจัดส่ง ซอร์สโค้ดเคลื่อนย้าย แต่ไม่ได้ถูกแปลงสภาพ
ดังนั้นจากมุมมองของนักพัฒนา C/C++ รุ่นเก่า forge จึงรู้สึกเป็นคำที่ค่อนข้างแปลกสำหรับการหมายถึง เซิร์ฟเวอร์ Git แบบโฮสต์เอง
หลังจากพยายามรัน GitLab CE ต่อไปอยู่พักหนึ่งแล้วเจอปัญหากิน CPU และหน่วยความจำมาก ผมเปลี่ยนมา Forgejo และไม่ผิดหวัง
มันรันเป็น คอนเทนเนอร์แบบ rootless และแทบไม่ใช้หน่วยความจำกับ CPU เลย การอัปเดตก็แค่
podman pullครั้งเดียวก็เรียบร้อยตอนนี้รัน Actions ด้วย เพื่อเรียก Jekyll และอย่างอื่นให้คอยอัปเดตเว็บไซต์สแตติกอยู่เรื่อย ๆ
การมีฟอร์จของตัวเองที่สามารถนำเข้ารีโพซิทอรี อิชชู และอื่น ๆ จากฟอร์จอื่นอย่าง GitHub, GitLab ได้เป็นเรื่องดี และก็ตั้งตารอการผสานกับ Fediverse ที่กว้างขึ้นบนฐาน ActivityPub ในอนาคต
แนวทางโฮสต์โค้ดที่กระจายศูนย์แต่ยังเชื่อมต่อกันได้คือสิ่งที่ผมอยากได้มาตลอด และตอนนี้รู้สึกว่าเกือบไปถึงแล้ว
ตลอดหลายปีที่ผ่านมา ผมย้ายจาก GitHub → GitLab โฮสต์เอง → Gitea → Forgejo และไม่เสียใจเลย
Forgejo ยอดเยี่ยม และน่าจะดียิ่งขึ้นเมื่อ federation เสร็จสมบูรณ์ ถ้าทำ fork และ pull request แบบกระจายข้ามหลายอินสแตนซ์ ได้ ปัญหาความแตกกระจายของโซลูชันแบบโฮสต์เองก็จะถูกแก้
Gitea เสียความน่าเชื่อถือไปตอนที่ตั้งแขนงเชิงพาณิชย์ที่มีเงิน VC หนุนหลัง และนั่นแหละคือเหตุผลที่ Forgejo ถูก fork ออกมา
สิ่งเดียวที่เสียไปจาก GitLab คือแพลตฟอร์ม CI/CD ที่มีมาให้ในตัว แต่ผมย้าย pipeline ไป Drone CI และ trigger ผ่าน webhook ได้ อย่างไรก็ตามนี่อาจไม่ใช่ทางเลือกที่ทำได้เสมอไป ขึ้นอยู่กับว่า pipeline ของ GitLab ซับซ้อนแค่ไหน
ยังไงก็ตาม ผมไม่อยากโฮสต์เซิร์ฟเวอร์ GitLab ที่กิน RAM 5GB เพื่อโปรเจกต์เล็ก ๆ ไม่กี่ตัว Forgejo ใช้ RAM ราว 500MB แม้ตอนพีค
อยากรู้ว่า ประสบการณ์การรีวิวโค้ด เป็นอย่างไร เดาว่าคงคล้ายกับ Gitea แต่ก็ยังไม่เคยใช้ทั้งคู่
ช่วงนี้ได้ลองทำ code review บน GitHub แบบค่อนข้างจริงจังดูแล้ว ในฐานะเครื่องมือรีวิวโค้ด มันใกล้เคียงกับเวอร์ชันของเล่นมากกว่า ถ้าไม่ได้ออกแบบโมเดลการควบคุมซอร์สทั้งหมดให้เข้ากับเครื่องมือนั้น ก็ดูเหมือนจะใช้กับงานวิศวกรรมจริงจังไม่ได้ และถ้าทำแบบนั้น ปัจจัยอื่น ๆ ที่มีผลต่อการจัดการประวัติก็จะต้องถูกเสียสละไป
ส่วนใหญ่คุ้นกับ Gerrit ซึ่งโมเดลพื้นฐานก็สมเหตุสมผล แต่มีส่วนที่หยาบอยู่มากและยังมีปัญหาด้านประสิทธิภาพด้วย
นึกขึ้นมาได้ว่าเหมือนจะไม่เคยใช้เครื่องมือรีวิวที่ถูกใจจริง ๆ เลย สงสัยว่าในอุตสาหกรรมนี้เราแค่ทนใช้กันไปโดยไม่มีเครื่องมือที่ดีจริง ๆ อยู่หรือเปล่า
เท่าที่จำได้ ฝั่ง GitLab ดีกว่า GitHub เล็กน้อย แต่จำรายละเอียดไม่ได้
ถ้ามีคนถามว่า “Forgejo คืออะไร?” ก็คงตอบประมาณว่า “Forgejo เป็น software forge น้ำหนักเบาที่โฮสต์เองได้ ติดตั้งง่าย ดูแลรักษาน้อย และทำสิ่งที่ควรทำได้” หรือเปล่า
แน่นอนว่าไม่จำเป็นต้องปรับทุกอย่างให้เข้ากับภาษาอังกฤษ และว่ากันว่าเป็น Esperanto แต่ส่วนอื่น ๆ ของเว็บไซต์ไม่ได้เป็นแบบนั้น คนส่วนใหญ่จึงคงไม่ตีความอย่างนั้น