오픈소스와 비즈니스
최근 우리 회사는 오픈 소스를 회사 소프트웨어에 적용하는 문제로 토론
을 시작했습니다. (광고성으로 인식될 수도 있으므로 회사 이름은 밝히
지 않습니다)
최근의 리눅스 관련 업체들의 일부조차 오픈 소스를 적용하지 않는 상태에
서, 주요 플랫폼이 윈도우즈인 우리 회사에서 오픈 소스를 적용하는 것
이 문제된다는 의견이 있는 반면, 회사 경영진은 대체로 오픈 소스 정책
을 비즈니스 성공의 기회로 받아들이고 있습니다.
대체로 이 게시판에 들어오시는 분들은 오픈소스를 긍정적으로 받아들일
것으로 예상하지만, 어떤 경우에는 오픈 소스 자체를 비즈니스와 연결시
키는 것 자체에 대해 부정적인 견해를 나타내는 사람을 본 적도 있습니
다.
이런 토론은 이미 네스케이프사의 오픈 소스 정책 채택 시에 이루어졌던
것입니다. 저는 이런 토론을 한국상황에서 해 보았으면 하는 것입니다.
주제는 이렇지 않을까요?
1. 한국에서 성공한 패키지 소프트웨어는 매우 적습니다. 아래한글, 이야
기, 칵테일, 블루엣... 이런 정도입니다. 그것이 한국기업이 오픈 소스
정책을 취할 이유가 될 수 있을까요? - 저는 그렇다고 봅니다.
2. 한국의 많은 소프트웨어 업체는 SI 사업에서 이익을 얻고 있습니다.
이것이, 소스를 공개할 경우, 소스를 제작한 업체보다 해당 업체에 경쟁
적인 SI 업체에게 기업 비밀을 그대로 노출하는 결과를 낳지는 않을까
요? - 저는 이것이 상당한 모험이 될 수도 있다고 봅니다.
3. 미국의 래드헷 사가 배포판의 판매에서 많은 이익을 얻은 반면 국내
리눅스 관련 업체들은 배포판보다는 하드웨어 판매에서 많은 이익을 얻고
있습니다. 소스를 공개한 업체가 한국에서 배포판으로 얼마나 이익을 얻
을 수 있을까요? - 저에게는 "의문"일 뿐입니다.
4. 네스케이프사의 MPL이 GPL이나 오픈라이센스와 타협한 지점은 소스
의 일부를 커스터마이징하여 제공하고 그것을 공개하지 않을 권리를 네스
케이프사가 갖고 있는 것입니다. 특정 고객을 위하여 개발한 버전의 소스
를 공개하지 않는 것이 오픈소스의 취지에 맞는 것일까요? - 리처드 스톨
만은 분명한 반대의견을 밝혔던 것으로 알고 있습니다(제 기억으로는).
경쟁적 상태의 기업으로서는 뿌리칠 수 없는 유혹이라는 점은 분명하고,
저는 아직 생각을 정리하지 못했습니다.
참고로 저희 회사의 소프트웨어는 GCC를 전혀 사용하지 않습니다. Java
와 MFC를 이용하고 있고(오픈소스에 문제가 될만한 부분도 없지 않습니
다), 대부분의 라이브러리는 자체에서 개발합니다(오픈소스를 적용하는
데 문제가 없다는 얘기죠)리눅스에서도 구동 가능한 소프트웨어가 있지만
(Java 기반의 경우), 아닌 제품도 있습니다. 일부 제품군은 플러긴으로
제작되었기 때문에 소스 공개 자체가 불법이거나, 공개하더라도 이용하려
면 해당 회사의 SDK를 구입하여야만 합니다.
회사는 일부 독점 소프트웨어를 갖고 있으면서 주요 소프트웨어에 GPL 또
는 MPL 유사 라이센스를 적용하는 것이 올바른지 검토한다는 뜻입니다.
리눅서들의 고견을 기대해 봅니다.
국내에도 출간된 "오픈 소스"책에 이와 관련된 장이 있습니다.즉 오픈
국내에도 출간된 "오픈 소스"책에 이와 관련된 장이 있습니다.
즉 오픈 소스로 자신의 소프트웨어를 공개하고자 할 때
왜, 어떻게 해야 하는지에 대한 것이죠.
꼭 읽어보시고 어떤 전략을 취해야 할 지 알아보세요.
http://www.oreilly.com/catalog/opensources/book/brian.html
왜 오픈 소스를 도입하려고 하시는지에 대한 이유를 명확히 안쓰신것 같
왜 오픈 소스를 도입하려고 하시는지에 대한 이유를 명확히 안쓰신
것 같습니다.
기업의 입장에서는, 오픈소스를 도입해서 어떤 이익을 얻을 수 있습니까?
오픈소스를 도입해서 잃어버리는 손해는 많습니다. 경쟁사에게 주기
싫은 도움을 주게 되는 수도 있고, 가뜩이나 좁은 국내 시장에서
귀 회사의 입지를 더욱 좁히는 자충수를 두는 결과를 초래할 수도
있습니다. 한마디로 위험을 감수해야 합니다.
그럼에도 불구하고, 오픈소스가 어떤 이익이 되는지 한번 잘
생각해 보시기 바랍니다. 제가 지금 당장 생각나는 오픈소스의
이익이란, 기업의 입장에서는 별다른 비용을 들이지 않고도
버그 패치를 얻을 수 있고, 자원 봉사자들의 노력을 소프트웨어의
quiality를 높이는데 쓸 수 있습니다. GPL쪽 라이센스를 쓰면
소프트웨어가 자유 소프트웨어로 남을 수 있도록 보호장치를
걸 수 있고 BSD쪽으로 가면 약간의 add-on을 덧붙여서 금전적인
이익을 남기기 좋은 환경으로 갈 수 있지만 대신 경쟁사도
같은 전략을 쓸 수 있겠죠.
여하간, 이 모든 것은 오픈소스 프로젝트가 '성공했을때'의
이야기입니다. 오픈소스 프로젝트가 한번 성공하면 전세계를
점령하지만, 실패하면 그냥 덧없이 사라집니다. freshmeat에는
쓸만한 프로그램도 많지만 유치한 프로그램도 많습니다. 게다가
말씀하셨듯이 우리나라는 아직 제대로된 오픈 소스 프로젝트가
성공한 적이 없습니다. 시장 자체가 워낙 좁고, 남는 시간에
프로그래밍을 심심풀이로 해 볼만한 여유가 사회적으로 주어지지
않습니다. 알란 콕스가 산다는 영국의 스완지를 방문해 본 적이
있는데... 성질 급한 사람은 거기서 못살겠더군요. 해만 지면
정말로 할 짓이 없습니다. :) 그러니까 심심해서 책도 보고
프로그래밍도 하고 그런 거겠죠.
일단은 오픈 소스를 도입해서 자신이게 어떤 이익이 돌아오는지를
잘 생각해 보시는 게 좋을 것 같습니다. 레드햇은 자사의 배포본을
통해 레드햇의 브랜드 밸류를 키우고, 리눅스 시장을 넓혀 나가는
이익을 취하고 있습니다. VAlinux는 지속적으로 high end server
시장을 넓혀 나가고 있습니다. 나름대로 이유가 있기 때문에
GPL을 통한 오픈 소스를 추진하고 있는 것이죠.
오픈소스를 도입해서 얻는 것과 잃는 것을 잘 저울질 해 보시기를
부탁드립니다. 얻는 것이 많다고 생각되면 충분히 추진해 볼
필요가 있겠죠.
참고가 되었는지 모르겠습니다. :)
솔직히 여러 님들의 의견은 제 예상 밖입니다. 의외로 오픈소스 비지니스
솔직히 여러 님들의 의견은 제 예상 밖입니다. 의외로 오픈소스 비지니스
의 한국 성공 가능성에 대해 부정적이군요.... (하하하... 그말은 할 사람
이 별로 없다는 뜻이니 오픈 소스로 갈 경우 "경쟁자"는 별로 없겠군요)
오픈소스로 갈 때 다른 프로그래머들의 도움을 받는다는 것은 큰 매력이
있습니다. 하지만, 장사하는 사람 입장에서는, 개발자 측면의 매력은, 결
코 제품 판매에 도움이 되지 않습니다.
고객 측면에서 오픈소스가 이익이 될까를 고민해 보는 겁니다. 정확히 말
하면, 고객들한테, "이거 오픈소스로 만든건데, 이러저런게 참 좋은거
다"라고 말하고 설득할 만한 게 뭘까 하는 겁니다.
우선, GPL 지지자들에게 호의를 얻을 수는 있겠죠. 근데, GPL 지지자가 엄
청난 고객층을 형성하는 건 아닐 거구요. 오히려 제품을 팔러 다니면서
GPL 지지자를 만들어야 하겠죠. ^^; 그니까 이 항목은 고객의 매력 항목에
서 빼야 될거구요.
소스코드가 있으니까 회사가 망해도 계속 유지보수할 수 있다고 할 수 있
습니다. 고객에게는 매력적으로 들리기는 하겠지만, "망할 지도 모른
다"는 얘기를 고객에게 할 수 없으니 역시 빼야 할 것 같습니다.
어차피 외부 프로그래머의 도움이라는 측면은 좋기는 하지만, 핵심적인 개
발역량이 없다면 이익을 낼 수가 없을 겁니다. 즉, 공짜로 팔고 관련 서비
스로 돈을 버는건데, 그럴려면 관련서비스를 최고로 잘하는 회사, 즉 공개
한 소프트웨어의 주요 관리자라는 점이 알려져야 한다는 얘깁니다. 그러
니 우리 회사에서 주요 부분을 개발한다는 얘기를 강조해야 겠죠. (그렇
든 그렇지 않든... 먹고 살려면 ^^;) 뭐, 외부 프로그래머의 도움이라는
측면은 고객들이 좋아하기는 하겠군요. 해커 누구누구가 소프트웨어 개발
하는데 도움을 줬다. 이런 식으로도 광고할 수 있겠네요.
GPL 소프트웨어를 많이 집어넣을 수 있다는 점은 장점이네요. 고객은 소프
트웨어 지원에 "지불"해야 하지만, 엄청나게 많은 소프트웨어가 들어갔어
도 소프트웨어 자체에 "지불"할 필요는 없는 셈이니까요.
또, 저는 오픈소스로 개발하는 경우라 해도 개발 역량의 주요 부분을 외부
에 의존할 생각은 없습니다. 자체적으로 소화하는 게 원칙이고, 외부에서
훌륭한 패치판이 나오면 추가하게 되겠지만요. 다만 오픈 소스라고 해
서 "계획할 수 없는 일정"으로 장사할 수는 없다는 얘깁니다.
헉, 말이 꼬이기 시작했군요. 오픈 소스에 대해서는 찬성하지만, 오픈 소
스로 돈을 버는 것은 어렵다는 게 여러분들의 생각인가요?
오픈소스가 소비자에게 어필할 수 있는 장점이 뭘까요?소스가 공개 되어
오픈소스가 소비자에게 어필할 수 있는 장점이 뭘까요?
소스가 공개 되어 있다는 것이 소비자에게는 특별히 다르다고 느끼지도
않을 겁니다.
소스가 공개 되어 있던 아니던 사용자가 편하면 사용자로서는
만족일 것입니다.
오픈 소스라는 토론을 일반화 시키기에 지금은 좀 힘들지
않을까 하는 생각입니다.
기업에게 있어서도 오픈소스는 그다지 매력적이지는 않을겁니다.
경쟁 집단을 양산하지 않습니까.
물론 소스를 오픈하면 절대적인 기술 진보는 빠르겠지요...
( 성당과 시장을 잘 읽어보진 않았지만... )
시장이 훌륭한 결과를 낳더라도 시장에는 그 결과를 평가 받을
뚜렷한 주체가 없지 않나요?
물론 성당보다야 결과적 산물은 우수하겠지만 말입니다.
----------
김창한 wrote..
솔직히 여러 님들의 의견은 제 예상 밖입니다. 의외로 오픈소스 비지니스
의 한국 성공 가능성에 대해 부정적이군요.... (하하하... 그말은 할 사람
이 별로 없다는 뜻이니 오픈 소스로 갈 경우 "경쟁자"는 별로 없겠군요)
오픈소스로 갈 때 다른 프로그래머들의 도움을 받는다는 것은 큰 매력이
있습니다. 하지만, 장사하는 사람 입장에서는, 개발자 측면의 매력은, 결
코 제품 판매에 도움이 되지 않습니다.
고객 측면에서 오픈소스가 이익이 될까를 고민해 보는 겁니다. 정확히 말
하면, 고객들한테, "이거 오픈소스로 만든건데, 이러저런게 참 좋은거
다"라고 말하고 설득할 만한 게 뭘까 하는 겁니다.
우선, GPL 지지자들에게 호의를 얻을 수는 있겠죠. 근데, GPL 지지자가 엄
청난 고객층을 형성하는 건 아닐 거구요. 오히려 제품을 팔러 다니면서
GPL 지지자를 만들어야 하겠죠. ^^; 그니까 이 항목은 고객의 매력 항목에
서 빼야 될거구요.
소스코드가 있으니까 회사가 망해도 계속 유지보수할 수 있다고 할 수 있
습니다. 고객에게는 매력적으로 들리기는 하겠지만, "망할 지도 모른
다"는 얘기를 고객에게 할 수 없으니 역시 빼야 할 것 같습니다.
어차피 외부 프로그래머의 도움이라는 측면은 좋기는 하지만, 핵심적인 개
발역량이 없다면 이익을 낼 수가 없을 겁니다. 즉, 공짜로 팔고 관련 서비
스로 돈을 버는건데, 그럴려면 관련서비스를 최고로 잘하는 회사, 즉 공개
한 소프트웨어의 주요 관리자라는 점이 알려져야 한다는 얘깁니다. 그러
니 우리 회사에서 주요 부분을 개발한다는 얘기를 강조해야 겠죠. (그렇
든 그렇지 않든... 먹고 살려면 ^^;) 뭐, 외부 프로그래머의 도움이라는
측면은 고객들이 좋아하기는 하겠군요. 해커 누구누구가 소프트웨어 개발
하는데 도움을 줬다. 이런 식으로도 광고할 수 있겠네요.
GPL 소프트웨어를 많이 집어넣을 수 있다는 점은 장점이네요. 고객은 소프
트웨어 지원에 "지불"해야 하지만, 엄청나게 많은 소프트웨어가 들어갔어
도 소프트웨어 자체에 "지불"할 필요는 없는 셈이니까요.
또, 저는 오픈소스로 개발하는 경우라 해도 개발 역량의 주요 부분을 외부
에 의존할 생각은 없습니다. 자체적으로 소화하는 게 원칙이고, 외부에서
훌륭한 패치판이 나오면 추가하게 되겠지만요. 다만 오픈 소스라고 해
서 "계획할 수 없는 일정"으로 장사할 수는 없다는 얘깁니다.
헉, 말이 꼬이기 시작했군요. 오픈 소스에 대해서는 찬성하지만, 오픈 소
스로 돈을 버는 것은 어렵다는 게 여러분들의 생각인가요?
회사의 주 수입원이 무엇인지, 그리고 만약 그 수입원이 소프트웨어라면
회사의 주 수입원이 무엇인지, 그리고 만약 그 수입원이 소프트웨어라면
소프트웨어의 판매로 기인한 것인지 그렇지 않으면 유지보수에 기인한
것인지, 그렇지 않으면 그때그때 프로젝트 수행(SW개발 외주업체)에
의존하는지 먼저 분석할 필요가 있을 것입니다.
그리고 오픈소스(저는 사실 이 말보다는 자유 소프트웨어라는 말을 더
좋아합니다만....)화로 인해 얻고자 하는 잇점이나 예상되는 잇점을
간단히 생각해 봅시다.
몇가지 관점에서 오픈소스 자체의 장점이나 속성에 대해서 짚어
본다면 뭔가 "feel"이 오지 않을까요. :-)
우선 개발자의 관점에서, 오픈소스 개발 모델은 회사 입장에서는
distributed development, distributed debugging의 장점을 살릴 수
있어야 하겠지요. 그러자면 오픈소스 모델을 적용할 소프트웨어가
개발자들의 입맛에 맞는 재미있는(?) 소프트웨어라야겠지요.
소스코드 자체가 너무 거대하고 방대해서 개발자의 참여 의지를
꺾는 일이 되어서도 안될 것이고, 회사 입장에서는 오픈소스화로
인해 야기될 수 있는 project forking 현상을 피하면서 개발의
주도권을 계속해서 잡고 회사가 원하는 방향으로 개발을 진행해
나갈 수 있는 관리 능력이 필요하게 됩니다. 자칫 잘못하면 경쟁사에게
핵심 기술을 그대로 노출시키는 경우가 될수도 있으니 경쟁사가
도저히 따라오지 못하도록 계속해서 앞질러 가야 한다는 얘깁니다.
그러자면 개발자들이 쉽게 공동작업을 할 수 있는 기반이 있으면
좋겠지요? 말씀하시는 걸로 봐서는 MS 기반에서 소프트웨어를 개발하시고
거기서 개발된 소스코드를 공개하시겠다는 것 같은데 그렇게 될 경우
해당 소프트웨어 개발 툴이 없는 사람들은 참여를 하고 싶어도
참여하기가 쉽지 않겠지요?
리눅스/유닉스 계열에서 오픈소스 개발 모델이 지속적으로 유지되는
가장 큰 이유중의 하나가 바로 개발 환경의 통일성이라고 생각합니다.
(g)cc, gdb, make, cvs 등등 무료로 사용할 수 있는 개발자의 기반
환경을 지금 오픈소스화하시려는 소프트웨어의 개발 작업에도
적용할 수 있습니까? 실제로 오픈소스 라이센스 하에서 소스코드를
릴리즈하고 그것을 회사 밖의 다른 사람들과 함께 개발하시고자
한다면 공통적인 개발 환경에 대해서도 한번쯤 고려해 보시는게
좋을 것입니다. 리눅스/유닉스 환경이 아니라 MS 윈도우즈 기반에서
주로 작업을 하신다기에 드리는 말씀입니다.
부디 현명한 결정을 내리시기를 바랍니다...어떻게 결정을 내리든
쉽지않은 결정이 되겠지만요... :-)
개발환경 등의 문제는 개선할 수 있을 것으로 생각합니다. MFC를 사용하
개발환경 등의 문제는 개선할 수 있을 것으로 생각합니다. MFC를 사용하기
는 하지만, Java 기반의 어플리케이션을 개발하기 때문에 주요 알고리즘
은 포팅을 고려해서 개발해 왔기 때문이죠. 요는 개발환경을 다양하게 가
져갈 수 있는 구조는 이미 준비되어 있다는 것입니다.
문제는 Linux 기반 환경에 대한 고객들의 반응입니다. 지금은 많이 상황
이 개선되어 고객들이 Server Application으로 리눅스를 채용하고 있으
나, Client 측면에서 볼 때는 여전히 어려운 것이 사실입니다.
"실용적인 측면에서 볼 때" 리눅스 사용 고객을 포기할 거냐 윈도우즈 사
용 고객을 포기할 거냐를 묻는다면 주저없이 리눅스 쪽이 될 겁니다. 물
론 제 개인적인 취향이 워낙에 MS를 싫어하는데다 장기적으로는 "특정 플
랫폼"이 사라져야 한다는 생각이기 때문에, 가능하면 크로스플랫폼 환경
을 지향하고 있기는 합니다. 즉, 어느한쪽을 포기하지는 않는 전략을 채택
하는 게 제일 이상적이라는 겁니다.
MS 플랫폼에서 사용가능하고 Linux의 공개 개발툴을 이용할 수 있는 개발
환경이라... 이것이 무지막지하게 어려운 장애는 아니더라도 몇달 정도 개
발자들에게 혼란을 줄 수 있는 조건은 될 수 있겠습니다. 최소한 UI를 MFC
나 WFC 대신 wxWindows같은 걸로 교체해야 하겠군요...(맥은 별로 관심이
없걸랑요)
프로젝트가 크지않고 쉽지만, 개발사는 못따라올 정도로 앞서가야한다...
엄청나게 골치아픈 과제를 주셨습니다.
개발사(경쟁사)에게도 소스를 줄 거고, 프로젝트에 참여한 프로그래머들에
게도 소스를 줄 건데, 경쟁사는 어려워서 못 따라오고 프로젝트에 참여한
프로그래머들은 따라올 수 있게 해야 한다...는 얘기 맞죠? 그럴려면 "공
개한" 프로젝트에 몇가지 제한을 걸거나, 내부적인 개발 속도에 비해 "몇
달"정도 묵은 소스만을 공개해야 하는 건데, 그것이 GPL의 의도, "소프트
웨어 지식을 나눠갖자"는 것과 화해할 수 있을까요?
혹시 우리들이 GPL을 잘못 이해하고 있는 것은 아닐까요?
님의 회사의 수익이 어디서 나오고 앞으로 어디서 나올 것인지 분석하는
님의 회사의 수익이 어디서 나오고 앞으로 어디서 나올 것인지 분석하는
것부터가 먼저일 것 같습니다. 진짜로 소프트웨어를 '판매'하는 것 만으
로 수익을 얻는 회사는 의외로 적지 않나요?
어쨌던 마법의 솥 http://www.tuxedo.org/~esr/writings/magic-cauldron/
을 꼭 읽어보시기 바랍니다. 성당과 시장 3부작의 마지막 편이죠. 오픈소
스 비지니스 모델들 이야기를 하고 있습니다. 제가 본 버전에서는 개인용
워드프로세서는 오픈소스로 비지니스하기 힘든 것으로 이야기하고 있었습
니다. 읽어보시면 의외로 많은 회사들이 소프트웨어를 '판매'해서 수익을
올리고 있다고 _착각_하고 있음을 볼 수 있습니다.
한편 재미있는 사례로 Zope의 경우가 있는데, 프로그래머들이 오픈소스화
에 주저하고 벤처 케피탈리스트가 오픈소스화를 주장한 재미있는 사롑니
다. 보통은 반대지요. 거기서 투자자인 폴 하다주르의 논리도 참조할 만
합니다. 일단 리눅스 메가진의 이 기사 중에서 How Zope Became Open 부분
을 보시고 http://www.linux-mag.com/cgi-bin/printer.pl?issue=2000-
01&article=venture , 폴 하다주르의 프레젠테이션도 참고하시면 좋을 것
입니다. http://www.digicool.com/Library/FTPB/ 에 있습니다.
----------이관수 wrote..님의 회사의 수익이 어디서
----------
이관수 wrote..
님의 회사의 수익이 어디서 나오고 앞으로 어디서 나올 것인지 분석하는
것부터가 먼저일 것 같습니다. 진짜로 소프트웨어를 '판매'하는 것 만으
로 수익을 얻는 회사는 의외로 적지 않나요?
-> 저의 고민 중 하나도 그겁니다. 어차피 소프트웨어를 판매해서 얼마나
남겠냐는 거죠. 개인 대상의 소프트웨어가 성공할 가능성은 드문 반면, 기
업 대상의 소프트웨어는 "빅 히트"가 아니라 해도 상당한 이익을 얻을 수
있습니다. 이 경우 문제는 "소프트웨어" 자체의 가격이 아니라 "유지보
수" 서비스인 경우가 많죠.
----------
이관수 wrote..
한편 재미있는 사례로 Zope의 경우가 있는데, 프로그래머들이 오픈소스화
에 주저하고 벤처 케피탈리스트가 오픈소스화를 주장한 재미있는 사롑니
다. 보통은 반대지요. 거기서 투자자인 폴 하다주르의 논리도 참조할 만
합니다. 일단 리눅스 메가진의 이 기사 중에서 How Zope Became Open 부분
을 보시고 http://www.linux-mag.com/cgi-bin/printer.pl?issue=2000-
01&article=venture , 폴 하다주르의 프레젠테이션도 참고하시면 좋을 것
입니다. http://www.digicool.com/Library/FTPB/ 에 있습니다.
-> 재미있는 사례이고 참고할만했습니다. 문제는 "한국"적 상황에서 이런
게 통할까 하는 겁니다. 해볼 수는 있겠죠. 그런 경우라면 "리눅스"같은
브랜드-like 이름이 필요한데 첫번째 불행은 우리 회사가 리눅스 자체하고
는 별로 안친하다는 거고 두번째 불행은 우리 회사가 거짓말로 리눅스같
은 이름을 회사 앞에 붙이는 걸 싫어한다는 거죠. (오픈 소스를 써볼수는
있는데, 도대체 한국에서 오픈 소스를 이해하는 투자자가 얼마나 있을까
요?)
source 공개 하지 않는게 낫겠군요.하지만 진정한 "리눅스 업
source 공개 하지 않는게 낫겠군요.
하지만 진정한 "리눅스 업체"라는 호칭은 포기해야 겠지요?
요샌 리눅스 서버만 판매해도 "리눅스 업체"라 불려지는
모양이긴 합니다만..
source code 공개했다가 회사가 망할지도 모르는데 책임질
사람은 없다?
그럴바에야 source code 하지 않는것이 더 낫습니다.
p.s.----------------------------
앞으로 갈수록 프로그래밍으로 이익을 남기기란 어려워질것
입니다. 기업에서 source code 를 공개하는일도 수익구조를
다른곳에서 찾겠다는 각오를 하지 않고서는 쫄딱 망하기 쉽
습니다.