GitHub가 준 가장 큰 변화 중 하나는 프로젝트 중심이 아니라 사람 중심 구조였다고 봄
내 이름에 바로 저장소를 붙여서 빠르게 만들 수 있다는 점이, SourceForge에서 프로젝트 이름 정하고 예약해서 CVS나 SVN 저장소와 웹사이트, 메일링 리스트, 이슈 트래커까지 갖추던 무거운 절차보다 훨씬 해방감 있었음
"이건 그냥 잠깐 만드는 것"이라는 정신적 부담을 크게 줄여줬음
GitHub가 이슈 트래커, PR, 릴리스 페이지, 위키, 조직 페이지, API, 웹훅, CI를 한꺼번에 준 건 아니기도 했음
예전엔 조직 기능이 없어서 새 사용자 계정을 만들어 조직 흉내를 내기도 했고, "GitHub가 몇 달 안에 내놓겠지" 하며 별도 버그 트래커 도입을 미루다가 결국 저장소에 텍스트 파일로 관리한 적도 있었음
보통 프로젝트에서 Git이 Fossil보다 이긴 게 아직도 아쉬움
Linux 커널 같은 초대형 코드베이스에서는 Git의 성능 이점이 있겠지만, 대다수 프로젝트는 VCS 성능 한계에 닿을 일이 거의 없음
Fossil은 위키, 포럼, 티켓 같은 내부 도구가 코드와 함께 한 파일에 버전 관리되는 점이 정말 유용함
프리랜서 작업에서는 Fossil 덕분에 프로젝트 맥락, 세부 사항, 클라이언트와의 합의를 다시 파악하기가 매우 쉬움
코드베이스를 지저분하게 만들거나, 이메일과 메모 도구를 여기저기 뒤져서 문맥을 복구할 필요가 없음
Git이 문화적으로 너무 깊게 박혔다고 해서 못 바꾼다고 생각하는 것도 싫음
Fossil은 전환도 쉽고, Git에서 넘어와도 워크플로가 오히려 더 단순함
Git 프로토콜과 저장소를 기반으로도 비슷한 도구는 만들 수 있었고, 실제로 분산 코드 리뷰 같은 것도 있었음
다만 다수는 그런 걸 원하지 않았고, 그래서 힘을 못 받았음
이슈를 프로젝트와 함께 저장하면 곤란한 경우도 꽤 있음
클라이언트가 버그 재현용 스크린샷이나 영상 파일을 많이 보내면 저장소가 금방 불어나고, 코드와 함께 묶어 두면 로컬에서 티켓 보려고 모두가 비대한 저장소를 받아야 해서 매우 번거로워짐
결국 "이건 쓰지 말자, 너무 복잡하고 저장소만 부풀린다"로 흐르기 쉬움
Fossil 기능 대부분은 Git 백엔드 위에도 구현 가능해 보이고, 위키나 이슈는 별도 병렬 브랜치 계층으로 두면 될 듯함
타이밍 영향도 있었던 듯함
기억으론 Git이 이미 안정적이고 일상적으로 쓸 만한 시점에도 Fossil은 버전 업데이트 때 저장소를 통째로 다시 만들어야 하는 경우가 있었음
Git은 UX가 더 나빴고 지금도 그럴 수 있지만, 어쨌든 돌아갔고 실전 투입 가능한 느낌이 강했음
게다가 세계 최대급 오픈소스 프로젝트 중 하나가 쓰고 있었으니, 인식 면에서 그 차이가 결정적이었음
지금이야말로 누가 fossilhub.com을 사서 새 커뮤니티를 만들기 좋은 때라고 봄
대형 저장소에서 Git이 왜 더 빠른지 궁금하긴 함
다만 한동안은 큰 blob 처리에서는 그 장점이 잘 안 드러났던 걸로 기억함
GitHub가 아카이브 역할을 한 건 오히려 나쁘다고 봄
99%의 시간엔 유용한 중앙집중형 서비스가 있으면, 공동체 전체의 보존 능력이 퇴화함
무언가를 살아 있게 하려면 누군가가 직접 시드해야 하는 구조였다면, 사람들은 정말 중요하게 여기는 것의 사본을 더 잘 붙들고 있었을 것임
"나중에 다시 체크아웃하면 되지"라고 쉽게 가정할 수 있게 된 게 오히려 문제임
뭔가를 내릴 수 있는 단일 장소가 있어선 안 됨
GitHub 프로젝트가 DMCA를 맞으면 포크까지 함께 사라짐
Nintendo가 2024년에 인기 있던 Switch 에뮬레이터를 내렸을 때도, 누가 최신 리비전을 체크아웃해뒀는지 찾아서 돌려보는 식으로만 보존과 후속 작업이 가능했음
그마저도 워낙 인기 프로젝트였기 때문에 가능했던 일임: https://news.ycombinator.com/item?id=40254602
덧붙이면 이 사이트의 Splatoon 느낌 헤더/푸터 애니메이션은 정말 좋음
거슬리지 않고 분위기를 살리면서도 스크롤하면 바로 비켜줘서, 나도 이거 그대로 훔쳐 쓰고 싶어짐
그러다 보니 GitHub에 없으면 존재하지 않는 것처럼 느껴지는 분위기도 생김
코드가 다른 곳에도 저장될 수 있다는 사실 자체를 모르는 개발자가 너무 많은 듯함
아카이빙 자체는 쉬운데 저작권과 지식재산권 법이 발목을 잡음
정보를 접근 가능하게 만드는 장애물을 줄이면 권력 집중도 덜해질 것임
여기에 동의하지 않음
GitHub가 수년간 신뢰를 얻은 이유 중 하나는 아직까지 그 아카이브 역할을 직접 수익화하지 않았기 때문임
물론 Copilot 관련 새 기능들을 보면 앞으로는 모르겠음
대안이 사이트 여러 개로 쪼개지는 것이라면, 각자 다른 DMCA 규칙을 갖게 될 뿐임
그보다 나은 대안이 정확히 무엇인지 되묻게 됨
이런 글을 읽으면 내가 참여했던 프로젝트들의 여정을 돌아보게 됨
내 오픈소스 작업 대부분은 self-hosted 인프라 위에서 이뤄졌고, 대표 사례는 Xfce임
2004년에 처음 참여했을 때는 SVN 서버와, 아마 CVSweb의 새 SVN 지원 웹 인터페이스 정도가 있었던 걸로 기억함
내가 코어 팀에 들어간 뒤 Bugzilla를 세팅했던 것 같기도 한데, 그건 다른 사람이었을 수도 있음
Git이 대세가 되기 시작했을 때는 큰 SVN 저장소를 여러 Git 저장소로 옮기는 작업을 주도했고, cgit 웹 인터페이스도 붙였음
그때까지도 Bugzilla를 썼음
2009~2010년쯤 작은 스타트업에 들어가면서 OSS에 쓸 시간이 줄어 프로젝트를 떠났다가 2022년에 돌아왔는데, 그 사이 GitLab 인스턴스와 CI 러너를 세우고 Bugzilla도 GitLab 이슈로 옮겨놨더라
여전히 활동 인원은 한 줌이고 인프라 관리도 거의 한 사람이 맡지만, 작은 팀이어도 충분히 굴릴 만함
인프라가 후원으로 제공되는 건 큰 행운이고, 정기 후원만으로도 필요하면 직접 비용을 낼 수 있을 듯함
무엇보다 GitHub/Microsoft에 의존하지 않는다는 점이 정말 좋음
20년 전에 누가 Microsoft가 세계 최대 OSS 코드 포지를 소유하게 된다고 말했다면 토할 뻔했을 것이고, 지금도 그건 영 불편함
종종 간과되지만 공유 로그인도 정말 중요했음
Rust는 crater라는 도구로 알려진 Rust 프로젝트 전체 테스트를 돌리는데, Cargo 내부 구현에 의존하는 프로젝트를 찾아 수백 개 이슈를 수작업으로 올릴 때 마찰이 적은 흐름이 큰 도움이 됐음
사이트 자격 증명을 이미 갖고 있고 빈 템플릿도 허용되면 200개 이슈를 올리는 일이 훨씬 수월함
반대로 self-hosted 인스턴스를 만나면 대개 거기서 포기하게 됨
SourceForge가 생기기 전부터 Planet Source Code에 글을 올렸었음
나는 Trac을 정말 좋아했음
새 오픈소스 프로젝트를 시작하면서 첫 단계로 Trac을 세팅하는 건 믿기 어려울 정도의 마찰이 있었지만, 그래도 좋았음
Django는 지금도 20년 넘게 Trac 위에서 돌아가고 있음: https://code.djangoproject.com/timeline
그걸 내가 세팅한 건 아니지만, 그보다 앞선 비공개 Trac을 띄우는 데는 도왔을 수도 있음
Trac은 정말 좋았음
다만 내 첫 이슈 트래커는 Bugzilla였고, 세팅이 꽤 고통스러웠으며 다른 도구와 통합도 잘 안 됐음
그래도 Zarro Boogs를 보는 재미는 꽤 각별했음
Trac은 여러 면에서 내가 배포용 앱을 PHP 대신 Python으로 만들게 한 계기였음 플러그인 시스템이 정말 훌륭했음
나는 Bitbucket을 좋아했음
자기 역할을 잘했고, 내겐 딱히 깨지는 일도 없었고, Mercurial 쪽이 더 취향이었음
회사들이 GitHub를 쓰니까 나도 옮겼지만, 지금도 GitHub는 그냥 둔한 Git 엔드포인트처럼만 쓰고 빌드/배포는 Docker와 셸 스크립트로 처리해서 갈아타는 비용이 매우 낮음
업무에선 내가 결정권이 없으면 SVN 시절처럼 돈 받고 쓰는 도구를 그냥 쓰면 된다고 생각함
이상하게도 당시엔 Trac을 엄청 싫어했으면서도 지금은 좋은 기억으로 남아 있음
이것저것 너무 많이 하려다 어느 하나 탁월하지 못하다고 느꼈었음
지금 그 상은 아마 GitLab이 가져갔고, 나중엔 그것도 좋게 기억할 듯함
Flask를 거의 초기에 써본 사람 중 하나였던 것 같음
무료이면서 쉬운 현대적 호스팅이던 AppEngine을 활용하려고 Python을 배웠고, 그 덕분에 Flask가 나왔을 때 딱 좋은 자리에 있었음
Armin을 오래 존경해왔고, 링크를 누르기 전부터 도메인을 보고 바로 알아봤음
그 시절엔 기본 선택지가 GitHub가 아니었다는 그의 말에도 공감함
이 글이 몇 시간 전 Mitchell 글에 대한 응답이라는 점도 인상적이고, 이렇게 빨리 길고 잘 짜인 고품질 글을 썼다는 게 놀라움
code.google.com 생각이 나게 됨
Google이 그렇게까지 크게 공을 놓쳤다는 게 아직도 믿기지 않음
Hacker News 의견들
내 이름에 바로 저장소를 붙여서 빠르게 만들 수 있다는 점이, SourceForge에서 프로젝트 이름 정하고 예약해서 CVS나 SVN 저장소와 웹사이트, 메일링 리스트, 이슈 트래커까지 갖추던 무거운 절차보다 훨씬 해방감 있었음
"이건 그냥 잠깐 만드는 것"이라는 정신적 부담을 크게 줄여줬음
GitHub가 이슈 트래커, PR, 릴리스 페이지, 위키, 조직 페이지, API, 웹훅, CI를 한꺼번에 준 건 아니기도 했음
예전엔 조직 기능이 없어서 새 사용자 계정을 만들어 조직 흉내를 내기도 했고, "GitHub가 몇 달 안에 내놓겠지" 하며 별도 버그 트래커 도입을 미루다가 결국 저장소에 텍스트 파일로 관리한 적도 있었음
Linux 커널 같은 초대형 코드베이스에서는 Git의 성능 이점이 있겠지만, 대다수 프로젝트는 VCS 성능 한계에 닿을 일이 거의 없음
Fossil은 위키, 포럼, 티켓 같은 내부 도구가 코드와 함께 한 파일에 버전 관리되는 점이 정말 유용함
프리랜서 작업에서는 Fossil 덕분에 프로젝트 맥락, 세부 사항, 클라이언트와의 합의를 다시 파악하기가 매우 쉬움
코드베이스를 지저분하게 만들거나, 이메일과 메모 도구를 여기저기 뒤져서 문맥을 복구할 필요가 없음
Git이 문화적으로 너무 깊게 박혔다고 해서 못 바꾼다고 생각하는 것도 싫음
Fossil은 전환도 쉽고, Git에서 넘어와도 워크플로가 오히려 더 단순함
다만 다수는 그런 걸 원하지 않았고, 그래서 힘을 못 받았음
이슈를 프로젝트와 함께 저장하면 곤란한 경우도 꽤 있음
클라이언트가 버그 재현용 스크린샷이나 영상 파일을 많이 보내면 저장소가 금방 불어나고, 코드와 함께 묶어 두면 로컬에서 티켓 보려고 모두가 비대한 저장소를 받아야 해서 매우 번거로워짐
결국 "이건 쓰지 말자, 너무 복잡하고 저장소만 부풀린다"로 흐르기 쉬움
Fossil 기능 대부분은 Git 백엔드 위에도 구현 가능해 보이고, 위키나 이슈는 별도 병렬 브랜치 계층으로 두면 될 듯함
기억으론 Git이 이미 안정적이고 일상적으로 쓸 만한 시점에도 Fossil은 버전 업데이트 때 저장소를 통째로 다시 만들어야 하는 경우가 있었음
Git은 UX가 더 나빴고 지금도 그럴 수 있지만, 어쨌든 돌아갔고 실전 투입 가능한 느낌이 강했음
게다가 세계 최대급 오픈소스 프로젝트 중 하나가 쓰고 있었으니, 인식 면에서 그 차이가 결정적이었음
다만 한동안은 큰 blob 처리에서는 그 장점이 잘 안 드러났던 걸로 기억함
99%의 시간엔 유용한 중앙집중형 서비스가 있으면, 공동체 전체의 보존 능력이 퇴화함
무언가를 살아 있게 하려면 누군가가 직접 시드해야 하는 구조였다면, 사람들은 정말 중요하게 여기는 것의 사본을 더 잘 붙들고 있었을 것임
"나중에 다시 체크아웃하면 되지"라고 쉽게 가정할 수 있게 된 게 오히려 문제임
뭔가를 내릴 수 있는 단일 장소가 있어선 안 됨
GitHub 프로젝트가 DMCA를 맞으면 포크까지 함께 사라짐
Nintendo가 2024년에 인기 있던 Switch 에뮬레이터를 내렸을 때도, 누가 최신 리비전을 체크아웃해뒀는지 찾아서 돌려보는 식으로만 보존과 후속 작업이 가능했음
그마저도 워낙 인기 프로젝트였기 때문에 가능했던 일임: https://news.ycombinator.com/item?id=40254602
덧붙이면 이 사이트의 Splatoon 느낌 헤더/푸터 애니메이션은 정말 좋음
거슬리지 않고 분위기를 살리면서도 스크롤하면 바로 비켜줘서, 나도 이거 그대로 훔쳐 쓰고 싶어짐
코드가 다른 곳에도 저장될 수 있다는 사실 자체를 모르는 개발자가 너무 많은 듯함
정보를 접근 가능하게 만드는 장애물을 줄이면 권력 집중도 덜해질 것임
GitHub가 수년간 신뢰를 얻은 이유 중 하나는 아직까지 그 아카이브 역할을 직접 수익화하지 않았기 때문임
물론 Copilot 관련 새 기능들을 보면 앞으로는 모르겠음
대안이 사이트 여러 개로 쪼개지는 것이라면, 각자 다른 DMCA 규칙을 갖게 될 뿐임
그보다 나은 대안이 정확히 무엇인지 되묻게 됨
내 오픈소스 작업 대부분은 self-hosted 인프라 위에서 이뤄졌고, 대표 사례는 Xfce임
2004년에 처음 참여했을 때는 SVN 서버와, 아마 CVSweb의 새 SVN 지원 웹 인터페이스 정도가 있었던 걸로 기억함
내가 코어 팀에 들어간 뒤 Bugzilla를 세팅했던 것 같기도 한데, 그건 다른 사람이었을 수도 있음
Git이 대세가 되기 시작했을 때는 큰 SVN 저장소를 여러 Git 저장소로 옮기는 작업을 주도했고, cgit 웹 인터페이스도 붙였음
그때까지도 Bugzilla를 썼음
2009~2010년쯤 작은 스타트업에 들어가면서 OSS에 쓸 시간이 줄어 프로젝트를 떠났다가 2022년에 돌아왔는데, 그 사이 GitLab 인스턴스와 CI 러너를 세우고 Bugzilla도 GitLab 이슈로 옮겨놨더라
여전히 활동 인원은 한 줌이고 인프라 관리도 거의 한 사람이 맡지만, 작은 팀이어도 충분히 굴릴 만함
인프라가 후원으로 제공되는 건 큰 행운이고, 정기 후원만으로도 필요하면 직접 비용을 낼 수 있을 듯함
무엇보다 GitHub/Microsoft에 의존하지 않는다는 점이 정말 좋음
20년 전에 누가 Microsoft가 세계 최대 OSS 코드 포지를 소유하게 된다고 말했다면 토할 뻔했을 것이고, 지금도 그건 영 불편함
Rust는
crater라는 도구로 알려진 Rust 프로젝트 전체 테스트를 돌리는데, Cargo 내부 구현에 의존하는 프로젝트를 찾아 수백 개 이슈를 수작업으로 올릴 때 마찰이 적은 흐름이 큰 도움이 됐음사이트 자격 증명을 이미 갖고 있고 빈 템플릿도 허용되면 200개 이슈를 올리는 일이 훨씬 수월함
반대로 self-hosted 인스턴스를 만나면 대개 거기서 포기하게 됨
새 오픈소스 프로젝트를 시작하면서 첫 단계로 Trac을 세팅하는 건 믿기 어려울 정도의 마찰이 있었지만, 그래도 좋았음
Django는 지금도 20년 넘게 Trac 위에서 돌아가고 있음: https://code.djangoproject.com/timeline
그걸 내가 세팅한 건 아니지만, 그보다 앞선 비공개 Trac을 띄우는 데는 도왔을 수도 있음
다만 내 첫 이슈 트래커는 Bugzilla였고, 세팅이 꽤 고통스러웠으며 다른 도구와 통합도 잘 안 됐음
그래도
Zarro Boogs를 보는 재미는 꽤 각별했음플러그인 시스템이 정말 훌륭했음
자기 역할을 잘했고, 내겐 딱히 깨지는 일도 없었고, Mercurial 쪽이 더 취향이었음
회사들이 GitHub를 쓰니까 나도 옮겼지만, 지금도 GitHub는 그냥 둔한 Git 엔드포인트처럼만 쓰고 빌드/배포는 Docker와 셸 스크립트로 처리해서 갈아타는 비용이 매우 낮음
업무에선 내가 결정권이 없으면 SVN 시절처럼 돈 받고 쓰는 도구를 그냥 쓰면 된다고 생각함
이것저것 너무 많이 하려다 어느 하나 탁월하지 못하다고 느꼈었음
지금 그 상은 아마 GitLab이 가져갔고, 나중엔 그것도 좋게 기억할 듯함
GitHub 자체 프로그램도 있고: https://archiveprogram.github.com/
UNESCO 지원 비영리인 Software Heritage도 있음: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
다만 이쪽은 주로 코드와 커밋 히스토리 보존에 가깝고, 이슈나 PR, 토론, 위키 같은 주변 메타데이터까지는 잘 다루지 않음
무료이면서 쉬운 현대적 호스팅이던 AppEngine을 활용하려고 Python을 배웠고, 그 덕분에 Flask가 나왔을 때 딱 좋은 자리에 있었음
Armin을 오래 존경해왔고, 링크를 누르기 전부터 도메인을 보고 바로 알아봤음
그 시절엔 기본 선택지가 GitHub가 아니었다는 그의 말에도 공감함
이 글이 몇 시간 전 Mitchell 글에 대한 응답이라는 점도 인상적이고, 이렇게 빨리 길고 잘 짜인 고품질 글을 썼다는 게 놀라움
Google이 그렇게까지 크게 공을 놓쳤다는 게 아직도 믿기지 않음
그 서비스가 닫히기 전에 내가 그 팀에 있었음