오픈소스. 유지비용의 감소. (기업편)
오픈소스. 유지비용의 감소. (사용자편)
오픈소스. 유지비용의 감소. (사회편1)
오픈소스. 유지비용의 감소. (사회편2 – 결론)
0.
function __toggle_hide_zone10()
{
elm = document.getElementById(“hide_zone10”);
if(elm.style.visibility == ‘visible’) __hide_hide_zone10();
else __show_hide_zone10();
}
function __show_hide_zone10()
{
elm = document.getElementById(“hide_zone10″);
elm.style.visibility=’visible’;
elm.style.display=”block”;
}
function __hide_hide_zone10()
{
elm = document.getElementById(“hide_zone10″);
elm.style.visibility=’hidden’;
elm.style.display=”none”;
}
그냥 살아온 부분
해커문화를 접하게 된 건, 고등학교때 읽었던 몇권의 서적에서.
오픈소스를 접하게 된 건, 대학들어와 만난 모씨에 의해서.
처음 접하게 된 오픈소스는 모씨에 의한 영향인지 맑스와 연관되어 생각되기 시작했다.
FSF와 GNU, GPL에 의해 만들어진 신세계는 놀라운 것이었으며, 활발하게 활동하는 수많은 멋진 프로그래머들은 동경의 대상이 되어버렸다.
그리고, 사용.
과서버를 관리하기 시작한 뒤, 리눅스를 사용할 수 밖에 없게 되었고, Social Contract라는 멋진 약속을 표방하는 Debian을 만나게 되었다. (thx to 승준)
대부분이 영어권 사용자인 오픈소스의 세계에서 CJK문제를 만나게 되었고, 이를 해결하기 위한 유니코드를 만나게 되었으며,
w3c와 같은 표준안 제정 단체를 알게 되었다. 표준을 알면 알수록 독점적 지위에 의해 발생하는 안타까움을 알게 되었고, 이
안타까움은 일종의 신념으로 변했다.
CJK문제를 해결하기 위한 버그레포팅, 패치 제안 등을 하면서.
잡히지 않는 랜카드를 잡기 위해 커널소스를 분석하면서, 조금씩 발전하는 모습을 발견하곤 하였으며, 묘한 희열도 느끼게 되었다.
1. 견제.
MS는 이미 독점을 맛보았으며, 독점으로 얼마나 돈을 벌 수 있는지를 알고 있다. 한때, 기업시장(PC급 서버 및 그보다 조금
상위의 장비들)에서 윈도우NT의 비율은 Unix를 누르며 급격히 성장했으며 이 당시 리눅스는 상대도 안되는 것으로 치부하고
있었다. 그러나, 엔터프라이즈 리눅스를 표방한 2.4의 발표와 함께 진입하기 시작한 리눅스의 거센 공격에 MS는 초조함을 감추지
못하고 각종 언론에 노출되는 여러 문서들을 남기게 된다. (정확히 기억은 안나지만, 몇가지 되는 것으로 기억함)
리눅스를 견제하기 시작한 것이다.
얼마전, MS측에서 리눅스의 총소유비용(TCO)이 윈도우에 비해 크다고 주장한 적이 있다.
굉장하다. 핀란드의 한 프로그래머가 시작한 프로젝트가 MS에 의해 견제를 받는 지위까지 올라가다니.
물론, 실제로 발표된 논문은 그런 내용이 아니었다.
ZDNet 관련기사
MS는 자신들의 NT가 사용되고 있는 위치에서 리눅스에게 시장을 빼앗기고 싶어하지 않는다.
2. 기업입장의 유지비용
(1) 개발자를 잡기 위해서.
MS플랫폼 (뿐만 아니라 기타 상용 플랫폼) 을 사용하는 개발자들 중, 상용툴이나 플랫폼들을 돈주고 직접 구입해서 사용하는
개발자는 드물다. 사실 많은 수의 버그들이 개발자들이 개발을 하다가 발견하게 되는 경우가 많은데, 돈주고 사서 쓴게 아니므로
레포팅을 안하게 된다. (걸릴일 있습니까.. 버그 레포팅하게)
하지만, 오픈소스라면 다르다. 작업을 하다 버그사항을 발견하면 이를 직접 고쳐서 사용할 수 도 있고, 자신이 고친 내용을 해당
커뮤니티에 공개하고 다음 버젼에 적용시킬 수도 있다. 개발자에게 "자유"를 주는 것이다. 이 자유는 개발자가 마음대로 개발을 할
수 있는 토양을 제공해주며, 지원하는 해당 기업들에겐 자신들이 자사제품에 사용하고 있는 오픈소스 코드에 대한 관리/개발/유지
비용을 줄일 수 있다.
– 기업의 지원을 받는 많은 오픈소스 프로젝트들이 대부분 컨소시엄형태로 구성된다. 대표적인 사례가 IBM에서 오픈소스로 시작한
자바 개발툴인 Eclipse (http://www.eclipse.org) 프로젝트인데, 이에 참여한 기업들을 보면 손가락이
모자랄 정도의 숫자다. 각 기업들은 Eclipse의 기술을 자사제품에 적용시키고 있다. –
활발한 버그 레포팅과 이에 대한 능동적인 사용자의 패치시도, 적용 등은 오픈소스의 원동력이라고 할 수 있다.
(2) 기술지원 비용의 측면.
MS는 자사 웹서버인 IIS에 대한 기술지원을 위해 기술지원팀을 운영하며, 고객들의 전화에 머리가 아플지도 모르겠다. 대부분 돈주고 산 제품에 대해서는 전화해서 엄청나게 따져댄다. (직접 보고, 겪는 일입니다 ㅡㅜ)
하지만, ASF(Apache Software Foundation)도 그럴지는 의문이다. 아파치를 사용하는 사람들은 알아서 서로
기술지원을 해주기도 하고(주로 IRC?), 책도 사서 보고 공부도 하고, 정중하게 메일링리스트에 질문을 올리기도 한다.
(물론 대형 벤더들에서 만든 리눅스나 기타 유닉스에 포함된 아파치에 대해 각 벤더들에서 기술지원을 해주기는 한다.)
오픈소스 소프트웨어는 기술지원의 측면에서 상당히 자유로운 편이다. 해당 소프트웨어를 어떻게 사용하느냐의 문제는 전적으로
사용자에게 달려있기 때문이다. 물론, 메일링 리스트나, 게시판,매뉴얼 정도의 지원은 이루어진다. 이를 통해 해결되지 않는 것은
사람들끼리 서로 도와주거나, 자신이 직접 해결책을 찾아내야 한다. 이런 문제점은 아주 특수한 경우가 아니라면, 대부분 다수에게
발생하기 마련이고 누군가는 해결책을 찾아낸다. (대부분 개발자일 경우가 많죠.) 그리고, 이는 인터넷이라는 공간을 통해
축적된다. – 구글이 상당히 잘 찾아줍니다. 🙂 –
물론 오픈소스 소프트웨어에 대한 기술지원을 제공하는 회사들도 있다. 이는 어떤 보장을 원하는 대기업에 의해 파생된 부분이라고 볼
수 있는데, 대부분 해당 소프트웨어를 개발한 개발자들이 모여있는 회사에서 담당하는 경우가 많다. (일종의 부가사업?) 이때도,
일반적인 오픈소스 소프트웨어 사용자들의 지식이 농축되어있는 메일링 리스트나 게시판등을 효율적으로 활용할 수 있다.
대부분의 상용소프트웨어는 그 가격의 대부분이 기술지원비용이다. 돈 주고 사서쓰는 가장 큰 이유가 기술지원이기 때문이다. 하지만,
기술지원이 필요없을 정도의 인력이 존재한다면 굳이 기술지원을 받을 필요가 없다. 불필요한 비용이 발생하는 것이다.
회사라는 울타리를 넘어선 개발 – 기술지원의 분리와 협업은 분명 생산성 측면에서도 유리할 것이다.
ps. 다음편엔 사용자측면 – 결론.
