리눅스용 nateon 유감 - 데비안에서 패키지 삭제

Qt3 라이브러리 제거 계획과 더불어 리눅스용 공식 nateon이 데비안 아카이브의 unstable/testing에서 삭제되었다.

이 프로그램 역시 3년이 넘었고 Qt 버전4가 맨 처음 나온 게 2005년이었는데 어디서부터 문제의 가닥을 잡아야 할까. 2007년 9월 KLDP.NET 사이트에 입주한 "nateon" 프로젝트는 특이한 정책을 취했다. "참여하고 싶습니다"라고 말 한마디만 하면 프로젝트에 가입되었다. 한 줄도 커밋하지 않은 개발자, 패키징을 한 번 했다가 사라져서 다시 나타나지 않는 패키지 관리자가 수두룩했다. 치열한 토론을 거친 코드가 아니면 적용도 안 되는 까칠스러운 프로젝트만 접해 본 내게는 생소한 환경이었다.

개발 커뮤니티를 개방적으로 잘 활용하는 것은 좋지만, 눈에 보이는 개발자의 대부분이 뜨내기라는 현실은 파악할 필요가 있다. 그리고 활동적으로 보이는 사람도 누구든, 언제든 떠나갈 수 있다. 믿을 개발자는 결국 자기 자신밖에 없다. (!)

QT4/KDE4 이슈는 이 정책과 관계가 있다. 2007년 11월 프로젝트 관리자는 결정적인 실수를 범한다. QT4/KDE4 포팅에 대해서 커뮤니티 분에게 PM을 맡기자고 한 것이다. 개발자 커뮤니티를 잘 활용하자는 욕심인데 사실 여기까지는 나쁘지 않았다. 언젠가 커뮤니티에게 주도권을 넘겨 주는게 바람직하다. 문제는 그 다음이다.

다시, 오픈소스 프로젝트에서는 "누구든, 언제든 떠나갈 수 있다.믿을 개발자는 결국 자기 자신밖에 없다." 몇 달간 진행이 없을 때 부터 판단을 내렸어야 했다. 의욕만 넘치고 일을 하지 못하는 건 그 사람의 잘못도 아니고 누구의 잘못도 아니다. 그 헛된 의욕을 잘라내지 못하고 기대를 하는 사람의 책임이다. 더 시간이 지났을 때 냉정해 질 필요가 있었다. 이건 개인의 능력이나 성실성 문제가 아니라, 이미 이 프로젝트에 대한 관심이 떠난 상태였다.

Qt4/KDE4 개발

2009년 7월 12일 

포팅은 전혀 시작도 안 한 상태인데, 1년 반이 지난 것으로 볼 때 segfault 님이 이제 와서 하실 생각은 없는 것 같은데요.
특별히 누구를 탓하려는 생각은 없는데요. 오픈소스 프로젝트에서 누군가가 "내가 하겠습니다"라고 자원한다고 해서 그 사람이 그대로 할 거라고 믿고 있으면 곤란합니다.

2009년 11월 1일 

또 다시 몇 달이 흘렀는데요. 이제 2년으로 접어듭니다. 냉정하게 진행될 가능성이 있는지 다시 평가해야 된다고 생각합니다.
하다 못해 svn branch에 진행이 되고 있다는 흔적이라도 있으면 모르겠습니다. 아무 것도 없고 아무 계획도 없는데 어떻게 믿고 기다릴 수 있다는 건지 모르겠습니다. 앞으로 몇 달이 더 흘러도 진행될 것 같지 않습니다.
공개적으로 다른 분을 찾아 보시던가, 아니면 계획 없다고 선언하는 것도 한 가지 방법입니다. :>

그리고 그 전에 2008년 11월 개발 커뮤니티는 한번 흔들린다. 인증 메커니즘이 알려진데 대해 불편해 했던 SK  커뮤니케이션즈 내부에서 이 부분을 바이너리로 빼자는 제안을 한 것이다. (kldp.net 사이트가 nforge로 옮긴 후 메일링 리스트 서비스가 중단되어 이제 접근할 수 없다.)

거기에 대해 2008년 11월 15일 내가 메일링 리스트에 썼던 글,

안녕하세요. 

지금 네이트온의 보안강화와 관련된 메일을 읽었습니다. SK 커뮤니케이션즈 측에서 이런 결정을 한 데 대해 정말 실망스럽고, 가능하다면 재고해 주기를 바랍니다. 

첫째 바이너리로 만드는 것은 프로토콜을 숨길 수 없고 보안 강화에 별 도움이 되지 않습니다. 알아내는 데 좀 오래 걸리고 수고가 더 들긴 하겠지만 패킷 캡쳐이든 리버스엔지니어링이든 언젠가는 알아냅니다. 게다가 눈가리고 아웅 식으로 svn 기록만 들춰봐도 나오는 현재의 패스워드 생성 방식도 바이너리로 감춰보자라는 건 정말 쓸모없는 일입니다. 정말 보안이 걱정되는 거라면 SSL이든 디지털 사인이든 "진짜 보안"을 사용해야 할 일이지, 그 방법 자체를 비밀로 하는 가짜 보안은 오래 가지 못 합니다. 

그리고 더 심각한 부분은... 소스가 비공개가 되면 이 프로젝트의 라이센스 정책이 변한다는 말이 됩니다. 소스가 없는 프로그램은 더 이상 GPL이 아니고 당연히 오픈소스도 아닙니다. 파이프로 읽어들인다면 GPL 호환성 논란까지는 피해갈 수 있을 지 몰라도 독점 프로그램이 없으면 동작하지 않는, 사실상 독점 프로그램이 된 것과 마찬가지입니다. 

어쨌든 만약 말씀하신 대로 서버 프로토콜이 바뀐다면, 그리고 기존 클라이언트에서 더 이상 로그인할 수 없고 독점 프로그램의 바이너리를 사용해야 한다면, 제가 업로드한 deb 패키지는 제 스스로 데비안 아카이브에서 삭제 요청을 하겠습니다. 제 기분대로 그렇게 하려는 게 아니라 소스가 없는 프로그램이나 거기에 의존하는 프로그램은 데비안에 들어갈 수 없습니다. non-free나 contrib에 들어갈 수는 있겠지만 빌드머신에서 빌드를 못하는 제한된 프로그램을 관리할 생각은 없구요. (지금은 13개 아키텍쳐로 빌드되어 있습니다. 아무리 열심히 빌드를 하셔도 s390 바이너리같은 것까지 만드실 수는 없겠지요. http://buildd.debian.org/build.php?arch=&pkg=nateon ) 

그리고 kldp.net에는 오픈소스가 아닌 프로젝트는 입주할 수 없습니다. 만약 이 프로젝트가 비공개 정책으로 간다면 먼저 kldp.net부터 떠나야 하지 않을 까요.

다행히 그 이후 버전은 바이너리를 사용하지 않고 SSL을 사용하도록 바뀌었다.

무엇 때문이라고 해야 할까? 개발 커뮤니티에 대한 지나친 신뢰? 관련자들의 불분명한 입장 표명? SK 커뮤니케이션즈 회사와 개발 커뮤니티 사이의 불투명한 의사 결정 구조? 정말 프로젝트에서 발생할 수 있는 온갖 실수들이 묘하게 엮여서 삐걱거린 프로젝트가 아닐 수 없다.

데비안 패키지 삭제로 이제 신경 쓸 일이 별로 없을 테니, 앞으로 어떻게 진행될지 모르겠지만.. 어떻게 되든 프로젝트에 참여했던 사람들, 프로젝트를 지켜본 사람들 모두가 오픈소스 프로젝트에 대한 (특히 기업이 끼어 있는 프로젝트에 대한) 좋은 교훈을 얻을 수 있었으면 좋겠다.