'오픈소스'에 해당되는 글 10건

  1. 2008/01/02 맘대로 예언 2008 (?)
  2. 2007/12/10 기업의 목적은
  3. 2007/10/19 OSS 정책 - "리눅스OS `부요 2.5` 기술이전" (1)
  4. 2007/03/22 배포판 중심 메세지 번역의 폐해 - 커뮤니케이션 부재
  5. 2007/03/21 메세지 번역에서 흔히 발생하는 문제와 해결
  6. 2007/03/03 FOSDEM의 자바 프리젠테이션 중 몇 마디
  7. 2007/01/14 어색한 메세지 번역을 피하는 팁 몇가지 (1)
  8. 2007/01/01 Debian/Ubuntu 사용자는 popular-contest를 써 주세요
  9. 2006/12/14 리눅스에 여성 참여를 장려하는 하우투
  10. 2006/12/09 WoC 2006: 기대와 걱정

맘대로 예언 2008 (?)

생각 2008/01/02 06:40
연시를 맞아 수많은 올해 예언 시리즈가 나오는 바, FL/OSS 세계에 대해 올해 벌어질 일들에 대해 써 보려고 한다. OOXML, DRM, GPLv3 적용 등등 FL/OSS 분야의 큰 뉴스거리가 될 만한 이야기는 이런 예언을 보면 될 것이고, 기술 분야에 대한 광범위한 예언은 이런 예언을 봐도 될 것이지만...  국내의 이야기나 직접 관계있고 당장 생각나는 이야기들을 모아본다.

생각나는 대로 뽑아 봤기 때문에 결론은 내리지 않고 문제만 제기하는 것으로 대신하려고 한다.

그놈이 그놈?

언제나처럼 그놈 데스크탑이 3월과 9월에 릴리스될 것이다.  (너무 뻔한 얘기?) 그놈 데스크탑 L10N의 과제에서 말했던 도움말 번역 부분은 2007년에 일단 시작을 했다는 것만으로 만족해야 겠지만, 2008년은 한국어 L10N에 관해서도 더더욱 많은 문서와, 충실한 번역과, 나은 품질의 번역이 들어갈 것이다. 어느정도나 "더"일지는 참여자들이 얼마나 더 많이, 더 적극적으로 하느냐에 달려 있다.  :)

새로운 글꼴?

한편 작년에 뉴스로 나왔던, 2008년 6월까지 개발할 것이라고 하는 NHN의 글꼴이 (계속 진행중이라면) 기대된다. 부디 사악하지 않은 라이선스로 자유롭게 배포/수정할 수 있기를..

지역화 개발

맞춤법검사, 사전 구축, TTS 등 손쓰기 어려운 한국어 관련 신규 개발 이슈 중에서 어느 하나라도 진전이 있지 않을까? (품사태깅 기능은 KPC에서 필요한데...)

리눅스 탑재 장난감들, 한국에 출시될까?


Asus EEE PC - 수입가격과 국내 수요가 문제.
구글 안드로이드 탑재 휴대전화 - 국내 제조업체중 하나가 만들 건 분명해 보이는데, 국내 출시는 미지수.
Nokia N800/N810 - 이건 몇년 됐고 2008년도 안 될 것 같지만 희망사항으로 일단 적어놓고...
리눅스 탑재 WiFi/VoIP 전화기들 - 이것도 희망사항.

오픈웹 vs 금결원 소송의 결과와 그 이후?

오픈웹과 금결원 소송은 작년 초에도 2007년에 어느정도 결론이 나올 거라고 생각했는데 2008년으로 넘어왔다. 합의가 안 될거라고 어느정도 예상했다. 공공기관은 소송의 피고가 되었을 때 합의해서 생긴 손해를 담당자가 책임진다고 생각하고 패소해서 생긴 손해를 조직 전체가 감수한다고 생각해서인지, 지는 입장에서는 최종 소송까지 가는 선택을 하는 게 보통이다. 금결원 소송이 결론이 나면 다른 기관을 상대로도 진행이 될까?

이제 리눅스에서 웹질을 할 만해 질까?

2000년대초에 비하면 나아졌지만, 플래시 비디오인 척 하는 activex 사이트가 (uccc, 판도라tv) 등장하질 않나, 플래시가 만능이라고 플래시로 이상하게 만들어서 문제를 일으키는 사이트가 (MBC) 등장하질 않나, 어떻게 한 건지 몰라도 리눅스용 플래시에서만 잘 죽게 만든 플래시 비디오 사이트가 (엠엔캐스트) 등장하기도 하고 시련은 끊기지 않았다. 하지만 언터처블이라고 생각했던 전자정부가 2007년 초에 표준준수 원칙을 공표했고 제한적이나마 ia32 리눅스를 지원하기 시작하는 걸 보면 새로운 시련이 닥치더라도 영원히 가는 시련은 없을 것이고 만족스러운 속도는 아니겠지만 조금씩이나마 개선될 것 같은 생각이 든다. 2008년에는 그놈 애플리케이션과 최근의 웹 서비스들과의 연동 문제를 개선하는 데도 참여하고 싶다.

GPL 위반 기업은 언제까지?

GPL 위반에 대해 무감각했던 한국 기업들은 올해에는 얼마나 솔직해 질 수 있을까? (1, 2, ...) 오래전도 아니고 2년 전에, 바로 한국에서, 꽤 유명한 리눅스 기반 휴대용 게임기인 GP2X를 만든 (주)게임파크홀딩스는 "GPL을 위반했다"는 정도가 아니라 "GPL을 이해하지 못한다"는 비아냥을 받은 적이 있다. 우여곡절 끝에 게임파크는 제대로 개발포럼에 소스코드와 SDK를 릴리스했고 GP2X는 지금도 매니아들에게 꽤 괜찮은 홈브루 게임기로 판매되고 있다. 이제 GPL 이슈를 생각도 안 하거나 고의로 무시하는 기업들은 정신 차려야 할 일이다..

"공개SW" 정책은 어떻게?

"open source"라는 말이 "free software"가 듣기에 불편해서 새로 만든 용어임에도 불구하고, 오픈소스라는 말조차도 듣기 불편했는지 한국 정부가 새로 만든 물타기용 용어, "공개SW". 공개SW 활성화 정책 중에서도 실행 과정에서 가시밭길을 걸어왔으면서 부풀리기도 힘들 정도로 성적이 초라했던 (하지만 실행되면 효과는 클 것 같은) "공공기관의 공개SW 도입"이 2008년에는 얼마나 실행될 수 있을까? 아니면 새 정부 들어서 이 쪽 정책이 방향이 완전히 바뀔 가능성은?

한편 지금까지의 정책은 너무 쉬운 방법의 단기적인 예산 집행에 급급했던 게 아쉬웠다. 아쉬웠던 제도적 개선도 이루어졌으면 한다.

북한이 눈에 뜨일까?

6자회담에서 북한의 테러지원국 해제 문제가 순탄치 못하더니 결국 2008년으로 넘어왔다. 갑자기 왠 외교 문제냐 하겠지만 FL/OSS 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?


Trackback 0 : Comment 0

기업의 목적은

생각 2007/12/10 08:25
오래전 술집에서의 대화:
사원A씨: 돈도 별로 못 버는데 왜 이렇게 고생하며 일해야 되는 지 모르겠어요.
창우: 글쎄, 돈을 많이 벌려면 호스트바에서 일하는 게 더 많이 벌겠지.
사원A씨: ...
창우: 은행을 털어도 좋고.

"기업의 목적은 이윤 추구이다." 맞을까? 중고등학교 경제 교과서 개요에 등장할 만한 이 문장, 시험에 괄호 채우기로 나올 만한 이 문장은, 사람들이 의심할 생각도 하지 않을 정도로 명백해 보이는 문장이다. 정말 기업의 궁긍적인 목적이 이윤 추구일까?

정치 쪽에도 비슷한 문장이 있다. "정당의 목적은 정권 획득이다" 그러면 목적인 정권 획득을 위해서 뭐든지 해도 되는 걸까? 불법적인 돈 거래나, 폭력을 행사해도 되는 걸까? 여론의 변화에 따라서 선거에서 많은 득표를 할 수 있도록 정당의 정책이 이랬다 저랬다 해도 되는 걸까? 정권을 획득하는 방법인 선거에만 목을 매는 정당이 정당의 본래 목적을 충실히 수행하는 걸까? 실제로 지금까지 한국의 정당들이 실제로 그렇게 부정하거나 비도덕적인 방법으로 정권을 획득하기도 했지만, 그런 모습을 당연하게 생각하는 사람은 별로 없다. 정치를 통해 이루고 싶은 정치적 신념이 없다면 정권은 무엇때문에 획득하는 건가?

영화 에일리언에 나오는 웨일랜드유타니 코퍼레이션이나, 아니면 TV쇼 엔젤에 나오는 울프람앤하트 법률 사무소처럼 폭력, 뒷거래, 음모가 회사의 주요 업무가 되어도 이윤추구를 위한 정당한 활동을 한 것인가? 이 회사들이 총을 들고 우리를 죽이려고 해도 회사가 이윤추구를 위해 움직이는 게 당연한데 왜 반항하냐고 리플을(!) 달건가?

KLDP의 글과 댓글들을 읽다보면, 오픈소스가 확산되면서 제대로 된 이해는 확산시키지 못하고 마케팅 용어로 사용되는 오픈소스라는 말만 확산된 것만 같다. 조금 관련이 있다고 오픈소스라고 칭하는 기업, 오픈소스 정의에 맞지 않는데도 오픈소스라고 주장하는 기업, 심지어는 라이센스를 어겨가며 단물만 빨아먹는 기업, 그런 기업들을 "기업의 목적은 이윤 추구..." 이런 구태의연한 말까지 꺼내가면서 이해해 줄 필요가 있을까?  복잡하게 기업의 목적이나 국수주의까지 덮어 씌우지 말고..

Trackback 0 : Comment 0

OSS 정책 - "리눅스OS `부요 2.5` 기술이전"

Misc/정책 2007/10/19 20:58
리눅스OS `부요 2.5` 기술이전

ETRI 공개SW솔루션연구팀 우영춘 팀장은 "부요는 그동안 수 차례의 기술이전을 통해 국내 공개SW 활성화에 매우 긍정적인 영향을 미쳤다고 본다"며 "이번에 기술이 이전되는 부요 2.5 버전은 데스크톱 SW 플랫폼의 경우 업데이트 기능이 대폭 강화됐고, 서버 SW 플랫폼은 최근 업계의 이슈가 되고 있는 가상화 기능이 포함된 것이 특징"이라고 말했다.

여유가 되면 부요 프로젝트의 문제에 대해 모두 써보겠지만...  (한국형 규격이라는 어긋된 방향, 정부기관 주도의 커뮤니티가 없는 폐쇄적 진행 등등)  그 중에서도 한 가지 문제가 지금 당사자들이 하고 있는 자화자찬식 정책 평가의 문제이다. 생색내기와 과장된 보도자료는 부요 관련뿐만 아니라 모든 정부산하기관의 문제이기도 하지만, 부요가 대체 어떤 긍정적인 영향을 미쳤다는 건지 이해하기 어렵다. 현재 상황은 오직 부요를 만든 당사자들만 부요에 대해 말하고 있는 실정이다.

부요 규격이 하는 일이 레드햇/수세/우분투의 최신 기능과 (업데이트/가상화) 최신 버전을 써 넣는 것일까?  실제 현재까지 표준화된 규격을 보면 부요 규격은 리눅스 커널 옵션, LSB/FHS, 그리고 Fedora 최신판을 설명한 것에 지나지 않는다.

Trackback 0 : Comment 1

배포판 중심 메세지 번역의 폐해 - 커뮤니케이션 부재

L10N 2007/03/22 05:54
과거에도 그랬듯이, 배포판 중심의 메세지 번역은 보통 그 배포판 안에서만 사용되고 그 안에서 수명을 다한다.

우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.

간단히 예를 들어 우분투 feisty의 한국어 번역 중에서 KDE 관련 프로그램은 로제타에서 많은 부분이 번역되어 있다.  많은 부분이 비슷한 모습을 보이지만, 꽤 많이 번역된 일부분을 보면,

사용자 삽입 이미지


그럼 KDE upstream의 한국어 통계를 들어가서 이 부분이 업스트림에 어떻게 되어 있는 지 확인해 보자.  위에 나온 kdebase를 비교해 보면 다음과 같다.  거의 반영이 되어 있지 않다.

사용자 삽입 이미지


그럼 보너스로 또 한 가지 비교해 보자.  한소프트리눅스는 어떨까?  한소프트리눅스 오픈 프로젝트에서 kde-i18n 패키지의 src.rpm 파일을 받아서 확인해 보았다.
zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ for X in kcm*po; do msgfmt --stat $X -o /dev/null; done
번역된 메시지 70개.
번역된 메시지 47개.
번역된 메시지 68개.
번역된 메시지 121개.
번역된 메시지 21개.
번역된 메시지 8개.
번역된 메시지 67개.
번역된 메시지 34개.
번역된 메시지 180개.
...
어라?  -_-  완벽한데 대체 무슨 일이 벌어진 것일까?  과연 누가 이걸 번역했는지 알아보기 위해 PO 파일의 Last-Translator: 엔트리를 찾아보았다.
zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ grep Last-Translator: kcm*po
kcmaccess.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmaccessibility.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmarts.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbackground.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbell.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcgi.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcolors.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcomponentchooser.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcrypto.po:"Last-Translator: root <root@localhost.localdomain>\n"
...
다름 아닌 한소프트리눅스 측에서 자체 번역한 결과물이다.  (위의 결과로 알 수 있는 사실, 번역자는 루트 계정으로 KBabel을 이용해 번역한다.)  이것이 한소프트리눅스 광고에 등장하곤 하는 "전문 번역팀을 통해 자연스럽지 못했던 한글 번역부분을 말끔히 개선하였습니다"의 실체인가?

"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다.  FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다".  배포판 업체들도 마찬가지이다.  번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다.  런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.

이 상황을 어떻게 해결해야 하나.  업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..

Trackback 1 : Comment 0

메세지 번역에서 흔히 발생하는 문제와 해결

L10N 2007/03/21 05:24
보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다.  이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다.  번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 5개국 번역이 되었는데 (정확하진 않지만) 60-70여만원정도가 필요했다.  (그러면 GNOME 2.18의 한국어 메세지는 35000여개가 되므로 이 계산법에 따르면 수억의 가치가 있다고 할 수 있다. ^^)

그 번역 업체는 IT 전문 번역을 표방했고 상당히 많은 경험이 있는 것으로 보였다.  하지만, 번역이라는 건 그렇게 뚝딱 할 수 있는 게 아니다. 번역이라는 작업은 한계가 있다.

1. 번역자가 CCTV 시스템에 대한 지식이 부족했다.  예를 들어 전통적인 보안 시스템에서 NC/NO는 Normally Close, Normally Open으로 보안용 센서의 종류를 나타내는 말로 "붙은" 상태가 정상인가 "떨어진" 상태가 정상인가를 나타내는 말이다.  (예를 들어 출입문에 부착하는 접점 센서는 닫혔을 때 즉 붙은 상태가 정상이고 문을 열면 떨어지면서 센서가 activate된다.) 하지만 많은 번역자가 NC를 (유행이 한참 지난 용어인) Network Computer라고 번역하기 십상이었고 NO를 Number의 약자로 번역하기 십상이었다.

2. 꽤 오랜 기간동안 제품을 업데이트하다 보니 번역을 하면서 일관성이 맞지 않는 부분이 많이 발생했다.  의뢰인인 우리쪽 입장에서는 사실 누가 번역했는지는 알 수도 없고 신경도 안 쓰는데, 같은 용어를 여기저기서 다르게 사용한다든지 말투가 달라진다든지 하는 일이 그 언어를 전혀 모르는데도 뻔히 알 수 있을 정도로 자주 발생했다.

3. 번역 업체와는 상관없지만 번역한 결과를 적용할 때마다 언제나 화면 크기의 부족에 시달렸다.  작은 NTSC/PAL TV 화면의 크기에 맞춰야 하는 입장에서는 난감하기 짝이 없었다.  화면상의 각종 컨트롤의 크기를 dynamic하게 만들고 복잡한 클리핑과 스크롤 기능으로 보완해 보려고 했지만 결국 한계가 있었고, 특히 이탈리아어와 스페인어의 경우 점(.)으로 단어를 줄여쓴 (Abracatabra라면 Abra. 식으로) 신조어 레이블이 화면의 많은 부분을 차지하게 되었다.

옛날 얘기는 여기까지 하고 현재로 돌아와서, 위의 현상은 오픈소스 소프트웨어의 메세지 번역에도 똑같이 적용된다.  얼마전에 그놈 2.18이 릴리스되었지만, 여전히 (1) 메세지의 일부는 해당 프로그램의 기능에 대해 잘 이해하지 못한 부분때문에 오역이 있고, (2) 업데이트하면서 가끔 말투와 용어를 다르게 쓰기도 하며, (3) UI의 문제때문에 번역해 놓은 모양이 아주 보기 나쁜 경우가 많이 있다.  이와 같은 실수는 번역자의 실력과 경험에 따라 달라지겠지만 여전히 발생한다.

이와 같은 문제를 100% 없애기는 쉽지 않다.  실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다.  역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.

그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...

Trackback 0 : Comment 0

FOSDEM의 자바 프리젠테이션 중 몇 마디

생각 2007/03/03 23:02
FOSDEM 비디오 중에서 썬의 "Liberating Java" 프리젠테이션을 보다가 맨 앞에 소프트웨어 특허에 관해서 이야기하다가 나온 이야기:
특허를 출원하는 이유는, 미국 사람들이 총을 구입하는 이유와 비슷합니다.  미국 사람들이 총을 구입하는 이유는, 미국 사람들이 총을 구입하기 때문입니다.  미국 소프트웨어 회사들이 특허를 출원하는 이유도, 미국 소프트웨어 회사들이 특허를 출원하기 때문입니다.
공감 100%.  지금까지 경험한 회사가 비교적 작은 회사였기 때문이었을까?  지금까지 회사에서 특허에 관한 교육이나 특허에 관한 이야기가 나올 때마다 항상 처음에 소개하면서 듣는 이야기는, "특허가 없으면 특허 분쟁이 발생했을 때 X된다"였다.

(이 비디오에는 그 외에도 자바 이슈에 관심있는 사람이라면 재미있는 내용이 많다)

Trackback 0 : Comment 0

어색한 메세지 번역을 피하는 팁 몇가지

L10N 2007/01/14 19:06
문장 부호를 똑같이 붙이려고 하지 말아라.
- 우리말에서는 문장에 세미콜론을 쓰지 않는다.
- 원문에 쉼표가 있다고 번역문에 쉼표를 넣을 필요는 없다.  우리말로는 쉼표를 쓰지 않아도 문장이 명확한 경우가 많다.
- 영어에서는 흔히 문장 끝에 괄호를 열고 괄호를 닫은 다음 마침표를 찍는다.  하지만 우리말에서는 그렇게 쓰지 않는다.

영어 문장의 처음에 쓰인 대소문자를 그대로 따라할 필요는 없다.
- 영어에서는 첫 단어가 소문자로 쓰는 단어일 경우에도 (프로그램 이름 따위) 대문자로 만들어서 쓴다.  그대로 쓰지 않도록 신경 쓴다.

관계사가 줄줄이 붙은 문장을 한문장으로 번역하려고 순서를 여기저기 뒤집지 않는다.
- 어느정도 같은 말을 반복하더라도 여러 문장으로 쓰는 편이 낫다.  한 문장으로 쓰려고 하다가는 오히려 말 순서가 바뀌어서 핵심단어가 뒤에 가는 등 의미가 불명확해질 수가 있다.

Trackback 0 : Comment 1

Debian/Ubuntu 사용자는 popular-contest를 써 주세요

Debian 2007/01/01 05:06
프로그래밍을 모르는, 혹은 프로그래밍하기 귀찮은 (...) 사용자가 프리소프트웨어 프로젝트에 기여할 만한 일은 여러가지가 있습니다..  하지만 그 여러가지도 (버그리포트, 번역, 문서, 커뮤니티, ...) 생소한 대부분의 사람들에게는 귀찮기 짝이 없죠.  그래서 이 글을 끝까지 다 보기 전에 끝낼 수 있는, 별로 귀찮지 않은 한 가지 간단한 방법을 떠올렸습니다.  개인정보를 팔 통계 작업에 참여해 주시면 상당한 도움이 됩니다.

데비안/우분투 사용자라면 popularity-contest를 설치하시고, 혹시 이미 설치되어 있다면dpkg-reconfigure 명령으로 이 기능을 사용하도록 설정하십시오.  개인정보를 파는 건 농담이고, popular-contest가 보내는 하드웨어 정보는 무슨 아키텍쳐를 사용하느냐 정도뿐이고 (사실 lspci -v 결과같은 것 좀 수집해 봤으면 좋겠는데), 시스템에 무슨 꾸러미(패키지)가 깔려 있나의 정보만 보냅니다. 

popularity-contest 설정

명시적으로 설정해야만 정보를 보내기 때문에 (당연히 사용자의 명백한 동의가 있어야 되겠죠) 전체 사용자 규모에 비하면 현재 2만명 정도의 통계는 별로 충분한 숫자가 아닙니다.  위에 스크린샷에 쓰여있는 것처럼 CD 만들 때 우선순위를 결정하는 용도에도 쓰이고, 부족한 점을 개선하는 데에도 중요한 자료가 됩니다.  예를 들어 http://popcon.debian.org/unknown/by_vote 여기를 보면 데비안에 없는 아마도 non-free인 꾸러미를 뭘 깔았냐를 볼 수 있고 데비안에 무엇을 개선해야 하는지 참고 자료가 됩니다.  (멀티미디어 툴들, JDK, skype, opera, ...)

데비안의 경우에는 http://popcon.debian.org, 우분투의 경우에는 http://popcon.ubuntu.com 사이트에서 정보를 볼 수 있습니다.

BSD 사용자라면 BSDstats 프로젝트에 참여할 수 있습니다.  (http://openlook.org/blog/1116)

Trackback 0 : Comment 0

리눅스에 여성 참여를 장려하는 하우투

Misc 2006/12/14 03:57
오늘 컨퍼런스에서 민망한 사진이 프리젠테이션에 노출된 사고에 대한 블로그 글을 읽으면서 HOWTO Encourage Women in Linux 문서도 끝까지 읽게 되었는데..  여러가지 생각해 볼 기회가 많았다.  하우투 강력 추천!

이 중에서 특히 리눅스를 기피하는 이유를 인용하면:

Linux development is more competitive and fierce than most areas of programming. Often, the only reward (or the major reward) for writing code is status and the approval of your peers. Far more often, the "reward" is a scathing flame, or worse yet, no response at all. Since women are socialized to not be competitive and avoid conflict, and since they have low self-confidence to begin with, Linux and open source in general are even more difficult than most areas of computing for women to get and stay involved in.

(대충 의역) 리눅스 개발은 프로그래밍의 다른 분야보다도 더 충돌이 심하고 험합니다. 어떤 경우 코드를 작성해서 얻는 보상이라곤 어떤 지위를 갖거나 상대방로부터 허락받는 것일 뿐일 수도 있습니다.  심지어는 그 "보상"이라는 게 비난에 가까운 플레임일 수도 있고 더 나쁜 경우는 아예 아무런 반응이 없을 수도 있습니다. 여성들은 사회화되면서 다른 사람과 충돌을 피하고 조화롭게 지내도록 훈련받습니다.  또 그런 충돌을 시작할 만한 자신감이 부족합니다.  그래서 리눅스와  일반적인 오픈소스 분야는 다른 분야의 컴퓨팅보다도 훨씬 더 여성의 참여가 어렵고 참여를 계속하기도 어렵습니다.

간단하게는 IRC에서 여성에게 남자친구에 대해 질문을 한다던지, 생각없이 내뱉는 말이나 여러가지 가정들이 여성에게는 그 커뮤니티를 기피하는 원인이 된다. 

지난 12월 3일에 있었던 오픈소스 뛰어들기 행사에서는 특이하게도 참석자에 대해 여성 쿼터제가 있었지만, 결과적으로 15명이었던 쿼터 수를 줄이고 했지만 실제 참석 인원은 그에 미치지 못했다.  혹시 기피 요인들이 있었을까?  (물론 의도한 건 아니지만)  여성 강사가 없다든지, 주제나 형식이 부담스러웠을 수도 있고, 새로운 사람이 들어가기 어려웠었을 수도 있었을 것이다.

Trackback 0 : Comment 0

WoC 2006: 기대와 걱정

Misc 2006/12/09 15:43
몇년간 "공개소프트웨어 진흥정책"의 교육분야에 집행된 예산은 제도적인 문제때문에, 대학의 연구비 정도로 소비될 수밖에 없었다.  이른바 눈 먼 돈이라서 기간과 금액에 비해서 터무니없이 쉬운 주제라던지, 오픈소스와 관계없는 주제에 연구비를 집행한 경우가 많았다. 그리고 실제 프로젝트 진행이 "오픈소스럽지 않게" 공개/피드백/지속적인 관리가 되지 않았고 보고서와 함께 종료되었다.  사업의 목적이 인력 양성이긴 하지만 지금까지와 같은 방식으로는 그 목적을 달성하기 어렵다고 보인다.  그저 대학 연구실을 조금 풍족하게 하는 정도의 효과밖에 없었다.

이번에 열릴 Winter of Code는 기대를 갖게 한다.  적어도 개인에게 보상이 지급되고 좀 더 제대로 된 심사를 거칠 수 있을 것 같다.  (역으로 별로 많은 보상금이 아니기 때문에 엉터리 주제가 더 적을지도?)   하지만 괜히 높은 눈높이와 기대때문에 WoC 2006에 대해 걱정스러운 의견을 말해 보자면...

첫쨰로 프로젝트의 범위가 너무 제한되고 편향될 수가 있다.

학생이 프로젝트를 제안할 수 있다지만..  일단 기업은 기업이 필요해서 제안한 프로젝트를 우선 선정할 수밖에 없을 것이다.  커뮤니티의 경우에도 학생이 제안한 프로젝트를 수용할 만한 오픈소스 개발 커뮤니티가 마땅히 없고, 제안받은 프로젝트에 대해 멘토를 선정하고 검토하기에도 사람이 별로 없을 것 같고, 있다고 해도 준비시간이 많이 부족하다.  (게다가 SoC와는 달리 단체에 대한 지원이 없다.  SoC도 500 USD밖에 안 되긴 하지만..)  결국 학생이 제안한 프로젝트보다는 기업이 필요로 하는 프로젝트를 학생이 수행하는 방향으로 흘러가지 않을까?  실제 수행되는 프로젝트는 현재 제안되어 있는 프로젝트에서 크게 벗어나지 않을 것으로 보인다.

게다가 현재까지 올라온 프로젝트들은 웹 서비스 관련 소프트웨어에 너무 편향되어 있다 (게다가 평범한 학생들의 실력으로는 기간내에 끝내기 어려운 난이도로 보인다.  심지어 WoC 소개 문구에도 "만들어낸 결과물은 실제 서비스에 적용되는 기회를 얻게 되며..."라고 쓰여 있다.  사실 웹은 중립적이라서..  프로젝트를 오픈소스 세계(?)에서 해 보려는 생각이 없는 학생도 얼마든지 상금을 타기 위해 참가할 수 있는 것 아닐까.

둘째로 취지에 맞게 참가 학생이 오픈소스에 참가할 수 있는 기회가 될 지 걱정이다.

학생이 2개월이 좀 넘는 기간에 익힐 수 있는 기술적인 내용은 어차피 한정되어 있다.  SoC가 학생들에게 주는 가장 큰 영향은 프로젝트를 하는 과정에 있다고 생각하고 기술적인 것보다 훨씬 큰 부분이다.  그냥 프로젝트를 제안하고 멘토와 메일만 교환하면서 마감에 맞춰 끝내기만 하는 게 아니라, 기존에 진행중인 프로젝트에 참여해서 계속해서 공개적인 커뮤니케이션을 하고 중간에 결과를 내놓아서 피드백을 받고 하는 과정이 더 중요하다.  그리고 그 과정 자체가 상당히 재미있기 때문에 의욕을 불러일으킨다!  (SoC에서도 참가자가 그런 과정을 무시해서 안 좋은 평가를 받는 경우가 있었지만..) 

하지만 애초에 국내에서 그런 커뮤니케이션의 재미를 느낄 만큼 활발하고 규모있는 개발 커뮤니티가 전무하기 때문에 (물론 행사 기획의 문제가 아니라 현실의 문제라서 딱히 해결책도 없지만) 그 분위기를 느낄 기회가 없을 걸로 보인다.  게다가 앞에서 얘기한 것처럼 기업이 제안한 프로젝트 중심으로 흘러갈 것 같아서 더욱 오픈소스같지 않게 진행될 것만 같다.   멘토의 진행 방식에 따라 얼마든지 달라질 수 있는 부분이긴 하지만 걱정스럽다.


첫 술에 배부를 순 없겠지만, 이 행사에 기대하는 사람이 많은 만큼 더 바람직한 방향으로 진행되었으면 좋겠다.  어떤 사람들은 미숙한 학생들보단 지식을 갖춘 개발자에게 실질적 성과를 달성하도록 하는 게 낫지 않느냐고도 하지만, 나는 미숙하고 성과가 없더라도 학생들을 대상으로 하는 일이 중요하다고 생각한다.   동서를 막론하고 오픈소스 개발자가 탄생하기에 좋은 사람, 환경, 시간적 여유를 갖춘 곳이 바로 대학이지만, 국내 대학들은 담당 교육자들이 경험했던 환경이 그래서인지 취업위주의 교육이라서 그런지 PC 환경 위주로 편향되어 있다.  (그렇지 않다고 생각했던 모교에서도 그 멋진 엑스터미널들이 사라지지고 윈도우 PC가 차지했다는 이야기를 들어서 몹시 서운. )  정책적인 이유든 오픈소스의 실질적인 수요가 있는 경우든 학교에 피드백을 줘서 지속적으로 개발자가 나오게 만들 필요는 있다.


tags : 오픈소스
Trackback 0 : Comment 0