NetBSD의 미래

NetBSD의 창시자 4명중의 한명으로서 저는 꽤 독특한 위치를 차지하고 있습니다. 저는 이 프로젝트의 전과정에 계속해서 참여하고 지켜 봐 온 유일한 사람이라고 말할 수 있습니다. 그간 많은 변화가 있었고, 동시에 많은것들이 그대로 남겨져 있기도 했습니다 -- 우리들의 초기 착오들도 포함해서 말이죠.

저는 제가 전체 OSS마켓을 제바로 내다본 굉장한 예측가중 한 사람이라고 말하고 싶지만, 사실은 그와 반대인 것 같습니다. 우리가 프로젝트를 시작했을 때, 리눅스와 386BSD는 둘다 모두 벅이 꽤많고, 많은 주요한 하드웨어 지원을 빠뜨린 조그만 취미용 시스템들이었습니다. 전반적으로 가려운 곳을 긁고있는 정도 였던 것같습니다: 완전한 386BSD 패키지에 더해 더 많은 시스템에서 돌아 가도록하는 그리고 벅을 수정하는 데 필요한 패치들도 없었고 Bill Jolitz가 다시 표면으로 부상해서 뭔가 좀 하리라는 아무 징조도 없었습니다.

대부분의 프로젝트 구조는 우리가 초기에 가졌던 문제점들 때문에 형성되어 왔습니다. 아마도 우리의 최선의 선택은 센트럴 버전 컨트롤을 진작에 사용하기 시작했어야 하는 것이 었습니다; 이 센트럴 버전 컨트롤은 코드 히스토리를 보다 넓은 관점에서 볼수 있게 해주고 (결과적으로) 많은 개발자들이 원격으로 협력하는 것을 매우 쉽게 해주어 왔습니다. 우리가 미적거린 다른 점들을 살펴보면; 예를 들어, 크리스는 모든일의 구심점 역할을 하는 데 지치기 시작해 왔고, 대학을 졸업하려고 노력하고 있었습니다, 그래서 우리는 프로젝트 관리를 위해 내부 그룹(cabal)을 만들었고, 이는 ''핵심 그룹''으로 알려지게 되었습니다. 웹이 굉장히 새로운 것이기는 했어도, 굉장히 초기에 웹 사이트를 구축해서 프로젝트와 우리의 릴리즈에 관한 정보를 퍼뜨리기 시작했습니다.

이러한 초창기 구조는 (CVS, 웹사이트, 비밀그룹 등등.) 거의 그대로-- 거의 프로젝트 이름 형태와 ''핵심''이라는 말 까지-- 다른 오픈 소스 (이 용어가 아직도 생소했던 그 때) 프로젝트에 그대로 사용되었습니다. 이는 후에 오픈 소스 프로젝트를 시작하는 데 있어 일종의 기본 템플릿이 될 정도였습니다.

불행하게도 우리는 여기서 몇가지 잘못을 저질렀습니다. 수년에 걸쳐 보아왔듯이, 리눅스의 커다란 성공요인중의 하나는 목표와 방향을 설정하고 사람들로 하여금 자신이 의도했던 바를 실행해 나갈 수 있게한 - 아니면 그렇게 할 수 있는 다른 사람들을 찾아 내는- 강력한 지도자를 갖고 있었다는 것입니다. 뒤에 말한 부분 -다른 사람을 찾아내는 것 - 도 중요한 부분입니다; 누군가 리눅스의 한 부분을 '차지'하고 있다는 그런 것은 통하지 않았습니다( 비록 실제 몇몇 부분에선 ''내관할''이라는 게 있긴 했어도 말입니다); 만일 당신이 만들어 내지 못하면, 리누스는 다른 사람의 코드를 채택해 버렸습니다. 다른 사람이 내것을 사용하게 만들려면, 계속해서 움직여 나가야만 했던 것입니다.

NetBSD는 이렇지 못했습니다. 한편으론 인원의 부족 때문에, 한편으론 좀더 단체를 생각하는 마음가짐에서, 프로젝트는 종종 ''잠겨''버렸습니다. 한 사람이 그 사람들이 프로젝트 작업을 하고 있다고 말하면, 다른 모든 사람들은 이들에게 맡기도록 권고 되었습니다. 종종 이런 프로젝트들은 정체되거나, 전혀 진전이 없는 경우도 있었습니다. 진전이 있다해도, 프로젝트 발제자들은 너무 느리기 일 수 였습니다. 결과로 많은 중요 프로젝트들이 거의 빙하가 흐르는 속도로 진행되거나, 전혀 완결되지 못했습니다.

제가 이런한 문제점에 일조를 했으며, NetBSD를 따라 (아마도 1993년과 1994년의 높은 인기에 힘입어) 모델된 대 부분의 프로젝트들이 비슷한 문제점들을 격어 왔다는 점을 말하게 되서 죄송스럽게 생각합니다. 예를 들어, FreeBSD와 XFree86은 둘다 매우 비슷한 이유로 후속 프로젝트들(Dragonfly 와 X.org)를 만들어 내게 되었습니다.

불행하게도, 오늘에도 이런한 문제점들이 여전히 NetBSD에는 존재하며, 이들을 고치기위한 아무런 노력도 없는 실정입니다.

--

이에 대해선 이들가운데 몇가지가 확실하게 제 실수라고 말하는 것 이외에 어떤 특정한 사람들에게 비난을 전가하려고 하지는 않을 것입니다. 뒤를 돌아보았을 때 매우 강력한 지도자가 필요했다는 것만은 확실한 것 같습니다. 제가 10년 전에 이를 추구했더라도 일들은 많이 달라졌을 것입니다. 인생이 다 그렇죠. 어쨋든 오늘의 상황에 대해서 말해봅시다.

오늘날, 프로젝트는 다른 그룹(cabal)에 의해서 운영되고 있습니다. 이는 2000년 - 2001년 사이에 일어난 반란에의한 것으로, 이때 NetBSD Foundation은 운영 위원회의 정직하지 못한 변화에 의해 강탈당했습니다 (불행하게도 제가 이에대한 어떤 법적 시정을 구하는 것은 너무 늦은 것 같습니다) 'The NetBSD Project'와 'The NetBSD Foundation'이 처음부터 서로 분리된 단체로서 의도되긴 했지만 - 후자가 전자에대해 지원 인프라스트럭춰를 제공하는 - 이런 구별은 그 이후 의도적으로 모호하게 되어왔으며, 그 결과 현재의 TNF ''위원회(board)'' 가 TNP의 여러 면에 결쳐 꽤 타이트한 콘트롤을 가지고 있는 실정입니다.

TNF가 좋은 지도자들로 구성되어 있었더라면, 이런 상황은 --비록 이상적인 아니라도-- 어느 정도 받아들일 만 했을 겁니다. 문제는 이 시점에 실제로 아무 지도자도 없다는 점입니다. 릴리즈의 ''달성목표''들은 사용자(customer)들의 피드백에 기반을 두거나 앞으로 필요한 사항들에 맞추어져 있지 않으며, 순전히 충분히 부풀어 오른 상태니까 제시간에 끝마칠 수 있겠다라는 근거아래 설정되어 있습니다. 상위(high-level) 지침이라는 것은 존재하지 않습니다: "쓰레드 문제들은 좀 어때요" 나 "플래쉬-친화적인 파일 시스템(flash-friendly file system)은 추가 될건가요"라고 문의하면, "둘다 해야죠"라는 답변이 얻는 것 전부일 겁니다 -- 이것들을 코딩할 사람을 모으거나 또는 기존의 개발자들이 이들 작업을 하도록 격려하거나 하는 그런 일들은 전혀 이루어 지지 않고서 말입니다.

이런 공백은 실제적으로 프로젝트의 현재 답보상태에 일조를 해왔습니다. 사실, NetBSD는 넘쳐나는 매우 중요 프로젝트들에 대해 매우 뒤쳐져 있습니다. 쓰레딩은 실제로 여러 다수의 CPU들에 분산되어 작동되지 않으며, 한 CPU에선 상당히 벅이 많기조차 합니다. 쓸만한 플레쉬 파일 시스템도 없습니다. 파일 시스템 저널링도(file system journaling)(여전히 다소 실험적인 LFS를 제외하곤) 없습니다. suspend 지원(suspend support)에 대해 최근에 작업이 좀 있었지만, 여전히 대부분 완성과는 거리가 멀고, 전원 관리(Power management)는 거의 기초적인 상태입니다. 그밖에도 여러가지 있습니다. NetBSD에선 새로운 하드웨에 지원조차도도 더 이상 나오고 있지 않은 상태입니다; 이런 지원은 FreeBSD 그리고 OpenBSD에서 개발되어 나중에 가져옵니다. (최근의 좀 중요한 유일한 예외는 블루투쓰 지원으로 생각됩니다)

이러한 그리고 다른 이유로, 프로젝트는 거의 별관심을 못 끄는 지경에 이르게 되었습니다. (몇 사람들은 아마 이 지경도 지난지 오래라고 말하고 싶어할 겁니다, 그렇지만 저는 보다 관대하게 보려고 합니다) 이건 특히 NetBSD 사용이 위에 말한 반란이 있기 전인, 2000년과 2001년에 꽤 빠른 속도로 증가하고 있었다는 점을 생각할 때 불행한일이 아닐 수 없습니다.

--

이 시정에서, 대부분의 독자들은 제가 단지 NetBSD 프로젝트의 조사를 쓰고 있는 게 아닌가 하고 의하해 하실게 틀림없을 것 같습니다. 어떤 면에선 그렇다고 할 수 있습니다 -- 프로젝트는 현상황을 보았을 때 미래가 확실히 없습니다. 계속해서 보다 뒤 쳐저서 점점더 중요성을 잃어 갈 겁니다. 시작할 때 그렇게 밝은 전망을 모아온 프로젝트에겐 슬픈 결말이 아닐 수 없습니다.

제가 이에 관해 틀렸을 수 도 있습니다. 그러나, 제가 생각하건데 NetBSD에 공헌해 왔으며, 앞으로도 계속 그렇게 하실 분들은 프로젝트가 이런 식으로 지저분하게 나 뒹글어 다니는 걸 원하지 않으 실 겁니다. 따라서 제가 생각컨데 유일한 해결책을 요약해 보겠습니다:

1) 강력한 지도부가 필요합니다. 그리고 현재 같아서는 안됩니다. 지도부는 진정으로 NetBSD가 첫번째로 꼽히는 세계 수준의 최첨단 기능을 가진 시스템이 되길 원해야 합니다. 지도부는 공격적인 목표사항들을 정해놓고 이를 실현시킬 사람들을 능동적으로 모아야 합니다.

2) 더이상 문을 닫아 건 프로젝트가 있어서는 안됩니다. 어떤 사람이 어떤 문제에 작업을 하고 있다고 여겨진다고 해서, 다른 사람이 이것을 해서는 안된다고 해선 안됩니다. 아이디어가 좀 명석하지 못하거나, 또는 최적화 되지 못하기만 해도, 개선 시켜 버리세요! 진행이 더이상 없으면, 뛰어드세요. 다른 사람이 할 때까지 기다리지 마세요.

3) 프로젝트는 제가 하는 말로 양적 기여사회(volumetocracy) 보다는 실질적 공헌 기여사회(meritocracy)가 되어야 합니다. 지금 현재, 가장 큰 영향력을 행사하는 사람은들은 종종 가장 쓸모없는 제품을 만든 사람들인 경우가 있습니다. 실제로, 이들은 별거 아닌걸 만든 사람들인 경우가 있으며(예를 들면 라인 엔딩 공백을 바꾸는 일!), 종종 일을 망칩니다.

4) 일을 망치는 것에 대해서 좀 말해보자면, 사람들이 일을 망치게 하지 못하게 하는 네거티브한 피드백이 있어야 합니다. 이것은 10년이 넘게 특정 ''개발자들''에 관련되 계속되어 온 문제점이어왔습니다.

5) NetBSD 아키텍처에 관해 거의 완전히 부서져서 꽤 심각한 재활이 필요한 여러 사항들이 있습니다. 다시한번, 지도부는 이 문제점들을 해결하기 위해 사람들을 모아야할 필요가 있습니다. 이들중 몇가지는 다음과 같습니다:

*먼저 언급한 바와 같은, 쓰레딩 아키텍처에 관련된 심각한 문제점(사용자-커널 인터페이스 포함);
*형편없는 커널 모듈 지원
*형편없는 32/64-bit 호환성, 32-bit 애플리케이션이 64bit 커널에선 종종 제대로 작동하지 않는 결과를 가져옴; 그리고
*부적절하고 제멋대로 날 뛰는 "quirk" 테이블과 칩-전용 테이블 사용으로인한 끝업는 관리 작업; 예를 들면, SCSI, ATAPI, IDE, ACPI 그리고 SpeedStep 지원. (제가 실제로 SCSI에 대해서 대부분의 작업을 했지만 현재는 더이상 관리할 수 없습니다)

6) 현재의 NetBSD Foundation은 해산되어서 그 원래의 목적을 달성할 단체로 바뀌어야합니다: 즉, 단순히 관리 이슈만을 담당하며, 사사건건 일에 간섭하지 않는. 그 외에 거의 아무일도 하지 않는 커미티(committees)들도 해산되어야 합니다. 다른 모든 것들은 원래(과거의)

또하나의 실질적 단체인 NetBSD 프로젝트에 귀속 되어서 그 기술적인 공헌도에 따라 관리 되어야 합니다. Foundation에 참가하는데 어떤 특정한 선별이 있어서는 안되며, Foundation은 프로젝트에 헌신하며 돕기를 원하기 때문에 참가하는 사람들로 구성되어야 합니다.

(여기서 이게 반란에 대한 쓴맛때문에 이러는 게 아니란 걸 밝힙니다. NetBSD 프로젝트를 하나로 묶어두지 않는 게 실제로 프로젝트의 보호를 돕습니다.)

7) 소위 ''핵심''그룹은 실제 능력있고 프로포절들을 검토하고, 피드백을 받아들이며 올바른 결정을 하는데 총분히 기여해온 사람들로 바뀌어야합니다. 더 확실히 말하자면, ''핵심''그룹은 필요로 할때만 행동해야 합니다. -- 대부분의 기술적인 결정은 커뮤니티가 할 수 있게 해야 합니다; 핵심 그룹은 더 나은 솔루션을 개발하는데있어 커뮤니티를 제약해서는 안됩니다. (이게 ''핵심''그룹이 대부분의 프로젝트 성장 기간동안 일 해온 방식이었습니다.)

8) 일련의 관리 기준이 필요합니다 -- 예를들면, 언제 기능성(functionality)을 변화 시키지않는 변경사항들을 커밋(commit)하는 것을 혀용하거나 말 것인가; 언제 다수의 변경사항을 하나의 커밋(commit)으로 모아야 하는가; 등등. 현재론 쭉정이를 쌀알로 부터 가려내는 것이 힘든상황 입니다. 이에 더해서, 리뷰의 기준도 있어야만 합니다.

제가 이미 말했던 점들을 반복해야 겠습니다. 현재의 프로젝트 '관리'는 프로젝트의 문제점을 고치거나 프로젝트를 해결책들로 이끌어 갈 수 없을 것입니다. 이들은 현상 유지만을 답습할 것이며, 다른 것은 할 수 없을 것입니다. 프로젝트가 이 터버린 그루터기에서 다시 일어서려면, 이 '관리'는 해산되어서 완전히 바뀌어야 합니다. 이보다 덜한 어떤 것도 해결책이 될 수 없습니다.

--

몇몇 분에겐, 사과드리고 십습니다. 지금도 좋은 일을 하고 계시는 BSD 개발자분들이 계십니다. 특히 커널 록킹과 UVM문제; 무선 지원( 제 방대한 rtw 벅 수정에 그간 뭔일이 생겼는지는 모르지만); 블루투쓰; G5; 그리고 향상된 ARM 지원에 작업하고 계신 분들에게 존경과 감사를 드리고 십습니다. 그렇지만, 보다 큰 그림을 생각했을 때, 프로젝트는 굉장히 많은 일을 더 해야할 필요가 있습니다.