오픈소스에서 소스코드는 아무 의미가 없다?

권순선의 이미지

우연히 어떤 블로그를 읽어보고 생각이 나는 것이 있어 씁니다. 이분의 글을 저는 다음과 같이 요약했습니다.

- 오픈소스에서 소스코드는 대부분의 사람들에게 거의 의미가 없다. 개발자들을 포함해서 소스를 보는 사람이 거의 없다.
- 소스코드를 볼 수 없는 이유는... 이해하기 쉽게 짜여진 오픈소스가 많지 않고, 따라서 분석이 어렵기 때문이다.

두번째 내용은 별달리 이론의 여지가 없습니다. 오픈소스라는 사실 자체가 코드의 품질을 보증할 수는 없으니까요. 그러나 첫번째 내용에 대해서는 좀 할 말이 있네요. 과연 소스코드를 보지 않는다고 해서 소스코드 자체가 전혀 의미가 없는 것일까요? 물론 소스코드라는 것은 개발자들에게 가장 중요합니다. 그러나 오픈소스의 속성상 누구나 소스코드에 접근할 수 있는 권리가 동등하게 보장되고 해당 소스를 수정 & 재배포할 수 있는 권리까지 보장된다는 사실 그 자체가 얼마나 큰 의미를 지니는지 그분이 한번쯤 생각해 보았다면 오픈소스에서 소스코드는 아무런 의미가 없다는 말을 그토록 쉽게 하지는 않았을 것입니다.

위의 세가지 권리가 모두에게 보장된다는 사실은 사용자들을 특정 벤더에 lock-in되지 않도록 하는데 큰 역할을 합니다. 그리고 필요할 경우 적절한 능력(인적 능력 or 경제적 능력 모두 포함)을 투입하기만 하면 해당 오픈소스 라이센스가 허용하는 범위 내에서 사용자의 입맛에 맞도록 수정할 수 있고요. proprietary SW로는 절대 불가능한 일들이 가능한 것입니다.

그리고 만약 개인 개발자가 아니라 회사에서 개발되고 지원되는 오픈소스 소프트웨어를 사용하고 있을 경우라면, 소스코드를 제공한다는 것은 누구나 원할 경우 해당 소프트웨어를 빌드해 보고 테스트해볼 수 있는 가능성을 함께 제공한다는 것이기 때문에 고객에게 그만큼 더 정직한 회사가 되도록 하는 효과가 있습니다. 결국 해당 소프트웨어와 관련된 제어권이 고객에게도 최대한 담보되는 것입니다.

그렇기 때문에 소스코드를 실제로 보는 사람이 거의 없다고 해서 오픈소스에서 소스코드가 아무런 의미가 없다는 식의 이야기는 상당히 문제있는 표현입니다. 이는 마치 우리가 헌법이나 법률을 실제로 들춰보는 일도 별로 없고 고칠 일은 더더욱 없다고 해서 헌법이나 법률이 의미없고 필요없다는 것과 비슷합니다.

댓글

ydhoney의 이미지

sangu http://kldp.org/node/79293 오픈소스에서 소스코드는 아무 의미가 없다?
ydhoney^R60e 소스코드의 내용은 의미가 없을지 몰라도, 소스코드 그 자체는 매우 중요하고, 어떤 문화적 의미를 담고 있다고 봐야겠죠
ydhoney^R60e 솔직히 어떤 개발자가 전혀 개발에 참여하지 않고 외부에서 소스코드만 보고 해당 프로젝트에 바로 참여하기는 무지 어려운건 사실이니까..
fender 자바 개발자의 이상향은... 오버뷰 문서 한 번 보고 jar 파일 떨구고 javadoc 보면서 IDE 자동완성 쓰는거 =3
fender 근데 사용자 관점이 다가 아니기 땜에...
fender 저건 좀 너무 비약 같아요
fender 스프링 참 멋지긴 한데... =3
ydhoney^R60e 아무리 코드 내용을 보지 않는다고 해서 코드가 중요하지 않다는건 아니죠
ydhoney^R60e 코드는 코드를 보고 코딩하는데만 쓰는건 아니니까..
ydhoney^R60e 일반 사용자에게도 디버깅을 포함한 오픈소스 프로젝트 사이클을 따라가는데는 매우 중요한 요소이기도 하고..
fender 라이브러리나 프레임워크 사용자 관점에서는... 자바의 경우 그 소스를 봐야할 일이 생긴다면 뭔가 구현에 버그가 있거나 퀄리티가 떨어지는 경우일 거고...
fender 대신 그 프레임워크/라이브러리가 오픈소스로서 버그/패치 등의 피드백을 통해 오픈소스로서 생명력을 갖느냐는 완전히 다른 이야기겠죠...
ydhoney^R60e 그런것들을 수정하는 과정 자체가 오픈소스 사이클로 볼 수 있죠 :-)
fender 그걸 무시하고 소스가 의미 없다면 좀 비약 같음..
fender 그죠
ydhoney^R60e 그러니까 단순하게 소스를 보지 않으니 소스는 의미가 없다 라고 하면
ydhoney^R60e 그건 정말 허접한 낚시꾼이 낚은거라고밖엔 생각할 수 없어요
ydhoney^R60e 그러니까 지금 우리는 글을 끝까지 읽기 귀찮아서 지금 앞부분만 대충 훑어보고 이렇게 떠들고 있는거죠
ydhoney^R60e 그러니까 실제로 글 내용은 보지 않으므로 글 내용은 중요하지 않아요

IRC에서 해당 쓰레드에 대한 이야기를 하다가 따로 정리하긴 귀찮고 해서 그냥 간단하게 특정 종족만의 허락을 맡고 고냥 고대로 긁어옵니다.(G모채널..) - 일부 삭제;;
 
====================여기부터 식은어치====================
안녕하세요. 저는 야동 초등학교 2학년 6반 11번입니다!! 제 컴퓨터에 리눅스를 깔아보고 싶습니다. 리눅스라는건 어제 처음 들어 보았습니다.
리눅스에서도 카트라이더는 되겠지요? 설마 안되나요? 안되면 왜 쓰나요? =3=33 리눅스에서는 카트라이더 캐릭터 머리가 너무 커서 못받아들이나요?

송효진의 이미지

끝까지 읽어보면 '오픈소스 커미터가 되어보자' 인것 같은데요.:)
제목에 의한 낚시가 된건가요? ;;;

emerge money

ganadist의 이미지

권순선 wrote:

- 소스코드를 볼 수 없는 이유는... 이해하기 쉽게 짜여진 오픈소스가 많지 않고, 따라서 분석이 어렵기 때문이다.

그대신 쉽게 짜여진 오픈소스는 훨씬 큰 생명력을 가질 수 있습니다. 활발한 오픈소스 프로젝트들은 그나마 꽤 쉽게 짜여져있다고 생각하면 될 것 같습니다.

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

랑데뷰.의 이미지

// fender 자바 개발자의 이상향은... 오버뷰 문서 한 번 보고 jar 파일 떨구고 javadoc 보면서 IDE 자동완성 쓰는거 =3

무지 잘못된 개발자적 마인드의 댓글이군요.

자바 개발자의 이상향은 전체적인 틀과 업무의 효율과 생산라인의 병합과 프로젝트의 통합적인 개과 입니다.

ydhoney의 이미지

글을 처음부터 끝까지 좀 더 자세히 읽어보시면 해당 내용을 다 언급을 했답니다. -_-

이래서 글 내용은 아무런 의미가 없다니까..

=3=33 
 
====================여기부터 식은어치====================
안녕하세요. 저는 야동 초등학교 2학년 6반 11번입니다!! 제 컴퓨터에 리눅스를 깔아보고 싶습니다. 리눅스라는건 어제 처음 들어 보았습니다.
리눅스에서도 카트라이더는 되겠지요? 설마 안되나요? 안되면 왜 쓰나요? =3=33 리눅스에서는 카트라이더 캐릭터 머리가 너무 커서 못받아들이나요?

익명사용자의 이미지

개인이 개인에게 자문자답한 논픽션형의 댓글이었나요?

keizie의 이미지

채팅의 일종입니다. MSN이나 네이트온 대화 장면을 그림으로 잡아서 올리는 거랑 같은 식으로 이해하시면 되요.

익명사용자의 이미지

풉~ ==3

서광열의 이미지

인용하신 블로그 글을 읽어보면, 코드만 오픈했다고 "오픈소스"라고 부르기는 힘들다는 느낌으로 쓰신 것 같은데요. API 문서나 설계, 개발 철학 등을 함께 오픈하고, 개발을 오픈하려는 생각없이 코드만 오픈해 놓은 오픈소스 프로젝트들은 사실상 오픈소스가 아닌 것이나 마찬가지니깐요.

(아무도 고칠 수 없고 이해할 수 없고 입맛대로 고치쓰기도 불가능한 오픈된 코드는 닫힌 코드랑 다를 바가 없으니깐요.)

1day1의 이미지

오픈소스 커미터가 되어 좋은 소스를 만들어 보자.(의미가 있는 코드로?)

F/OSS 가 함께하길.. (F/OSS서포터즈 : [[FOSS/Supporters]], [[FOSS/Supporters/Group]]) - 추천 프로젝트 : 추천하기 힘드시나요? 추천 꾹 눌러주세요! -

F/OSS 가 함께하길..

토비의 이미지

KLDP에 글을 처음 남겨보네요.

옮겨오신 "제목"은 제가 쓴 것과 다릅니다.
저는 "오픈소스에서 소스코드는 거의 의미가 없다"라고 썼지 "아무"의미가 없다라고 하지 않았습니다.

거의라는 것은 소스코드의 질을 가지고 하는 말이 아니고 대부분의 (주로 자바)개발자에게는 별다른 의미가 없다는 것입니다.

물론 여기 언급하신 것처럼 코드의 질이 낮아서 들여다 봐도 별 도움이 안된다라고 생각할 수도 있지만 그 이전에 (제 글의 순서상) 먼저 "관심이 없다"는 것이 더 심각하다고 봅니다. 리눅스쪽은 좀 얘기가 다르겠지만 그것이 오픈소스라는 것 자체를 의식하지 않고 쓰는 사람이 대부분인게 자바쪽 경우라고 생각됩니다.

JBoss(오픈소스)를 쓰는지 WebLogic(상용)을 쓰는지, Hibernate(오픈소스)를 쓰는지 TopLink(상용,essentials말고)을 쓰는지가 대부분의 개발자들에게는 별 차이가 없다는 것이죠. 비용을 생각해야하는 오너가 아니라면 그들에게는 그것은 그냥 비슷비슷한 툴과 라이브러리일뿐입니다. 그 개발 커뮤니티와 소수의 개발자들에게는 그것이 큰 의미가 있을지 몰라도 소스코드를 다운 받아볼 생각조차 안하는 대부분의 사람들에게 그 차이가 무슨 의미가 있는가라는 얘기였습니다. 오히려 그사람들의 관심은 사용자 입장에서 "품질"문제이지 코드의 질이나 존재유무, 자유의 문제가 아니라는 것입니다.

권순선의 이미지

아래에도 제가 잠깐 썼지만 거의 의미가 없는 것이나 아무 의미가 없는 것이나 의미가 없다는 것은 같은 이야기이죠. :-) 토비님께서 처음부터 명확하게 '누구에게' 의미가 없다는 것인지를 표현하셨더라면 오해가 적었을 텐데 전반부에서 대상이 없이 그냥 의미가 없다고 표현하셔서 저 역시 확대해석한 측면이 있네요.

cleansugar의 이미지

제작자 입장에서는 사실 프로그래밍할 때 FOSS쪽 소스를 참고하지 않을 수가 없고 베끼는 경우도 있습니다.

도용이나 버그가 드러날까봐 소스를 공개하지 못하는 경우도 적지 않을 겁니다.

사용자 입장에서

초보자들은 소스를 이해하지 못해도 소스 내부에서 http://나 이메일 주소같이

외부로 접속되는 링크 정도는 검색하거나 바꿀 수 있습니다.

이게 어려우면 원클릭으로 작동하는 소스코드 자동 분석기를 쓰면 됩니다.

아니면 자신이 좋아하는 소스 감사 전문가나 자동 감사 프로그램에 의뢰합니다.

중급자들은 여러 종류의 소스버그 분석기 중에 자신에게 맞는 걸로

버퍼오버플로같은 버그를 잡아서 공개하고 스스로 컴파일하거나 제작자에게 보고합니다.

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

마잇의 이미지

벤더 락 인

이것 하나만 생각해도 엄청난 가치가 있습니다. 직접 개발을 맡으신 분들에게는 의미가 없을지도 모르겠습니다. 하지만, 최종 소비자의 입장에서는 어떻습니까?

여러분이 개발자라고 생각해 봅시다. 여러분이 농땡이를 피우던가 실력이 딸려서 버벅거리고 있으면 발주자의 입장에서 큰 모험을 감행하지 않고 여러분을 퇴출시킬 수 있다는 것이 벤더 락 인을 피한다는 의미라고 전 생각합니다.

합리적인 소비를 할 수 있는 가능성, 오픈소스와 자유 소프트웨어의 가치는 이것과 곧바로 직결 됩니다.

--
마잇


--
마잇

토비의 이미지

사용의 자유가 있고 라이센스비용이 들지 않는다는 면에서가 아닌 소스코드의 접근이나 수정,재배포의 자유가 벤더락인을 어떻게 막아주는지 잘 이해가 되지 않습니다.

투자한 비용과 라이센스의 제약때문라면 벤더 락인이 될 수 있을 것입니다. 하지만 proprietary제품이 입맛에 맞게 또는 필요에 의해서 수정할 수 없다는 것이 새로운 기능을 자꾸 찾는 기업들에게는 오히려 소프트웨어 벤더를 자주 변경하게 하는 이유중의 하나라고 생각됩니다. 물론 비용걱정이 없다면요.

오픈소스 제품을 사용한다고 해서 특정 제품에 락인되지 않는다는 것은 비용적인 문제를 빼면 어떤 또다른 이유가 있는 것인가요? 제 경험으로 보면 오픈소스를 개발자가 사용한다고 해도 특정 제품의 기술을 본격적으로 사용하게 되면 직/간접적인투자(학습,교육,이미 오픈소스제품을 활용해서 개발한 소스코드)비용 때문에라도 쉽게 제품을 바꾸지 못합니다. 오히려 소스코드를 이용해서 원하는 부분을 수정할 수 있는 자유는 특정 제품의 락인을 더 심화시킨다고 보입니다. 구지 새 제품을 찾지 않고도 아쉬운 부분은 고쳐쓰면 될테니까요.

벤더/제품 락인을 막는 것은 오히려 표준의 존재/준수여부 또는 플러깅을 위한 유연성의 문제라고 생각됩니다. 자바는 JCP통한 표준스펙제정을 통해서 벤더/오픈소스제품의 구현에 대한 lock-in을 막아주려고 하는 것으로 알고 있습니다.

비즈니스적으로 보면 사용의 자유가 소스코드의 열람,수정,재배포의 자유보다 더 의미가 있지 않나 생각됩니다. 물론 소스코드를 받아 직접 빌드해야만 쓸 수 있다면 당연히 소스코드가 매우 중요하지만 요즘은 대부분의 오픈소스제품도 바이너리 버전을 기본적으로 제공하고 있죠.

권순선님의 "위의 세가지(소스코드의 접근,수정,재배포) 권리가 모두에게 보장된다는 사실은 사용자들을 특정 벤더에 lock-in되지 않도록 하는데 큰 역할을 합니다"라는 말씀에 대해서 오픈소스의 비용/사용의 자유보다 소스코드를 통한 자유가 벤더 락인을 막아주는데 어떤 역할을 더하는지 묻고 싶습니다.

권순선의 이미지

유명한 오픈소스 소프트웨어일수록 다양한 업체들이 존재합니다. 그리고 그렇게 다양한 업체들이 존재할 수 있는 것은 바로 해당 오픈소스에 대해 누구나 소스코드에 접근하고 수정하고 재배포할 수 있는 권리가 보장되기 때문에 누구나 능력만 된다면 새로운 업체를 만들 수 있고, 이는 경쟁을 촉발하기 때문에 사용자 입장에서 매우 바람직한 모델이고 자연스럽게 lock-in을 회피할 수 있는 가능성이 항상 존재한다는 것입니다. 윈도에서 리눅스로 전환하는 것보다는 레드햇에서 수세로 전환하는 것이 훨씬 쉽겠지요...

토비의 이미지

오픈소스도 벤더가 있다는 관점에서 생각한다면 그렇게 볼 수 있겠군요.
또는 자유와 경쟁을 통한 다양성의 확보라는 면에서도요.

좋은 답변 감사합니다.

체스맨의 이미지

"대부분의 개발자들에게 소스 공개가 별로 의미가 없다"

라는 것은 그저 당연한 얘기라고 느껴지네요. 의미가 없다라는 것은 결국 개발자들이 가지고 있는 평균적인 의견에 의해 판단된 것이라 볼 수 밖에 없을 것 같은데요...

세상 모든 일이 다 그렇지 않은가요? 기술의 핵심이 되는 내용들을 필요로하는 사람은 극소수일 뿐이지만, 공개 여부의 중요성 문제는 그렇게 필요로 하는 사람이 많은가 적은가로 판단할 수가 없는 것 아닌지요?

컴퓨터 조립하는데 CPU 설계도가 필요한 것은 아니듯이 말이지요. 프로그램 소스도 마찬가지 문제인 것 같은데요.

그리고 소스의 품질 관련해서는, 소스를 작성한 사람의 문제도 있지만, 소스를 보는 사람의 책임도 있습니다. 다른 사람이 작성한 소스를 보는 것이 어려운 것 또한 아주 당연한 일인데, 그 어려움을 모두 소스가 잘 못 작성된 문제로 치부하는 개발자들도 많습니다.

Orion Project : http://orionids.org

knight2000의 이미지

순선 님의 마지막 말을 빌자면...

사실 대부분의 국민은

[헌법]이
[법률]이
[조례]가
[정책]이

공개되어 있어도 폐쇄되어 있어도 그다지 의미가 없습니다.
대부분의 국민은 "결과"만 중요시합니다.
뭐, 겉으로는 국회의원의 도덕성 어쩌고 하면서, 실제로는 자신에게 이익이 되는 사람을 더 뽑는...
소프트웨어로 따지면 다른 회사의 권리를 침해하더라도 일단 편하면 불법복제라도 해서 쓰겠다는 말과 비슷하죠.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

angpang27의 이미지

저는 프로젝 하나 완성하고 사장님께 보고드릴기회가 있었거든용,,
AJAX를 강하게 어필하려고 프리젠테이션 자료를 AJAX위주로 만들었었는데,
앞으로 이런 기술적인 보고따위를 할려면 하지말라고 하시더군요..

돈(즉,,결과) 과 직결되는거 아니면 사회에선 잘 인정을 안해주나봐용~~ ^^

고통이 지천에 있다한들 어이해 멈출수있더냐

knight2000의 이미지

공산품은 제조물 책임(법적 책임)을 져야 합니다.
저작물은 저작물에 대한 도의적 책임을 져야 합니다. 가끔은 "선량한 미풍양속" 어쩌고 하면서 법적 책임을 지우기도 합니다.
하지만 컴퓨터 프로그램은 명백히 악의를 가진 프로그램이라도, 해당 프로그램 전체가 악의의 부분으로 구성되지 않는다면, 현실적으로 법적, 도덕적 책임을 지지 않습니다.

소스코드의 공개는 이러한 책임의 회피 또는 책임의 포기에 대한 자기 구속입니다.
가령 2003년의 윈도XP 시스템에 악성 코드가 침투하여 우리나라 거의 전체의 인터넷이 마비된 현상을 두고 MS는 아무런 책임을 질 필요가 없었고, 지지도 않았습니다.
만약에 컴퓨터 칩이 잘못되어 그런 사고가 났더라면, 그 칩을 만든 회사는 매우 많은 손해 배상을 해 주어야 합니다.
사실 위의 두 문제는 본질적으로 같습니다. 둘 다 "컴퓨터에서 동작하는 프로그램"의 문제인데, 한쪽은 하드웨어로 취급되어 책임을 져야 하고, 다른 한쪽은 책임을 회피할 수 있습니다. 이것은 명백히 무언가가 잘못되어 있다는 뜻입니다.
이에 따라 몇몇 선각자들은 앞으로는 저작물 전체가 소프트웨어처럼 "읽을 권리"와 "볼 권리"를 제한하는 쪽으로 나아가게 되리라 예상하였고, 지난 20세기 말에 디지털저작권법(흔히 밀레니엄저작권법)이 만들어졌습니다. 다행스럽게도 그 법은 발효를 하지 못하였습니다.
오픈 소스라는 개념은 이러한 실정법에서 보장하고 있는 "책임의 회피"를 스스로 거부하며, 자신의 프로그램에 대해 "자기 구속"을 하는 행위입니다. 이것은 법적 의무 이전에 도덕적으로 그것이 옳음을 인정하고, 그것으로써 자신을 구속하는 "희생"이라고 볼 수도 있습니다.
* 영어의 "희생"(sacrifice)은 그 이면에 "자기만족"(self-satisfaction)이라는 뜻이 들어 있게 됩니다. 인간관계에서 이익관계가 기본인 서양에서는 이보다 더 적합한 표현은 없는 셈이죠.

무엇보다도 다른 저작물보다 더 특별한 보호를 받는 컴퓨터 프로그램-특히 소프트웨어-이기에 그 제작자는 더 특별한 의무를 짊어질 필요가 있습니다. 하지만 실정법은 그러한 의무를 많은 부분 없애 주었습니다. 그 까닭은 불법복제의 가능성이 다른 저작물보다 현저히 높다는 데에 있습니다.
하지만 그렇다고 해서 프로그램의 원본조차 공개하지 않으면서 그 원본을 법률에서 보호해 주어야 한다는 억지까지도 받아들여야 할까요? (현재는 그것이 실정법에 의해 받아들여졌습니다.)
이것은 중대한 모순입니다. 보호의 실체를 저작권자를 제외하고는 아무도 알지 못합니다. 심지어 그 저작권자의 저작권을 침해한 사람조차도 그 사실을 인지할 수가 없는 경우가 생깁니다. 앞으로는 그런 경우가 훨씬 더 많이 생기리라 봅니다.
다른 문제는 같은 프로그램이 서로 다른 분야에서 다른 시기에 저작물로 등록되더라도 알아낼 수 있는 방법이 없습니다. 심지어 그러한 저작물이 서로 다른 분야에서 특허로 등록된 예까지 있습니다. 이런 경우에 둘 가운데 하나는 저작권법 침해입니다.
* 컴퓨터 프로그램은 상대의 프로그램을 알지 못하였다는 이유로 책임을 면할 수 없습니다. 헬렌 켈러의 경우-헬렌 켈러의 저작물이 우연히 당시 유명 작가의 저작물과 매우 비슷하였으나, 보지도 듣지도 못하는 헬렌 켈러가 그 저작물을 알 수 없었다는 이유로 무죄를 선고하였습니다-는 컴퓨터 프로그램에는 적용되지 않습니다.

법률 이론에서는 GPL은 그 자체로 완전한 계약이지만, 실정법에서는 그렇지 않다는 데에 심각한 문제가 있습니다.
많은 나라에서 소스를 공개할 경우 그것을 권리의 포기로 간주하거나, 법적 보호의 포기로 간주하는 법률 해석을 내리고 있다는 점입니다. "법률은 도덕의 최소한"이라는 격언이 이 경우에는 정반대로 적용되고 있는 셈입니다. 우리나라도 그와 비슷하게 법률이 구성되어 있습니다. ㅡㅡ;
만약 GPL과 관련한 재판이 벌어지게 될 때 법관의 성향에 따라 결과가 달라지리라 봅니다. 법관이 영미법의 경우를 더 우선시한다면 미국 판례에 따라 판단하겠지만, 그렇지 않고 법률의 문구를 그대로 해석한다면, 한국에서의 GPL은 그 미래가 불투명하게 됩니다.

아무튼 한국에서는 법적인 해석이 GPL에 불리할 수도 있습니다.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

토비의 이미지

오픈소스코드 활용의 자유가 얼마나 큰 의미가 있고 중요하다는 것은 충분히 잘 알고 있습니다. 고객이나 주변 사람들에게 항상 그런 얘기를 하고 더 나아가 코드의 활용을 통해서 얻을 수 있는 가치가 얼마나 큰지에 대해서도 자주 강조하는 편입니다. 작년엔 마소에 "오픈소스의 소스코드는 개발자를 위한 숨겨진 보물이다"라는 내용의 글을 쓰기도 했습니다.

하지만 그런 얘기들이 점점 공허하게 느껴졌습니다.

오픈소스 제품의 사용자(많은 개발자들은 라이브러리나 프레임워크의 사용자입니다)들은 점점 자신이 사용하는 것이 오픈소스라는 것에 의미를 두지 않습니다. 소스코드의 존재여부 자체에 관심도 없습니다. Free/OSS라고 하면 대부분 "공짜"라는 것에만 관심을 둡니다.

반대로 소스코드가 뭔가 대단한 것을 줄 것이라는 환상에 빠져있는 사람도 많습니다.

의미라는 것은 결국 어떤 것이 가지는 "가치"라는 뜻입니다. 저는 의의(significance)가 없다고 한 것이 아니라 개개인에게 현실적인 의미(meaning)나 가치(value)가 없다고 얘기한 것입니다. 현실적으로 각종 차별이 견고하게 존재하는 한국에서 "평등"이라는 헌법조항이 무슨 의미가 있냐고 항변하는 것과 마찬가지 입니다. 물론 그 평등조항이 있기 때문에 넓게 보면 얼마나 큰 혜택을 받는지 알 수 있겠죠. 하지만 그것이 존재의미가 있다고 해서 현실에서 차별당하는 사람에게 "헌법에는 평등권이 있어"라고 얘기해주는 것이 현실적으로 무슨 유익이 있겠냐는 것입니다.

물론 극히 좁은 시각과 제한된 관점에서 나온 발언인 것은 인정합니다. 제 최근의 경험 때문에 그런 말을 꺼낼 수 밖에 없었습니다. 소스코드에 대해서 막연한 환상을 가지고 있다가 나중엔 그 존재 의미조차 부정할지도 모르는 사람들에게 좀 더 "현실적"이 되자는 얘기였습니다.

그리고 진정한 그 존재 의미를 이해하고 그 가치를 누리며 적극적으로 활용하는 소수의 사람들이 있겠죠. 그들을 무시한 것은 절대 아니기에 저는 이 포스트의 제목에 고쳐 쓰신 것처럼 "아무" 의미가 없다라고는 하지 않았습니다.

마지막으로 오픈소스의 소스코드는 저한테는 개인적으로는 큰 의미가 있습니다. 저는 그 가치를 충분히 누리고 있고 그 점에 대해서 항상 감사하게 생각하고 있습니다. 하지만 이제는 다른 사람에게 그렇게 너도 하라고 "강요"할 욕심은 버렸습니다.

권순선의 이미지

이곳에 올리신 답글과, 그 이후에 올리신 별도의 글을 보니 '오픈소스에서 소스코드는 아무런 의미가 없다.'가 아니라 '내가 아는 주위의 일부 개발자들에게는 오픈소스의 소스코드가 실제로 거의 활용되지 않는다'라고 말씀하시려 한 것으로 생각됩니다. 그러나 저는 처음 올리신 글을 읽고 나서 불특정 다수에게 던진 화두로 생각하였고, 글 곳곳에서 오픈소스에 선의를 가지고 협력하고 함께 발전시켜 나가려는 사람들까지 싸잡아서 그런 일이 그다지 가치없다는 뉘앙스로 표현하신 것에 마음이 상당히 불편했습니다. 그렇지만 그러한 의도가 아니었다는 점은 이제 이해할 수 있겠습니다.

Scarecrow의 이미지

약간 오프성이긴 하지만

가만 보면 프로그래밍 개발환경이 스크립팅/인터프리터 위주로 나아가는 것 같습니다.
중간언어형태로 컴파일하더라도 그걸 다시 인터프리터로 해석하는 언어들
예를 들면 자바나 닷넷 등등은 디컴파일 하면 그냥 소스코드 수준으로 복원됩니다.
심지어 스크립트언어들은 소스/실행파일 구분없이 그냥 소스 그자체가 하나의 완성된 프로그램입니다.

또한 스크립팅/인터프리터의 장점은 기존 컴파일 언어에 비해 익히기 쉽다는 것입니다.
이것은 제작뿐 아니라 유지보수에서도 그대로 장점이 됩니다.
해당 언어를 사용하는 사람을 늘리는 데에도(교육) 기존 컴파일언어보다 오래 걸리지 않을 겁니다.

소스노출은 꺼리지만 이러한 이득을 얻기 위해
스크립팅/인터프리터는 클라이언트사이드가 아닌 서버사이드를 중심으로 발전한 듯 합니다.
클라이언트 사용자가 많은 윈도우에서도 닷넷은 아직 서버사이드 중심인 것 같습니다.
많이 쓰이는 스크립트 언어중에 하나인 php의 유행도 그런 측면이라 생각됩니다.
루비도 레일즈 이후 더욱 주목 받았던 이유도 그런 측면이 아닐까요. ^^

스크립팅/인터프리터 언어는 이득이 있는 반면 소스가 공개된다는 특징이 있습니다.
생각하기에 따라서 소스코드가 공개된다는 것이 단점으로 작용하여
오퓨케이션등의 추가적인 방법도 필요하며 존재하게 되었지만
제가 생각할 때 근본적인 해결책은 프로그램 제작 페러다임이 오픈소스로 바뀌는 것입니다.

그런 관점에서 스크립팅/인터프리터를 가지고 유명해진 클라이언트사이드 프로그램을 보면
제가 아는 것이 적어 그럴 수도 있겠지만 제가 아는한 대부분 오픈소스입니다.
eclipse, azureus, beagle, f-spot, ...

최근들어 주목받고 있는 위젯이라느니 가젯이라느니 하는 것도
자바스크립트로 제작하는 것으로 알고 있습니다.
그래서 기존 프로그램보다 쉽게 제작할 수 있다고 합니다.

컴파일언어에 비해 쉽다는 상대적인 특징일 수도 있지만
쉽게 제작할 수 있다는 얘기는 쉽게 읽을 수 있다는 얘기이고 쉽게 개작할 수 있다는 의미입니다.
즉 오픈소스에 아주 적합니다.
파이썬이나 펄 등의 소스를 바라보며
이건 읽기도 힘들고 그래서 소스가 공개되어 봐야 사용자는 아무런 필요도 없다라는
그런 생각은 컴파일 언어에 비해 어색합니다.

그리고 그 소스는 수정 즉시 컴파일 등의 복잡한 과정 없이 즉시 동작합니다.
그렇게 되면 사용자는 소스코드에 관심이 높아지지 않을까요?

쓰다 보니 길어져서 여기서 마무리 짓자면 오픈소스는 스크립팅/인터프리터의 발전을 통해
지금보다 더 활성화될 것이라 예언(?)합니다. ( 예언까진 오바인가??? =3=3==333 :-)

시그너쳐: ./configure --prefix=/usr; make; sudo checkinstall

ResVera의 이미지

재미있는 예언(?)을 하셨습니다. 유명한 스크립팅 언어들은 쉽습니다. 쉽기 때문에 널리 쓰여 유명해졌을 것입니다. J 등의 스크립팅/인터프리팅 언어는 제대로 쓰기 쉽지 않습니다. 그래서 유명해지기 어렵습니다. (내가 무슨 이야기를 하고 있지..) 여튼, 댓글로 작성하려고 한 것은, '펄' 코드는 쉽게 제작할 수(도!) 있지만 쉽게 읽기 어려운 코드가 되기 쉽다는 것입니다. (쉽다와 어렵다가 섞여 있어서 쉽게 이해하기가 어렵기 쉽습니다. 댓글 달기 어렵네..)

오늘 어떤 블로그에서 본 글이 생각납니다.

"모든 말은 결핍이다. 자신이 말하고자 하는 것을 다 담지 못한다.
모든 말은 과잉이다. 차마 전하지 않았으면 했던 것들도 전하게 된다."

- 스페인 철학자 호세 오르테가이가세트 -

riverful의 이미지

관심갖는 주제라서 몇마디 적고갑니다.

현재 저는, 오픈소스 경험이 많은 것은 아니지만, kernel관련 업종에 있고
linux-media쪽에서 commiter로써 활동중 입니다.
분야는 V4L2이고 driver Author로써 device driver를 컨트리뷰션한 경험이 있습니다.
헌데, 제가 보기엔 오픈소스의 코드가 어려울 수 밖에 없는 이유는 따로 있는 것 같습니다.

아시다시피, mailing이나 IRC등에서 정보교환이 이루어지고 maintainer혹은 reviewer를
설득시켜 ACK를 받아야 contribution자체가 가능하기 때문에, contribution을 바라는
개발자 입장에서는 그들을 이해시키기 위해 정말 쉽고 간결하다고 생각될 만큼 코드를 풀어서
만드는데 주력하게 됩니다.

이 부분에서 문제가 생길 수 있는데요, 일반 개발자들이 생각하는 쉬운 code와
maintainer혹은 reviewer들과 같은 expert들의 보는 눈은
생각보다 "차이가 크다"는 것입니다.

mailing이나 IRC의 100명중 95명이 평범한 개발자들이고
그 분야를 새로 시도하려는 사람들도 많을텐데,
정작 contribution이 되는 code들은 5명 정도의 expert들이 보기에 편하고 심플한
(좀 과장되서 얘기하자면 함축적이고 다른 개발자들이 사용하지 않는 생소한) 코드가
되어버리는 경우가 많습니다.

어느 순간엔가 저도 쉬운 코드보다 함축적이고 짧은 coding을 선호하게 되더군요.
그리고 그 생각이 드는순간, 이것은 open을 저해하는 요소라고 생각이 드네요.
그럼에도 불구하고, 제가 실력이 없어서 라거나 혹은
제가 경험했던 분야가 kernel뿐이라 그런지도 모르겠습니다.

다른 open source쪽 경험자분들은 이런 경험이 없으신가요.

123......

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.