오픈소스. 유지비용의 감소. (사회편2 – 결론)
3. 사용자 입장의 유지비용 (능동적인 컴퓨터 사용 – 개발 프로세스와 개발 주기.)
사용자의 개입/참여/기여의 여부를 통해 유지비용의 차이를 보이려 한다. 더 깊은 내용을 원하시는 분에겐 에릭 레이먼드의 "성당과
시장"을 추천한다.
(1) 보안에 대한 대처
MS Windows를 써본 사람은 OS가 가진 버그에 의해 등장하는 많은 폐단들을 알 것이다. 인터넷이 일반화 되면서 전국의
인터넷을 마비시킬만한 트래픽을 만들어내는 웜이 등장하는가 하면, 압도적인 스케일의 쓰레기 메일을 양산하는 웜이나 심지어는 내가
원하지 않은 ActiveX 플러그인들이 컴퓨터에 설치되는 현상까지.
이러한 문제점들을 수정하기 위해서는 MS가 해결책을 내놓을때 까지 기다려야 한다. 백신같은 소프트웨어를 이용해서 임시방편으로
막을수는 있지만, 결국은 OS에서 해당 문제를 수정해야 한다. 사용자는 OS를 수정할 권한이 없으며, 따라서 MS측에서 문제를 해결해줄때까지 기다리는 수밖에는 없다.
다른 예로 많은사람들이 사용하는 M사의 F플러그인을 생각해보자. 일반적으로 이 플러그인은 사용자의 시스템에 별 영향을 미치지
않는 것으로 알려져왔다. 하지만, 만약 치명적인 버그가 발견되어 이 플러그인을 사용하는 사용자 시스템의 정보를 외부인이 마구
가져갈 수 있게되거나, 시스템을 파괴할 수 있게 된다면, 이 역시 M사에서 수정할때까지 기다릴 수 밖에 없을 것이다.
이러한 류의 보안 문제/버그는 보안 전문가 그룹, 혹은 보안 관련 업체에서 운영하는 연구소에서 사전에 발견하는 경우가
대부분이다. 해당 소프트웨어가 이런 문제에 대처하는데는 개발자가 이해하고 대처하는 시간이 소모된다. 이러한 점에서 볼 때, 상용
소프트웨어는 소프트웨어 개발 주기가 상당히 긴 편이며, 각 릴리즈의 텀 역시 길다. 오픈소스 소프트웨어의 경우는 빠른 릴리즈와
빠른 패치를 기준으로 하고 있다. 이러한 차이로 오픈소스 소프트웨어는 이런 종류의 문제에 있어서 좀 더 빠른 대치가 가능하다고
할 수 있다.
또한, 개발자가 놓칠 수 있는 보안 이슈나 버그등을 사용자가 찾아내서 제안할 수 있는 것은 당연히 가능한 일이다. – 물론, 보안 이슈같은 경우는 제안할 수 있는 사용자가 소수이긴 하지만. –
이러한 보안문제/버그 이외에도 사용성이나 UI설계같은 측면에서도 같은 형태의 적용이 가능하다.
(2) UI-사용성 측면
사용자가 특정 소프트웨어를 사용하다 불편한 점(주로 UI)가 발견되었을 경우, 상용소프트웨어는 자신의 불편함을 해당
업체(개발자)에게 피드백 주는 것이 상당히 힘들다. 불법 소프트웨어를 사용한다는 점도 있지만, 대부분의 사용자는 무언가 작동되지
않을 때 레포트를 하지 뭔가 불편할 때 레포트를 하지는 않는다. 그냥 주어진 대로 사용하는 것이다. 이는 해당 상용 소프트웨어의
개발자와 커뮤니케이션 채널이 거의 없다는 점이 크게 작용하며, 어떤 참여의식이 없기 때문이다.
하지만, 오픈소스 소프트웨어의 경우에는 상용 소프트웨어에 비해 개발자와의 커뮤니케이션 장벽이 낮은 편이다. 대부분의 프로젝트들은
IRC나 포럼 혹은 위키같은 사용자가 의견을 개진할 수 있는 채널을 열어두고 있기 때문이다. 이러한 채널을 통해 사용자는 해당
소프트웨어에 대해 참여의식을 가질 수 있으며, 뭔가 기여를 할 수 있게 된다.
물론, UI나 사용성의 경우에는 많은 비용을 들인 전문적인 연구가 필요하다. 이는 상용 소프트웨어에서만 가능한 것이 아니다.
2장에서 말했던, 기업이 오픈소스 프로젝트에 참여하고 이를 유지하는 과정에서 기업의 투자가 이쪽으로 적용될 수 도 있는 것이며,
기업 연구소의 연구인력이 이쪽으로 투입될 수 도 있는 것이다. 하지만 가장 중요한 것은 "사용자가 원하는 UI가 가장 편한
UI" 라는 점이다. 아무리 GUI가 발전해도 에디터는 vim이나 emacs가 제일 편하다고 여기는 해커레벨 사용자가 있는
것처럼.
(3) 기능 추가의 용이성.
상용 소프트웨어는 기능을 추가하는데 있어서 필요한 제반 사항이 인색한 편이다. 기능을 추가하는데 필요한 지식이 기업 비밀에
속하는 경우도 있으며, 기법이나 지식이 해당 회사에만 전승되는 경우도 있기 때문이다. 이러한 이유로 사용자가 기능을 추가하는데
어려움이 있다. 또한, (2) UI-사용성 측면에서 설명한 바와 같이 개발 프로세스에 사용자가 참여하는 것도 어려운 데서
기인하는 바도 크다.
오픈소스 소프트웨어는 대부분 소수의 개발자에서 출발하며, 이 경우 초기 개발자는 동료 개발자를 구하기 위해서라도 기능추가의
용이성이나 확장을 고려하게 된다. 초기의 구조/설계/코드가 이러한 상황에 적합하지 않더라도 결국은 이를 향해 진행되게 된다.
아파치의 경우를 볼 때, 초기에는 모듈 추가가 힘들었지만, DSO와 같은 동적 모듈 추가기법등이 등장하면서, 기능 추가가 쉽게
된 경우라고 할 수 있으며, PHP역시 유사한 케이스로 볼 수 있다.
에릭 레이먼드가 내놓았던 개념인 '성당'에서 개발되는 상용 소프트웨어보다 '시장'에서 개발되는 오픈소스 소프트웨어가 이런 면에서
강점을 갖는 것은 어쩌면 당연한 것일지도 모른다. 오픈소스 소프트웨어 역시 처음부터 '시장'인 것은 아니지만, 공개와 함께
'시장'에 나오는 것으로 볼 수 있다. 필자가 이 글을 쓰고 있고, 개발중인 오픈소스 소프트웨어인 PlayAction2 역시
현재는 '성당'에 있으며 곧 '시장'으로 나갈 예정이다. (사실 이 글을 읽는 분이 원하시면 바로 '시장'이 됩니다.
kldp.net에서 소스를 받아보고 의견을 주시면 되는거죠. ^^)
사용자의 개발 프로세스에 대한 참여와 빠른 개발주기는 오픈소스의 최대 장점이며, 사용자가 유지비용을 줄일 수 있는 길이다.
물론, 이러한 참여/기여가 사용자의 유지비용을 늘리는 것처럼 보일 수 있겠지만, 이러한 참여/기여를 통해 사용자 자신이 좀 더
자신이 원하는 방향의 소프트웨어를 사용할 수 있다는 점은 장기적으로 유지비용을 줄여준다고 볼 수 있다.
사용자의 참여/기여는 능동적인 컴퓨터 사용을 이끌어 낼 수 있으며, 오픈소스 소프트웨어가 상용 소프트웨어로 변질되는 것을 막는 좋은 방법이기도 하다.
– 원래는 여기서 결론을 내려고 했지만, 사회 전체로 볼 필요도 있을 것 같고 결론이 생각보다 길어질 것 같아 다음 편으로 미루렵니다. ^^ –
