Forgejo: 자체 호스팅 경량 소프트웨어 포지
(forgejo.org)- Forgejo는 개발 플랫폼을 직접 운영하려는 팀을 위한 자체 호스팅 경량 소프트웨어 포지로, 설치와 유지보수 부담을 낮추는 데 초점을 둠
- Codeberg e.V. 산하 커뮤니티가 운영하며, 프로젝트와 개발 과정 모두 자유 소프트웨어 기반을 유지함
- GitHub에 익숙한 사용자가 옮겨오기 쉬운 환경을 제공하면서도, 플랫폼 소유권과 협업 생산성을 사용자가 직접 통제하도록 설계됨
- 풍부한 기능을 제공하되 낮은 서버 요구사항을 유지하며, 다른 포지보다 한 자릿수 규모로 적은 리소스를 요구한다고 밝힘
- 보안, 확장성, 연합, 개인정보 보호를 중심에 두고 분산형 협업 개발을 지향함
Forgejo의 위치와 운영 방식
- Forgejo는 자체 호스팅 경량 소프트웨어 포지로, 자체 서버에서 소프트웨어 개발 플랫폼을 운영할 수 있게 함
- 설치와 유지보수가 쉽고 낮은 관리 부담을 목표로 함
- Codeberg나 다른 공개 인스턴스에 계정을 만들 수도 있고, 직접 다운로드해 자체 호스팅할 수도 있음
- 운영 주체는 Codeberg e.V. 산하의 포용적 커뮤니티임
- Codeberg e.V.는 민주적 비영리 조직으로 소개됨
- Forgejo는 독점적으로 자유 소프트웨어로 신뢰할 수 있다고 밝힘
- 제품 초점은 보안, 확장성, 연합, 개인정보 보호에 있음
- 다른 소프트웨어 포지와의 차이는 비교 페이지에서 확인할 수 있음
기능 방향과 참여 영역
- Forgejo는 소프트웨어 개발 프로세스의 통제권을 되찾고, 프로젝트를 자체 호스팅하며, 참여자들이 품질 좋은 소프트웨어 제공에 함께 집중하도록 돕는 것을 목표로 함
-
사용성과 운영 부담
- 간단한 프로젝트 관리를 내세우며, 협업과 생산성을 위한 사용자 경험을 중시함
- GitHub 사용자에게 익숙한 환경을 제공해, 사용자가 소유한 플랫폼으로 옮겨갈 수 있게 함
- 전문 기술 없이도 자체 소프트웨어 포지를 운영할 수 있도록 설치와 유지보수 부담을 줄임
-
자유 소프트웨어와 분산형 협업
- 풍부한 기능을 제공하면서도 낮은 서버 프로파일을 유지함
- Forgejo 자체와 프로젝트 개발 과정 모두 자유 소프트웨어를 사용함
- 분산형 플랫폼을 통해 협업 소프트웨어 개발을 가능하게 하는 방향을 제시함
-
기여할 수 있는 영역
댓글과 토론
Hacker News 의견들
-
FAQ 기준으로 발음은 forˈd͡ʒe.jo이고, 중서부 미국식 귀에는 “4 Jay yo”처럼 들림. Esperanto로 Forge라는 뜻이라고 함
Gitea의 포크지만 비영리로 운영되고, 프리미엄 업셀 없이 전부 자유 라이선스(GPL)라 좋음. 커뮤니티 소통이 Matrix와 Mastodon인 것도 마음에 듦
Codeberg가 이걸 쓰는 듯하고, 겉보기엔 Gitea/GitHub처럼 보이는데 문제없음. 소스 코드는 오른쪽 위 작은 브랜치 아이콘에서 볼 수 있고, Codeberg에 호스팅되어 있음. 오늘 알게 된 건 Codeberg 자체가 Forgejo 인스턴스라는 점
https://forgejo.org/2024-02-forking-forward/
https://v10.next.forgejo.org/explore/repos
https://codeberg.org/forgejo/forgejo- “프리미엄 업셀 없음”이면 Gitea도 그렇지 않나 싶음
이해하기로는 Gitea가 회사 요청이 있으면 맞춤 기능을 만들어주는 회사를 세웠기 때문에 포크가 생긴 것이고, 라이선스 뒤집기 같은 징후가 많았던 건 아님 - Esperanto에서 kafejo가 “커피 장소”, 즉 카페인 것처럼, forgejo도 “forge 장소”에 가까움
- 실제로는 “forge”의 Esperanto 단어가 forgejo라고 생각했는데, 누군가 forgejo가 “fora gejo”, 즉 멀리 있는 게이 사람처럼 해석될 수 있다고 지적했을 때는 이미 늦었다고 함. 그래서 지금은 forge의 Esperanto 단어인 forĝejo에서 영감을 받았다고 설명하는 듯함
- Gitea와 Forgejo가 갈라진 지 좀 됐으니 현재 주요 차이점이 뭔지 궁금했는데, 직접 비교 자료는 찾기 어려웠음
- “프리미엄 업셀 없음”이면 Gitea도 그렇지 않나 싶음
-
Fedora Project가 이쪽으로 옮기는 중이라고 함: https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/
-
Forgejo가 왜 Gitea에서 갈라졌는지 궁금해서 찾아보니, 또다시 돈 없는 자유 오픈소스 창작자/관리자가 위에서, 어쩌면 아래에서도 당하는 사례처럼 보임
Gitea 법인화 발표를 보면 자유 오픈소스만으로는 비용을 감당하지 못했고, MIT 라이선스가 허용하는 부유한 무임승차자들이 있었던 듯함
“수년 동안 유지보수자와 프로젝트를 지원하기 위해 바운티, 직접 후원, 보조금 등 여러 방식을 시도했다. 많은 훌륭한 개인과 몇몇 기업이 매우 관대했지만, 일부 기업은 일부 국가 GDP보다 큰 매출을 올리면서도 Gitea를 핵심 제품에 쓰고 개선 사항을 되돌려주지 않았다”는 대목이 핵심임
Bruce Perens를 좋아하진 않지만 “우리에게는 훌륭한 기업 복지 프로그램이 있고, 사용자는 세계에서 가장 부유한 회사들이다. 반대로 개발자가 그 회사들에서 일하지 않으면 보상을 거의 못 받는다”는 말은 문제를 정확히 찌름
반대로 창립자들이 회사를 만들자 커뮤니티가 반발했는데, 회사 설립 자체보다는 그 회사가 도메인과 상표를 갖고 있어서였다고 함. 보기엔 작은 이유 같지만 세부 사정은 모르겠음
어쨌든 취미 개발자와 FAANG 밖에서는 FOSS가 실패하는 사례 #187처럼 보임- FOSS는 사업 모델이 아님. 예전에도 아니었고 앞으로도 아닐 것임
자유 소프트웨어는 원래 윤리 운동이었고, 수익원을 우선할 필요가 없었음. 목표는 지속 가능한 개발이 아니라 사용자 자유였기 때문임. “사용자가 소프트웨어로 원하는 일을 할 자유가 있어야 한다”는 말 어디에도 “그리고 그 윤리적 목표를 위해 일하는 몇몇 개발자에게 월급을 줄 수 있어야 한다”는 내용은 없음
OSI의 자체 역사에 따르면 어느 시점에 사람들이 개방형 개발 모델이 비즈니스에도 본질적으로 좋다고 생각하기 시작했고, Netscape가 합류했으며, 일부가 모여 자유 소프트웨어를 오픈 소스로 리브랜딩했음
http://web.archive.org/web/20071115150105/https://opensource.org/history/
FOSS라는 단어는 미국식 기업 불교와 비슷하게 느껴짐. 마음챙김과 명상이 원래의 깊은 종교적 맥락에서 떼어져 자기계발 프로그램이 된 것처럼, 원래 실천자들이 알아보기 어려운 형태가 됨. 자유 소프트웨어는 지속 가능한 개발이 아니라, 사용자 자유라는 옳은 일을 하는 것에 관한 것이었고, 나머지는 그 목적을 위한 수단이었음. 그런데 어느 순간 수단이 목적이 되었고, FOSS가 왜 당연히 비용을 대주지 않는지 의아해하게 됨 - 많은 오픈소스 개발자가 아직도 환경이 15~20년 전처럼, 낮에는 좋은 직장을 다니는 취미 개발자들이 명성 때문에 만든 소프트웨어가 중심이라고 오해하고 있음
흐름을 제대로 읽은 곳은 GitLab임. 오픈소스 방식으로 제품을 제공하면서도 운영비를 감당하는 균형점을 찾았고, 신뢰와 수익을 모두 얻었으니 잘한 일임
오픈소스 작업으로 생계를 유지하고 싶다면 사업처럼 운영하고 적절한 사업적 장치를 써야 함. 그렇지 않으면 자기 노력이 언젠가 자기 자신에게 착취처럼 돌아올 수 있음. 악의를 말하는 건 아니지만 공정성은 균형의 문제이고, 열심히 한 일이 자신을 제대로 대우하지 못한다면 그것도 불공정함 - 카피레프트 라이선스는 이런 무임승차를 어느 정도 막으라고 있는 건데, 이제는 “유행”이 아닌 듯함
라이선스에 추가 카피레프트 조건을 넣기는 거부하면서, 결국 기업들이 선의로 그 조건이 있는 것처럼 행동하길 바라는 건 이해하기 어려움
Google 같은 회사는 허용적 라이선스를 좋아하고, toybox처럼 흔한 구성 요소의 MIT/BSD 라이선스 대체재를 후원하기까지 함
Forgejo v9 이상은 실제로 GPL 라이선스인 듯함 - 여기서 그 논리가 정확히 어떻게 적용되는지 모르겠음. 여기서 말하는 “기업 복지”가 뭔가? Gitea로 이익을 내는 곳은 거의 없고, 특히 빅테크는 더더욱 아님
빅테크 괴담은 오픈소스 프로젝트가 라이선스를 뒤집는 걸 정당화할 때 유용하지만, 여기에는 맞지 않음. 보통도 말이 잘 안 되지만, 이 경우엔 유지보수자들 자신도 그런 얘기를 한 적이 없어 보임
MongoDB, ElasticSearch, Redis 같은 프로젝트는 오픈소스였기 때문에 인기를 얻었고, 무료와 경쟁하기 어렵기 때문에 수년간 경쟁도 제한했을 가능성이 큼. 그러다 훗날 사용자에게 등을 돌린 셈임. MongoDB 1.0이 상용 제품이었다면 아무도 안 썼을 테니, 그들이 번 돈도 애초에 오픈소스였기 때문에 생긴 것임 - FOSS는 배포 전략이지 사업 모델이 아님
- FOSS는 사업 모델이 아님. 예전에도 아니었고 앞으로도 아닐 것임
-
Forgejo의 흥미로운 점은 포지 연합(federation) 작업이 진행 중이라는 것임
https://codeberg.org/forgejo/forgejo/issues/59#issuecomment-1652830
이상적인 세계라면 GitHub와 GitLab도 연합을 지원하겠지만, 아마 그렇게 되진 않을 듯함
같은 문제 공간의 대안으로는 P2P 방식인 https://radicle.xyz/ 같은 것이 있음- 요즘 “연합”이 사실상 “ActivityPub 구현”을 뜻하게 된 건 아쉬움. 너무 많은 프로젝트가 자기 데이터 모델을 ActivityPub에 매핑하는 복잡한 작업, 정확한 매핑 논쟁, 표준 확장 제안 작성에 빠져 있음
Forgejo 인스턴스 간의 유용한 연합은 OIDC와 몇 개의 웹훅만으로도 충분히 해결할 수 있음. 예를 들면 인스턴스 간 협업, 포크, 풀 리퀘스트 같은 것임. Forgejo와 Mastodon 사이의 연합이 왜 필요한지 모르겠고, 그게 무슨 의미인지도 애매함 - Forgejo 웹사이트의 연합 페이지(https://forgejo.org/2023-01-10-answering-forgejo-federation-questions/)는 오래됐고 링크 대부분이 작동하지 않음
예전에는 2023년까지 연례 진행 보고서도 냈는데, 그 웹사이트도 더 이상 접근되지 않는 듯함: https://web.archive.org/web/20240830030315/https://forgefriends.org/blog/2023/06/21/2023-06-state-forge-federation/
그래도 월간 업데이트에서 연합이 마지막으로 언급된 건 10월이고, 그때 연합이 Forgejo 프로젝트의 “최우선 과제”였고 앞으로도 그렇다고 강조했음
https://forgejo.org/2024-10-monthly-update/#:~:text=Forgejo%20federation%20is%20and%20will%20always%20be%20the%20highest%20priority%20of%20the%20Forgejo%20project - 수년간 겪어보니 Git 위에 얹은 이런 UI들은 별 의미가 크지 않다는 결론에 가까워짐. Git 자체가 이미 분산형이라 연합을 넘어서는 모델임
Git 저장소를 네트워크에 노출하는 건 HTTP나 SSH로 아주 쉽고, 이메일 기반 코드 리뷰 흐름도 지원함. 다만 git-appraise처럼 리뷰를 저장소 안에 저장하는 방식은 꽤 마음에 듦
https://github.com/google/git-appraise
CI/CD 파이프라인도 푸시로 트리거할 수 있다면 단순하게 통합할 수 있음. 그런데 우리는 Git 위에 중앙화된 UI를 만들어놓고, 이제 그 UI끼리 서로 통합하려고 하고 있음. Git이 이미 탈중앙화되어 있다는 점을 생각하면 거꾸로 가는 것처럼 보임 - GitLab은 ActivityPub을 실험적으로 지원함: https://gitlab.com/gitlab-org/gitlab/-/blob/v17.1.0-ee/doc/development/activitypub/actors/index.md
관련 내용: https://gitlab.com/groups/gitlab-org/-/epics/11247#why - 연합을 정말 기대하고 있음. 내 작업은 내 Forgejo에 호스팅하면서도 다른 인스턴스와 발견 가능성/이슈 추적을 함께 쓸 수 있다면 양쪽 장점을 모두 얻는 셈임
지금은 자체 호스팅 Forgejo, github.com, gitlab.com에 걸쳐 미러링하고 있고, Forgejo 인스턴스는 필수 인프라라기보다는 자체 호스팅 취미의 일부임
GitLab Cells도 같은 방향으로 갈 수 있어 보이고, 설계 문서에 연합 언급이 있음
https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/
- 요즘 “연합”이 사실상 “ActivityPub 구현”을 뜻하게 된 건 아쉬움. 너무 많은 프로젝트가 자기 데이터 모델을 ActivityPub에 매핑하는 복잡한 작업, 정확한 매핑 논쟁, 표준 확장 제안 작성에 빠져 있음
-
몇 년 동안 Gogs에서 Gitea로, 다시 Forgejo로 옮겨왔고, 정말 훌륭한 소프트웨어임
90%는 개인 Git 저장소를 SSH 서버에 올리는 것만으로 충분함. Chezmoi 저장소를 모든 컴퓨터에서 접근 가능한 곳에 두려는 정도라면 Forgejo 계열이 크게 더해주는 건 없음
하지만 10%의 경우, 즉 몇몇 친구와 코드를 비공개로 공유하고 싶을 때는 훌륭함. GitHub 유료 플랜보다 무료가 낫고, 어차피 그 10% 프로젝트 때문에 돌릴 거라면 나머지도 개인 기준 Git 저장소로 쓰는 편이 좋음- 내 프로젝트에는 Onedev를 쓰고 있음: https://github.com/theonedev/onedev
칸반과 코드 편집기도 있음 - 처음 Git 서버를 돌려본 건 회사에서 쓰던 GitLab CE였음. RAM이 부족한 Atom 기반 서버에서 돌렸더니 너무 느려서 페이지 로드가 시간 초과됐음
Gitea로 바꾸니 숨통이 트였고, Fedora가 저장소 서버로 Forgejo를 선택하면서 Forgejo가 눈에 들어옴
내 요구사항은 단순해서 노트와 소스 코드의 중앙 파일 저장소 정도임. Gitea 1.21에서 Forgejo 9로 마이그레이션을 테스트했는데 마찰이 없었음
진지하게 이전을 고려 중이지만, 장기적으로 어느 쪽이 더 잘 지원되고 무료 사용에 적합할지는 아직 고민됨 - 이념 말고 Gitea와 Forgejo의 중요한 차이를 느꼈는지 궁금함. Forgejo는 그 사이 Actions도 추가한 듯함
- 처음엔 Gogs를 설치했지만 GitLab CI와 다른 기능들 때문에 GitLab으로 옮겼음. 다만 비교적 너무 무거웠고 업데이트를 따라가기도 어려워져서 결국 Gitea와 Drone CI로 옮김. Woodpecker CI를 좋아할 사람도 있을 듯함
솔직히 다음 이동지는 CI/CD용 Forgejo Actions(https://forgejo.org/docs/next/user/actions/)를 붙인 Forgejo이거나, 아예 깊은 쪽으로 가서 Jenkins로 돌아가는 선택지가 될 것 같음
- 내 프로젝트에는 Onedev를 쓰고 있음: https://github.com/theonedev/onedev
-
태그라인이 그다지 설명적이지 않음. 메인 페이지를 한두 번 스크롤하고 나서야 목적이 뭔지, 즉 자체 호스팅 GitHub 대안이라는 걸 알 수 있었음
소프트웨어에서 “forge”라는 말은 여러 의미로 해석될 수 있으니 더 앞에서 명확히 말하는 게 좋겠음- “forge”는 SourceForge 때부터, 어쩌면 그 전부터 이런 종류의 호스팅 패키지를 설명하는 데 쓰였음
기술적으로는 Redmine 같은 당시 시스템도 forge라고 부를 수 있었을 텐데, 그 뒤로 용어가 자리 잡은 것 같음 - GitHub를 범주를 정의하는 기준처럼 부르는 건 Forgejo 정신과 어긋난다고 봄. Forgejo는 독자적으로 서 있음
- 이걸 소프트웨어 포지라고 부르는 건 맞는 표현임. 용어가 널리 알려져 있지 않을 뿐임
참고: https://en.wikipedia.org/wiki/Forge_(software) - 명확히 자체 호스팅 GitHub 대안이고, 그렇게 설명하는 게 맞다고 봄. 다른 댓글들처럼 실제로 써보면 더 분명한데, 기본적으로 GitHub 인터페이스와 비슷하고 그래서 좋음. 익숙하고 쓰기 쉬움
- 여기서 “forge”가 무슨 뜻인지 파악하려고 했음
“forge”라고 하면 원재료를 완제품으로 바꾸는 도구가 떠오름. 예를 들면 쇠를 말굽으로 바꾸는 대장간 도구임
소프트웨어 비유라면 텍스트 소스 코드를 실행 가능한 바이너리로 바꾸는 것, 즉 컴파일러나 인터프리터가 더 맞음
GitHub와 SourceForge는 소스 코드를 한 곳에서 다른 곳으로 옮김. 비유를 억지로 늘리면 가게와 배송 서비스의 조합에 가까움. 소스 코드는 이동하지만 변형되지는 않음
그래서 오래된 C/C++ 개발자 입장에서는 forge가 자체 호스팅 Git 서버를 가리키는 용어로 꽤 이상하게 느껴짐
- “forge”는 SourceForge 때부터, 어쩌면 그 전부터 이런 종류의 호스팅 패키지를 설명하는 데 쓰였음
-
GitLab CE를 계속 운영하려다 CPU와 메모리를 많이 먹는 문제로 고생한 뒤 Forgejo로 바꿨고 실망하지 않았음
루트리스 컨테이너로 돌아가며 메모리와 CPU를 거의 쓰지 않음. 업데이트도podman pull한 번이면 그냥 잘 됨
이제 Actions도 돌려서 Jekyll 등을 실행해 정적 웹사이트를 계속 갱신하고 있음
GitHub, GitLab 같은 다른 포지에서 저장소와 이슈 등을 가져올 수 있는 나만의 포지를 갖는 게 좋고, 앞으로 나올 ActivityPub 기반의 더 넓은 Fediverse 통합도 기대됨
탈중앙화되어 있으면서도 연결된 코드 호스팅 접근법이 늘 원하던 것이었고, 이제 거의 도달한 느낌임- 연합 지원 상태가 궁금함. 인스턴스 간 풀 리퀘스트와 버그 리포트가 가능해지면 협업이 아주 쉬워질 것 같음
-
몇 년 동안 GitHub → 자체 호스팅 GitLab → Gitea → Forgejo로 옮겨왔고, 후회하지 않음
Forgejo는 훌륭하고 연합이 완성되면 더 좋아질 것 같음. 여러 인스턴스에 걸친 분산 포크와 풀 리퀘스트가 가능해지면 자체 호스팅 솔루션의 파편화 문제가 해결됨
Gitea가 VC 자금을 등에 업은 영리 지점을 만들었을 때 신뢰를 잃었고, 바로 그 이유로 Forgejo로 포크된 것임
GitLab에서 잃은 유일한 건 기본 제공 CI/CD 플랫폼임. 하지만 파이프라인을 Drone CI로 옮기고 웹훅으로 트리거할 수 있었음. 다만 GitLab 파이프라인이 얼마나 복잡한지에 따라 항상 가능한 선택은 아닐 수 있음
어쨌든 작은 프로젝트 몇 개를 위해 RAM 5GB를 잡아먹는 GitLab 서버를 호스팅하는 건 싫었음. Forgejo는 피크에도 RAM 500MB 정도를 씀 -
코드 리뷰 경험이 어떤지 궁금함. Gitea와 비슷하리라 짐작하지만 둘 다 써보진 않았음
최근 GitHub에서 꽤 진지한 코드 리뷰를 해봤는데, 코드 리뷰 도구로서는 장난감 버전에 가까웠음. 소스 제어 모델 전체를 그 도구에 맞게 설계하지 않는 한, 진지한 엔지니어링 작업에는 쓸 수 없을 것 같았고, 그러면 이력 관리에 영향을 주는 다른 요소들이 희생됨
주로 Gerrit에 익숙한데, 기본 모델은 합리적이지만 거친 부분이 많고 성능 문제도 있음
갑자기 생각해보니 정말 마음에 드는 리뷰 도구를 써본 적이 없는 것 같음. 업계가 제대로 된 도구 없이 그냥 버티고 있는 건 아닌가 싶음
기억으로 GitLab 쪽은 GitHub보다 약간 나았지만 자세히는 기억나지 않음- Phabricator와 GitHub로 원자력 발전소 설계 코드를 설계해봤는데, 꽤 진지한 작업 같음. 리뷰를 쓸 만하게 만드는 데 뭐가 빠졌다고 보는지 더 알고 싶음
- GitHub용 리뷰 도구인 Codelantis를 써봤는지 궁금함
-
“Forgejo가 뭔가?”라는 질문에 “Forgejo는 자체 호스팅 가능한 가벼운 소프트웨어 포지입니다. 설치가 쉽고 유지보수가 적으며, 해야 할 일을 합니다”라고 답하는 식인가 싶음
- GitHub, BitBucket, GitLab 등을 언급하지 않고 그들을 어떻게 설명할 수 있을지 궁금함
- 커뮤니케이션이 정말 산만함. 이름도 영어권에서는 꽤 어색함
물론 모든 걸 영어에 맞출 필요는 없고 Esperanto라고 하지만, 사이트의 다른 부분은 그렇지 않으니 대부분은 그렇게 해석하지 않을 것임