오픈 소스 성공 사례 분석
GNU/Linux
가장 널리 알려진 오픈소스 프로젝트. 1991. 리누스 토발즈가 MINIX의 소스 코드 기반에서 시작. MINIX newsgroup을 통해 공개 GNU tools도 비슷한 시기에 갖춰짐. 많은 프로그래머의 관심을 받으며 성장 GNU/Linux가 성장하면서 레드햇을 필두로 기업의 참여가 이어짐.
컴퓨터가 보급되는데 반해 OS가 빈약하던 시절이라 프로그래머의 주 관심사가 OS였고 그래서 리눅스는 전세계의 프로그래머의 관심을 모을 수 있었다. 그리고 리누스 토발즈의 개인적인 능력도 리눅스의 성장에 큰 영향을 미쳤다. 상업적인 기업의 참여는 리눅스가 충분히 성장한 후에 이루어지기 시작했고 오픈소스로서의 리눅스의 성공에 중요한 요인이었다고 보기는 어렵다. 하지만 시장에서의 리눅스가 현재 엔터프라이즈 시장에 깊숙히 침투하고 있는 것은 기업의 참여가 결정적이다.
Apache Software Foundation
최대의 오픈 소스 커뮤니티. 다수의 Market Leader.
Apache HTTP Server
1995. NCSA 개발자 일부가 모여서 출발. 단기간에 NCSA를 밀어내고 시장 장악
프로젝트 초기에 짧은 시간에 시장을 장악할 수 있었던 요인은 당시 시장을 점유하고 있던 NCSA의 개발자가 나와서 만들었다는 점이 크게 작용한 것 같다. 그래서 짧은 시간에 기존 제품의 품질을 넘어서는 제품을 만들어낼 수 있었고 free라는 점 때문에 빠른 속도로 퍼져 나간 것 같다.
[http://www.webtechniques.com/archives/1999/10/jagielski/ 아파치 개발 프로세스]의 요약
- 코어 개발자도 전세계에 흩어져 있다.
- CVS를 사용한다.
- 코어 개발자 전용 메일링 리스트가 있었지만 참여자에게 공개된 메일링 리스트에서 개발의 핵심 논의가 이루어졌다.
- +1, -1을 이용한 투표로 의사 결정
- 리눅스나 펄, 파이썬과 달리 뚜렷한 한 명의 리더가 존재하지 않는다.
- 정해진 릴리스 일정이 없이 중요한 변경이 있거나 품질이 만족스러울 때 릴리스를 한다.
- 코어 개발자만 커미터이고 다른 참여자의 코드 패치는 커미터가 반영한다. 이 방식은 커미터의 작업을 더 활성화시킬 수 있지만 새로운 참여자의 작업을 더디게 만든다. 아파치 프로젝트는 성공적이었지만 다른 프로젝트들은 그렇지 못한 경우가 많았다.
- FreeBSD와 달리 개발자에게 담당 영역을 따로 지정하지 않았다. 코어 개발자는 자신이 관심 있는 영역을 어디든 건드릴 수 있고 아무 것도 책임지지 않는다.
- 개발 프로세스가 유연하고 심지어 개발 프로세스 자체도 수년간 변경되어 왔다.
- 기업의 개발 프로세스로 채용되어서 성공한 사례가 있다.
How the ASF Works
- Meritocracy 프로젝트에 참여한 사람이 그 프로젝트로부터 무언가 이익을 얻었다고 판단될 때 그 사람을 커미터로 인정한다. 개발자는 자신에게 필요한 것을 만들 때 열심히 참여하고 잘하게 되므로 프로젝트로부터 이익을 얻는 사람은 좀더 많은 기여를 할 수 있을 것이다.
- 프로젝트별로 최대한의 자유를 허용한다. Project Management Committee가 프로젝트에 관한 모든 것을 결정한다.
- Apache Way의 6가지 원칙
- collaborative software development
- commercial-friendly standard license
- consistently high quality software
- respectful, honest, technical-based interaction
- faithful implementation of standards
- security as a mandatory feature
- 공개 토론과 기밀성의 조화. 원칙적으로 공개 토론을 장려하지만 비공개로 토론할 채널을 열어두고 있으며 비공개 토론 내용은 허락 없이 공개할 수 없다.
- Apache Infrastructure
- the web serving environment (web sites and wikis)
- the code repositories
- the mail management environment
- the issue/ bug tracking
- the distribution mirroring system
- Foundation Incubator
- Mozilla
Eclipse Foundation
가장 널리 쓰이는 자바 IDE의 커뮤니티. 98년에 IBM에서 시작. 이클립스가 널리 퍼지려면 많은 third-party의 참여가 절실했지만 IBM의 비즈니스 파트너들은 비협조적이었다. 그래서 오픈소스 라이센스를 채택하고 Eclipse Consortium을 결성한다. 여기에는 8개의 벤더가 참여했고 새로운 오픈소스 개발 모델이 만들어진다. 코드에 대한 것은 오픈소스 커뮤니티가 관리하고 벤더들은 마케팅을 하고 이클립스를 이용한 제품을 만든다. 이러한 모델은 기업의 참여를 좀더 활성화시켰다. 하지만 여전히 Eclipse가 IBM의 지배 하에 있다는 인식이 있었고 이것이 이클립스의 활성화를 저해했다. 그래서 이클립스가 IBM과 독립적이라는 사실을 홍보하기 시작했고 그 홍보는 성공적이었고 자바 커뮤니티 전체에 영향력을 미치게 되었다.
- 프리랜서 writer를 통한 Eclipse를 이용한 성공 사례의 지속적인 홍보
- 정규 멤버에게는 가입 후 1년 이내에 이클립스 기반의 상업적 제품을 내놓거나 이클립스를 상업적 제품 개발에 활용하는 것을 기대한다.
성당과 시장
내용 요약
- 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다.
- 프로그램에 흥미를 잃었다면 프로그램에 대한 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다.
- 사용자들을 공동 개발자로 생각하면 코드가 다른 어떤 방법보다도 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다.
- 일찍 발표하고 자주 발표하라. 그리고 사용자들의 소리에 귀를 기울이라.
- 충분히 많은 베타 테스터와 공동 개발자가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다.
- 처음부터 시장 스타일로 개발할 수 없다는 것은 자명하다.
- 평판에 대한 오픈 소스 공동체의 내부 시장은 미묘한 압력을 사람들에게 작용한다.
- 시장 스타일의 프로젝트를 조정하거나 이끄는 사람은 사람들과 잘 의사 소통하는 기술을 가지고 있어야 한다.
- 개발 조정자가 최소한 인터넷만큼 좋은 매체를 가지고 있으며 강제력을 사용하지 않고 어떻게 이끌어야 할 지 알고 있다면, 한 명 보다는 여러 명의 리더가 필연적으로 더 낫다.
성당과 시장에 대한 비판
- 성공한 시장(오픈소스) 뒤에는 성당(기업)이 버티고 이다.
- 반론: 리눅스나 아파치처럼 성공한 오픈소스는 시장에 영향력을 행사하기 시작하면서 기업이 후원하기 시작했다.
FreeBSD vs GNU/Linux
- FreeBSD는 오픈소스임에도 성당 스타일의 개발을 하고 GNU/Linux는 시장 스타일이다. 이것이 BSD License가 GPL보다 더 유연한데도 리눅스가 시장에서 FreeBSD를 앞서는 이유 중 하나이다.
- codehaus
- opensymphony
- python
- ruby
- 비즈니스로 전환한 후의 motivation
- 비즈니스 가치
- 성당과 시장에 대한 비판
[http://www.zdnet.co.kr/builder/platform/nix/0,39031679,39137137,00.htm 오픈소스로 돈 벌기]