오픈 소스 모델의 약점이나 반대 의견에 관한 글을

geekforum의 이미지

저는 최근 Open Sources: Voices from the Open Source
Revolution 책을 읽고 있습니다.
제가 막연히만 알고 있던 내용들을 확인할 수 있어서 좋고, 또 어떤 내용
들은 새로운 시각을 가지게 해주더군요.

그런데 읽으면서 책의 내용들이 너무 성공담에만 치우친 것이 아닌가 하
는 생각이 문뜩 들었습니다.
오픈 소스 모델을 적용했어도 성공적이지 못한 경우들도 있었을텐데 그런
부분에 관한 내용은 좀 찾기가 어렵더군요.

그래서 혹시 오픈 소스 모델을 적용해 실패한 경우와 이 때 어떤 부분이
실수로 작용했는지 논하거나 소개한 글이 있으면 추천해 주십시오.
그리고 오픈 소스 모델을 반대하는 사람들도 꽤 있으리라 생각됩니다.
이런 사람들의 글도 알려주시면 고맙겠습니다.
물론 직접 글을 올려주시면 더욱 좋겠습니다.

저도 현재 소프트웨어 산업에 패러다임이 바뀌어 가고 있다는 것을 인정하
지만 그 패러다임의 종착지가 오픈 소스 모델이 될 것인지는 아직 의문점
이 남아 있습니다.
그럼 좋은 답변들을 기대하겠습니다.

logout_의 이미지

제가 보기에 오픈 소스는 한마디로 벤처입니다. 분명히 working 하기는
하지만 성공 확률은 백에 하나가 드뭅니다. 대신에 제대로 성공하면
순식간에 전세계로 퍼져 나가 de facto standard로 자리를 잡는
장점이 있죠.

외국 오픈 소스 개발자들의 대부분이 part time으로 오픈 소스
소프트웨어를 만드는 것은 어찌보면 당연한 것입니다. 잘 되면
좋고 안되어도 별 탈이 없는 그런 일들을 오픈 소스로 밀어 부치는
것이 좋겠죠. 어차피 돈들 일이 거의 없으니까요. 특히 우리나라에는
바쁘게 사는 사람들이 대부분이다보니 '식음을 전폐'하고 오픈
소스에 달라붙으면 무엇인가 하나 해 낼 수 있다고 확신아닌
오해를 하는 분들이 가끔씩 있는데 조심해야 합니다. 오픈소스는
망하는 프로젝트가 99%입니다. 벤처보다 더 한 것 같아요.

오픈 소스로부터 또하나 배울 점은... 디지털 네트워크의 위력입니다.
솔직히 상품 하나 만드는 것보다 소프트웨어 하나 만드는 것이
쉽습니다... 어디 잡지에 기사를 읽다 보니까 제대로된 인터넷
사이트는 밤새는 프로그래머 대여섯명에 피자만 열심히 공급해주고
1년쯤 기다리면 만들어지게 되어 있다고 하던데 틀린 얘기는
아닌 것 같습니다. 공장짓고 라인 건설하고 유통망 확충하고
수요 예측 및 재고 관리할 필요가 없죠. :)

여기에 디지털 네트워크가 추가되면... 밤새는 프로그래머 없이
가끔씩 쉬는 시간에 해커들이 몇자 써 놓은 버그 패치를 네트워크로
모을 수 있습니다. mp3 같은 경우는 전세계 네트웍 이용자 중에서
너댓명만 cd를 떠버려면 아무리 희귀종이라도 네트워크로 퍼지게
되어있구요. 예전에는 버리고 까먹어 버리는 자원, 혹은 노동을
써먹을 수 있는 방법이 생긴거죠.

줄이자면 세상이 이렇게 바뀌는 까닭에 새로운 가능성이 열린 겁니다.
대신 성공확률은 높아지긴 했지만 믿고 맡길만큼 높지는 않아요.
성공확률을 높이는 methodology를 제시한 사람이 eric raymond이고
라이센스를 통해서 개인 자유 소프트웨어 개발자들의 권익을 보호하고
프리 소프트웨어가 확산될 수 있는 기반을 만든 사람이 리차드
스톨만이죠. 리누스 토발즈는 리눅스라는 운영체제 프로젝트를
진행하면서 숨겨져 있던 천재적인 프로젝트 매니저의 소질을
전세계에 과시했구요. 아마도... 리누스 토발즈는 후세 사람들이
보기에는 커널을 만든 사람이라기 보다는 최초의 성공적인
(거의 본능적인) 대규모 자유 소프트웨어 프로젝트 매니저로
기억할겁니다.

오픈 소스 프로그램은 절대 밤새서 무리해 개발하지 마세요. 나중에
본전 생각날겁니다. :)

방위 있을때 경험이 하나 생각나네요. 2개 중대 병력이 동원되어서
다들 삽 하나씩 들고 연병장을 만들었습니다. 더운 여름날에
땀을 후덥지근 흘리며 한달 정도 시간이 걸렸는데.... 옆 부대는
보니까 포크레인 한대를 부르더니 한 일주일 작업해서 연병장을
만들더군요. --; 오픈소스를 여기 비유하자면 길거리에 지나가는
사람들 중에 희망자에게 삽을 쥐어주고 자기 맘대로 파게 만드는
겁니다. 어떤 사람은 10분, 어떤 사람은 살뺀다고 땀흘려가며
며칠씩 일하겠죠. 프로젝트 매니저는 작업만 분배해 주고
자원자들한테 삽을 잘 나누어 줘야 하겠죠. 실제 이렇게 연병장을
오픈 소스식으로 만들 수는 없겠습니다만 지나가는 행인의 숫자가
하루에 수백만 정도라면 그 중에 자발적으로 일을 하고 싶어하는
사람이 너댓은 있겠죠. 인터넷이 생기니까 행인의 숫자가 갑자기
불어난 셈이라고 볼 수 있습니다.

글이 길어지네요. 이만.

문경귀 wrote..
: 저는 최근 Open Sources: Voices from the Open Source
: Revolution 책을 읽고 있습니다.
: 제가 막연히만 알고 있던 내용들을 확인할 수 있어서 좋고, 또 어떤 내

: 들은 새로운 시각을 가지게 해주더군요.
:
: 그런데 읽으면서 책의 내용들이 너무 성공담에만 치우친 것이 아닌가 하
: 는 생각이 문뜩 들었습니다.
: 오픈 소스 모델을 적용했어도 성공적이지 못한 경우들도 있었을텐데 그

: 부분에 관한 내용은 좀 찾기가 어렵더군요.
:
: 그래서 혹시 오픈 소스 모델을 적용해 실패한 경우와 이 때 어떤 부분

: 실수로 작용했는지 논하거나 소개한 글이 있으면 추천해 주십시오.
: 그리고 오픈 소스 모델을 반대하는 사람들도 꽤 있으리라 생각됩니다.
: 이런 사람들의 글도 알려주시면 고맙겠습니다.
: 물론 직접 글을 올려주시면 더욱 좋겠습니다.
:
: 저도 현재 소프트웨어 산업에 패러다임이 바뀌어 가고 있다는 것을 인정

: 지만 그 패러다임의 종착지가 오픈 소스 모델이 될 것인지는 아직 의문

: 이 남아 있습니다.
: 그럼 좋은 답변들을 기대하겠습니다.

방준영_의 이미지

제가 생각하기에 오픈 소스 프로그램을 밤새워 만드는 것은 스타같은
게임을 밤새워하는 것보다 *훨씬* 재미있습니다. 본전이요? 돈벌려고
하는 게 아닌데 본전 생각이 왜 날까요.

logout wrote..
: 제가 보기에 오픈 소스는 한마디로 벤처입니다. 분명히 working 하기

: 하지만 성공 확률은 백에 하나가 드뭅니다. 대신에 제대로 성공하면
: 순식간에 전세계로 퍼져 나가 de facto standard로 자리를 잡는
: 장점이 있죠.
:
: 외국 오픈 소스 개발자들의 대부분이 part time으로 오픈 소스
: 소프트웨어를 만드는 것은 어찌보면 당연한 것입니다. 잘 되면
: 좋고 안되어도 별 탈이 없는 그런 일들을 오픈 소스로 밀어 부치는
: 것이 좋겠죠. 어차피 돈들 일이 거의 없으니까요. 특히 우리나라에는
: 바쁘게 사는 사람들이 대부분이다보니 '식음을 전폐'하고 오픈
: 소스에 달라붙으면 무엇인가 하나 해 낼 수 있다고 확신아닌
: 오해를 하는 분들이 가끔씩 있는데 조심해야 합니다. 오픈소스는
: 망하는 프로젝트가 99%입니다. 벤처보다 더 한 것 같아요.
:
: 오픈 소스로부터 또하나 배울 점은... 디지털 네트워크의 위력입니다.
: 솔직히 상품 하나 만드는 것보다 소프트웨어 하나 만드는 것이
: 쉽습니다... 어디 잡지에 기사를 읽다 보니까 제대로된 인터넷
: 사이트는 밤새는 프로그래머 대여섯명에 피자만 열심히 공급해주고
: 1년쯤 기다리면 만들어지게 되어 있다고 하던데 틀린 얘기는
: 아닌 것 같습니다. 공장짓고 라인 건설하고 유통망 확충하고
: 수요 예측 및 재고 관리할 필요가 없죠. :)
:
: 여기에 디지털 네트워크가 추가되면... 밤새는 프로그래머 없이
: 가끔씩 쉬는 시간에 해커들이 몇자 써 놓은 버그 패치를 네트워크로
: 모을 수 있습니다. mp3 같은 경우는 전세계 네트웍 이용자 중에서
: 너댓명만 cd를 떠버려면 아무리 희귀종이라도 네트워크로 퍼지게
: 되어있구요. 예전에는 버리고 까먹어 버리는 자원, 혹은 노동을
: 써먹을 수 있는 방법이 생긴거죠.
:
: 줄이자면 세상이 이렇게 바뀌는 까닭에 새로운 가능성이 열린 겁니다.
: 대신 성공확률은 높아지긴 했지만 믿고 맡길만큼 높지는 않아요.
: 성공확률을 높이는 methodology를 제시한 사람이 eric raymond이고
: 라이센스를 통해서 개인 자유 소프트웨어 개발자들의 권익을 보호하고
: 프리 소프트웨어가 확산될 수 있는 기반을 만든 사람이 리차드
: 스톨만이죠. 리누스 토발즈는 리눅스라는 운영체제 프로젝트를
: 진행하면서 숨겨져 있던 천재적인 프로젝트 매니저의 소질을
: 전세계에 과시했구요. 아마도... 리누스 토발즈는 후세 사람들이
: 보기에는 커널을 만든 사람이라기 보다는 최초의 성공적인
: (거의 본능적인) 대규모 자유 소프트웨어 프로젝트 매니저로
: 기억할겁니다.
:
: 오픈 소스 프로그램은 절대 밤새서 무리해 개발하지 마세요. 나중에
: 본전 생각날겁니다. :)
:
: 방위 있을때 경험이 하나 생각나네요. 2개 중대 병력이 동원되어서
: 다들 삽 하나씩 들고 연병장을 만들었습니다. 더운 여름날에
: 땀을 후덥지근 흘리며 한달 정도 시간이 걸렸는데.... 옆 부대는
: 보니까 포크레인 한대를 부르더니 한 일주일 작업해서 연병장을
: 만들더군요. --; 오픈소스를 여기 비유하자면 길거리에 지나가는
: 사람들 중에 희망자에게 삽을 쥐어주고 자기 맘대로 파게 만드는
: 겁니다. 어떤 사람은 10분, 어떤 사람은 살뺀다고 땀흘려가며
: 며칠씩 일하겠죠. 프로젝트 매니저는 작업만 분배해 주고
: 자원자들한테 삽을 잘 나누어 줘야 하겠죠. 실제 이렇게 연병장을
: 오픈 소스식으로 만들 수는 없겠습니다만 지나가는 행인의 숫자가
: 하루에 수백만 정도라면 그 중에 자발적으로 일을 하고 싶어하는
: 사람이 너댓은 있겠죠. 인터넷이 생기니까 행인의 숫자가 갑자기
: 불어난 셈이라고 볼 수 있습니다.
:
: 글이 길어지네요. 이만.
:
:
: 문경귀 wrote..
: : 저는 최근 Open Sources: Voices from the Open Source
: : Revolution 책을 읽고 있습니다.
: : 제가 막연히만 알고 있던 내용들을 확인할 수 있어서 좋고, 또 어떤

: 용
: : 들은 새로운 시각을 가지게 해주더군요.
: :
: : 그런데 읽으면서 책의 내용들이 너무 성공담에만 치우친 것이 아닌
가 하
: : 는 생각이 문뜩 들었습니다.
: : 오픈 소스 모델을 적용했어도 성공적이지 못한 경우들도 있었을텐데

: 런
: : 부분에 관한 내용은 좀 찾기가 어렵더군요.
: :
: : 그래서 혹시 오픈 소스 모델을 적용해 실패한 경우와 이 때 어떤 부

: 이
: : 실수로 작용했는지 논하거나 소개한 글이 있으면 추천해 주십시오.
: : 그리고 오픈 소스 모델을 반대하는 사람들도 꽤 있으리라 생각됩니
다.
: : 이런 사람들의 글도 알려주시면 고맙겠습니다.
: : 물론 직접 글을 올려주시면 더욱 좋겠습니다.
: :
: : 저도 현재 소프트웨어 산업에 패러다임이 바뀌어 가고 있다는 것을
인정
: 하
: : 지만 그 패러다임의 종착지가 오픈 소스 모델이 될 것인지는 아직 의

: 점
: : 이 남아 있습니다.
: : 그럼 좋은 답변들을 기대하겠습니다.

준호의 이미지

문경귀 wrote..
: 저는 최근 Open Sources: Voices from the Open Source
: Revolution 책을 읽고 있습니다.
: 제가 막연히만 알고 있던 내용들을 확인할 수 있어서 좋고, 또 어떤 내용
: 들은 새로운 시각을 가지게 해주더군요.
:
: 그런데 읽으면서 책의 내용들이 너무 성공담에만 치우친 것이 아닌가 하
: 는 생각이 문뜩 들었습니다.
: 오픈 소스 모델을 적용했어도 성공적이지 못한 경우들도 있었을텐데 그런
: 부분에 관한 내용은 좀 찾기가 어렵더군요.
:
: 그래서 혹시 오픈 소스 모델을 적용해 실패한 경우와 이 때 어떤 부분이
: 실수로 작용했는지 논하거나 소개한 글이 있으면 추천해 주십시오.
: 그리고 오픈 소스 모델을 반대하는 사람들도 꽤 있으리라 생각됩니다.
: 이런 사람들의 글도 알려주시면 고맙겠습니다.
: 물론 직접 글을 올려주시면 더욱 좋겠습니다.
:
: 저도 현재 소프트웨어 산업에 패러다임이 바뀌어 가고 있다는 것을 인정하
: 지만 그 패러다임의 종착지가 오픈 소스 모델이 될 것인지는 아직 의문점
: 이 남아 있습니다.
: 그럼 좋은 답변들을 기대하겠습니다.

오픈 소스는 모든 소프트웨어에 적합한 모델이 아닙니다.
적어도 제가 듣고 본 것을 감안하면 다음에 해당하는 것에는
오픈 소스가 별 이득이 없거나 좋지 않습니다.

- 사용자 편의에 크게 치우친 유저 인터페이스 프로그램
(GUI 워드프로세서, 통합 개발 도구 등)
- 미션 크리티컬 소프트웨어
(은행이나 군대에서 사용할 만한)

하지만 다음 분야에는 적합합니다.

- 기술적 분야에 치우친 운영체제나 네트워크 소프트웨어
- 각종 표준의 구현체
- 분야가 명확한 중간 수준의 사용자 도구

물론 이견이 많이 있을 수 있습니다. 하지만 리눅스나
FreeBSD같은 표준 구현의 운영체제의 발전 속도에 비하면
LyX같은 GUI워드프로세서의 발전이 얼마나 느린지 생각해
볼 수 있을 것입니다. 미션 크리티컬 분야에서의 적용도
그렇고요. 단지 "있다" 정도가 아니라 "아주 훌륭하며
많은 사람들이 채택하는 단계"에 있는것을 말합니다.

이에 대해서는 오픈 소스 책을 읽으신다니 아파치 프로젝트의
Brian Behlendorf가 쓴 장을 읽어보시면 됩니다.

http://www.oreilly.com/catalog/opensources/book/brian.html

익명 사용자의 이미지

있죠.

많은 사람들이 추종하는 alan cox가 slash dot에 쓴 글을
찾아보세요. esr의 자기자랑 문서에 대한 코멘트인데,
아주 적절한 예를 들어 놓았읍니다.
물론 alan cox가 썼으니 oss movement자체에 비판적인게 아니라,
oss가 뭔지도 제대로 알지도 못하면서, 개발 능력도 없으면서
입만 살아있는 일부(일부가 아닌가?)를 경계하는 글입니다.

웹을 잘 활용하면 그 외에도 '뻘질'이라는 표현이 딱 들어맞는
그런 자칭 프로젝트들 많이 찾을 수 있읍니다. 우후죽순으로
마구마구 늘어나는 sourceforge.net의 페이지들을 주욱 관찰해보세요.
oss라는 거창한 이름하에 기초도 없이 뻘질하는게 얼마나
많은지 금방 알게됩니다. 그러다 보면 어느날 갑자기 없어지는
페이지가 생깁니다. (한페이지는 이거 두달이상 가면 장을
지진다고 장담했었는데, 다행히 장을 지질일 없이 제대로 사라져
주더군요. :-)

OSS model자체는 먹고사는 문제말고는 크게 무리가 없는것으로
보이지만, 더 큰 문제는 OSS에 동참한다고 스스로 자부하는 입만
살아있는 무능력자들이겠죠. 어떤게 그런지는 소스보면 압니다.
소스라도 공개되어있으니 옥석구분이 쉬운게 다행이라면 다행이랄까요?

문경귀 wrote..
: 저는 최근 Open Sources: Voices from the Open Source
: Revolution 책을 읽고 있습니다.
: 제가 막연히만 알고 있던 내용들을 확인할 수 있어서 좋고, 또 어떤 내용
: 들은 새로운 시각을 가지게 해주더군요.
:
: 그런데 읽으면서 책의 내용들이 너무 성공담에만 치우친 것이 아닌가 하
: 는 생각이 문뜩 들었습니다.
: 오픈 소스 모델을 적용했어도 성공적이지 못한 경우들도 있었을텐데 그런
: 부분에 관한 내용은 좀 찾기가 어렵더군요.
:
: 그래서 혹시 오픈 소스 모델을 적용해 실패한 경우와 이 때 어떤 부분이
: 실수로 작용했는지 논하거나 소개한 글이 있으면 추천해 주십시오.
: 그리고 오픈 소스 모델을 반대하는 사람들도 꽤 있으리라 생각됩니다.
: 이런 사람들의 글도 알려주시면 고맙겠습니다.
: 물론 직접 글을 올려주시면 더욱 좋겠습니다.
:
: 저도 현재 소프트웨어 산업에 패러다임이 바뀌어 가고 있다는 것을 인정하
: 지만 그 패러다임의 종착지가 오픈 소스 모델이 될 것인지는 아직 의문점
: 이 남아 있습니다.
: 그럼 좋은 답변들을 기대하겠습니다.

정규현의 이미지

핵심개발자(프로젝트 매인테이너)의 역량이 무척이나 중요합니다.
물론 어떤 소프트웨어 프로젝트의 경우 PM이나 PL의 역할이
중요하긴 하지만, 오픈소스모델같은 경우는 특히 그 중요성이
더 강조됩니다.
상업 프로젝트의 경우 멤버가 고정되고, 그들에게 일상적으로
작업을 분배하는 식으로 프로젝트가 진행되는 반면에
오픈소스 프로젝트의 경우 릴리즈 데이트를 확실하게 정하기도
힘들며, 누가 어떤 일을 얼마만큼 하느냐에 대한 명확한 선을
긋기가 힘듭니다.
게다가 상업프로젝트의 PM은 프로젝트에 대한 분명한 권한을
가지지만, 오픈소스 프로젝트의 경우 리더가 팀구성원에게
강제할수 있는 어떠한 권한도 가지고 있지 않습니다.
따라서 뛰어난 개발자로서의 역할 이상으로
커뮤니티를 리딩할수 있는 오피니언 리더와 서로 다른 의견을
통합할 수 있는 인티그레이터로서의 역할이 대단히 중요합니다.

이 예기 저 예기 많았는데
간단히 말해 인적자원의 구성에 대한 의존도가 상업 프로젝트에 비해서
훨씬 더 크다는 말입니다.

그리고 상업적 측면에서 봤을때
릴리스 데이트를 확정할 수 없다는 건 굉장히 커다란 약점입니다.

현재 오픈소스모델을 비지니스화시켜 성공한 래드햇과 시그너스의
경우 분명히 소프트웨어에 대한 태반의 통제권을 자신들이 가지고
있었습니다.
(여기에 오해 없길 바랍니다. 래드햇의 경우 배포판이 주 상품이고
배포판 구성부분들에 대한 통제권을 예기하는 것이 아니라
배포판 전체에 대한 통제권이 있다는 말입니다.
시그너스의 경우 컴파일러 프로젝트의 주요 리딩 개발자가
사내구성원이었습니다. 그렇기 때문에 프로젝트의 통제권 대부분을
쥐고 있었죠.)

정규현의 이미지

핵심개발자(프로젝트 매인테이너)의 역량이 무척이나 중요합니다.
물론 어떤 소프트웨어 프로젝트의 경우 PM이나 PL의 역할이
중요하긴 하지만, 오픈소스모델같은 경우는 특히 그 중요성이
더 강조됩니다.
상업 프로젝트의 경우 멤버가 고정되고, 그들에게 일상적으로
작업을 분배하는 식으로 프로젝트가 진행되는 반면에
오픈소스 프로젝트의 경우 릴리즈 데이트를 확실하게 정하기도
힘들며, 누가 어떤 일을 얼마만큼 하느냐에 대한 명확한 선을
긋기가 힘듭니다.
게다가 상업프로젝트의 PM은 프로젝트에 대한 분명한 권한을
가지지만, 오픈소스 프로젝트의 경우 리더가 팀구성원에게
강제할수 있는 어떠한 권한도 가지고 있지 않습니다.
따라서 뛰어난 개발자로서의 역할 이상으로
커뮤니티를 리딩할수 있는 오피니언 리더와 서로 다른 의견을
통합할 수 있는 인티크레이터로서의 역할이 대단히 중요합니다.

이 예기 저 예기 많았는데
간단히 말해 인적자원의 구성에 대한 의존도가 상업 프로젝트에 비해서
훨씬 더 크다는 말입니다.