GN⁺: GitHub이 실제로 승리한 이유
(blog.gitbutler.com)- GitHub이 승리한 이유는 두 가지로 요약할 수 있음
- 적절한 시기에 시작했음
- 좋은 감각을 가졌음
초기 환경
- 2005년 즈음, 소프트웨어 개발자는 대부분 Subversion과 같은 중앙 집중형 버전 관리 시스템을 사용
- Git과 Mercurial이 처음 커밋된 시점이 이 즈음이며, 오픈 소스 기여는 아직도 복잡하고 비효율적이었음
- 오픈 소스 프로젝트 수는 2005년에 매우 적었고, 전체적으로 중앙 집중형 시스템이 오픈 소스 기여에 적합하지 않았음
Git의 등장
- Git은 Linus Torvalds가 기존 BitKeeper의 라이선스 문제로 인해 개발한 버전 관리 시스템
- Git의 주요 장점:
- 브랜치와 병합이 매우 쉬움. 빠른 속도, 간단한 권한 관리
- 분산형 구조로 자신만의 포크를 쉽게 만들 수 있고, 풀 요청이 쉬워짐
GitHub의 등장
- GitHub의 창립자들은 Git 호스팅의 어려움을 해결하기 위해 GitHub를 개발
- 사용자를 중심으로 한 접근법을 통해 프로젝트 중심의 기존 호스팅 방식과 차별화됨
- 사용자 중심의 네임스페이스와 풀 모델을 도입
- "안 예쁘지 않음"을 핵심 기능으로 삼음
- 초기 루비 커뮤니티가 GitHub를 빠르게 수용하면서 성장의 발판이 됨
Git의 승리
- Git이 성공한 이유 중 하나는 Linus Torvalds와 Linux 커뮤니티의 PR 효과 덕분
- GitHub는 루비 커뮤니티와의 강력한 연계를 통해 홍보 효과를 얻었고, 이는 Git의 성장에 기여했음
- Git의 다른 분산 버전 관리 시스템에 비해 뛰어난 브랜치/병합 기능과 사용자 경험 중심의 호스팅이 큰 장점으로 작용
경쟁의 붕괴
- 2011년 Google Code와 BitBucket이 Git을 지원하면서 Mercurial의 패배가 확정
- 다들 GitHub의 성장세를 따라잡지 못함
- 2015년 Google Code는 서비스를 종료하고 GitHub로의 이전을 권장
Google Code가 승리하지 못한 이유
- 기존 대형 호스팅 서비스는 수익 모델과 배급에 초점을 맞추었지만, GitHub는 개발자 경험을 최우선으로 고려
- Google Code, BitBucket 등은 GitHub에 비해 '맛'이 부족했고, 개발자 워크플로우를 제대로 이해하지 못함
- GitHub는 창업 초기 자금 지원 없이도 성공했으며, 이는 사용자 경험과 커뮤니티 지원의 결과
GitHub이 승리한 이유
- GitHub는 새로운 패러다임이 형성되는 시점에 적절히 등장했으며, 개발자 경험을 최우선으로 고려하는 접근 방식이 성공의 핵심 요인
- 오픈 소스 커뮤니티가 분산 버전 관리로 전환할 때, GitHub는 개발자 경험을 개선하는 데 집중했음
- 앞으로의 과제는 다음 개발자 워크플로우의 변화가 무엇이 될지, 그리고 이를 성공적으로 구현할 수 있는 '맛'을 가진 회사가 누구일지 궁금
GN⁺의 정리
- GitHub가 승리한 이유는 적절한 시기와 좋은 감각 덕분임
- Git의 분산 특성과 GitHub의 사용자 중심 접근 방식이 결합되어 성공을 이끌었음
- 오픈 소스 커뮤니티와의 긴밀한 관계가 GitHub의 인기를 높였음
- 경쟁 서비스들은 개발자 경험에 대한 관심이 부족했음
- GitHub의 성공은 개발자 경험을 중시하는 접근 방식의 중요성을 보여줌
저도 처음에 웹 형태로 UI를 지원하는 Git 호스팅 서비스를 보면서, 이거는 시장에서 성공하겠다는 생각이 강하게 들었습니다. 나름 깃허브를 초기부터 사용했었는데 당시에도 엄청나게 잘 되어 있었던 게 기억이 나네요.
MS 의 Github 인수를 두고 한국 경제계에서는 “MS가 돈이 남아도니 돈 안되는 Github을 인수했다”는 의견이 지배적이었었죠. 당시 저도 오픈소스인 데다가 Github 충분히 경쟁력 있고 자체구축 오픈소스라 매력적인 Gitlab 을 선호했었습니다. 하지만 시장은 한국의 기대와 완전히 상반된 결과를 보여줬습니다. 오픈소스 데이터 자산 빵빵한 Github이 경쟁에서 승리하고, 신뢰성을 등진 Gitlab 은 매물로 나와버리고 말았죠. 둘 다 한국 회사라면 물론 둘 다 망할 회사긴 하지만요.
Github보다 개인적으로 Gitlab을 상당히 좋아했는데 시장경쟁에서 밀리는게 의아하고 안타깝습니다
프로젝트 이슈관리부터 소스코드 관리, CI/CD에 위키에다 인프라 관리까지 싹다 그것도 잘 어우러져서 제공한 훌륭한 서비스인데도 참...
Github이 선점효과를 굉장히 영리하게 잘 쓰기는 했지만 그게 경쟁에서의 결정적인 포인트가 될줄은 상상도 못했네요
Hacker News 의견
-
Google Code는 SourceForge의 독점적 문화를 막기 위해 시작되었음
- Google Code는 돈을 벌기 위한 것이 아니었음
- 목표를 달성한 후, GitHub 및 Bitbucket과 협력하여 마이그레이션 도구를 제공했음
- 사람들이 질문하지 않아서 오해가 생겼음
-
SourceForge는 한때 악성 소프트웨어를 번들로 제공했음
- 많은 개발자들이 GitHub의 원격 저장소가 SSH 연결만으로도 가능하다는 것을 모름
- GitHub는 개인 저장소를 통해 수익을 창출했음
-
Linus의 유명세가 Git의 승리에 기여했음
- GitHub는 Git의 친숙한 인터페이스로 인식됨
- GitHub는 초기부터 Git에 집중했음
- GitHub는 오픈 소스 호스팅 서비스로서 독점적임
-
GitHub는 Git의 승리 덕분에 성공했음
- GitHub의 경쟁자들은 Git을 받아들이는 데 느렸음
- 개발자들은 DVCS 선택에 열정적이었음
-
"Taste"가 초기 시장 지배에 중요한 요소였음
- 많은 프로젝트가 GitHub로 이동했음
- GitHub의 "Product-market fit"이 성공 요인이었음
- 클라우드 컴퓨팅과 Web 2.0의 전환이 시기적으로 맞아떨어졌음
-
비즈니스에는 진정한 승자가 없음
- GitHub도 언젠가 대체될 수 있음
- 암호화된 Git 저장소 서비스가 필요함
- SourceHut는 관리자 문제로 인기가 없음
-
Subversion은 FTP보다 나았지만, Git은 더 나은 대안이었음
- Git은 여전히 혼란스러울 수 있음
- GitHub 없이는 Git이 성공하지 못했을 것임
-
Google Code는 Google의 오픈 소스 프로젝트를 위한 것이었음
- Google은 자체 도구를 사용했음
- Google의 프론트엔드 문화가 약했음
-
GitHub는 UX가 뛰어났음
- BitBucket은 사용하기 어려웠음
- GitHub는 무료 개인 호스팅을 제공하지 않았음
-
Git은 2005년에 만들어졌음
- Git은 오래된 기술처럼 느껴짐