페이지

2013년 12월 11일 수요일

8비트 키즈. 우리는 운이 좋은 세대

얼마전에 출간된 "오픈소스 개발자 이야기"를 보면서 많은 공통점을 발견할 수 있었는데, 그 중 하나가 80년대에 8비트 컴퓨터에서 코딩을 시작한 부분이다. 나도 초등학교 때 5학년 때, 학교 컴퓨터반에서 금성 FC-100으로 베이직을 배웠는데, 당시에는 컴퓨터 학원도 인기가 많아서, 컴퓨터 학원에 다니는 아이들도 꽤 있었다.


당시 컴퓨터가 주는 가장 큰 매력은 컴퓨터를 켜면 바로 베이직 인터프리터 모드로 실행되는 부분이다. 지금 따지면, PC를 켜자마다, Python이 바로 실행된 모습과 같다고 할까?

베이직 프로그래밍은 마치 컴퓨터와 대화를 나누는 느낌이였다. 뭔가 명령을 내리면 컴퓨터는 계산도 하고 그림도 그리고 음악도 연주했다. 정말 대단한 물건이였다. 프로그래밍은 필수 코스였고 이미 중학교 때, 베이직에 어느 정도 익숙해져서 게임을 짤 수 있는 수준이였다. 그 당시 GOSUB 문을 이해하는 것이 어려웠던 것 같다.  일종의 함수 루틴으로서 순차적으로만 실행되는 베이직에서 특정 행번호가 실행되고 다시 돌아온다는 개념인데, 다른 사람이 짠 게임을 보고 이해할 수 있었다. 조기교육 덕분(?)에 나중에 혼자 C/C++도 공부할 수 있었다.

그 당시 8비트 세대 중 코딩 좀 했던 분들이 이제 30대 후반에서 40대 중반에 되어서 현재 한국 IT를 이끌어나가고 있는 것 같다. 90년 들어서 게임기가 유행하고 PC가 도입되면서 학생들에게 코딩은 아마도 생소한 것이 되었을 것이다. 게임기는 정말 게임만 할 수 있지, 거기서 뭔가를 생각하고 만들 수 있는 환경은 제공되지 않는다. PC도 기본적으로 개발 환경을 제공하지 않기 때문에 어린 청소년이 코딩을 하려면 누군가의 도움이 필요하다. 그리고 C/C++는 어린 나이에 처음 프로그래밍을 배우기에는 적당하지 않다. 물론, 웹브라우저만 있으면 자바스크립트로 프로그래밍이 가능하지만, 주로 DOM, BOM API를 이용해서 웹컨텐츠를 만드는 용도라서 프로그래밍을 자체를 배우기에는 적절하지 않다. 이러한 사정으로, 90년대 이후 부터는 자연스럽게 프로그래밍을 배울 기회가 차단된 것이다.

다행스럽게도 어린이에게 쉽게 프로그래밍을 가르치려고 하는 노력들이 있어왔고, 다양한 툴도 개발되었다. 하지만, 8비트 컴퓨터에서 제공되던 베이직 만큼 자유도는 떨어지는 것 같다.

프로그래밍에 대한 접근성을 보면, 기술 발전이 늘 반가운 것은 아니다. 좀 더 쉽게 컴퓨터 자체를 이해하고 프로그래밍을 배울 수 있는 기회가 예전에는 많았으나, 기술의 발전으로 이런 기회가 점점 줄어들고 있다. 어린 나이에 프로그래밍을 접할 수 있었고, 그런 추억을 갖고 있는 것이 8비트 세대만이 갖는 행운인 것 같다. 물론, 지금 세대에 8비트 시절과 똑같은 경험을 강요할 수는 없다. 그래도 뭔가 비슷한 경험을 이후 세대에게도 전해주고 싶다.

2013년 11월 25일 월요일

오픈소스 프로젝트에 참여하는 효과적인 방법


얼마전 아는 분의 소개로 아래와 같은 질문을 받았다.

"오픈소스에 공헌하기 위해, 새롭게 프로젝트를 만들어볼까 했는데, 이미 생각한 프로젝트는 거의 다 있는 것 같고, 기존 프로젝트에 참여하려고 하니, 참여할만한 프로젝트를 찾기가 너무 어려워요. 어떤 분야라도 좋으니, 꼭 구현해야 하는 기능이나, 고쳐해야할 버그, 바로 공부해서 기여할 수 있는 프로젝트 있는지 알고 싶습니다."

참 어려운 질문이다. 솔직히 이런 질문으로 나도 한적이 있다. WebKit Reviewer에게 시급하게 수정해야할 버그나 내가 할만이 일이 있으면 알려달라고 했지만, 대답을 받지 못했다. 아마도, 그 reviewer입장에서 쉽게 해결될 문제면 벌써 해결했을 것이고, 어려운 부분은 내가 해결하기 어렵기 때문에 딱히 알려주기 힘들었을 것이다. 사실, 오픈소스 프로젝트에 등록된 버그 또는 요구사항등을 살펴보면 대부분 딱히 해결방법이 잘 떠오르지 않거나, 많은 시간과 노력이 필요한 버그나 기능이 대부분이다. 한마디로 maintainer도 귀찮아하는 버그만 남아있다고 보면 된다. 정말 쉬운 버그가 있다면, 이미 다 해결되었을 것이다. 그러니 처음 시작하는 분들이 이런 버그를 해결해보겠다고 나서는 것이 상당히 무모한 일이다.

새로 프로젝트를 시작하는 것은 쉽지만, 의미있는 작업이 되기 위해서는 독창적인 프로젝트를 시작해야 하는데, 오픈소스도 이미 red ocean이라서, 이미 비슷한 프로젝트가 상당수 존재한다.

처음부터 새 프로젝트를 시작하는 것 보다, 기존 프로젝트에서 경험을 먼저 쌓는 것도 중요하 것 같다. 그렇다면, 어떻게 하면 나에게 잘맞고 오픈소스 프로젝트를 찾을 수 있을까? 여기서 두가지 중요한 관점 있다.  첫번째, "내가 잘할 수 있는 프로젝트" 두번째, "열정을 갖고 지속할 수 있는 프로젝트"이다.

첫번째, "내가 잘 할 수 있는 프로젝트"를 찾는 것은 쉬을 수 있다. 일단, 본인의 개발 경험이 중요하다. 오랫 동안 게임을 개발했다면, 게임과 관련해서 프로젝트를 찾는 것이 좋다. 임베디드 시스템에서 리눅스 커널 드라이버를 개발했다면 리눅스 커널 프로젝를 참여하면 좋다. 웹개발자라면 JQuery와 같은 JavaScript toolkit에 관심을 가지면 좋다. C++ 개발자라면 역시 C++로 쓰여진 프로젝트가 더 편할 것이고, 윈도 개발자라면, 특정 프로젝트의 윈도용 포트 부분을 공부하다면 더 빠르게 기여할 수 있을 것이다.

두번째, "열정을 가지고 지속할 수 있는 프로젝트"를 찾는 것은 조금 어렵다. 열정이 어디서 부터 시작하는지 각자 다르기 때문이다. 지적 호기심일 수도 있고, 회사 업무나 취업과도 연관성이 있을 수도 있고, 오픈소스 운동/철학에서 열정이 시작될 수도 있다.

예를 들어, Firefox같은 경우, Open Web이라는 철학적 기반이 있다. 웹은 절대 특정 회사나 단체의 소유가 될 수 없고, 누구나 참여해서 웹을 발전시켜 나가야 한다는 것이 주된 내용이다. 이런 생각으로 MS나 Google 틈속에서 Mozilla가 묵묵히 웹이 한쪽으로 치우치지 못하도록 조정자 역할을 하고 있고, 웹이 정체되지 않도록 늘 혁신을 준비하고 있다. 

이런 두가지 관점에서 프로젝트를 찾으면 좋겠다.

한가지 조언을 한다면 너무 성숙한 프로젝트에 참여를 시작하기 보다는 새로 시작하고 혁신적으로 프로젝트에 참여하면 더 좋을 것 같다. 유명한 리눅스 커널 해커인 Alan Cox는  인터뷰에서, 지금 Linux Kernel프로젝트에 참여하지 말라고 조언하고 있다. 너무 방대하고 유명해서, 어떤 문제가 생기면 이미 수 많은 사람들이 관심 갖기 때문이다. 그 대신, 3D Printing, HTML5, WebGL과 같은 새로운 프로젝트에 참여를 권유했다. 이들 프로젝트는 시작한지 얼마안되서 오픈되어 있고, 유연성이 있기 때문에, 누구나 새로운 시도를 할수 있고, 어떻게 될지 모르기 때문에, 일단 받아들이기가 쉽다. 이는 마치 Linux 초기 시절과 비슷하다고 언급했다. 

개인적으로 지금 오픈소스 참여를 시작한다면, Mozilla의 Rust나 Servo에 참여해보고 싶다. 이미 본궤도 올아와 있고, 웹브라우저 개발을 위해 언어 부터 새로 개발하니까, 뭔가 해야할 일이 많이 있을 것 같다. 

아, 생각보다 글이 길어졌다. 짧은 경험으로 이런 글을 쓰려고 하니, 글만 길어진 것 같다. 주제넘지만, 이런 고민을 하는 분들께 조금이나 도움이 되면 좋겠다. 특히 Alan Cox의 인터뷰는 많은 것을 생각하게 해준다. 역시 고수는 달라.

2013년 10월 26일 토요일

Flash를 웹기술로 렌더링?

Mozilla는 늘 새로움을 추구한다. 이제는 Shockwave/Flash(SWF) file을 HTLM/CSS/JavaScript로 렌더링하는 시도를 하고 있다. Plug-in 없는 세상을 만들겠다는 Mozilla의 노력이기도 하고 Adobe가 더 이상 Linux에서 NPAPI기반 Flash를 업데이트하지 않겠다는 발표 때문인 것 같다. 프로젝트 이름은 Shumway이며 이번에 lwn.net에 자세하게 소개되었다. JavaScript만으로도 게임 에뮬레이터가 나오고, 이미 PDF.js로 pdf출력도 가능하니, 기술적으로 불가능해보이지는 않는다.  Firefox mainline에 반영되었고 내년초에 Firefox에 포함되어 릴리스될 것 같다.

분명히 Canvas를 사용했을 것이고, 방대한 Flash spec과 ActionScripts는 어떻게 지원했을까? 여러가지 기술적으로 재밌는 부분이 많은 듯 보인다.



2013년 10월 24일 목요일

한국 오픈소스 개발자 이야기

오픈소스에 대한 책이 하나 나왔다. 오픈소스 프로젝트에 많은 경험을 가진 한국인 개발자를 인터뷰하고, 그 내용을 책으로 엮은 것이다. 부끄럽게도 이 블로그 필자도 인터뷰 대상이 되어 책의 한 부분을 차지하게 되었다.

사실 더 많은 분들이 오픈소스 프로젝트에 기여하고 훌륭한 분들도 많다. 하지만, 다양한 분야를 다루다 보니, 인터뷰 대상이 된 것 같다. 참고로 한국인 오픈소스 기여자 명단은 KLDP wiki에서 확인할 수 있다.

이 책은 KLDP 운영자이며 구글에서 일하시는 권순선님의 아이디어로 시작되었고, 평소 여러 행사에 뵙던 송우일님이 편집했다. 책은 시중 온라인 서점에 판매되고 있지만, 무료로 내용이 공개되어 있다. 

아직 책을 받아보지 못해서 현재 공개된 부분만 읽어봤는데, 기술적인 내용이 다소 담겨져 있지만, 각자의 생생한 오픈소스 경험이 소개되어 있어서 아마 오픈소스 기여를 처음 시작하는 분들에게는 도움이 될 것 같다.

얼마전에  MBC 황금어장에 인공위성을 쏳은 분이 일반인으로 처음 나왔다고 하는데, 오픈소스 개발자도 출현할 수 있는 날이 왔으면 좋겠다. 아마 리눅스 커널 개발자인 허태준님이 나온다면 딱 좋을 것 같다. 

2013년 10월 3일 목요일

BlinkOn Conference

지난 주에 샌프란시스코 Google 사무실에서 열린 BlinkOn Conference에 참석했다. Google이 WebKit Project에서 나와 Blink라는 이름으로 Browser Engine을 개발하기 시작한 이후, 처음 열리는 Blink 개발자 모임이다. WebKit committer로서 Community가 둘로 나누어지는 것은 가슴 아픈 일이였다. 하지만, Apple과 Google이 추구하는 바가 다른 이상, 혁신을 위해 각자의 길을 갈 수 밖에 없는 현실을 지켜볼 수 밖에는 없었다.

여러 회사가 이미 WebKit에서 Chromium으로 옮겨갔다. Qt가 Chromium을 기반으로 웹엔진을 개발하겠다고 발표해서 WebKit Community가 좀 시끄러웠다. Google이 Apple보다는 개방적으로 프로젝트를 운영하기 때문에 이러한 현상은 계속될 것 같다. Google에는 Chromium 관련 내부 mailing list 조차 없다고 하니, 열린 개발 방식이 얼마나 무서운지 새삼 느낄 수 있었다. 이제 Chromium Project가 모든 것을 다 빨아들이고 있다. 여기 승선하지 못하면 왠지 뒤떨어진다는 느낌을 갖게 되는 것도 무리는 아닌 것 같다.

이번 Conference에서 소개된 Blink 현황과 기술적인 내용을 살펴보자.

먼저, Blink의 성능 향상과 위한 노력이 진행중이다. 성능은 Parsing, DOM, HTML, SVG, CSS 처리, Style resolution, Layout, Rendering 등등 전반적으로 모든 부분에서 개선 중이다. Blink내 Web Engine이 가져야할 핵심 기능이 아닌 Platform관련 코드 (예, keycode 변환), Networking(예, WebSocket Protocol), Rasterization 코드를 제거할 계획이다.

이외에 Chromium과 Blink의 모둘화 작업도 진행중이며, Blink와 V8의 garbage collection기능을 통합할 계획이다. Blink는 WebKit과 같이 Smart Pointer를 사용했는데, 이 부분이 모두 변경될 것 같다.
많은 시도들이 앞으로 일어날 예정이다.

Mobile과 관련된 Session이 하나 있었는데, Android Blink가 Desktop가 다른 점와 Mobile 환경의 여러 제약점, 빌드 방법 등을 소개하였다.
Android Blink는 platform코드 일부가 Java로 코딩되어 있어서 JNI로 Blink로 연결되어 있다. Mobile기기는 core개수, memory크기, GPU성능이 많이 뒤지지만 사용자는 초당 60FPS의 성능을 요구하기 때문에 여러가지로 어려운 상황이다. 프로세스를 많이 만들수도 없고 cache memory를 넉넉하게 사용할 수도 없다.  Network도 안정적이지 않고 비용이 든다. 그렇기 때문에, mobile은 특히 Chromium에게는 도전적인 부분이다. 이미 WebKit 기반의 Safari는 mobile에 많이 최적화되어 있지만, Chrome이 이제 시작 단계이다.

Performance 관련해서 Trace Event Profiling Tool이 소개되었는데, 아주 흥미로웠다. 툴을 이용해서 병목 지점을 찾고 code까지 고치는 것을 보여주었다. 특히, frame viewer를 이용해서 Skia paint를 단계별로 replay할 수 있는 기능까지 제공한다.

Rendering관련해서, 사실 Blink가 fork한 WebKit코드는 10년의 역사를 갖고 있고 계속 기능이 추가되다 보니 몇 개의 주요 class의 경우 코드 길이가 매우 길다.  RenderBlock이 6.8k, RenderBox가 4.7K이고 RenderLayer의 경우 HW 가속 및 svg관련 코드를 포함하고 있다.  또한 repaint도  불필요한 repaint를 줄이기 위해 최적화가 필요하다. 예로 table의 경우 여러번 다시 그리는 경우가 많다고 한다. 일부 웹사이트는 CSS 파일 크기도 커서 thread CSS parser를 도입할 필요가 있고, RenderStyle Cache 종류도 많고 복잡도가 높아서 개선이 필요하다고 한다.

Editing은 WebKit에서 독립하면서 maintainer가 없었는데, 이번에 새로 맡은신 분이 Editing 현황을 잘 소개해주었다. 연세가 지극하신 개발자인데, 유머있는 발표가 인상적이였다. 사실, WebKit/Blink의 모든 코드를 다 이해하는 사람은 없다. 특히, Editing부분 소수의 사람만이 이해하고 있는 다소 복잡다고 높고 버그가 많다고 알려져있지만, 발표자는 전혀 그렇지 않으니 많이 기여하라고 이야기해주었다. 재밌는 것은 Rich Edit 기능을 JS로 구현할수도 있다는 사실이다. Web Engine의 일부 기능을 JS로 구현하는 것은 성능이나 메모리 사용 때문에 주저할 수도 있겠지만, 복잡도가 높아서 Engine에서 분리할 수 있다면 나쁘지 않은 선택일 수도 있다.

Open Source 개발자에게 특히 외부 contributor에게는 뭔가 일할 부분을 찾는 것이 쉽지 않다. 그냥 보면 모두 완벽해 보이기 때문이다. 하지만 이런 자리에서 문제점을 확인하고 뭔가 기여할 만한 부분을 찾는 것은 굉장한 소득이다. 그리고, 내 patch를 review한 개발자와 만나 앞으로 개발 방향을 듣고 의견을 나누는 일도 좋았다.

여전히 웹은 진화 발전하고 있다. 이럼 흐름에 직접 기여할 수는 기회를 갖게 되어 기쁘다.

2013년 7월 28일 일요일

WebKit, Blink에 Caret Color Patch 적용 완료!

드디어 WebKit에도 그동안 작업했던 Caret Color patch가 적용되었고 Mac port를 위한 gardening도 끝났다. Blink와 WebKit에 적용된 이번 Patch로 인해 이제 적어도 IE를 제외한 모든 Gecko, WebKit, Blink 기반 브라우저는 같은 방식으로 Caret Color를 결정한다. 사실, Caret Color는 웹표준의 영역도 아니고, 대부분 플랫폼이 어떤 특별한 기준을 갖고 있지도 않다. 그렇기 때문에 브라우저 엔진 마다 Caret Color를 결정하는 방식이 달랐다. 어찌보면 사소한 일이지만, 이 부분이 상당히 눈에 거슬렸고, 나중에 접근성 문제까지 있다는 사실을 알게되어 관심을 갖지 않을 수 없었다. 그렇다면 그 동안 무슨 문제가 있었고 어떻게 해결했는지 잠깐 소개해보려고 한다.

Caret Color 문제는 HTML5 ContentEditable 표준과 관계가 깊다. IE에서 먼저 구현한 이 기능을 Firefox가 구현했고 HTML5 표준으로 채택되면서 이제 모든 브라우저에서 사용할 수 있게 되었다. 하지만 Caret Color에 대한 부분은 표준에서 논의되지 않았다. 어찌보면 플랫폼의 영역같이 보이지만, 실제 Windows를 제외하면 명확한 기준도 없다. 그러다 보니, Caret Color를 선택하는 기준이 애플리케이션 마다 다른 경우도 있다.

 위 비디오에서 봐서 알 수 있듯이, Opera, Firefox, Chromium 브라우저에서 Caret Color가 모두 다른 것을 알 수 있다. 특히, 당시 WebKit엔진을 사용했던 Chromium 브라우저의 경우, 검은 배경에서 Caret이 보이지 않는 특수한 상황이 존재했었다. 아직 반영된 patch가 릴리스버전에 포함되기 까지 시간이 걸리기 때문에 비디오에서 보는 Test Case를 열어보면 아직까지 Caret Color가 서로 다른 것을 확인할 수 있다.

각 브라우저 엔진에서 Caret Color를 얻어오는 방식은 다음과 같다.

1. Firefox : 편집 중인 element의 CSS color property에서 Caret Color를 얻어온다. 위 비디오에서 볼 수 있듯이, element의 Color에 따라 Caret Color가 바뀌는 것을 볼 수 있다.

2. IE: IE는 Windows에서 제공하는 API를 이용해서 Caret을 그린다. 그러므로 모든 응용 프로그램에서 같은 Caret Color를 보여준다. Color 선택방식으로 배경색의 XOR하여 즉, 반전효과를 이용해서 어떤 배경에서도 Caret를 구분시켜준다. 이 방식의 큰 장점은 이미지 배경에서도 Caret이 보일 수 있도록 한다. 단점이라면 회색 배경에서는 다소 Caret이 잘 보이지는 않는 점이다. 특히, 색명인 사용자는 회색 배경에서 반전된 Caret은 잘 보이지 않는다고 한다.

3. WebKit: WebKit은 특이하게 현재 편집중인 element의 최상위 ContentEditable element의 CSS color property에서 Caret Color를 얻어왔다. 예를 들어 body tag에서 contentEditable attribute를 추가했다면 body이하 모든 태그가 편집 가능한데, 바로 편집 가능한 최상위 태그인 body tag의 CSS Color property에서 Caret Color를 얻어온다는 것이다. 그러한 이유로, WebKit에서 대부분 Caret Color가 항상 검은색을 갖고 있다.

2010년에 처음 이 작업을 시작할 때는 Firefox 방식으로 patch를 작성했다. 가장 구현하기 쉽고, 검은 배경에서 검색은 글꼴만 아니면, Caret이 항상 구분 가능 방법이다. 하지만 Reviwer는 글꼴 색상에 따라 변경되는 것은 보기 좋지 않다는 의견을 주었고, 나 역시도 빨갛고 노란 Caret Color는 맘에 들지 않았다. 그래서 나온 아이디어가 배경의 lightness를 얻어서 이에 따라 Caret을 흰색 또는 검은색으로 결정하는 것이였다. 배경색을 얻기 힘든 이미지 배경만 빼면 색맹 사용자도 배려한 괜찮은 아이디였다. 물론 Windows용 WebKit port에서만 Caret를 구한 API를  사용하기로 하였다. 그리고는 다른 일로 인해 이 patch를 더 이상 발전시키지 못하고 시간이 2년 넘게 흐르고 말았다.

다시 Blink에 이 patch를 적용하면서 Caret Color를 구하는 방식을 잘못 이해한 부분과 배경의 lightness를 얻는 것이 특정 상황에서는 상당히 복잡도가 높다는 것을 알게 되었다. 예를 들어, CSS position, z-order, text-align 등 사용하면, 편집되고 있는 자식 element가 부모 element 영역을 벗어날 수 있다. 이 경우에는 좌표를 통해 배경색을 얻어야 하는데, caret를 그릴 때 마다 이런 작업을 하기에는 복잡도가 너무 높다.

결과적으로, 편집 중인 text node를 포함하고 있는 element의 CSS color property에서 Caret Color를 얻어오는 것으로 patch가 작성되었고, 이는 WebKit과 Blink에 모두 반영되었다. 참고로, Chromium Canary버전에서 확인할 수 있다.

아직 caret color 논쟁이 끝난 것이 아니다. 색맹인 사용자도 caret을 잘 구분할 수 있고, image배경에서도 잘 구분할 수 있는 방법이 필요하다.

이제 Firefox, WebKit, Blink가 같은 방식으로 caret를 그리게 되었다. 비록 큰 변화는 아니지만, 뭔가 브라우저간의 차이를 조금 줄였다는데 보람이 느껴진다.


2013년 7월 25일 목요일

OSCON 2013

꿈에 그리던 OSCON에서 드디어 갔다왔다. Expo만 갔다오긴 했지만, 그래도 기분은 좋다. Intel부스에서 동료들을 만나고, 나를 위해(?) Tizen IVI 시스템에서 소녀시대 비디오로 동영상 시연하는 센스!  Samsung 부스에서 옛 동료도 만나고.. 여기 저기 부스에서 T-Shirt도 좀 얻어서 올해 옷 걱정은 안해도 될 듯. RMS 전기도 하나 샀는데, 본인이 2판을 직접 update했다고 한다. 전기에서 자서전으로 바뀐건가?

삼성 부스에서 Rust Project에서 활약중인 서상현님과 Mozilla 사람들 만났다. Mozilla 티셔츠 입고 갔더니 더 반가워해주는 듯. Mozilla 사람들은 정말 오랜만에 만나보는 것 같다.  Rust와 Servo를 개발하는 분들인데, 사실 이쪽은 많이 공부하지 않아서 질문은 못했고, 최근 작업중인 Firefox 한글 입력 버그를 설명할 기회를 갖게 되었다. 한글의 조합원리는 영어로 설명하는 것이 그리 쉽지 않다는 것을 새삼 느끼며(우리말로 설명하기도 쉽지 않다고 스스로를 위안하며)... 그리고, 얼마전에 Linux Kernel 3.8에 merge된 Log structured flash memory file system도 전시장에서 소개되고 있었다. 개발자 분도 직접 만나 잠깐 이야기도 나누었다.

MS, Twitter도 부스가 있었는데, Twitter경우 오픈소스 개발자를 뽑으려고 부스를 만들어놓았다. Twitter 솔루션이 오픈소스 기반으로 동작하며 관련한 개발자를 뽑는다고 했다. MS는 자신들의 툴이 Php와 같은 오픈소스를 잘 지원한다는 것을 홍보하고 있었다.

지난 번 GNOME Asia에 keynote를 하신 GNOME Foundation Executive director인, Karen Sandler 님도 잠깐 만났다.

내년에는 반드시 full time으로 참석을 해야겠다.

2013년 7월 5일 금요일

Why upstream?


오픈소스 소프트웨어를 상용 제품에 적용하는 것은 이제 너무나 당연한 일이다. 특히 리눅스를 기반으로 제품을 개발하는 경우에는. 하지만, 많은 회사들이 여전히 실수하는 것 중 하나가 바로 개발 중에 upstream을 하지 않는 것이다. 도대체 upstream이 왜 중요하며, 개발 중에 upstream하면 뭐가 좋을까?

첫번째, maintainer들에게 code review를 받을 수 있다. 상용 제품에 들어가는 code를 maintainer에게 review를 받는다면 그 만큼 좋은 질의 code가 들어간다는 것을 의미한다. 뿐만 아니라 project 방향과 architecture에 잘 들어맞는지 확인도 해준다. 이는 나중에 upstream 불가능한 사태를 미리 피할 수 있도록 해준다. 또한 maintainer와 함께 patch를 review하면서 개발자도 더 많은 것을 배우게 되고 이는 제품의 품질 향상에 기여한다.

두번째, rebase 또는 merge에 따른 비용을 줄일 수 있다. 보통 제품이 나올 때면 작업하는 code의 기반이 upstream으로 최소 1년 최대 2년정도 차이가 생긴다. 이는 엄청난 차이인데, 나중에 upstream에서 code를 다시 가져올 때, 이미 상품화에 적용된 patch가 upstream에 반영되어 있다면 그 만큼 작업이 쉬워질 것이다.

세번째, code가 죽는 것을 방지
사실 개발자에게 상품화 이후 만들어진 patch를 upstream할 시간적 여유는 주어지지 않는 경우가 많다. 바로 다음 프로젝트에 투입되거나 다른 일을 맡기도 한다. 이런 경우, patch는 죽은 code가 되어 버리고 최소한 License 규약을 지키기 위해 tarball로 묶여서 인터넷 어딘가를 떠돌게 된다. 최악의 경우, 다음 상품화 버전에 다른 개발자가 똑같은 patch를 만드는 경우도 발생할 수 있다.

네번째, 특정 feature 또는 module에 관해 ownership확보 가능
작성한 patch의 규모가 큰 경우, ownership을 가지고 지속적으로 maintain도 가능하다. 이런 경우 자사 상품화 최적화도 할 수 있고 개발 방향을 이끌 수 있다.

그렇다면 왜, upstream을 못하는가?

첫번째, 가장 큰 이유는 code 공개에 따른 체질적 두려움이 있다.
회사 입장에서 비용들여 만든 code를 남이 쓴다는 것, 특히, 경쟁사가 쓰면 어떻게 하냐고 걱정 하는 경우가 많다. 설사 경쟁 회사가 쓰더라도 이미 우리는 상품화를 끝낸 후가 될 가능성이 높다. 그들 역시 upstream으로 부터 먼 code를 기반으로 제품을 개발하기 때문에 바로 해당 patch를 반영하기 어려울 수도 있고, 여러가지 기술적 검토를 안할 수 없기 때문에 patch가 공개된 이후 경쟁사가 이를 상품화 반영하기까지는 당연히 시간이 걸린다.

그리고, 우선 알아야할 것이 오픈소스 소프트웨어를 쓴다는 것이 경쟁사와의 차별화 요소가 아니라는 것이다. 소바자가 제품을 선택할 때, 리눅스 커널 버전 살피고 patch 내용을 살필 수 없다.  오픈소스 소프트웨어는 마치 3rd party에서 부품을 구매하듯이 누구나 공유하는 공공재라고 보면 된다. 기업의 오픈소스 참여는 공동 개발을 통해 개발 비용을 줄이는 것이 목적이지 경쟁사와의 차별화를 위한 것이 아니라는 것을 강조하고 싶다.

두번째, 너무 바쁘다.
최소한 개발자에게 upstream할 시간적 여유를 줘야 하는데, 상품화에 치여 그럴 여유를 주지 못하는 경우가 많다.

세번째, upstream process가 없다.
기업에서 code를 upstream할 때는 최소한의 process가 필요하다. 사소한 bug fix는 그냥해도 되지만, feature단위라면 IP 문제가 있는지도 확인할 필요가 있다. 다른 특허를 침해한다면 복잡한 특허 분쟁에 엮일 수 있기 때문이다. 주의할 점은 개발자에 또 하나의 업무가 아닌 upstream을 장려할 수 있는 process를 만들어야 한다.

Linux Kernel과 WebKit project는 여러 회사가 공동으로 개발에 참여하는 좋은 본보기이다. 살펴보면, contribution을 많이 하는 회사 제품이 당연히 시장에서도 잘 팔린다. 그 이유는 해당 소프트웨어를 더 잘 이해하는 개발자가 좋은 제품을 개발하기 때문이다. 예를 들어, 애플과 노키아를 제외한 모든 스마트폰 제조사가 똑같은 구글의 Android를 기반으로 스마트폰을 출시하고 있다. 하지만 삼성 제품이 독보적으로 잘 팔리고 있다. 이유를 살펴보면, 물론, 디자인도 중요하지만, 삼성이 Android 폰을 만드는 제조사 중에 Linux Kernel contribution을 제일 많이 하는 회사라는 사실은 우연이 아니다. 같은 Android에서 차별화가 가능한 부분은 Linux Kernel과 device driver가 가장 큰데, upstream 경험이 많은 Linux Kernel 개발자를 보유한 회사가 빠르고 안정적인 Android 폰을 만들 수 있는 것은 당연한 것이 아닌가 싶다.

이제 upstream은 선택이 아닌 기업의 경쟁력 확보를 위해 반드시 필요한 전략임을 깨달아야 한다.

2013년 5월 20일 월요일

5월 24/25일 GNOME Asia Summit에 오세요~

드디어 GNOME Asia Summit이 다음주에 서울에서 열립니다. 저도 이번에 발표를 합니다.

이번 행사에서 GNOME Desktop의 최신 기술과 GStreamer, Wayland, WebKitGtk+, HTML5, Linux Kernel, GObject, Tizen 등이 소개됩니다.  직접 참여하는 아래와 같은 튜토리얼도 이루어집니다.

* Introducing GNOME extensions - BinLi
* From Newbie to Translator - Yinghua Wang
* Introduction to GObject and GMainLoop - sunjin yang

저는 GNOME Development on Tizen이라는 주제로, Tizen개발 환경에서  Gtk+ Application을 개발하는 방법을 소개할까 합니다. Tizen과 Tizen 개발 환경을 소개하고 Gtk+ 빌드 부터 간단한 Application개발까지 다루어보려고 합니다. 물론, 실제로 Tizen에서 쓸만한 수준이 되려면 Theme도 새로 만들고 Touch 지원 부터, IME까지 해야할 일이 많습니다. 이제 시작하는 단계이고 제대로된 쓸한 Mobile Gtk+가 탄생할 수 있는 기반 작업이 되었으면 하는 바램입니다.

행사 참가는 여기를 클릭하세요.

2013년 5월 19일 일요일

천재태지와 Tizen 시작하기

Tizen에서  Application개발에 관심을 가진 분은 아마도 천재태지라는 블로그를 이미 알고 있을 겁니다. 삼성전자에서 Tizen EFL을 개발하고 있고 있는 소프트웨어 엔지니어인데, 본인이 너무 좋아서 열심히 Tizen과 EFL에 정보를 많이 올리고 있습니다. 저도 Tizen 개발에 참여하고 있는데, 이 블로그에서 많은 정보를 얻고 있습니다.

처음 Tizen을 시작할 때, 도움이 될 수 있는 연재글이 있어서 제 블로그에 소개할까 합니다.

얼마전에 EFL 한국 개발자 모임도 만들고 최근에는 EFL 세미나도 개최하는 등 열심히 오픈소스 및 커뮤니티 활동을 하고 있습니다. 발표 자료를 보면 왜 오픈소스 개발이 이 분을 열정적인 Evangelist로 만들었는지 알 수 있습니다.

앞으로도 활동이 기대가 됩니다.




2013년 4월 4일 목요일

구글과 모질라의 새 브라우저 렌더링 엔진



만우절이 지난 것이 확실한데, webkit-dev mailing list로 부터 "Thank you"라는 메일이 하나왔다. Eric이 WebKit일을 그만두나 싶었는데, 구글이 Blink라는 새로운 WebKit기반의 엔진의 시작을 알리는 메일이였다.  사실 Google과 Apple은 WebKit의 WebCore만 공유한채 서로 다른 JavaScript엔진과 서로 다른 Multi-process archicture를 가져갔다. WebCore에 새로운 feature 추가를 두고 서로 논쟁도 많았는데, 드디어 다른 프로젝트로 독립한다니 무척 슬프다. 사실 WebKit은 여러 경쟁 회사가 서로 협력하는 성공적인 오픈소스 프로젝트였다. 최근 Apple의 WebKit2 리뷰 정책때문에 불만이 높기는 하지만, 따로 독립한다는 결정은 그리 쉽지 않다.  오직 Google만이 가능한 결정 같다. 하여간, 이제 WebKit를 사용하는 다른 오픈소스 커뮤니티나 회사들의 이후 움직임이 궁금해진다. 일부는 Blink로 갈 수도 있을 것 같다.

Mozilla는 좀 더 혁신적인 프로젝트를 진행중에 있다.


정말 Mozilla 다운 생각이다. Chrome브라우저가 브라우저 기술의 혁신을 주도하면서 Firefox는 다소 주춤한 상태이다. 특히, Multi-process지원은 Firefox가 빨리 수용해야 할 기술인데, Mutil-Core 지원을 중점으로 새로운 브라우저 엔진인 Servo를 개발한다니, 기대가 크다.

지난 몇 년간 Mozilla와 WebKit기반으로 여러 프로젝트를 진행해 온 개발자로서 현재 상황이 상당히 혼란스럽기는 하지만, 오픈소스 개발자로 꿈을 키우는 사람들에게는 새로운 기회가 될 것 같다.



2013년 3월 20일 수요일

오픈소스 코드 문서화가 어려운 또는 쓸모 없는 이유

많은 개발자들이 Open Source Project에 참여하기 어렵다고 불평하는 것 중 하나가 문서화다. 방대한 코드에 버그를 수정하고 기능을 추가하는 일은 쉽지 않다. 그래서 Code에 대한 어느 정도 문서화나 안내서가 있으면 좋은데, 그런 문서를 찾기가 쉽지 않다. 있다고 하더라고 오래된 문서들이다.

왜 그럴까? WebKit Project에 참여하는 입장에서 생각해보면, 코드가 너무 빠르기 변경되기 때문에 문서화하기 어렵다고 이야기할 수 있다. 어느 정도 대략적인 문서화(요구사항 및 디자인 문서) 정도는 가능하지만, 실제 구현된 내용을 Class 수준으로 이야기하는 것은 어려운 일이다.  가능은 하지만, 글쎄, 한달 정도 지나면 Class 코드에 많은 부분이 변경되어 있을 것이다. 실제로 WebKit2의 Hardware Acceleration 코드인 Coordinated Compositing를 분석하고 문서화하려고 노력하고 있는데, 지난 몇 달간 없어진 Class도 있고 Class이름은 대부분 변경되었고, UI Process와 Web Process간의 message도 절반이상 제거되었다. 개발자들이 끓임없이 refactoring하기 때문이다. 일반 프로젝트에서는 refactoring은 잘 하지 않는다. 일단 기능이 구현되어 정상 동작하면 그만이기 때문이다. 하지만, Open Source Proejct는 다르다. 잘 동작하는 기능이라고 하더라도 좀 더 이해하기 쉬운 code를 만들기 위해서 끊임없이 Refactoring을 한다.

이런 상황에서 개발자는 code를 문서화하기 보다는 보다 이해하기 쉽고 간결한 code를 만들기 위해 노력한다. Class, variable, method이름 하나 하나가 제대로 지어졌는지 또 생각하고 의미가 명확한 이름으로 바꾸려고 노력한다.

오랜 시간을 들여 상세하게 문서화를 하려고 했던 나의 시도는 결국 실패하고 말았다. Code를 이해하고, 변경되지 않는 핵심 부분을 문서화 하는 것은 좋다. 하지만, 가장 좋은 문서화는 바로 쉬운 Code를 작성하는 것이다. 가끔 주석으로 설명된 문장들이나 그림들이 성경의 한 구절처럼 느껴질 때가 있는데, 이런 것들이 진정한 문서화 같다.

2013년 3월 12일 화요일

Ubuntu의 새로운 Display Server, Mir

Canonical이 Ubuntu에서 Wayland대신 새로운  Display Server인  Mir를 개발하겠다고 발표하여 인터넷이(lwn.net, Google Plus) 뜨겁게 달아오르고 있다.

Intel주도로 X-Window를 대체하는 Display Server Protocol인 Wayland와 Window & Compositing manager인 Weston 이개발되고 있다. Mobile기기에 리눅스 적용이 확대되고 GPU, Touch Interface가 기본으로 적용되면서 X-Window를 개선하기 위한 많은 노력들이 있어왔다. 하지만, X는 proxy역할만 할 뿐 많은 기능을 compositing manager가 하고 있고, X가 하던 mode setting등과 같은 기능은 커널로 옮겨갔다. 이미 Android도 X-Window 대신 자체 개발한 Window Manager를 사용한다.

Canonical이 Ubuntu에서 Wayland를 사용하겠다고 발표하는 등 X를 대체하는 de-facto표준으로 자리를 잡나 싶었는데, Mir의 발표 소식은 많은 오픈소스 개발자를 어리둥절하게 만들었다.  이유라는 것이 Wayland의 input기능 확장이 어렵다는 것인데, Wayland 개발자들은  Waylnad는 충분히 Ubuntu의 요구사항을 만족하고 있으면 문제가 없다고 대응하고 있다.

Ubuntu가 너무 커버렸나? 어찌돼었던 그들은 Desktop보다는 Mobile에 집중하면서 Wayland로 대응하기 늦다고 생각했던 것 같다. 하지만 이미 Wayland는 Android에서 동작하고 있다.

새로운 시도라면 나쁘지 않지만, 비슷한 것을또 다시 개발하겠다는 것은 시간의 낭비가 아닐 수 없다. Unity를 보라. GNOME Shell에 비하면 무엇이 좋은지 알수가 없다. 물론 Wayland개발이 좀 느리다는 비판도 있었다. 하지만, Wayland Proejct에  함께 참여해서 발전시켜나가도 늦지 않았을텐데, 여로모로 아쉬운 결정이다.

Display Server는 중요한 컴포넌트의 하나이다. 지금까지 Open Source Desktop이 발전할 수 있었던 것은 X-Window라는 de-facto표준이 있었기 때문이다. 이런 표준이 깨지면, Client Application의 호환성을 유지하기가 상당히 어려워진다.

다음 세대 Display Server를 위한 경쟁은 이제 시작되었다.

2013년 2월 26일 화요일

블로그를 옮겼습니다.

tistory를 사용하다가 blogger로 이사왔습니다. 도메인은 그대로 유지하나, 아마 이전 글 링크는 연결이 안될 것 같네요. 글은 예전에 wordpress시절 이쪽으로 백업해둔 것이 있어서 그 이후에 쓴 글만 옮겨놓았습니다.

이번에 여섯번째 이사인가요?  wiki -> tatter tools -> egloos -> 설치형 wordpress -> blogger -> tistory -> blogger

기존 Blogger에 있는 다른 블로그와 통합 관리하기 위해 다시 이사를 했습니다. 여러가지 구글 서비스와 통합도 무시할 수는 없지요.

앞으로 좀 더 열심히 블로그를 해야겠습니다.