OS/2 사용자로서 오픈소스 활동하면서 느낀 것들
개인적으로 OS/2 라는 OS 를 즐겨 사용한다. 한 때는 주류 OS 가 될 뻔 했지만, Windows 에 밀려나더니 결국 IBM 은 2006년에 지원을 중단했다. 하지만 다행히도 이후 다른 업체들(Senerity -> Mensys -> ARCA NOAE)과 OS/2 사용자 커뮤니티의 도움 덕택에 eComStation 이라는 이름으로 계속해서 지원되고 있다. 하지만 비주류 중에서도 비주류가 된 것은 부정할 수 없다. Haiku 심지어는 DOS 보다도 대우를 못 받고 있는 듯하니까. 비주류임에도 불구하고 상용 OS 이라서 그런지도.
어쨌든 이런 비주류 OS 를 쓰다 보니 대부분의 F/OSS 프로젝트를 이용하려고 하더라도 패치없이 쓸 수 있는 경우는 정말 극히 드물다. Linux 나 Windows 에서는 가장 일반적인 절차인 ./configure -> make -> make install 만 하면 되지만, OS/2 에서는 모든 단계에서 패치가 필요하다. 그렇다보니 되도록이면 새로운 프로젝트를 추가하지 않으려는 마음이 생겼고, 어쩔 수 없이 사용해야 하는 프로젝트를 빼고는 프로젝트 사용을 최소한으로 줄이고 있다.
처음에는 개인적으로 간단한 프로그램을 만들다가, 점차 OS/2 에서 사용되고 있는 F/OSS 프로젝트에 참여하게 되었다. 워낙 개발자 수가 적다보니 새로운 개발자의 참여를 매우 반기는 분위기였고, 덕분에 보다 적극적으로 참여할 수 있었다. 한 번은 예전 메일을 본 적이 있었는데, 어떤 코드에 대해 논쟁이 있었다. 지금 와서 보면 상대방 말이 맞았는데, 왜 그렇게 우기고 있었는지 이해가 되지 않았다. 어찌나 부끄러워지던지. ^^
이후 멀티미디어쪽에 관심을 많이 가지면서 다른 OS 의 F/OSS 프로젝트에 관심을 가지게 되었다. 시작은 FFmpeg 이었던 것 같다. 한 번은 OS/2 코드가 삭제되었었는데, 예전 코드를 다시 살리려니 이것이 잘못 됐다, 저것이 잘못 됐다, 이러는 것이다. 도무지 이해가 안됐었다. 그저 예전 코드를 그대로 되살리는 것 뿐이었는데, 왜 이러는 것일까 ? 결국은 FFmpeg 관리자가 원하는 형태로 코드를 재작성했다. 이 과정을 거치면서 코드를 빼기는 쉬워도 다시 넣기는 정말 힘들구나 하는 것을 뼈저리게 느꼈다. 그리고 사실 이전 코드보다 관리자의 요구대로 새롭게 정리된 코드가 더 나은 것은 사실이었다.
FFmpeg 의 FFplay 를 바탕으로 KMP 라는 OS/2 용 플레이어를 만들었었다. 이보다는 다른 플레이어를 포팅하는 것이 더 낫지 않을까 하는 생각이 들었고, 그 시작이 MPlayer 이었다. 예전에도 MPlayer 를 OS/2 로 포팅하려는 시도가 있었고, OS/2 의 WarpVision 이라는 플레이어는 MPlayer 의 코드를 무단 이용하기도 했었다. 하지만 여전히 공식 포트가 존재하지 않던터라, 포팅을 시도하였다. 패치를 OS/2 커뮤니티에서만 쓰고 있었는데, 공식 프로젝트에 패치를 합쳐야겠다는 생각에 메일링 리스트에 보냈는데, 역시나... 한 번에 될 리가 없다. 패치를 한꺼번에 보냈더니, 논리 작업 단위로 다시 쪼개라는 것이다. 또 OS 에 따라 기능을 구현하면, 기능을 테스트하고나서 구현하라고 하고... 어떨 때는 정말 이해할 수 없는 이상한 지적을 하기도 하고. 지금봐도 그 관리자가 왜 그랬는지 모르겠다. 하지만 이런 과정을 거치면서 많이 배웠다. 지금은 당연하게 여기고 있지만, 그 당시에는 참 까다로운 요구였다. 어쨌든 이러다보니 이제는 MPlayer 의 committer 가 되었다.
MPlayer 의 기능을 하나씩 포팅하다보니 여기에 딸려 있는 여러 라이브러리들이 있었고, 이들 또한 포팅해야 했다. 다른 라이브러리들은 FFmpeg 이나 MPlayer 와 달리 autotools 라는 것을 사용하고 있었기 때문에, autotools 라는 것을 알게 되었고, 이 역시도 포팅해야 했다. 다행히도 기존에 배포되던 autotools 가 있었지만, libtool 은 제대로 포팅이 되지 않았었다. 이 libtool 이 사연이 깊다. libtool 을 포팅하고 나서 해당 패치를 libtool 메일링 리스트에 처음 보내고나서 실제로 적용되기까지 4년이 넘게 걸렸다. 처음에는 호의적인 관리자가 있어서 리뷰를 해줬는데, 문제는 GNU 의 규칙상 일정 코드 이상의 패치를 적용하기 위해서는 Copyright Assignment 라는 것이 필요하다는 것이었다. 게다가 이 문서는 온라인은 안되고 반드시 종이 우편으로만 전달되어야 한다는 것이다. 도중에 우편 사고가 나기도 하면서 상당히 시간이 지체되었다. 그러는 와중에 호의적이었던 관리자는 그 이후로 거의 활동을 하지 않았고, 다른 관리자들은 관심을 가지지 않았다. 몇 번에 걸쳐 패치를 보냈음에도 불구하고 한 번도 답장을 받지 못했다. 악플보다 무서운 것이 무플이라고 했던가 ? 절실히 공감했다. 특히 비슷하게 올라온 패치인데, 내 것에는 답장을 안 하고, 다른 사람의 것에만 답장을 할 때의 그 기분. 아, 정말. 그런데 무슨 일인지 포기하지 않고 생각날 때마다 한 번씩 보냈더니, 드디어 리뷰를 받았고, 패치가 모두 적용이 되었다. 아... 그 때의 기분은 정말... 완전 십년 묵은 체증이 사라진 듯한 기분이었다.
다시 MPlayer 로 돌아와서, 관련 라이브러리들에 대한 패치를 적용하기 위해 해당 라이브러리에 대한 메일링 리스트에 패치를 보내놓고 리뷰를 기다리고 있었는데, 웬걸 MPlayer 에서 리뷰를 하던 사람이 그 곳에서도 리뷰를 하고 있는 것이다. 하... 이를 통해 같은 영역에서 활동하는 F/OSS 인력풀이 상당히 제한되어 있구나 하는 것을 다시금 깨달았다.
이런 경우는 GNU 프로젝트에서는 더했다. 해당 프로젝트 홈페이지에서 프로그램을 내려받은 사람들은 알 수 있겠지만, GNU 프로젝트를 관리하는 사람들은 정말 거기에서 거기다.
개인적으로 GNU 프로젝트에 대해 이상한 환상을 가지고 있었다. GNU 프로젝트를 진행하는 사람들은 매우 개방적이고 호의적일 것이라 생각했다. MS 나 애플의 독점과는 다른 방향이니까... 하지만 이는 여지없이 깨지고 말았다. 그들 또한 매우 현실적이었고, 매우 냉정했다. 사용자가 적은 비주류 OS 의 코드는 유지보수가 힘들다는 이유로 패치를 적용하고 싶지 않다는 대답도 들었고, libiconv 의 경우 패치를 보내고 나서 6개월이나 1년이 지나고 나서 답장을 받기도 했다. 이유를 물었더니, 바쁘다는 단순한 이유였다. 하... 그때의 허무함이란... 덕분에 환상을 깰 수 있었다. 그들에게도 역시 현실은 무시할 수 없고, 비주류는 역시 인정받기 힘들다는 것.
이제는 그런 반응에 적응을 했고, 리뷰가 바로 바로 이루어지지 않고 시간이 걸릴 때도 있다는 것을 잘 이해하고 있다. 아픈만큼 성숙한다던 말이 떠오른다.
솔직히 내가 저 자리에 있었다면 어떻게 했을까 ? 자문해 보면 크게 다를 것 같지는 않다. ^^
지금은 VLC 에도 참여하고 있고, 다른 여러 프로젝트에도 참여하고 있는데, 관리자들의 유형이 정말 다양하다. 패치를 보냈을 때 시시콜콜한 것까지 패치 작성자로 하여금 고치게 하는 사람이 있는가 하면, 간단한 것은 관리자가 직접 수정해서 적용하는 사람도 있고, 리뷰하면서 독설을 날리면서 인격을 모독하는 사람이 있는가 하면, 매우 조심스럽게 표현하는 사람도 있고, 매우 독단적인 관리자가 있는가 하면, 매우 개방적인 관리자도 있고, 비주류 OS 에는 관심이 없는 관리자가 있는가 하면, 매우 호의적으로 대하는 관리자도 있고, 리뷰를 해서 잘못된 것이 있으면 어떻게 고치라고 이야기해 주는 관리자가 있는가 하면, 그냥 잘못됐다고만 하고 어떻게 고치라고 이야기 하지 않는 관리자도 있고, 아예 리뷰를 하지 않는 관리자도 있다. 심지어 어떤 관리자는 처음에는 리뷰를 잘 하다가 심경의 변화가 생겼는지 갑자기 리뷰를 하지 않는 관리자도 있다. 으~~~~ 정말 짜증 폭발... 완전 줬다 뺏는 케이스...
결국 중요한 것은 관리자 유형에 따라 일희일비하지 말고 패치를 적용하기 위해 꾸준히 시도하고 노력해야 한다는 것이다.
지금도 리뷰받지 못하고 기다리는 패치가 있고, 비주류 OS 라 무시 받고 있는 패치도 있다. 언젠가는 이 모든 패치들이 적용될 날이 있다고 생각하면서 상처받지 않고 기다리고 있다. 이미 4년만에 적용된 패치도 있었으니까... ^^
어쨌든 이런 비주류 OS 를 쓰다 보니 대부분의 F/OSS 프로젝트를 이용하려고 하더라도 패치없이 쓸 수 있는 경우는 정말 극히 드물다. Linux 나 Windows 에서는 가장 일반적인 절차인 ./configure -> make -> make install 만 하면 되지만, OS/2 에서는 모든 단계에서 패치가 필요하다. 그렇다보니 되도록이면 새로운 프로젝트를 추가하지 않으려는 마음이 생겼고, 어쩔 수 없이 사용해야 하는 프로젝트를 빼고는 프로젝트 사용을 최소한으로 줄이고 있다.
처음에는 개인적으로 간단한 프로그램을 만들다가, 점차 OS/2 에서 사용되고 있는 F/OSS 프로젝트에 참여하게 되었다. 워낙 개발자 수가 적다보니 새로운 개발자의 참여를 매우 반기는 분위기였고, 덕분에 보다 적극적으로 참여할 수 있었다. 한 번은 예전 메일을 본 적이 있었는데, 어떤 코드에 대해 논쟁이 있었다. 지금 와서 보면 상대방 말이 맞았는데, 왜 그렇게 우기고 있었는지 이해가 되지 않았다. 어찌나 부끄러워지던지. ^^
이후 멀티미디어쪽에 관심을 많이 가지면서 다른 OS 의 F/OSS 프로젝트에 관심을 가지게 되었다. 시작은 FFmpeg 이었던 것 같다. 한 번은 OS/2 코드가 삭제되었었는데, 예전 코드를 다시 살리려니 이것이 잘못 됐다, 저것이 잘못 됐다, 이러는 것이다. 도무지 이해가 안됐었다. 그저 예전 코드를 그대로 되살리는 것 뿐이었는데, 왜 이러는 것일까 ? 결국은 FFmpeg 관리자가 원하는 형태로 코드를 재작성했다. 이 과정을 거치면서 코드를 빼기는 쉬워도 다시 넣기는 정말 힘들구나 하는 것을 뼈저리게 느꼈다. 그리고 사실 이전 코드보다 관리자의 요구대로 새롭게 정리된 코드가 더 나은 것은 사실이었다.
FFmpeg 의 FFplay 를 바탕으로 KMP 라는 OS/2 용 플레이어를 만들었었다. 이보다는 다른 플레이어를 포팅하는 것이 더 낫지 않을까 하는 생각이 들었고, 그 시작이 MPlayer 이었다. 예전에도 MPlayer 를 OS/2 로 포팅하려는 시도가 있었고, OS/2 의 WarpVision 이라는 플레이어는 MPlayer 의 코드를 무단 이용하기도 했었다. 하지만 여전히 공식 포트가 존재하지 않던터라, 포팅을 시도하였다. 패치를 OS/2 커뮤니티에서만 쓰고 있었는데, 공식 프로젝트에 패치를 합쳐야겠다는 생각에 메일링 리스트에 보냈는데, 역시나... 한 번에 될 리가 없다. 패치를 한꺼번에 보냈더니, 논리 작업 단위로 다시 쪼개라는 것이다. 또 OS 에 따라 기능을 구현하면, 기능을 테스트하고나서 구현하라고 하고... 어떨 때는 정말 이해할 수 없는 이상한 지적을 하기도 하고. 지금봐도 그 관리자가 왜 그랬는지 모르겠다. 하지만 이런 과정을 거치면서 많이 배웠다. 지금은 당연하게 여기고 있지만, 그 당시에는 참 까다로운 요구였다. 어쨌든 이러다보니 이제는 MPlayer 의 committer 가 되었다.
MPlayer 의 기능을 하나씩 포팅하다보니 여기에 딸려 있는 여러 라이브러리들이 있었고, 이들 또한 포팅해야 했다. 다른 라이브러리들은 FFmpeg 이나 MPlayer 와 달리 autotools 라는 것을 사용하고 있었기 때문에, autotools 라는 것을 알게 되었고, 이 역시도 포팅해야 했다. 다행히도 기존에 배포되던 autotools 가 있었지만, libtool 은 제대로 포팅이 되지 않았었다. 이 libtool 이 사연이 깊다. libtool 을 포팅하고 나서 해당 패치를 libtool 메일링 리스트에 처음 보내고나서 실제로 적용되기까지 4년이 넘게 걸렸다. 처음에는 호의적인 관리자가 있어서 리뷰를 해줬는데, 문제는 GNU 의 규칙상 일정 코드 이상의 패치를 적용하기 위해서는 Copyright Assignment 라는 것이 필요하다는 것이었다. 게다가 이 문서는 온라인은 안되고 반드시 종이 우편으로만 전달되어야 한다는 것이다. 도중에 우편 사고가 나기도 하면서 상당히 시간이 지체되었다. 그러는 와중에 호의적이었던 관리자는 그 이후로 거의 활동을 하지 않았고, 다른 관리자들은 관심을 가지지 않았다. 몇 번에 걸쳐 패치를 보냈음에도 불구하고 한 번도 답장을 받지 못했다. 악플보다 무서운 것이 무플이라고 했던가 ? 절실히 공감했다. 특히 비슷하게 올라온 패치인데, 내 것에는 답장을 안 하고, 다른 사람의 것에만 답장을 할 때의 그 기분. 아, 정말. 그런데 무슨 일인지 포기하지 않고 생각날 때마다 한 번씩 보냈더니, 드디어 리뷰를 받았고, 패치가 모두 적용이 되었다. 아... 그 때의 기분은 정말... 완전 십년 묵은 체증이 사라진 듯한 기분이었다.
다시 MPlayer 로 돌아와서, 관련 라이브러리들에 대한 패치를 적용하기 위해 해당 라이브러리에 대한 메일링 리스트에 패치를 보내놓고 리뷰를 기다리고 있었는데, 웬걸 MPlayer 에서 리뷰를 하던 사람이 그 곳에서도 리뷰를 하고 있는 것이다. 하... 이를 통해 같은 영역에서 활동하는 F/OSS 인력풀이 상당히 제한되어 있구나 하는 것을 다시금 깨달았다.
이런 경우는 GNU 프로젝트에서는 더했다. 해당 프로젝트 홈페이지에서 프로그램을 내려받은 사람들은 알 수 있겠지만, GNU 프로젝트를 관리하는 사람들은 정말 거기에서 거기다.
개인적으로 GNU 프로젝트에 대해 이상한 환상을 가지고 있었다. GNU 프로젝트를 진행하는 사람들은 매우 개방적이고 호의적일 것이라 생각했다. MS 나 애플의 독점과는 다른 방향이니까... 하지만 이는 여지없이 깨지고 말았다. 그들 또한 매우 현실적이었고, 매우 냉정했다. 사용자가 적은 비주류 OS 의 코드는 유지보수가 힘들다는 이유로 패치를 적용하고 싶지 않다는 대답도 들었고, libiconv 의 경우 패치를 보내고 나서 6개월이나 1년이 지나고 나서 답장을 받기도 했다. 이유를 물었더니, 바쁘다는 단순한 이유였다. 하... 그때의 허무함이란... 덕분에 환상을 깰 수 있었다. 그들에게도 역시 현실은 무시할 수 없고, 비주류는 역시 인정받기 힘들다는 것.
이제는 그런 반응에 적응을 했고, 리뷰가 바로 바로 이루어지지 않고 시간이 걸릴 때도 있다는 것을 잘 이해하고 있다. 아픈만큼 성숙한다던 말이 떠오른다.
솔직히 내가 저 자리에 있었다면 어떻게 했을까 ? 자문해 보면 크게 다를 것 같지는 않다. ^^
지금은 VLC 에도 참여하고 있고, 다른 여러 프로젝트에도 참여하고 있는데, 관리자들의 유형이 정말 다양하다. 패치를 보냈을 때 시시콜콜한 것까지 패치 작성자로 하여금 고치게 하는 사람이 있는가 하면, 간단한 것은 관리자가 직접 수정해서 적용하는 사람도 있고, 리뷰하면서 독설을 날리면서 인격을 모독하는 사람이 있는가 하면, 매우 조심스럽게 표현하는 사람도 있고, 매우 독단적인 관리자가 있는가 하면, 매우 개방적인 관리자도 있고, 비주류 OS 에는 관심이 없는 관리자가 있는가 하면, 매우 호의적으로 대하는 관리자도 있고, 리뷰를 해서 잘못된 것이 있으면 어떻게 고치라고 이야기해 주는 관리자가 있는가 하면, 그냥 잘못됐다고만 하고 어떻게 고치라고 이야기 하지 않는 관리자도 있고, 아예 리뷰를 하지 않는 관리자도 있다. 심지어 어떤 관리자는 처음에는 리뷰를 잘 하다가 심경의 변화가 생겼는지 갑자기 리뷰를 하지 않는 관리자도 있다. 으~~~~ 정말 짜증 폭발... 완전 줬다 뺏는 케이스...
결국 중요한 것은 관리자 유형에 따라 일희일비하지 말고 패치를 적용하기 위해 꾸준히 시도하고 노력해야 한다는 것이다.
지금도 리뷰받지 못하고 기다리는 패치가 있고, 비주류 OS 라 무시 받고 있는 패치도 있다. 언젠가는 이 모든 패치들이 적용될 날이 있다고 생각하면서 상처받지 않고 기다리고 있다. 이미 4년만에 적용된 패치도 있었으니까... ^^
댓글
댓글 쓰기