GitHub 이전의 오픈소스 세계

• GitHub가 오픈소스의 사회적 인프라로 자리 잡기 이전, 개발자들은 자체 Trac, Subversion 저장소, 메일링 리스트 등 직접 운영하는 인프라 위에서 프로젝트를 관리했으며, 의존성 추가에도 상당한 마찰과 신중함이 수반되었음
• GitHub는 프로젝트 생성·발견·기여를 획기적으로 쉽게 만들었고, 이슈 트래커·풀 리퀘스트·CI 등을 표준화하며 오픈소스의 아카이브 역할까지 수행
• npm 등 패키지 생태계와 결합하면서 마이크로 의존성 폭발이 발생했고, GitHub는 신뢰 체계의 핵심 축이 되었으나, 현재 불안정성·제품 방향성 혼란·AI 노이즈 등으로 신뢰가 침식 중
• Ghostty도 떠나고, Strudel, Tenacity 등이 Codeberg로 이전하는 움직임이 나타나고 있으며, 분산화는 자율성을 높이지만 이슈·리뷰·보안 권고 등 사회적 맥락의 소실 위험도 존재
• 최근 GitHub의 중심성이 약해지는 조짐 속에서, 기억은 보존하고 의존은 줄이는 공적 아카이브가 더 중요해짐. 다음 시대의 오픈소스는 기억은 유지하되 의존성은 줄이는 방향이어야 함

GitHub 이전의 오픈소스 환경

• GitHub 이전에는 의존 가능한 프로젝트 수가 제한적이었고, 각 프로젝트의 평판과 지속성이 의존성 선택에 직접 연결됨
• 의존성은 단순한 패키지명이 아니라 프로젝트의 역사, 웹사이트, 유지관리자, 릴리스 과정, 커뮤니티 맥락까지 함께 따라왔음
• 큰 프로젝트는 자체 인프라를 운영하는 경우가 많았고, 작은 프로젝트는 대학 서버나 SourceForge에 올라가는 경우가 있었음
• Debian 패키징 과정처럼 라이선스와 저작권 헤더까지 검토받는 마찰이 있었고, 이런 마찰도 신뢰 판단의 일부로 작동함

자체 인프라 운영과 분산 버전 관리의 역설

• 초기 오픈소스 프로젝트는 Trac, Subversion, tarball, 문서를 직접 운영하는 서버 위에서 굴러가는 경우가 흔했음
• Pocoo처럼 여러 프로젝트가 서버 비용과 Subversion, Trac, 메일링 리스트 운영 부담을 함께 나누는 구조도 있었음
• Subversion은 중앙집중형 저장소라 서버 운영이 자연스럽게 따라왔고, 프로젝트의 집은 호스트명과 디렉터리, Trac 인스턴스, 메일링 리스트 아카이브처럼 물리적으로 분명했음
• Mercurial과 Git은 누구나 전체 저장소와 브랜치, 히스토리를 가질 수 있는 분산형 시스템이었지만, 실제 중심은 다시 GitHub로 모임
• 분산 버전 관리 시스템이 승리한 뒤 전 세계가 하나의 거대한 중앙 서비스에 표준화된 점이 현대 오픈소스의 큰 아이러니로 남음

GitHub가 만든 변화

• GitHub는 프로젝트 생성과 발견을 쉽게 만들고, 개발 메일링 리스트 경험이 없는 사람도 기여 흐름을 이해하기 쉽게 만듦
• 이슈 트래커, pull request, 릴리스 페이지, 위키, organization 페이지, API, webhook, 이후의 CI까지 제공하면서 공개 협업의 기본값을 바꿔 놓음
• 오픈소스 협업은 보이는 히스토리와 보이는 토론 위에서 진행하는 방식으로 보편화됨
• 한동안 GitHub는 오픈소스 프로젝트를 올리기 위한 매우 합리적인 기본 선택지로 기능함
• 미국 제재 대상 국가에서도 GitHub 접근성을 유지하려 했던 정책처럼, 중앙화는 단순한 호스팅을 넘어 접근 가능한 공용 기반 역할도 했음

아카이브로서의 GitHub

• GitHub의 덜 주목받은 기능은 아카이브 역할이었고, 방치된 프로젝트도 검색 가능하게 남아 소프트웨어 공용 자산의 인덱스처럼 작동함
• fork, 오래된 이슈, 토론 기록이 계속 남아 있으면서 중앙화가 발견 가능한 기억을 만들어 줌
• 반대로 대형 플랫폼 이전에는 개인 도메인 만료, VPS 종료, 개발자 부재와 함께 프로젝트 파일과 서비스가 사라지는 일이 흔했음
• PyPI에 메타데이터만 남고 실제 패키지는 사라진 초기 프로젝트처럼, 저장소 주소가 오래된 개인 서버를 가리키다 끊기는 상황도 있었음
• 과거의 많은 프로젝트는 결국 Internet Archive 같은 외부 보존 수단에 크게 의존하게 됨

npm과 의존성 폭증

• micro dependency 문제는 작은 패키지가 많아진 데서 끝나지 않았고, GitHub와 npm이 생성, 배포, 검색, 설치, 의존 비용을 거의 없애 보이게 만든 데서 더 커짐
• GitHub 이전에는 신뢰와 지속성이 의존성 선택의 필수 요소였고, 다른 서비스 가용성을 믿기 어려워서 코드를 직접 저장소에 포함하는 vendoring도 흔했음
• API 이전 시기에는 외부 코드를 가져오는 스크립트 유지도 번거로웠고, 이런 마찰이 의존성 추가 전에 한 번 더 생각하게 만듦
• npm식 생태계에서는 패키지 그래프가 사람이 추론할 수 있는 속도보다 더 빠르게 커질 수 있음
• 라이선스 상태가 불명확해지는 문제에 대응하려고 GitHub는 약관 개정도 시도함
• 작은 패키지에 의존하더라도 저장소, 유지관리자 존재 여부, 이슈, 최근 변경, 다른 프로젝트 사용 여부, 코드와 패키지 설명의 일치 여부를 GitHub에서 확인하는 문화가 자리잡음
• GitHub는 npm 같은 레지스트리에 대한 trusted publishing까지 맡는 몇 안 되는 시스템 중 하나가 되었고, GitHub 신뢰 약화는 소스 호스팅을 넘어 공급망 문화 전체에도 영향을 줌

GitHub의 약화와 이동 조짐

• GitHub는 최근 불안정성, 제품 변화 반복, Copilot AI 소음, 불명확한 리더십 때문에 예전의 필연성 일부를 잃는 중임
• agentic coding 흐름 한가운데 놓이면서 내부 압박도 커졌지만, 현재는 리더십 부재가 크게 느껴지는 상태로 묘사됨
• 한동안 GitHub 이탈은 상징적 움직임에 가까웠지만, 이제는 영향력이 큰 프로젝트들도 이동을 공개적으로 검토하거나 실행 중임
• Ghostty의 GitHub 이탈 발표는 목적지가 아직 뚜렷하지 않아도 강한 신호로 다뤄짐
• Strudel moved to Codeberg
• Tenacity moved to Codeberg
• 아직 대세 전환을 만들 수준은 아닐 수 있어도, GitHub 바깥의 호스팅 공간을 다시 더 자주 보게 되는 흐름이 나타남
• Git 자체가 원래 여러 개의 집을 전제로 설계된 만큼, 한 회사가 모든 것의 기본 집이 되는 상태를 끝내는 일은 오픈소스에 건강할 수 있음

분산 회귀의 비용

• 여러 forge, 여러 서버, 여러 작은 커뮤니티로 돌아가면 탈중앙화와 자율성은 커지고 Microsoft 리더십 변화에 대한 의존은 줄어들 수 있음
• 각 커뮤니티가 각자 다른 워크플로를 고를 수 있다는 장점도 있음
• Pi의 현재 이슈 트래커 문제는 GitHub의 제품 선택이 오늘날 오픈소스 유지관리 현실과 맞지 않는 결과로 이어짐
• GitHub는 유지관리자 정신 건강보다 engagement 중심으로 설계된 면이 드러남
• 반면 self-hosted forge, 자체 Mercurial 서버, cgit 서버로 이동하면 코드 자체는 분산돼도 사회적 맥락은 쉽게 흩어질 수 있음
• 이슈, 리뷰, 설계 토론, 릴리스 노트, 보안 공지, 오래된 tarball은 생각보다 훨씬 쉽게 사라짐
• 과거에 이런 맥락을 담던 메일링 리스트는 오늘날 요구를 따라가지 못했고, 사용자 경험도 좋지 않음
• 소프트웨어가 잊히는 성격에는 정화 효과가 있을 수 있지만, 손실 위험이 커지면 분산 버전 관리 시스템을 실제로 활용하는 방식도 다시 고민해야 함

필요한 것은 공공 아카이브

• GitHub가 남든 프로젝트가 다른 곳으로 가든, 오픈소스에는 공적이고 지루하지만 안정적인 아카이브가 필요함
• 개발자 생산성 시장에서 이기기 위한 서비스가 아니라, 중요한 소프트웨어가 사라지지 않게 하는 구조가 필요함
• endowment나 공공 자금처럼 장기적으로 유지 가능한 기반 위에서 돌아가야 함
• 소스 아카이브, 릴리스 산출물, 메타데이터, 프로젝트 맥락은 한 회사의 사업 모델이나 리더십 기분에 묶이지 않은 곳에 보존돼야 함
• GitHub는 오픈소스 활동의 중심이 되면서 우연히 그 아카이브 역할까지 맡았지만, 중심성이 약해지면 그 기능이 자동으로 유지된다고 가정할 수 없음
• 개인 서버와 선의만으로는 보존이 충분하지 않았고, Google Code와 Bitbucket에서도 플랫폼 종료 이후의 공백이 이미 드러남
• 앞으로의 시스템은 기억은 보존하고 의존은 줄이는 방향으로 가야 하며, 프로젝트 이동, 사회적 맥락 미러링, 릴리스 보존이 쉬워지고 한 회사의 표류가 모두의 문화적 위기로 번지기 어려워져야 함
• 깨진 tarball 링크와 버려진 Trac 인스턴스로 돌아가고 싶지도 않고, 지난 20년의 GitHub 중심 구조를 영구적인 정상 상태로 받아들일 수도 없다는 긴장이 함께 남아 있음