OSS는 특이한 강점과 약점을 지닌 특이한 개발 과정을 갖는다:
OSS 과정은 그 참가자들의 동기와 문제를 푸는데 사용하는 방법에서 특이하다. OSS는 따라서 이
해가 요구되는 흥미롭고 복제할 수 없는 장점을 갖는다.
역사
인터넷 소프트웨어
OSS의 가장 큰 사례는 인터넷이다. 인터넷의 대부분의 초기 코드가 그랬고, 다음의 Tim O'Reilly의
인터뷰에서 알 수 있듯이 현재도 그렇다.
(http://www.techweb.com/internet/profile/toreilly/interview):
TIM O'REILLY: 우리가 시작할 때의 가장 큰 메시지는 "오픈 소스 소프트웨어는 동작한다"였다.
BIND는 인터넷에서 단일의 가장 미션 크리티컬한 소프트웨어로 절대적으로 월등한 시장 점유율
을 유지한다. 아파치는 우세한 웹 서버이며, SendMail은 아마도 80퍼센트의 전자우편 서버에서
동작하며 아마도 인터넷의 모든 전자우편에 손을 댈 것이다.
자유 소프트웨어 재단/GNU 프로젝트
현대적인, 조직화된 OSS의 첫 번째 명예는 일반적으로 MIT의 Richard Stallman에게 주어진다.
1983년 늦게 Stallman은 자유 소프트웨어 재단(Free Software Foundation, FSF)를 만들었다 -
http://www.gnu.ai.mit.edu/fsf/fsf.html - 유닉스 운영체제의 공개 버전을 만들고자 하는 목적이었
다. FSF는 GNU라는 이름으로("Gnu's Not Unix"라는 재귀적인 의미임) 일련의 소스와 바이너리를
공개했다. [ 특이한 것은 GNU 프로젝트의 많은 프로그램들은 오픈 소스이지만 최근의 OSS만큼 일
반 사용자들의 참여가 많지는 않았다는 점이다. GNU emacs, GNU cc 등은 널리 사용되는 유틸리
티이지만, 그 개발은 '시장(Bazzar) 스타일'의 것은 아니었다. 그리고 GNU프로젝트는 현재 HURD라
고 불리는 독자적인 커널을 만들고 있다 ]
카피레프트 라이센스
FSF/GNU 소프트웨어는 GNU 소프트웨어에서 소스 코드를 숨기는 것을 불법으로 할 뿐 아니라
GNU 소프트웨어에서 파생된 소스를 숨기는 것도 불법으로 하는 "카피레프트" 라이센스를 소개하였
다. 이 라이센스를 설명한 문서는 GPL(General Public License)로 알려져 있다.
오픈 소스 과정
상용 소프트웨어 개발 과정은 경제적인 목적의 집단에 의해 보증된다. 그러나, 오픈 소스 소프트웨
어에서는 돈이 종종 (기본적인) 동기가 아니므로, 이 위협의 본질을 이해햐는 것은 오프 소스 개발
팀의 과정과 동기에 대한 깊은 이해를 필요로 한다.
다른 말로 하자면, OSS에 대항하기 위해서는 회사보다는 과정에 목표를 맞추어야 한다
{ 이것은 마이크로소프트가 놓치기를 바랬던 아주 중요한 식견이다. 진짜 전투는 NT 대 리눅스도
아니고, 마이크로소프트와 래드햇/칼데라/S.u.S.E도 아니다 - 이것은 닫힌 소스 개발 방식과 열린
소스 개발 방식 - 성당과 시장 - 의 대결인 것이다. ... 실제적인 수준에서, 이런 식견은 마이크로
소프트의 선전은 특정 경쟁자가 아니라 오픈 소스의 프로세스와 문화에 맞추어질 것을 의미한다.
... }
오픈 소스 개발 팀
인터넷 위주의 OSS 팀의 특징은 다음과 같다:
- 지역적으로 광범위하다 - 예를 들어 리눅스의 핵심 개발자는 유럽, 미국, 아시아에 골고루 분포
되어 있다.
- 적은 수의 핵심 인물과 많은 공헌자들
- 돈에 의해 동기부여가 된 것이 아니다(단기적으로는). 각 개인은 다른 직업을 유지하면서 자신의
여가 시간과 에너지를 OSS에 투자하는 취미가에 가깝다. 이는 리눅스 OS의 상용 버전이 나오면서
다소 변하기 시작하였다 [ 래드햇이나 칼데라는 오픈 소스에 기여하는 것이 업무인 자사 개발자들
을 거느리고 있다 ].
OSS 개발의 조정
통신 - 인터넷 규모
OSS 팀의 조정은 인터넷 고유의 협동 양식에 크게 의존한다. 전형적인 방법은 인터넷의 협동 방법
의 전반에 걸쳐 있다.
공통적인 방향
통신 매체와 더불어 다른 요소들이 팀의 방향을 조정한다.
공통적인 목적
공통적인 목적은 전체 개발 팀이 내리는 분산된 결정에 담긴 비전과 동일하다. 단일하고 명료한 목
적(예. "유닉스를 다시 만들자")은 여러 가지이며 막연한 것(예. "좋은 운영체제를 만들자")보다 매
우 효율적으로 의사소통할 수 있고, 그에 따라 그룹이 행동하도록 한다.
공통적인 전례
전례는 잠재적으로 리눅스 운영체제와 같은 큰 OSS 프로젝트의 빠르고 결합력 있는 성장을 설명하
는 가장 중요한 요소이다. 전체 리눅스 사회는 수년 많은 종류의 유닉스를 다루어 온 경험을 공유
하므로, 무엇이 되고 무엇이 되지 않는지에 대해 대립되지 않는 방법으로 구별할 수 있다.
공통적인 기술
... 중요한 특성은 ... 공통적인 유닉스/GNU/make 기술이다. 그보다 더 높은 벽이 있다면 전체 과
정이 운영되지 않을 것이다... 적당한 정도의 기술을 가진 유닉스 프로그래머는 리눅스와 많은 OSS
제품에서 큰 일을 해내도록 성장할 수 있다. [ 프로그래머는 자신의 필요에 의해 OSS 프로젝트를
시작하고, 여기에는 그리 대단한 지식이 필요한 것이 아니다. Eric씨의 '성당과 시장' 문서에서 이런
단순한 동기(가려운 데를 긁어주는)와 일반적인 오픈 소스의 개발 동기에 대해서 잘 설명해 주고
있다 ]
병렬 개발
일단 컴포넌트 프레임워크가 갖추어지면(핵심 API나 구조체의 정의 등), 리눅스와 같은 OSS 프로
젝트는 특정 문제를 해결하기 위해 소수로 구성된 여러 팀을 활용할 수 있다. 개발자들은 보통 취
미가이므로, 여러 가지 노력의 경쟁은 문제가 되지 않으며 OSS 프로젝트는 만들어진 많은 것들 중
최고의 구현 방법을 선택할 수 있는 능력에서 이득을 얻는다.
병렬 디버깅
Eric씨에 의해 발전된 핵심 주장은 소프트웨어 개발의 다른 면과는 달리 코드 디버깅은 프로젝트에
관계된 사람의 수에 거의 비례하여 발전할 수 있는 작업이라는 것이다. 오픈 소스의 일부를 디버깅
하는데 소요되는 관리나 조정 비용은 거의 없다. [ 이말은 '디버깅은 병렬화 가능하다'라는 말과 같
은 의미이다. 역시 '성당과 시장'의 핵심 문구 중 하나이다 ]
충돌 해결
모든 큰 규모의 개발 과정은 해결해야 하는 문제를 안게 된다. 종종 해결은 프로젝트를 더 진행하
기 위한 임의의 결정이 된다. 상업적인 팀에서는 협동 구조 + 성능 비교 구조가 문제를 해결한다 -
OSS는 어떻게 이를 해결할까?
리눅스의 경우, Linus Tovalds는 프로젝트의 명백한 '지도자'이다. 그는 큰 요소(예. 네트워킹, 장치
드라이버 등)을 그가 믿을 수 있는 몇몇 "부관"들에게 위임하며, 그들은 소수의 해당 영역 관리자
(예. 랜 드라이버 등)에게 위임한다. 다른 방법으로는 투표에 의해 결정하는 방식과(아파치), 그 제
어권을 돌아가면서 맡는 경우(Perl)가 있다.
동기
- 자신에게 닥친 문제를 푼다:
이는 기본적으로 Raymond의 첫 번째 교훈을 반복하는 것이다 - "모든 좋은 소프트웨어는 개발자
개인의 가려운 곳을 긁는 것으로부터 시작된다('성당과 시장'에서)". 많은 OSS 프로젝트(아파치와
같은)은 직접 문제를 해결하기 위해 구성된 소수의 팀에서 시작하였다. 그 다음의 향상은 종종 그
코드를 자신의 문제에 적용하는 사람에 의해 일어난다(예. 특정 NIC의 장치 드라이버가 없다는 것
을 발견하는 등).
- 교육:
리눅스 커널은 헬싱키 대학의 교육 프로젝트에서 나왔다. 비슷하게 많은 리눅스/GNU 시스템의 요
소들(X윈도우 GUI, 쉘 유틸리티, 클러스터링, 네트워킹 등)은 교육 기관의 사람들에 의해 확장되었
다.
- 자아 만족:
OSS 개발 사회가 제시하는 가장 오묘하고 심오한 동기는 순수한 자아 만족이다. '성당과 시장'에서
Eric Raymond는 다음과 같이 주장하였다:
리눅스의 해커들이 최대화하려고 하는 '효용함수'는 고전적 의미에서의 경제적인 것은 아니고 그
들 자신의 측정할 수 없는 자아 만족과 다른 해커들 사이의 평판이다.
그리고, 물론 "다른 누군가가 당신을 해커라 부르기 전에는 당신은 해커가
아니다".
- 인지권을 개간하기(Homesteading on the Noosphere):
Raymond의 두 번째 논문 - "Homesteading on the Noosphere" 는 경제적 동기의 교환(돈을 벌기
위한 상용 소프트웨어 개발)과 "선물 교환"(예. 영광을 위한 OSS개발)의 차이를 논의하고 있다.
"Homesteading on the Noosphere"에서 인용하면:
... 이런 방식으로 조사해 보면, 오픈 소스 해커 사회는 실제로 선물 문화(gift culture)라는 것이
명백하다. 그 안에서는 '생존 필수품'의 심각한 부족은 없다 - 디스크 공간, 네트워크 대역폭, 컴
퓨팅 파워. 소프트웨어는 자유롭게 공유된다. 이 풍부함이 만드는 상황은 경쟁적인 성공의 유일
한 척도가 주변 사람들의 평판이라는 것이다.
Homesteading on the Noosphere: Eric씨가 1998년 4월에 쓴 글로, 해커 문화와 오픈 소스사
이의 관계를 논하고 있는 글이다. Eric씨는 '성당과 시장'외에도 총 4편의 연작 글을 썼는데, 이것이
두 번째 글이다. 이 글도 번역되었으면 하는 개인적인 바램이 있다.
인지권(人智圈) 사전적 의미는 인간 활동으로 변화가 현저한 지역. 여기서는 오픈 소스 프로그래
머/해커들의 활동 반경을 뜻한다.
- 이타주의(altruism):
이는 논쟁의 여지가 있는 동기이며, 어느 정도는 나는(VinodV) 믿고 싶다. 이타주의는 Raymond가
주장하는 자아만족의 형태로 변질된다.
코드 분리(code forking)
큰 개발 팀의 가장 큰 위협은 코드 분리의 위험이다. 코드 분리는 개발 프로젝트의 보통 이상의 밀
고 당기는 상황에서 프로젝트 코드 베이스의 복수의 일관성 없는 버전이 발전할 때 일어난다.
예를 들어 상용 세계에서는 윈도 NT 코드베이스의 단일한 개발은 상용 유닉스(SCO, Solarix,
HP-UX 등)에서 찾을 수 있는 '분리된' 코드베이스에 대해 갖는 가장 큰 장점 중 하나다.
[ BSD 유닉스는 4.3BSD이후 코드 분리의 가장 좋은 예가 된다. 4.3BSD의 386버전인 386BSD가
만들어진 이후, 이 프로젝트의 더딘 발전에 실망한 일련의 개발자들은 코드 베이스를 따로 만들기
로 결정하고 FreeBSD와 NetBSD로 분리되게 된다. 이후 NetBSD에서 다시 OpenBSD가 갈라지게
되며, 공개 유닉스인 이들 세 BSD유닉스와는 달리 BSD코드를 바탕으로 상용 유닉스 회사인 BSDI
사가 만들어지게 된다.
BSD유닉스에 대한 할로윈 I의 기술은 틀린 점이 많다. 하지만 중요한 것은, 이런 코드 분리는 어떤
동기에서든 실제로 일어나기 쉬운 일이며(emacs나 Xemacs, gcc/egcs 등), 이는 대체적으로 그
소프트웨어의 라이센스에 기반한다는 사실이다(아래에 나오는 BSD라이센스의 특성상). 하지만 이는
사용자와 개발자 사회의 크기를 줄이는 결과가 되기도 하며, 이는 BSD유닉스가 초기부터(리눅스
등장 이전의) 기술적인 우위를 점했음에도 불구하고 현재는 리눅스보다 많이 쓰이지 않는지를 설명
해 준다. 실제로 할로윈 문서의 발표 이후 BSD사회에서는 "(리눅스에 대항하기 위해) 세
BSD(Free, Open, Net)를 통합하자"는 의견도 있었고, 꽤 활발하게 의견도 나누었지만, 필자는 그
렇게 되기까지는 분리 이후 걸어온 만큼의 시간이 걸릴 것이라고 본다. ]
GPL과 달리, BSD의 라이센스는 파생 코드에 대해 제한을 부여하지 않는다. 따라서 여러분이 고친
것이 충분히 훌륭하다면, 코드를 분리해서 값을 매기거나 이름을 바꿀 수 있다.
리눅스에서의 코드 분리(가 없음)
BSD의 예와 달리, 리눅스 커널 코드 베이스는 분리되지 않았다. 다음의 몇몇 이유는 리눅스 코드
베이스의 통합이 유지되고 있는지를 설명해 준다:
- 널리 인정받은 리더쉽: Linus Tovalds는 리눅스 세계의 명사이며 그의 결정은 최종적인 것으로
인정된다.
- 열린 멤버쉽과 장기간의 공헌 잠재력: BSD의 닫힌 멤버쉽에 비해, 누구나 리눅스에 공헌할 수
있으며 여러분의 위치는 공헌도에 따라 달라진다. [이는 최근의 BSD도 마찬가지이다]
- GPL 라이센스는 코드 분리의 경제적인 동기를 제거한다: 리눅스의 파생본도 공개되어야 하므로,
분리된 리눅스 소스 트리로 소수 집단이 되는 것이 장기적으로 경제적인 이득이 없다.
- 코드베이스를 분리하는 것은 또한 '인지권(Noosphere)'를 분리하는 것이다: 자아만족은 OSS 개
발자들이 가장 큰 인지권에 가장 큰 말뚝을 심도록 재촉한다. 코드베이스를 분리하는 것은 새 코드
트리에서 개발자들이 달성할 수 있는 영역을 줄이게 된다.
오픈 소스의 강점
OSS의 지수적(exponential) 성질
- OSS 과정은 인터넷과 함께 증가한다:
OSS 프로젝트가 직면하는 가장 큰 제한은 프로젝트에 시간을 투자해 줄 충분한 개발자를 찾는 것
이다. 이를 가능하게 하기 위해서 인터넷은 운영체제 규모의 프로젝트에 충분한 사람을 모을 수 있
을 정도로 충분하다.
- OSS 과정은 "승자가 모든 것을 갖는다":
상용 소프트웨어와 달리 여러 분야에서 가장 생존 능력이 있는 하나의 OSS 프로젝트가 결국 경쟁
적인 OSS 프로젝트를 죽게 하고 그들의 IQ 자산을 얻을 것이다. 예를 들면, 리눅스는 BSD 유닉스
를 죽이고 있으며 거의 모든 핵심적인 아이디어를 흡수했다(상용 유닉스의 것도 포함하여). 이 특징
은 특정 프로젝트에게 우선권을 주게 된다. [ 과연 그럴까? 그렇다고 해서 열등한 다른 것들이 사
라지는 것은 아니다. 많은 경우에 있어 가장 유명한 것은 물론 남지만, 그렇지 않은 것들도 나름대
로의 특징이 남아있는 한(즉 열등한 프로젝트가 우등한 프로젝트의 부분집합이 되지 않는다면) 계
속 생존할 것이다. 리눅스/BSD 유닉스, emacs/Xemacs, sendmail/smail/qmail, qpopeer/imapd,
Qt/gtk, GNOME/KDE 등의 관계가 그러하다 ]
- 개발자들은 가장 큰 OSS 플랫폼에 공헌하려 한다.
- 큰 OSS 프로젝트는 더 많은 문제들을 풀 수 있다.
장기적인 신용
장기적인 신용은 빠른 시일 내에 사업을 그만두게 할 수 없을 때 존재한다. 이는 경쟁자들이 여러
분을 다루는 방법을 바꾸도록 강요한다.
{ 여기서 쓰인 '사업을 그만두게 하는'이라는 말에 주의하자. MS는 다른 회사들을 파산하게 하는
것이 단순히 '부차적인 피해' - 더 좋은 물건을 팔아서 얻는 부산물 - 가 아니라 직접적인 사업 목
적으로 믿는다. 이를 잘 살펴보면, 경제 이론과 전형적인 정직한 고객 위주의 사업자는 사업을 자
동차 경주 - 가장 훌륭한 드라이버가 탄 가장 빠른 차가 우승하는 - 으로 생각하지만, 마이크로소
프트의 관점은 사업을 죽음의 경마 - 될 수 있으면 많은 경쟁자를 쓰러뜨리는 - 으로 생각하고, 경
쟁자가 서로를 없애려 하여 결국은 그들 자신을 파멸하게 하도록 만들려 한다는 것이다.... }
OSS는 장기적인 신용이 있다
OSS시스템은 소스 코드가 수많은 사람과 장소에서 이용 가능하므로 장기적인 신용이 있는 것으로
생각할 수 있다.
... 아파치가 사라질 가능성은 WordPerfect가 사라질 가능성보다 훨씬 낮다. 아파치가 사라진다는
것은 바이너리의 소멸(구매 변동에 의해 영향받는)에 얽매인 것이 아니라 소스 코드와 지식 기반이
사라진다는 것을 의미한다. 역으로 말하면, 고객들은 아파치가 지금부터 5년 정도는 남아있을 것이
라는 사실을 알고 있다 - 그 사용자/개발 사회에 관심있는 사람이 남아있는 한.
병렬 디버깅
리눅스와 다른 OSS 지지자들은 점진적으로 OSS 소프트웨어가 적어도 상업적인 대체품 이상이라는
신뢰할 수 있는 주장을 하고 있다. 인터넷은 OSS 세계의 이상적이고 넓은 시야로 바라볼 수 있는
진열장을 제공한다.
{ 기술 마케팅 비즈니스에서 몇몇의 전문가들이 운영하는 수백만 달러의 선전 기구에 비해, OSS개
발자 대부분은 보수를 받지 못하고 남는 시간에 일하는 많은 아마추어들이다. 그리고 이들 아마추
어들은 "점진적으로 신뢰할 수 있는 주장을 하고 있다". }
특히 비즈니스에서 OSS에 의존하는 크고 지각 있는 조직은(예. ISP) 작업을 정지할만한 버그를 상
업적인 제공자의 스케쥴에 관계없이 고칠 수 있다는 사실에 안도하고 있다(예를 들면, UUNET은 첫
번째 teardrop 공격이 있는 후 24시간 내에 자신들이 갖고 있는 리눅스 기계에 공격에 대한 패치를
다운로드받아 컴파일해서 적용할 수 있었다).
병렬 개발
잠재적인 개발자의 수가 많으므로, 동시에 여러 가지 해결책을 개발하여 결국 가장 좋은 방법을 선
택하는 것이 경제적으로 이득이 있다. 예를 들면, 리눅스 TCP/IP 스택은 적어도 3번 이상 다시 쓰
여졌다. 특히 어셈블리 코드부가 계속적으로 조정되고 세밀화되고 있다.
OSS = 완벽한 API의 전도/문서화
OSS의 API 전도/개발자 교육은 기본적으로 개발자에게 코드를 제공하는 것이다. ... "열정적인 개
발자"는 OSS식의 전도에 안도하는데 비해, 초보/중급 개발자들 - 개발자 사회의 대다수 - 는 신뢰
모델 [닫힌 소스 개발 모델이 제공하는 정해진 API] + 조직의 신용을 더 좋아한다. (예. '마이크로
소프트는 API X를 이렇게 정의했다')
{ 대부분의 개발자들이 '신뢰' 모델을 좋아하는가 아닌가는 아주 흥미있는 질문이다. 이 방면에서의
20여년간의 경험은 나에게 그렇지 않다고 말한다. 일반적으로, 개발자는 그들의 기술을 잘 모르는
상관이 '신뢰'를 더 좋아할 만큼 순진한 경우에도 코드를 더 좋아한다.... }
릴리즈 빈도
잘 컴포넌트화한 OSS 프로젝트는 개발자가 코드를 완료하자마자 컴포넌트를 릴리즈할 수 있다. 따
라서 OSS 프로젝트는 빠르고, 자주 릴리즈를 발표한다.
오픈 소스의 약점
OSS프로젝트의 약점은 크게 3부분으로 나눌 수 있다.
관리 비용
OSS프로젝트의 가장 큰 걸림돌은 프로젝트가 혁신적이 됨에 따라 커지는데 따른 관리 비용의 지수
적인 증가를 다루는 일이다. 이는 OSS 프로젝트가 발전하는 정도를 제한한다. OSS 프로젝트를 시
작하는 것은 어렵다. Eric Raymond는 ('성당과 시장'에서) 다음과 같이 말했다:
아예 처음부터 시장 스타일로 개발할 수 없다는 것은 자명하다. 테스크, 디버그 그리고 개서는
시장 스타일로 할 수 있다. 하지만 프로젝트를 시작할 때 시장 스타일로 시작하기는 매우 어렵
다. Linus는 그렇게 하지 않았다. 나도 마찬가지이다. 개발자들의 공동체는 초기에 실행시키면서
테스트할 수 있는 장난감이 필요하다.
과정에 관련된 이슈
반복 비용
OSS 과정의 핵심 중 하나는 상용 소프트웨어보다 더 빠르게 반복된다는 것이다(리눅스는 하루에
한번 이상 릴리즈를 했다고 알려졌다!). 그러나, 상용의 고객은 릴리즈가 좀 덜 되었으면 하고 바란
다.
{ ... 상용 리눅스 배포자들이 존재하는 이유가 그것이다 - 빠른 개발 과정과 그 모든 것을 따라가
고 싶어하지 않는 고객 사이를 중재하기 위함이다. 커널은 하루에 한번 이상 릴리즈될 지 몰라도,
래드햇은 6개월에 한번씩 릴리즈된다. }
비전문가의 피드백
리눅스 OS는 최종 사용자들이 개발한 것이 아니라 다른 해커들이 만들었다. 비슷하게, 아파치 웹
서버도 부서의 인트라넷 서버가 아니라 거대하고 지각있는 사이트 관리자를 위해 만들어졌다. 여기
서의 주제는 OSS가 명시적인 마케팅/고객 피드백 요소, 희망사항을 갖고 있지 않으므로 더 기술적
으로 지각있는 사용자에 의해 결국 기능의 개발이 주도될 것이다는 사실이다.
{ 코멘트가 필요한데 - 이론상으로는 맞지만 실제적으로는 전혀 맞지 않는다. 이 잘못은 UI(사용자
인터페이스)를 강조하고자 하는 (마이크로소프트의) 전략의 약점을 드러낸다.
[ 사용상의 편리함을 "처음부터" 만들어내는 두가지 방법이 있다. 하나는 마이크로소프트 스타일로
UI에 의해 주도되는 단일 어플리케이션을 만드는 것이며, 두 번째는 유닉스/인터넷/웹의 방식처럼
엔진과 UI를 분리하는 방법이다. UI와 엔진이 결합되면 처음에는 사용자 편의적으로 보일지 몰라도
개발이 더디고 버그를 발견하기가 쉽지 않으며, 엔진을 분리하면 서로 별도의 발전이 이루어지고
한 엔진에 두 인터페이스를 가질 수도 있다 - linuxconf를 생각해 보라 ] }
조직의 신뢰성
어떻게 OSS가 소프트웨어 공급자들에서 고객이 기대하는 것과 같은 서비스를 제공할 수 있는가?
지원 모델
제품 지원은 전형적으로 OSS패키지의 고객이 걱정하는 첫 번째 이슈이며 상업적인 재배포자들을
권하는 기본적인 특징이기도 하다.
그러나, OSS프로젝트의 대다수는 해당 컴포넌트의 개발자에 의해 지원된다. 이 지원 기반 구조를
상업적 제품이 지원하는 수준까지 확대하는 것은 대단한 도전일 것이다.
{ ... 이 두가지 가능한 설명은 별도지만 동시에 실행 가능한 오픈 소스 지지자들의 전략을 나타내
어 준다. 하나는 소프트웨어는 잘 만들어서 별로 지원이 필요 없도록 하는 것이며(이미 그렇게 해
오고 있다), 다른 것은 하고 있는 작업을 지원 메일링 리스트, 뉴스그룹, FAQ 등 비공식적이지만
아주 효율적인 채널을 통하여 집중적으로 하는 것이다. ... }
전략적인 미래
OSS프로젝트의 전체 규모를 고객이 받아들이는데 영향을 미치는 아주 큰 문제는 OSS 개발 사이클
에 있어서의 전략적 방향이 부족하다는 것이다. OSS제품의 현재 기능의 점진적인 발전은 신용할
수 있지만, 미래의 기능은 그 개발을 보장하기 위한 어떤 조직적인 약속이 없다. [ 신제품 로드맵
발표 등 ]
{ 아니다. 오픈소스 사회에서, 새 기능은 진기함과 자신만의 영역을 찾는 개개인의 해커에 행동에
의해 주도된다. 이는 분명히 경멸받을 것이 아니다. 인터넷과 웹은 이렇게 만들어졌다 - "조직적인
약속"이 아니라, 어디서, 누군가가 "아 - 이거 좋겠는데..."라고 생각하였기 때문이다. }
오픈 소스 비즈니스 모델
지난 2년간, OSS는 OSS소프트웨어를 파는 회사의 등장으로 급진전하였다. 그리고 더 중요한 것은
코드 베이스를 발전시키기 위해 전일 근무하는 개발자를 고용한다는 것이다. 이 사람들의 급료를
정당화하는 비즈니스 모델은 어떤 것인가?
많은 경우, 이 질문의 답은 "왜 내가 내 프로토콜/API/어플리케이션을 표준위원회에 내야 하는가?"
와 비슷하다.
이차(secondary) 서비스
OSS관련 벤더는 고객에게 판매, 지원, 통합 기능을 제공한다. 이는 효율적으로 OSS 벤더를 패키지
제조자에서 서비스 제공자로 바꾸어 준다.
염가 매출 - 시장 진입
염가 매출 OSS 비즈니스 모델은 두가지 목적으로 사용할 수 있다:
- 초기 시장을 만드는 것
- 닫힌 소스 개발사의 기존 시장을 파고들기
많은 OSS의 시작 - 특히 운영체제 분야에서 - 은 OSS 제품의 개발에 투자하는 것을 마이크로소
프트에 대한 전략적인 방법으로 본다.
래드햇, 칼데라 등의 리눅스 배포사들은 OSS 사회에 모든 작업을 릴리즈하는 전일 근무 개발자들
에게 비용을 대어 준다. 이런 노력에 동시적으로 투자하여, 래드햇과 칼데라사는 서로 직접 경쟁하
기 보다는 결탁하여 리눅스 시장을 성장하도록 하여 단기적인 수입을 얻을 수 있을 것이라 믿고 있
다.
다운스트림 공급자들을 공유화
이는 염가매출 비즈니스 모델과 깊은 연관이 있다. 그러나 시장을 크게 성장하여 얻는 주변적인 서
비스를 얻으려 하는 대신, 이 비즈니스의 성장은 다운스트림 공급자들을 공유화하여 가치의 연결을
얻도록 한다.
현재의 가장 좋은 예는 Whistle Communications와 Cobalt Micro사와 같은 경량 서버(thin server)
벤더이며, 이들은 SAMBA와 리눅스에 각각 개발자들을 활발히 지원하고 있다.
선수를 치다 - 당장 만들고, 돈은 나중에
OSS의 지수적 성질 중 하나인 - 성공적인 OSS 프로젝트는 그 중 덜 성공적인 것을 흡수한다 -
는 오늘날 OSS에서 직접 투자하는 선점형 비즈니스 모델을 보여준다. 이들은 이후에 경쟁적인 프
로젝트를 선점하고 제거할 수 있다 - 특히 프로젝트가 API 전도를 필요로 할 때. 이는 OSS에서 선
수를 치는 것에 대한 장점을 얻는 것과 같다.
리눅스
[ 지금부터의 세 장은 알려진 가장 큰 규모의 OSS 프로젝트 중 세가지에 대한 분석이다. 역사나
특징 같은 것은 생략하기로 하고, 각각 프로젝트에 대한 MS의 생각을 중심으로 알아보자. ]
리눅스는 실제로, 신용할 수 있는 OS + 개발 과정이다
다른 OSS 제품과 마찬가지로, 리눅스의 진정한 열쇠는 제품의 정적인 버전이 아니라 이를 둘러싼
과정이다. 이 과정은 고객의 리눅스에 대한 투자에 신용과 미래의 안전을
보장한다.
- 미션 크리티컬한 환경에서 믿을 수 있음
- 리눅스 = 최고의 유닉스
- 시장을 확대하고 있는 유일한 유닉스 OS
- 개발 과정은 매우 빠르게 반복된다
리눅스는 서버에서의 단/중기적인 위협이다
마이크로소프트가 직면하는 기본적인 위협은 NT서버에 대한 리눅스이다. 리눅스의 NT서버(그리고
다른 유닉스)에 대한 미래의 강점은 여러 가지 요소로 나누어 볼 수 있다
- 리눅스는 일반 PC 하드웨어를 쓰고 모듈화 덕분에 NT 보다 낮은 시스템에서 운영할 수 있다.
- 유닉스를 이어받았기 때문에, 리눅스는 어떤 조직에서는 NT보다 낮은 전환 비용이 든다.
- 유닉스의 NT에 대한 확장성, 상호 운용성, 가용성, 관리성(SIAM)의 장점
- 리눅스는 서비스/프로토콜이 표준인 한 이길 수 있다.
{ ... 달리 말하면, 마이크로소프트는 서비스가 폐쇄적이고 프로토콜이 복잡하고 불투명해야 이길
수 있다. 조금 다르게 말하면, "표준" 서비스와 프로토콜은 고객에게 좋은 것이다. 이는 경쟁과 선
택을 촉진한다. 그러므로, 마이크로소프트가 이기기 위해서는 고객은 패배해야 한다. ... }
리눅스는 데스크탑의 위협은 되지 않을 것이다
- 빈약한 최종 사용자 어플리케이션과 초점: OSS 개발 과정은 최종 사용자의 편리성과 같은 점을
통합하기 보다는 개개의 컴포넌트 이슈를 푸는데 더 잘해 왔다.
{ ... 이는 실제로 리눅스의 데스크탑에서의 발전을 저해하는 요소였다. 그러나 계속 그러리라고 보
지는 않는데, GNOME이나 KDE가 성숙해질 때가 올 것이기 때문이다 }
- 설치된 데스크탑 기반을 전환하기: 데스크탑을 전환하는 것은 어렵고 도전하는 사람은 큰 장점이
있다는 사실을 증명할 수 있어야 한다.
- 유닉스의 유산이 침략을 늦출 것이다: 사용하기 쉬운 것은 처음부터 개발해야 한다 [ MS의 UI와
어플리케이션의 통합적인 방법을 말하고 있음 ]. 리눅스의 해커 지향은 결코 평균적인 데스크탑 사
용자에게 사용하기 쉬운 요구사항을 제공하지 않을 것이다. [과연 그럴지 여러분 스스로 생각해 보
기 바란다 ]
리눅스를 이기기
- 유닉스를 이기기 - NT 대 Sun의 모든 표준 제품 이슈는 리눅스에게 적용된다.
- 표준 프로토콜에 확장된 기능을 추가하고 새 프로토콜을 만든다
[ 이는 프로토콜의 비표준화와 같은 이야기이다. 나중에 다시 보게 될 것이다 ]
넷스케이프
조직과 라이센스
넷스케이프의 조직과 라이센스 모델은 리눅스 사회와 GPL에 약간의 기반을 두고 있다. 먼저, 모질
라와 넷스케이프 커뮤니케이터는 넷스케이프의 엔지니어가 동기화를 제공하는 두 코드베이스이다.
GPL과 달리, 넷스케이프는 모질라 코드베이스의 변경을 받아들이고 강제할 수 있는 권한을 가졌으
며 넷스케이프의 엔지니어가 큰 컴포넌트의 "영역 관리자"로 임명되어 있다.
강점
다른 OSS 프로젝트에 비해, 모질라는 마이크로소프트에 대한 가장 직접적이고 단기적인 공격 중
하나로 생각된다. 이 요소 하나가 아마도 모질라 코드베이스에 대한 개발자의 동기를 일으키는 요
소일 것이다.
가려운 곳을 긁어줌
브라우저는 널리 사용되고 퍼지고 있다. 따라서 "직접 문제를 해결하고" 버그를 잡아 줄 사람의 영
역은 매우 크다.
약점
모질라는 이미 IE4/IE5에 근접해 있다. [ 따라서 개발팀을 활발하게 움직이게 하기 위한 강력한 동
기가 없다. ] 넷스케이프는 일부 최고 개발자들을 모질라 코드베이스를 관리하는 작업에 전일로 종
사시키고 있으며, 이것이 모질라를 새 땅에 정착시키는데 얼마나 도움이 될 지 지켜보는 것도 흥미
있을 것이다.
좁은 인지권(noosphere)
[ 이 브라우저를 위해 남아있는 영역은 그리 많지 않다. 그 이유로서는 1. 기본 브라우저는 이미
종료되었고 2. 넷스케이프의 상업적인 관심이 인지권에 대한 공헌의 효과를 감소한다는 것이다. ]
통합 비용
아마도 모질라의 가장 큰 손해는 사용자가 브라우저에 기대하는 기능에 대한 통합 수준일 것이다.
이전에도 말했듯이, 통합 개발/검사는 병렬화 가능한 활동이 아니며 OSS 과정이 이를 해칠 수도
있다.
아파치
강점
시장 점유율!
아파치는 현재 인터넷의 최고 웹사이트 점유율의 서버이다. 시장의 주도적인 소유는 시장의 발전에
아주 강력한 영향력을 행사할 수 있다.
특히, 아파치 웹서버의 시장 점유율은 다음과 같은 경쟁 장애물을
보여준다:
- 최소한의 공통 분모의 HTTP 프로토콜 - 프로토콜을 확장하여 새 어플리케이션을 지원하려는 우
리의 노력을 감소시킴
- 유닉스에 더 생명을 불어넣음 - 아파치가 가는 곳에는 유닉스가 따라간다
약점
성능
단기적으로, IIS는 SPECweb에서 아파치보다 나은 성능을 보인다. 더 나아가면, IIS는 커널로 이동
하고 NT와의 더 깊은 통합의 장점을 누릴 수 있으므로, 이 차이는 더 커질 것이다.
반대로, 아파치는 모든 OS 환경에서 호환되는 코드를 만들어야 하는 요구사항을 만족해야 한다.
HTTP 프로토콜 복잡성과 어플리케이션 서비스
아파치가 근거지를 갖고 도약할 수 있는 이유중 하나는 HTTP프로토콜이 아주 간단하기 때문이다.
더 많은 기능이 웹서버 위에 추가되면(예. 멀티서버 트랜젝션 지원 등등), 아파치 팀이 따라올 수
있는지 보는 것도 흥미로울 것이다.
다른 OSS 프로젝트
이외에 큰 OSS프로젝트로는 GIMP, WINE/WABI, PERL, BIND, Sendmail, Squid, SAMBA, KDE,
Majordomo등이 있다.
마이크로소프트의 대응
[이 부분은 지금까지의 분석 결과를 바탕으로 마이크로소프트가 취할 수 있는 대응전략에 대한 글
이다. ]
제품의 취약성
가까운 장래에 OSS 프로젝트의 "위기"를 느낄 만한 곳은 어디일까? 서버가 클라이언트보다 OSS
제품에 취약하다. 그 이유는 다음과 같다:
- 클라이언트는 자주 "작업을 바꾼다": 평균적인 데스크탑은 서버보다 더 넓은 폭의 어플리케이션
을 사용한다. 따라서 통합, 사용하기 쉬움, 알맞음 등이 중요한 요소가 된다.
- 서버는 더 특정한 작업을 위한 것이다: OSS 제품은 목적과 전례가 명확히 정의된 경우에 가장
잘 동작한다 - 예. 표준 프로토콜의 지원
- 표준 서버들은 클라이언트보다 낮은 위임성을 갖는다: 파일, 프린트, 전자우편 릴레이 등을 오픈
소스 대체품으로 사용하는 것은 최종 사용자를 방해하지 않는다 [ 클라이언트만 사용하므로 ].
OSS의 장점을 취하자 - 개발자 의식
OSS 과정에서 인터넷의 수천명의 IQ를 집합적으로 모으고 동력화하는 능력은 놀라울 뿐이다. 더
중요한 것은, OSS의 전도는 우리의 전도 노력이 커지는 것 보다 훨씬 빠르게 인터넷의 크기와 함
께 커지고 있다. OSS제품에 맞추어진 개발자 의식의 일부를 잡으려면
어떻게 해야 하는가?
- 더 넓은 코드 라이센스를 하여 병렬 디버깅의 이득을 얻는다: 대학기나 특정 파트너에게 NT의
소스코드 라이센스를 주는 것에 좀 더 관대해진다
- 저가나 무료로 진입단계 도구를 제공한다: 도구의 2차적인 효과는 개발자들에 의해 유지되는 공
통적인 기술/용어를 만들어내는 것이다. [리눅스는 이런 면에서 충실하다]
- 소스 코드의 일부를 내놓자: MS가 스폰서를 하는 코드 베이스에 가치를 부가하는 것에서 해커의
흥미를 느끼게 한다.
- 더 나은 확장성을 제공한다: 리눅스의 "열정적인 개발자"는 문서화되지 않은 API와 내부를 이해
하고 문서화하기를 좋아한다. 이런 내부 API를 "지원 없음"으로 문서화해 두는 것이 외부에서의 혁
신을 만드는 수단이 될 수 있다.
- 사회/인지권을 형성한다: [ MSDN과 같은 큰 조직을 개발자의 자아 만족을 달성하기 위해 활용
한다 ]
- OSS 뉴스그룹을 모니터링한다.
OSS의 장점을 취하자 - 마이크로소프트 내부 과정
- 다른 개발 "모드": NT 컴파일/개발 환경은 아주 복잡하고 오피스 팀에서 사용하는 환경과도 다르
다.
- 다른 도구/소스코드 관리자
- 중심 저장소/코드 접근
- 폭넓은 개발자간의 의사소통: 특정 컴포넌트나 버그 리포트를 다루는 메일링 리스트는 일반적으
로 팀 멤버만이 볼 수 있다.
- 컴포넌트를 튼튼하게 만들기: 리눅스와 다른 OSS 프로젝트는 개발자들이 작은 컴포넌트를 시험
하기 쉽도록 한다.
- 통합
- 반복 비용과 의존성
OSS의 장점을 확장하자 - 서비스 기반 구조
플랫폼과 개발자 사회를 지원하는 것은 OSS가 제공할 수 없는 많은 서비스이다. 여기에는
MSDN(MicroSoft Developer Network), ISV(Independent Software Vendor), IHV(Independent
Hardware Vendor)등이 포함된다.
OSS의 공격을 무디게 하기
일반적으로, 마이크로소프트는 OSS프로젝트의 핵심적인 약점을 공격하여 이길 수 있다.
프로토콜과 어플리케이션을 비표준화하기
OSS 프로젝트는 잘 표준화되고 단순한 프로토콜을 폭넓게 이용할 수 있기 때문에 많은 서버 어플
리케이션에서 근거지를 얻을 수 있었다. 이 프로토콜을 확장하고 새로운 프로토콜을 개발하여, 우
리는 OSS 프로젝트의 시장 진입을 거부할 수 있다. 이를 위해서 마이크로소프트는 다음과 같은 일
을 할 수 있다.
- DNS와 디렉토리 서비스의 통합
- HTTP-DAV: HTTP-DAV는 복잡하며 여러 가지 어플리케이션에서의 무한 수준의 구현 복잡도를
제공한다. 아파치는 구현해야 할 올바른 DAV의 분야를 선택하는 일이 상당히 어려울 것이다.
{ 아이러니하게도, 할로윈 I의 발표 4일 뒤에 Greg Stein은 아파치에서의 HTTP-DAV의 오픈 소스
소프트웨어 지원을 발표하였다! }
- 구조화된 저장소: [ 파일 저장 공간을 기존의 FAT/NTFS가 아닌 새로운 저장 서버로 대체한다 ]
- 분산 어플리케이션을 위한 MSMQ: MSMQ는 대부분의 가치가 서비스와 구현에 있으며 프로토콜
에 있지 않은 분산 기술의 좋은 예이다. 같은 것이 MTS, DTC, COM+에도 적용된다.
- 시스템 관리
- 사용하기 쉬움
- 시나리오 해결: ZAW(Zero Administration Window), 전화접속 네트워킹, 마법사 등등
- 클라이언트 통합: 어떻게 클라이언트 베이스를 서버에서 유사한 통합 요구사항을 제공하도록 조
정할 것인가?
- 미들웨어 제어는 중요하다
할로윈 II: 리눅스 OS의 경쟁적 분석: 새로운 자바 VM인가?
할로윈 II는 리눅스에 대한 이야기이다. 앞서 할로윈 I이 전반적인 오픈 소스의 개발 과정과 시장에
서의 의미를 다루었다면, 할로윈 II는 리눅스에 대한 전반적인 분석(역사, 구성, 상업적 형태, 다른
OS와의 비교)를 다루고 있다. 이 문서는 할로윈 I이 발표된 뒤 며칠 후에 입수되었고, Eric이 마찬
가지로 비평을 곁들여 발표하였다. 이 글을 쓴 사람은 할로윈 I의 저자인 Vinod Valloppillil과 Josh
Cohen이다.
리눅스에 대한 정보는 다른 곳에서도 쉽게 접할 수 있고, 또한 오픈 소스에 대한 내용은 할로윈 I과
상당히 겹치는 부분이 있어서 자세한 내용은 생략하겠다(이 글을 읽기 전에는 반드시 할로윈 I을
읽어보아야 한다). 하지만 이 글 중 재미있는 부분이 몇가지 있는데, 그 글을 쓴 마이크로소프트의
엔지니어가 리눅스를 실제로 설치해 보고 쓴 경험담과, 리눅스와 다른 OS와의 비교이다. 이 두 부
분만을 발췌해서 보도록 하자.
리눅스 품질 평가
[ 여기에서는 이 글을 쓴 저자가 직접 리눅스(칼데라 오픈리눅스 1.2)를 설치하면서 쓴 경험담이다.
이 사람은 유닉스에는 비교적 초보인지, 일반적으로 사용자가 겪을 수 있는 실수까지 해 가면서 보
통사람의 리눅스 설치 과정을 잘 따라했다. DHCP 네트워킹을 가능하게 하기 위해 종종 웹과 FAQ
등을 찾아보기도 하는데, 큰 어려움은 없었다고 말하고 있다. 이 사람의 이야기를 조금 발췌해 보
겠다. ]
- 보통의 생각과는 달리, 오픈 소스이지만 나는 핵심적인 기능을 동작시키기 위해 "C"코드를 건드
릴 필요는 없었다. [ 이사람은 무슨 이야기를 잘못 들은 모양이다 ]
- (DHCP클라이언트) 드라이버의 저자와 문서의 저자는 서로 다른 지역에 사는 사람이었다.
- GPL+점진적인 향상 과정은 이미 케이블 모뎀/ADSL을 동작 가능하게 하고 있었다.
- 중요한 것: 할로윈 I에서 - "적당한 정도의 기술을 가진 유닉스 프로그래머는 리눅스와 많은
OSS 제품에서 큰 일을 해내도록 성장할 수 있다." 나는 초보 유닉스 프로그래머지만 어떻게 DHCP
클라이언트를 점진적으로 확장해야 하는지 금방 알 수 있었다(그 느낌은 상쾌하고 유혹적인 것이었
다) [ 여러분은 이런 느낌을 가진 적이 없는가? ]
리눅스와 다른 OS와의 비교
그림: OS의 전반적인 만족도를 계산하였을 때, 리눅스가 가장 높은 점수를
받았다. 리눅스는 9가지 테스트 중 7가지에서 1등이었으며, 기능성과
성능에서 DEC에 이어 2위를 차지했다(DataPro 의 연구 결과).
리눅스 vs NT
- 맞춤성(costomization): 끝없는 리눅스의 맞춤성은 - GFLOP 클러스터 워크스테이션에서 500K
램의 486기반 DNS서버까지 다양한 - 리눅스를 "고립된, 단일 작업의" 서버(DNS, 파일, 전자우편,
웹 등)에서의 매우 자연스러운 선택이 되도록 한다. 잘 밝혀진 내부구조와 밀접하게 연관된 엄격한
어플리케이션과 OS 컴포넌트화는 리눅스를 이상적으로 만든다.
- 가용성/신뢰성: 1년 이상이나 계속적으로 서비스하는 리눅스에 대한 이야기를 웹에서 많이 볼 수
있다. 안정성은 리눅스 개발 사회의 첫 번째 목표이다(그리고 윈도의 알려진 첫 번째 취약점이다).
- 확장성/성능: 리눅스는 네트워킹에서 NT보다 빠르다고 알려져 있으며, 특히 서버 프로세스에서
리눅스의 모듈 구조는 관리자가 그래픽이나 다른 시스템을 끄고 특정 서비스를 위해 최대의 성능을
낼 수 있도록 해 준다.
- 상호 운용성: 모든 공개된 프로토콜(그리고 많은 비공개 프로토콜도)은 리눅스에 포팅되었다. 윈
도 환경에서, SAMBA팀의 작업은 리눅스를 NT 도메인 콘트롤러/파일 서버로 동작하도록 한다.
리눅스 vs 자바
- 리눅스 개발자는 Sun의 자바에 대해 조심스럽다. 대부분의 자바를 향한 회의론은 Sun의 언어에
대한 엄격한 제어 - 그리고 OSS의 부족에 대한 것이다.
- 리눅스 공동체는 Sun이 리눅스 플랫폼을 언어 시작때부터 첫 번째 포팅 플랫폼으로 해 줄 것을
요청했다. 그러나 Sun은 리눅스용 JDK를 지원하지 않는다.
{ 이 상황은 변하기 시작했다 }
- 흥미있는 것은, 리눅스 JDK를 개발하기 위해 여러 리눅스 개발자들이 NDA가 포트를 개발하도록
했다는 사실이다(http://www.blackdown.org). 이런 압력은 http://www.kaffe.org를 포함하여 여러
가지 OSS JVM(자바 가상 머신)의 클론을 낳았다.
리눅스 vs SunOS/Solaris
리눅스 공동체는 Sun에 대해 양면의 감정을 가진다. 한편으로는 마이크로소프트에 대한 영향력 있
는 비평가로, Sun은 칭송되었다. 다른 한편으로는 유닉스 세계의 가장 명백한 척도인,
Solaris/SunOS를 능가하도록 만드는 것은 이전 리눅스 해커가 좋아하던 일이었다.
Lmbench OS 벤치마크에서 리눅스는 SunOS를 x86뿐 아니라 Sun 하드웨어에서도 네트워킹, 콘텍
스트 스위칭 시간, 디스크 입출력 등등에서 나은 것으로 나타났다.
(http://www.caip.rutgers.edu/~davem/scoreboard.html)
... Sun은 최근에 솔라리스 바이너리를 비영리 목적의 기관에게 무료 라이센스를 주겠다고 발표했
다(http://www.sun.com/edu/solaris/index.html). 아마도 이는 리눅스로부터의 경쟁적인 압력 때문
일 것이다.
할로윈 III: 마이크로소프트의 "할로윈 메모"에 대한 반응
이 문서는 앞서 말한 대로 마이크로소프트 네덜란드 지사의 Aurelia van den Berg가 쓴 것이다. 개
인적인 할로윈 I에 대한 생각을 담고 있는데, Eric은 마찬가지로 꼼꼼하게 코멘트를 해 두었다. 하
지만 내용은 크게 뚜렷한 것이 없으므로 자세한 내용은 싣지 않겠지만, 시간이 나는 독자들은 한번
쯤 읽어보기 바란다.
요약과 전망
지금까지 할로윈 I을 중심으로 마이크로소프트의 OSS에 대한 분석과 전략을 보았다. 대부분의 잘못
된 점과 쟁점들은 Eric의 코멘트 속에 대부분 담겨 있는데, 한번 제일 문제가 되었던 점에 대해서
알아보자. 필자와 많은 사람들은 다음의 세가지가 핵심적인 내용이라고 보고 있다:
- 특정 회사보다는 그 과정을 목표로 삼아야 한다.
- 리눅스는 서비스/프로토콜이 표준적인 한 승리할 수 있다.
- 표준화된 프로토콜을 확장하고 새로운 프로토콜을 개발하여, 우리는 OSS 프로젝트의 시장 진
입을 거부할 수 있다.
이는 할로윈 I을 쓴 사람의 통찰력에서 얻을 수 있는 것으로, 지금의 오픈 소스 공동체 또는 마이크
로소프트 측에서 서로를 안좋게 보는 일은, 궁극적으로는 특정 회사나 소프트웨어가 아닌, 80년대
초에 발생하여 90년대 말에 전성기에 들어서고 있는 오픈 소스라는 사회적 현상에 대한 이해에서
비롯된 것이다. 초기에 FSF가 GNU시스템을 위해 커널을 제외한 나머지 부분을 만들고 있을 때부
터 오픈 소스(프리 소프트웨어라 불러도 된다)에 대한 관심은 있어 왔다고 말할 수 있다. 하지만 이
것이 인터넷이 급속도로 커짐에 따라 전세계 어디에서나 네트워크에 연결할 수 있는 환경만 되면
이 세계 규모의 협동 작업에 참가할 수 있도록 되었고, 이전 BSD로 대표되는 유닉스 해커들의 전
통이 살아남아 오픈 소스 스타일의 개발 환경이 널리 확산되게 되었다. 여기서 나온 산물은 바로
기본적인 리눅스 배포본에 포함되는 모든 것들이다(리눅스 커널, GNU유틸리티, XFree86 X윈도우
시스템 등등).
이는 주로 유닉스 환경 중심으로 이루어져 왔고, 80년대를 거치며 90년대가 되면서 윈도로 IBM호
환 PC를 장악한 마이크로소프트를 비롯한 거대 소프트웨어 회사는 오픈 소스와 마주칠 일도 없었
고, 그때는 소규모였고 기능도 완전하지 못했기 때문에 문제의 대상이 되지 않았다. 그러나 90년대
가 되어 리눅스를 비롯한 여러 소스가 공개된 유닉스들이 나타나고, 이들이 마침 WWW와 더불어
전세계로 퍼져나가는 인터넷과 함께 널리 퍼지게 된 것이었다. 마이크로소프트가 자신의 서버 환경
이 이런 PC용 유닉스와 동등한 위치에 있다는 것을 안 이후에야 오픈 소스의 상황이 마이크로소프
트를 비롯한 상업적 소프트웨어 회사를 위협하기 시작한 것이다.
필자는, Eric씨의 견해대로 "오픈 소스와 닫힌 소스와의 문제"라는 것에 동의한다. 해커식 문화에서
비롯된 오픈 소스가 학교나 개인이 심심풀이로 만드는 수준이 아니라 이제는 제대로 된 상업적인
소프트웨어 시장을(사실 시장을 위협하지 않았다면 그리 문제가 없었을 것이다) 잠식하기 시작한
것이다. 이런 갈등에 대한 증폭이 할로윈 문서라는 마이크로소프트의 내부 보고서를 낳았다고 생각
한다. 적어도 "특정 회사보다는 그 과정 자체를" 목표로 삼겠다는 생각은 오픈 소스에 대한 전략으
로는 아주 효과적이다. 그렇지만 그 수단이 "프로토콜/서비스를 비표준화하는" 것에 의존한다면 마
이크로소프트에게는 단기적인 효과는 있을지 몰라도 장기적인 효과는 없다고 보는 바이다.
모두가 알고 있듯이 마이크로소프트는 IBM-PC에 MS-DOS를 공급하면서, 그리고 이 IBM-PC(그리
고 호환기종)이 널리 팔리기 시작하면서 큰 부를 얻게 되었다. IBM-PC의 특징이라면 그당시 나오
던 다른 PC와는 달리 공개된 구조를 갖는다는 것이었는데, 이것이 IBM-PC의 큰 성공 요인이자,
MS-DOS의 성공 요인이 되었다고 본다(당시 비표준 인터페이스를 쓰던 애플의 몇몇 기종과 PS/2
의 폐쇄적인 MCA아키텍처는 실패하였다). 그런 마이크로소프트는 자신이 공개된/표준적인 서비스/
프로토콜에서 얻는 이득을 잘 알고 있을 것인데, 자신의 경쟁자를 제거하기 위해 비표준화의 방법
을 사용한다면 그 결과는 기대했던 것 만큼 좋지 않을 것이다. 이미 인터넷 익스플로러에서만 제공
하는 태그에 대해 W3C에서 HTML표준으로 받아들이지 않는 일이 종종 있었는데, 여전히 자사 플
랫폼의 익스플로러에서만 동작하는 스크립트나 비표준 태그를 권장하는 것은 궁극적으로는 비호환
성의 문제를 일으켜 시장에서 독점적인 지위를 얻지 못할 때 사장될 수도 있는 것이다(이점에 대해
서는 넷스케이프사의 네비게이터도 마찬가지이다). (하지만 현재로서는 익스플로러가 인터넷 표준에
더 충실하다)
오픈 소스는 그 역사가 해커 공동체에서 유래하기 때문에, 해커 중심(다시 말하면, 개발자 중심)의
프로그램 개발과 문서화가 이루어져 왔다. 이런 개발 방식이 실제적인 소프트웨어 시장에 들어가게
될 때에는 할로윈 I에서 몇번 지적한 바와 같이 일반 사용자에 대한 피드백의 배려와 지원 서비스
가 있어야 할 것이다. Eric씨는 이에 대해서 마이크로소프트의 잘못된 통합 UI 어플리케이션의 예를
들면서 그보다는 낫다고 했지만, 다른 상업적 소프트웨어 회사의 예를 볼 때 꼭 그렇지만은 않다는
생각이다.
라이센스
생각보다 라이센스는 까다로운 문제이다. 우리는 보통 오픈 소스 소프트웨어라면 그냥 자유롭게 사
용할 수 있는 것으로 알지만 해당 소프트웨어에는 저자의 의도대로의 저작권이 걸려 있다. 어떤 소
프트웨어를 고쳐서 재배포하고 싶을 때에는 그런 점에 주의하는 것이 좋을 것이다. GPL의 장점은
한번 GPL로 공개가 되면 언제까지 GPL로 남게 된다는 점에서 오픈 소스 공동체에는 유익하지만,
오픈 소스 코드 일부를 상업적 소프트웨어에 사용하고 싶은 경우에는 BSD에서 파생된 라이센스를
따르는 코드를 사용해야 한다. 같은 4.4BSD기반이지만 FreeBSD는 공개 소프트웨어이고 BSDI는
상업용 소프트웨어이듯이, XFree86이나 BSD계열 운영체제의 코드는 자유롭게 상업적 소프트웨어
에 사용할 수 있다는 점에 유의하기 바란다(대부분의 TCP/IP 스택과 소켓 라이브러리 코드가 가장
처음에는 BSD코드였다는 점을 생각해 보면 모든 상업/비상업적 소프트웨어가 소켓을 사용할 수 있
게 되었다는 사실이 그 유연한(FSF의 입장에서 보면 '너무 자유로운') 라이센스에 있었다는 것을
알게 될 수 있을 것이다).
할로윈 문서에 대해 BSD공동체에 이야기할 때에는, BSD라이센스의 특성상 MS가 이 코드를 갖
고 MS-BSD라는 운영체제를 새로 만들 수 있다는 이야기도 한 적이 있다. 우스개소리가 아니라 실
제로 그럴 수 있다. (하지만 BSD기반 운영체제는 GPL하의 여러 프로그램(gcc, gdb, texinfo, gzip,
gmp)등을 사용하기 때문에 이 부분만은 소스를 공개해야 한다).
마이크로소프트는 악인가
오픈 소스 공동체에서는 마이크로소프트를 악의 화신처럼 생각하는 경향이 있는 것 같다. 종종 뉴
스그룹이나 메일링 리스트 등에서는 악의적이든 익살스럽게든 마이크로소프트가 주 공격 대상이 되
는 것을 볼 수 있는데, 사실 마이크로소프트에 대해 특별히 반감을 가질 필요는 없다. Eric씨의
"Homesteading on the Noosphere"에서는 이런 사람의 세가지 부류를 찾아볼 수 있다.
아주 비상업적인 사람은 "상업적인 소프트웨어는 도둑질한 물건을 모아둔 것이나 같아. 난 이 악
을 끝내기 위해 프리 소프트웨어를 쓰겠어" 라고 한다. 조금 비상업적인 사람은 "상업적인 소프트
웨어는 일반적으로는 프로그래머는 대가를 받아야 하므로 좋아. 하지만 겉만 번지르르한 제품을
팔고 거들먹거리는 건 악이야" 라고 한다. 전혀 비상업적이지 않은 사람은 "상업적인 소프트웨어
도 좋아. 난 그냥 내가 좋아서 오픈 소스 소프트웨어를 사용하거나 작성한다구" 라고 한다.
여러분은 어느 부류에 속하는가? GNU 선언문에서 언급하는 완전한 프로그래밍의 자유를 누리기
위해서는 우리는 상업적인 소프트웨어를 완전히 배제해야 한다(그것이 GPL이 그 파생물조차도
GPL을 따라야 한다고 정해놓은 이유이다). 하지만 공존하기로 생각한다면, 우리는 어느 정도 적절
한 입장을 취하는 것이 좋을 것이다. 이에 대한 자세한 내용은 FSF홈페이지의 "자유 소프트웨어에
대한 철학적인 생각들"에서 "마이크로소프트는 거대한 악마인가"라는 제목의 글을 읽어보기 바란다.
악이라면 상업적 소프트웨어 전체가 악이라고 말할 수 있는 것이다.
상업적 소프트웨어와 오픈 소스의 공존
마이크로소프트가 내부 문서에서 오픈 소스에 대한 자세한 조사를 실시하고, 오라클이나 IBM과 같
은 커다란 소프트웨어 회사들이 자사의 제품을 리눅스에 포팅할 만큼 오픈 소스는 이미 되돌릴 수
없는 현상이 되었다. 이 둘을 현명하게 공존할 수 있는 방법은 어떤 것이 있을까?
- 프로토콜/서비스의 표준화의 촉진
인터넷과 네트워크 서비스의 경우, 지금까지의 빠른 발전은 잘 정리되고 표준화된 프로토콜과 서비
스의 정의에 많은 덕을 지고 있다. 앞으로도 그런 현상이 계속되는 하에서 모든 서버/클라이언트
소프트웨어는 발전을 계속할 것이며, 최근에 늘어나는 미들웨어 서비스에 대해서도 마찬가지로 생
각할 수 있다. 사실 서버 소프트웨어는 자신만의 특정 프로토콜 지원으로 평가받기 보다는 널리 사
용할 수 있는 프로토콜을 잘, 그리고 성능 좋게 지원하는 것으로 평가되어야 하며, 일반 소프트웨
어는 그 기능으로 인정받아야 한다.
- 오픈 소스 사회에 대한 기여
이미 오픈 소스 기반으로 운영되는 회사들이 많이 있다. 미국과 유럽의 여러 리눅스 배포본 제작업
체가 그러하며, 고스트스크립트를 만드는 Aladdin Enterprises나 오픈 소스 운영체제를 사용하는 경
량 서버를 판매하는 Whistle Communications(이 회사는 FreeBSD기반의 Interjet라는 제품을 판매
한다)나 Cobalt Micro(리눅스 기반의 제품을 판매한다)등의 회사들이 여럿 생기고 있다. 우리나라에
서는 이런 변화가 이제 태동하는 단계이지만, 자신의 이익을 어느 정도 오픈 소스 사회로 되돌리는
방법을 사용한다면, 두 소프트웨어 공동체가 대립이 아니라 공존할 수 있는 좋은 방법이 되리라 본
다.
결론
할로윈 문서는 우리에게 최근의 오픈 소스 붐이 단순한 현상이 아니라 이제 당당히 소프트웨어 개
발의 한 방법으로 자리잡았다는 것을 알려 주었다. 그러나 모자란 점도 많이 있고, 오픈 소스라는
것 자체의 여러 다양성(주로 라이센스에 기인하는) 때문에 발생할 수 있는 여러 한계와, 상업적 소
프트웨어 개발사와 충돌하는 부분에 대해서도 충분히 이해할 수 있었다.
우리 입장에서 해 볼 수 있는 일은 이런 오픈 소스를 지원하는 일을 직접 해 보는 것이다. 간단한
것이라도 패치도 해서 제작자에게 보내 보고, 자신이 짠 조그만 유틸리티라도 형식을 갖추어서 네
트워크에 공개도 해 보는 것이다. 사람들이 오픈 소스 개발에 빠져들고 그런 일을 전문적으로 하는
회사도 생기는 것은 이 작업이 그만큼 매력적이고 생각하던 것보다 놀랍고 즐거운 일을 많이 만나
게 되기 때문이다. 자신의 능력이 부족하다고 생각하기보다는, 조그만 일부터 시작해 보는 것이 앞
으로의 즐거움에 초석이 될 것이라 믿는다.
May the source be with you...
참고 자료
$Id: index.shtml,v 1.1.1.1 2001/05/23 03:11:13 cjh Exp $
[
Home |
Freetime works |
FreeBSD |
KFUG
]
Copyright © 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006
CHOI Junho, all rights reserved.
Please send spam/UCE here to register your mail to razor
