@에릭레이먼드 성당과 시장 리눅스 오픈소스 해커

BIBLIOGRAPHY

에릭 레이먼드. 1957. “에릭 레이먼드 Eric Steven Raymond.” In 위키백과. https://ko.wikipedia.org/w/index.php?title=%EC%97%90%EB%A6%AD_%EB%A0%88%EC%9D%B4%EB%A8%BC%EB%93%9C&oldid=37219056.

———. 2015. 성당과 시장 - 우연한 혁명으로 일어난 리눅스와 오픈소스에 대한 생각 해커. https://www.yes24.com/Product/Goods/17942908.

———. 2025. “성당과 시장 the Cathedral and the Bazaar).” In 위키백과, 우리 모두의 백과사전. https://ko.wikipedia.org/w/index.php?title=%EC%84%B1%EB%8B%B9%EA%B3%BC_%EC%8B%9C%EC%9E%A5&oldid=38815900.

History

[2025-03-25 Tue 13:24] 오픈소스의 도

에릭 레이먼드 Eric Steven Raymond

(에릭 레이먼드 1957)

에릭 레이먼드
에릭 레이먼드(Eric Steven Raymond, 1957년 12월 4일\textasciitilde )는 소프트웨어 개발자이자 해커이며 자신을 인터넷과 해커 문화의 “참여 관찰 인류학자 (observer-participant anthropologist)“라고 부르고 있다. 그는 오픈 소스의 형태로 개발되고 발전된 패치 메일의 개발 경험을 바탕으로 오픈 소스 철학을 대변하는 문서인성당과 시장을 저술하였는데, 여기서 그는 오픈 소스 개발 과정이 어떤 식으로 운영되고 반복되는지 설명하고 있다. 이 외에도 그는 해커들이 쓰는 용어를 설명한 자곤 파일(“신 해커사전”)을 편집했으며, 넷스케이프의 소스 코드 공개, 모질라의 설립에도 큰 영향을 끼쳤다. 또한 그는 현재 태권도 검은 띠의 소유자이다.
1957

성당과 시장 The Cathedral and the Bazaar

(에릭 레이먼드 2025)

에릭 레이먼드
에릭 레이먼드가 쓴 〈성당과 시장〉(The Cathedral and the Bazaar)은 자유 소프트웨어 철학을 대변하는 유명한 글이다. 레이먼드는 이 글에서 리눅스 커널 개발과정과 패치메일이라는 오픈 소스 프로젝트를 개발한 경험을 들어 오픈 소스 개발 방식의 유효성을 설명한다. 1997년 5월 27일 리눅스 회의에서 처음 공개되었으며, 1999년 같은 이름의 책에 포함되어 출판되었다. 글에서 저자는 두 가지 방식의 자유 소프트웨어 개발 모델을 대조한다. 성당 모델: 출시 때에만 소스 코드를 공개하고 그 사이에는 제한된 개발자들만 소스 코드에 접근할 수 있다. GNU 이맥스와 GNU 컴파일러 모음이 예이다. 시장 모델: 소스 코드가 인터넷으로 일반에 공개된 상태로 개발된다. 레이몬드는 리눅스 커널 프로젝트의 리더인 리누스 투르발스가 이 방식을 발명해 냈다고 쓰고 있다. 그는 또한 페치메일 프로젝트에 자신이 이 모델을 적용한 이야기도 쓰고 있다. 글의 주제는 그가 리누스 법칙이라고 이름붙인 “보는 눈만 많다면, 어떤 버그라도 쉽게 잡을 수 있다”는 명제이다. 이 말은 많은 사람이 테스트하고 훑어보고 실험해 볼 수 있도록 코드가 공개되어 있으면 버그는 빨리 잡힐 것이란 뜻이다. 이에 대해 성당 모델에서는 소스 코드를 여러 명의 개발자들만 볼 수 있으므로 버그를 잡는데에 엄청난 시간과 노력이 든다고 주장했다. 이 글로 인해 GNU 이맥스와 GCC를 포함한 많은 오픈 소스와 자유 소프트웨어 프로젝트들이 시장식의 열린 개발 모델을 사용하게 되었다. 이 중 가장 유명한 것은 넷스케이프가 넷스케이프 커뮤니케이터의 소스를 공개한 것과 모질라 프로젝트를 시작한 것이다. 성당 모델은 상용 소프트웨어의 전형적인 개발 방식이다. 더욱이 상용 소프트웨어는 보통 출시 때 소스가 같이 제공되지 않는다. 그래서 “시장과 성당”이라는 구문은 종종 오픈 소스 소프트웨어와 상용 소프트웨어를 비유하는 데에 쓰인다. 그러나 원래 글에서는 자유 소프트웨어들 중에 두 종류를 비교하여 설명하고 상용 소프트웨어에 대한 언급은 없었다. 성당과 시장의 예는 소프트웨어 프로젝트에만 있는 것이 아니다. 위키백과는 시장식의 프로젝트이고, 누피디아나 브리태니커 백과사전은 성당형의 프로젝트이다.
2025

성당과 시장 - 우연한 혁명으로 일어난 리눅스와 오픈소스에 대한 생각 해커

(에릭 레이먼드 2015)

에릭 레이먼드
오픈소스에 관한 철학서!`보는 눈이 충분하게 많으면, 찾지 못할 버그는 없다` 이 말은 오픈소스의 철학을 대변하는 이 책의 주제를 단적으로 나타낸다. 여기에는 충분하게 많은 베타 테스터와 공동 개발자가 있으면, 거의 모든 문제는 빠르게 파악될 것이라는 저자의 …
2015 소개

오픈소스에 관한 철학서!

‘보는 눈이 충분하게 많으면, 찾지 못할 버그는 없다’ 이 말은 오픈소스의 철학을 대변하는 이 책의 주제를 단적으로 나타낸다. 여기에는 충분하게 많은 베타 테스터와 공동 개발자가 있으면, 거의 모든 문제는 빠르게 파악될 것이라는 저자의 신념이 드러난다.

이 책은 근본적으로 다른 두 가지 개발 방식을 소개한다. 두 가지 방식이란 상업용 소프트웨어의 ‘성당’ 모델과 리눅스 세계의 ‘시장’ 모델이다. 저자는 이 책에서 시장모델을 적용한 오픈소스 프로젝트인 페치메일을 개발하면서 얻는 생각들을 분석적으로 풀어가며 오픈소스 모델이 폐쇄소스에 비해 어떤 장점이 있고 오픈소스 모델이 어떻게 진행되고 방향을 잡아야 하는지를 설명한다. 그리고 진정한 프로그래머들이 존재하던 역사 이전의 시대와 MIT 인공지능연구소의 영예롭던 시기, 그리고 어떻게 아르파넷이 최초의 네트워크 국가를 만들어 내었는가를 포함한 해커 문화의 기원과 리눅스와 인터넷의 주류가 대중의 관심 밖에 있던 해커 문화를 현재와 같이 눈에 띄는 형태로 만든 방법을 설명한다. 이를 통해 이 책은 독자가 소프트웨어의 미래를 위해 ‘리누스의 법칙’이라고 부르는 통찰이 가지는 의미에 대해 생각해 보게 한다.

[지은이] 에릭 레이먼드 1970년 후반 아르파넷 시절부터 인터넷과 해커 문화에 매료돼 참여하고 관찰해온 해커이자 인류학자다. 그의 연구는 리눅스와 인터넷의 발전을 통해 효과적으로 증명된 분산화된 오픈소스 소프트웨어 개발 모델을 설명하는데 기여했다. 그는 컴퓨터에 매혹되기 전에 수학과 철학을 공부했고, 두 장의 앨범에서 플루트를 연주하는 등 음악가로서도 어느 정도 성공을 거뒀다. 직접 만든 여러 오픈소스 프로젝트 중에서 가장 널리 알려진 것은 페치메일이다. 페치메일은 인터넷에서 가장 많이 사용되는 이메일 전송 프로그램으로 모든 주요 리눅스 배포판에 포함돼 있다. 그는 미국 연방헌법 수정 제1조(표현의 자유)와 제2조(무기 휴대의 권리)를 지지하는 활동가다. 또한 태권도 검은띠 유단자이며 사격으로 기분 전환을 하기도 한다. 그의 홈페이지는 http://www.catb.org/~esr/%EC%9D%B4%EB%8B%A4.

[옮긴이] 정직한 1998년 여름, 「성당과 시장」의 한글 번역을 한국의 대표 리눅스 공동체 사이트 KLDP(Korean Linux Documentation Project)에 올려 널리 소개했다. 또한, 한국 최초의 SF 세계명작 시리즈를 복원한 아이디어 회관 직지 프로젝트 등의 활동에 참여했다.

[옮긴이] 송창훈 컴퓨터공학과 법학을 공부했고 오랫동안 GNU 프로젝트에 참여했다. 자유 소프트웨어 운동의 정신이 다른 시대, 다른 사회, 다른 분야에서도 상쾌한(cheerful)바람이 될 수 있기를 희망한다. 독자 모두가 프로그래머는 아닐 것이다. 그러나 조금의 유머와 재치, 상냥한 미소와 배려, 그리고 삶의 작은 곳에서도 새로움(technology)과 흥미(love)를 찾아간다면, 우리 모두 삶의 친구(life hacker)로 만나게 되리라 생각한다.

[옮긴이] 윤종민 서강대학교에서 기계공학을 전공했지만, 여러 회사를 거쳐 지금은 임베디드 소프트웨어 전문 회사 윈드리버(Windriver)에서 소프트웨어엔지니어로 일하고 있다. 리눅스 커널, 밤 하늘, 사진, 그리고 움직이는 모든 것에 대해 관심이 많으며, GNU 프로젝트 한국 팀 대표로 활동하고 있다.

[옮긴이] 이기동 중앙대학교 컴퓨터공학과를 졸업했고, 쓰리알소프트에서 웹 메일 시스템을 개발했다. 월간 「프로그램 세계」의 한 코너로 「리눅스 저널」을 번역해 실은 경험이 있다.

[옮긴이] 최준호 웹데이터뱅크를 거쳐 현재 씨디네트웍스 최고기술책임자 겸 성능팀장으로 재직 중이다. 대학 시절 리눅스와 FreeBSD를 접한 이래 네트스케이프 브라우저 한글화, GNU 번역 프로젝트 및 관련 유틸리티(nh2ps, nhppf)를 오픈소스로 만든 바 있으며, 2000년에서 2010년까지 FreeBSD 포트 커미터(cjh@)를 맡아 korean카테고리의 한글 관련 프로그램 패키징을 주로 진행했다. 회사에서는 운영과 개발 부서를 번갈아 담당했으며, 현재 CDN(Contents Delivery Network)과 AND(Application Delivery Network)의 성능 향상을 위한 데이터 모니터링 및 분석 작업을 진행하고 있다. 목차 추천사 저자 서문 한국어판 서자 서문

1장 해커 문화의 짧은 역사 요약 프롤로그: 진정한 프로그래머 초기 해커들 유닉스의 부상 오랜 시대의 끝 상용 유닉스 시대 초기의 공개 유닉스 웹의 폭발적인 성장

2장 성당과 시장 요약 성당과 시장 메일은 배달되어야만 한다 사용자가 있다는 것의 중요성 일찍, 그리고 자주 발표하라 장미가 장미다우려면 팝클라이언트가 페치메일이 되다 페치메일의 성장 페치메일에서 배울 점 시장 방식 개발에 필요한 선행조건들 오픈소스 소프트웨어의 사회적 문맥 후기: 네트스케이프가 시장 스타일을 받아들이다! 읽어볼 만한 글들 감사의 글

3장 얼누리의 개간 모순의 소개 해커 이념의 다양성 방종한 이론과 순결한 실천 소유권과 오픈소스 로크와 토지 소유권 증여경제로서의 해커 문화 해킹의 즐거움 명성의 여러 모습 소유권과 명성 추구 동기 자아의 문제 겸손의 가치 명성 게임 모델의 포괄적 의미 얼마나 좋은 증여인가? 얼누리 소유권과 세력권의 동물행동학 분쟁의 원인 프로젝트 구조와 소유권 분쟁과 분쟁 해결 문화적응과 학계로의 연결 교환을 능가하는 증여 결론: 관습에서 관습법으로 앞으로의 연구 과제 감사의 글

4장 마법의 솥 요약 마법과 구별할 수 없는 증여하는 기크를 넘어 제조업 착각 ‘정보는 무료여야 한다’는 신화 역공유지 소스를 폐쇄하는 이유 사용가치 자금 마련 모델 왜 판매가치가 문제가 되는가 간접 판매가치 모델 공개할 때와 폐쇄할 때 전략 무기로서의 오픈소스 오픈소스와 전략적 사업 위험 오픈소스의 사업 생태 성공에 대처하기 오픈 R&D와 후원 제도의 재발명 더 높은 곳으로 도약하기 결론: 혁명 뒤의 세상 뒷이야기: 왜 드라이버를 폐쇄하는 업체가 손해를 보는가? 감사의 글

5장 해커들의 반란 해커들의 반란 브룩스의 법칙을 넘어서 문화유전과 신화 창조 마운틴뷰로 가는 길 오픈소스의 기원 우연히 일어난 혁명 운동의 위상 현장의 진실 미래에 대한 전망

6장 후기: 소프트웨어를 넘어서?

7장 더 읽어볼 글들

부록 A 해커가 되는 방법 부록 B 페치메일 프로젝트 성장의 통계적 흐름 부록 C 에릭 레이먼드의 한국 관광 부록 D 오픈소스 정의 1.9판 부록 E 열린 출판 이용허락 1.0판 접어보기 만든 이 코멘트 저자, 역자, 편집자를 위한 공간입니다. 독자들에게 전하고 싶은 말씀을 남겨주세요. 코멘트 쓰기 접수된 글은 확인을 거쳐 이 곳에 게재됩니다. 독자 분들의 리뷰는 리뷰 쓰기를, 책에 대한 문의는 1:1 문의를 이용해 주세요. 출판사 리뷰 현대 흐름에 맞춰 재편집한 『성당과 시장(The Cathedral and the Bazaar)』의 한국어 번역판 『성당과 시장』은 1990년대 중반부터 이어지고 있는 오픈소스 운동을 사회경제적인 측면에서 분석한 에릭 레이먼드의 주요 저작을 모아 놓은 『성당과 시장(The Cathedral and the Bazaar)』의 한국어 번역판이다. 이 책은 개발 비용을 낮추고 품질 향상을 가능케 하는 체계적인 공개 개발과 분산화된 동료검토 방법을 가진 시장모델 오픈소스 소프트웨어에 대해 설명한다. 독자는 시장모델을 적용하여 페치메일을 성공시킨 저자의 경험을 통해 좀 더 나은 품질의 믿을 만한 소프트웨어를 만드는 방법을 깊이 있게 이해하고 그 속에 함축된 개념들을 함께 이해함으로써 오픈소스 개발을 어떤 방향으로 잡고 개발을 진행해야 하는지 깨달을 수 있다.

저자는 해커 문화 안에서 오랜 시간을 보내며 세상에서 가장 재미있고 뛰어난 사람들과 함께 작업하며 흥미로운 문제들을 해결하고 새롭고 유용한 것들을 만들 수 있는 특혜를 누려왔다고 말한다. 독자들도 저자가 오랫동안 걸어온 매력적인 여정의 기록을 함께 읽으며, 오픈소스를 향한 여행의 즐거움과 앞으로 펼쳐질 놀라운 가능성을 느끼고, 많은 것들에 대한 귀중한 교훈을 얻을 수 있길 바란다.

원문: The Cathedral and the Bazaar 성당과 시장

gemini 번역

Copyright

Copyright (c) 2000 by Eric S. Raymond. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License (the latest version is presently available at http://www.opencontent.org/openpub/).

Abstract

I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of the surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the “cathedral” model of most of the commercial world versus the “bazaar” model of the Linux world. I show that these models derive from opposing assumptions about the nature of the software-debugging task. I then make a sustained argument from the Linux experience for the proposition that “Given enough eyeballs, all bugs are shallow”, suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software.

저는 리눅스의 역사에서 제시된 소프트웨어 엔지니어링에 대한 놀라운 이론을 의도적으로 테스트하기 위해 실행된 성공적인 오픈 소스 프로젝트인 fetchmail을 분석합니다. 저는 이러한 이론을 대부분의 상업 세계의 “대성당” 모델과 리눅스 세계의 “바자회” 모델이라는 근본적으로 다른 두 가지 개발 스타일로 논의합니다. 저는 이러한 모델이 소프트웨어 디버깅 작업의 본질에 대한 상반된 가정에서 비롯된다는 것을 보여줍니다. 그런 다음 저는 “눈알이 충분히 많으면 모든 버그는 얕다”라는 명제에 대해 리눅스 경험에서 지속적인 주장을 펼치고, 이기적인 에이전트의 다른 자기 교정 시스템과의 생산적인 유사성을 제시하고, 이 통찰력이 소프트웨어의 미래에 미치는 영향에 대한 몇 가지 탐구로 결론을 맺습니다.

Introduction

Linux is subversive. Who would have thought even five years ago (1991) that a world-class operating system could coalesce as if by magic out of part-time hacking by several thousand developers scattered all over the planet, connected only by the tenuous strands of the Internet?

리눅스는 파괴적이다. 5년 전(1991년)만 해도 세계적인 운영체제가 인터넷이라는 미약한 연결망으로 연결된 전 세계 수천 명의 개발자들이 파트타임으로 해킹한 결과로 마법처럼 뭉쳐질 것이라고 누가 상상이나 했겠는가?

Certainly not I. By the time Linux swam onto my radar screen in early 1993, I had already been involved in Unix and open-source development for ten years. I was one of the first GNU contributors in the mid-1980s. I had released a good deal of open-source software onto the net, developing or co-developing several programs (nethack, Emacs’s VC and GUD modes, xlife, and others) that are still in wide use today. I thought I knew how it was done.

저는 물론 아닙니다. 1993년 초 Linux가 제 레이더망에 들어왔을 때, 저는 이미 10년 동안 Unix 및 오픈 소스 개발에 참여해 왔습니다. 저는 1980년대 중반에 GNU 기여자 중 한 명이었습니다. 저는 상당한 양의 오픈 소스 소프트웨어를 네트워크에 배포하여 여러 프로그램(nethack, Emacs의 VC 및 GUD 모드, xlife 등)을 개발하거나 공동 개발했으며, 이 프로그램들은 오늘날에도 널리 사용되고 있습니다. 저는 어떻게 해야 하는지 안다고 생각했습니다.

Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

리눅스는 제가 알고 있다고 생각했던 많은 것을 뒤엎었습니다. 저는 오랫동안 작은 도구, 빠른 프로토타입 제작, 진화적 프로그래밍이라는 Unix의 복음을 전파해 왔습니다. 하지만 저는 또한 일정한 임계 복잡성 이상에서는 더 중앙 집중화된, 사전적 접근 방식이 필요하다고 믿었습니다. 저는 가장 중요한 소프트웨어(운영 체제 및 Emacs 프로그래밍 편집기와 같은 정말 큰 도구)는 대성당처럼, 고립된 상태에서 작업하는 개인 마법사나 작은 마법사 집단에 의해 신중하게 만들어져야 하며, 때가 되기 전에 베타를 출시해서는 안 된다고 믿었습니다.

Linus Torvalds’s style of development---release early and often, delegate everything you can, be open to the point of promiscuity---came as a surprise. No quiet, reverent cathedral-building here---rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.

리누스 토르발스의 개발 방식, 즉 일찍 자주 출시하고, 할 수 있는 모든 것을 위임하고, 무분별할 정도로 개방적인 태도는 놀라웠습니다. 여기에는 조용하고 경건한 대성당 건설이 없었습니다. 오히려 리눅스 커뮤니티는 다양한 의제와 접근 방식으로 끊임없이 수다를 떠는 거대한 바자회와 같았습니다(누구든 제출물을 받는 리눅스 아카이브 사이트가 적절하게 상징함). 이 바자회에서 일관성 있고 안정적인 시스템은 일련의 기적을 통해서만 나타날 수 있을 것 같았습니다.

The fact that this bazaar style seemed to work, and work well, came as a distinct shock. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn’t fly apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders.

이 바자회 스타일이 효과가 있는 것처럼 보였고, 실제로 효과가 좋다는 사실은 뚜렷한 충격으로 다가왔습니다. 주변을 알아가면서 저는 개별 프로젝트뿐만 아니라 리눅스 세계가 왜 혼란 속에서 무너지지 않고 대성당 건설자들에게는 상상하기 어려울 정도의 속도로 계속해서 강해지는지 이해하려고 노력했습니다.

By mid-1996 I thought I was beginning to understand. Chance handed me a perfect way to test my theory, in the form of an open-source project that I could consciously try to run in the bazaar style. So I did---and it was a significant success.

1996년 중반쯤에는 이해하기 시작했다고 생각했습니다. 우연히 바자회 스타일로 의식적으로 실행해 볼 수 있는 오픈 소스 프로젝트 형태로 제 이론을 테스트할 완벽한 방법이 주어졌습니다. 그래서 저는 그렇게 했고, 그것은 상당한 성공을 거두었습니다.

This is the story of that project. I’ll use it to propose some aphorisms about effective open-source development. Not all of these are things I first learned in the Linux world, but we’ll see how the Linux world gives them particular point. If I’m correct, they’ll help you understand exactly what it is that makes the Linux community such a fountain of good software---and, perhaps, they will help you become more productive yourself.

이것은 그 프로젝트에 대한 이야기입니다. 저는 이 프로젝트를 사용하여 효과적인 오픈 소스 개발에 대한 몇 가지 격언을 제시할 것입니다. 이 격언들이 전부 리눅스 세계에서 처음 배운 것은 아니지만, 리눅스 세계가 어떻게 그 격언들에 특별한 의미를 부여하는지 살펴보겠습니다. 제 말이 맞다면, 이 격언들은 리눅스 커뮤니티를 훌륭한 소프트웨어의 원천으로 만드는 요인이 정확히 무엇인지 이해하는 데 도움이 될 것이고, 어쩌면 여러분 스스로도 더 생산적으로 일하는 데 도움이 될 것입니다.

The Mail Must Get Through

반드시 우편물을 전달해야 한다

Since 1993 I’d been running the technical side of a small free-access Internet service provider called Chester County InterLink (CCIL) in West Chester, Pennsylvania. I co-founded CCIL and wrote our unique multiuser bulletin-board software---you can check it out by telnetting to [BROKEN LINK: telnet://locke.ccil.org]. Today it supports almost three thousand users on thirty lines. The job allowed me 24-hour-a-day access to the net through CCIL’s 56K line---in fact, the job practically demanded it!

1993년부터 나는 펜실베이니아주 웨스트체스터에 있는 작은 무료 액세스 인터넷 서비스 제공업체인 체스터 카운티 인터링크(CCIL)의 기술 측면을 운영해 왔다. 나는 CCIL을 공동 설립하고 우리의 독특한 다중 사용자 게시판 소프트웨어를 작성했다. locke.ccil.org에 텔넷으로 접속하여 확인할 수 있다. 오늘날 그것은 30개의 라인에서 거의 3천 명의 사용자를 지원한다. 그 일 덕분에 나는 CCIL의 56K 회선을 통해 하루 24시간 내내 인터넷에 접속할 수 있었다. 사실, 그 일은 거의 그것을 요구했다!

I had gotten quite used to instant Internet email. I found having to periodically telnet over to locke to check my mail annoying. What I wanted was for my mail to be delivered on snark (my home system) so that I would be notified when it arrived and could handle it using all my local tools.

나는 즉각적인 인터넷 이메일에 꽤 익숙해졌다. 주기적으로 locke에 텔넷으로 접속하여 메일을 확인하는 것이 짜증난다는 것을 알게 되었다. 내가 원했던 것은 내 메일이 snark(내 홈 시스템)로 배달되어 메일이 도착했을 때 알림을 받고 내 로컬 도구를 모두 사용하여 처리할 수 있도록 하는 것이었다.

The Internet’s native mail forwarding protocol, SMTP (Simple Mail Transfer Protocol), wouldn’t suit, because it works best when machines are connected full-time, while my personal machine isn’t always on the Internet, and doesn’t have a static IP address. What I needed was a program that would reach out over my intermittent dialup connection and pull across my mail to be delivered locally. I knew such things existed, and that most of them used a simple application protocol called POP (Post Office Protocol). POP is now widely supported by most common mail clients, but at the time, it wasn’t built in to the mail reader I was using.

인터넷의 기본 메일 전달 프로토콜인 SMTP(Simple Mail Transfer Protocol)는 내 개인 컴퓨터가 항상 인터넷에 연결되어 있지 않고 고정 IP 주소가 없기 때문에 적합하지 않았다. 내가 필요로 했던 것은 간헐적인 다이얼업 연결을 통해 연결하여 내 메일을 로컬로 전달되도록 가져오는 프로그램이었다. 나는 그런 것들이 존재한다는 것을 알고 있었고, 대부분 POP(Post Office Protocol)라는 간단한 애플리케이션 프로토콜을 사용한다는 것을 알고 있었다. POP는 현재 대부분의 일반적인 메일 클라이언트에서 널리 지원되지만 당시에는 내가 사용하고 있던 메일 리더에 내장되어 있지 않았다.

I needed a POP3 client. So I went out on the Internet and found one. Actually, I found three or four. I used one of them for a while, but it was missing what seemed an obvious feature, the ability to hack the addresses on fetched mail so replies would work properly.

POP3 클라이언트가 필요했습니다. 그래서 인터넷에서 하나를 찾았습니다. 사실 세 개나 네 개를 찾았습니다. 그 중 하나를 얼마 동안 사용했지만, 가져온 메일의 주소를 해킹하여 답장이 제대로 작동하도록 하는 명백한 기능이 없었습니다.

The problem was this: suppose someone named ‘joe’ on locke sent me mail. If I fetched the mail to snark and then tried to reply to it, my mailer would cheerfully try to ship it to a nonexistent ‘joe’ on snark. Hand-editing reply addresses to tack on @ccil.org quickly got to be a serious pain.

문제는 다음과 같았습니다. locke의 ‘joe’라는 사람이 저에게 메일을 보냈다고 가정해 봅시다. 제가 snark로 메일을 가져온 다음 회신하려고 하면, 제 메일러는 snark에 존재하지 않는 ‘joe’에게 메일을 보내려고 할 것입니다. 회신 주소를 손으로 편집하여 @ccil.org 을 덧붙이는 것은 곧 심각한 고통이 되었습니다.

This was clearly something the computer ought to be doing for me. But none of the existing POP clients knew how! And this brings us to the first lesson:

이것은 분명히 컴퓨터가 나를 위해 해야 할 일이었습니다. 하지만 기존의 POP 클라이언트 중 누구도 그 방법을 알지 못했습니다! 그리고 이것이 첫 번째 교훈입니다.

Every good work of software starts by scratching a developer’s personal itch.

모든 훌륭한 소프트웨어 작품은 개발자의 개인적인 가려움을 긁는 것에서 시작됩니다.

Perhaps this should have been obvious (it’s long been proverbial that “Necessity is the mother of invention”) but too often software developers spend their days grinding away for pay at programs they neither need nor love. But not in the Linux world---which may explain why the average quality of software originated in the Linux community is so high.

아마도 이것은 당연했어야 할 것입니다(“필요는 발명의 어머니”라는 속담이 오랫동안 있었음). 그러나 너무나 자주 소프트웨어 개발자들은 필요하지도 좋아하지도 않는 프로그램을 위해 돈을 받으며 힘든 나날을 보냅니다. 그러나 Linux 세계에서는 그렇지 않습니다. 이것이 Linux 커뮤니티에서 시작된 소프트웨어의 평균 품질이 매우 높은 이유를 설명해 줄 것입니다.

So, did I immediately launch into a furious whirl of coding up a brand-new POP3 client to compete with the existing ones? Not on your life! I looked carefully at the POP utilities I had in hand, asking myself “Which one is closest to what I want?” Because:

그래서, 기존의 것들과 경쟁하기 위해 곧바로 맹렬하게 새로운 POP3 클라이언트를 코딩하기 시작했을까요? 천만에요! 나는 내가 가진 POP 유틸리티를 주의 깊게 살펴보면서 스스로에게 “어떤 것이 내가 원하는 것에 가장 가까운가?”라고 물었습니다. 왜냐하면:

Good programmers know what to write. Great ones know what to rewrite (and reuse).

좋은 프로그래머는 무엇을 써야 할지 안다. 훌륭한 프로그래머는 무엇을 다시 쓰고 (그리고 재사용해야) 할지 안다.

While I don’t claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it’s almost always easier to start from a good partial solution than from nothing at all.

저는 훌륭한 프로그래머라고 주장하지는 않지만, 훌륭한 프로그래머를 흉내 내려고 노력합니다. 훌륭한 프로그래머의 중요한 특징 중 하나는 건설적인 게으름입니다. 그들은 노력이 아닌 결과로 A를 받는다는 것과, 아무것도 없는 상태에서 시작하는 것보다 좋은 부분적인 해결책에서 시작하는 것이 거의 항상 더 쉽다는 것을 알고 있습니다.

Linus Torvalds, for example, didn’t actually try to write Linux from scratch. Instead, he started by reusing code and ideas from Minix, a tiny Unix-like operating system for PC clones. Eventually all the Minix code went away or was completely rewritten---but while it was there, it provided scaffolding for the infant that would eventually become Linux.

예를 들어, 리누스 토르발스는 실제로 리눅스를 처음부터 작성하려고 시도하지 않았습니다. 대신 PC 복제본용 초소형 Unix와 유사한 운영 체제인 Minix의 코드와 아이디어를 재사용하여 시작했습니다. 결국 모든 Minix 코드는 사라지거나 완전히 다시 작성되었지만, 그 코드가 존재하는 동안 결국 Linux가 될 갓난아기를 위한 발판을 제공했습니다.

In the same spirit, I went looking for an existing POP utility that was reasonably well coded, to use as a development base.

같은 정신으로, 저는 개발 기반으로 사용할 수 있는 합리적으로 잘 코딩된 기존 POP 유틸리티를 찾기 시작했습니다.

The source-sharing tradition of the Unix world has always been friendly to code reuse (this is why the GNU project chose Unix as a base OS, in spite of serious reservations about the OS itself). The Linux world has taken this tradition nearly to its technological limit; it has terabytes of open sources generally available. So spending time looking for some else’s almost-good-enough is more likely to give you good results in the Linux world than anywhere else.

Unix 세계의 소스 공유 전통은 항상 코드 재사용에 우호적이었습니다(이것이 GNU 프로젝트가 OS 자체에 대한 심각한 유보에도 불구하고 Unix를 기본 OS로 선택한 이유입니다). Linux 세계는 이 전통을 거의 기술적인 한계까지 끌어올렸습니다. 일반적으로 사용할 수 있는 테라바이트 단위의 오픈 소스가 있습니다. 따라서 다른 곳보다 Linux 세계에서 거의 충분히 좋은 다른 사람의 것을 찾는 데 시간을 보내는 것이 더 나은 결과를 가져올 가능성이 높습니다.

And it did for me. With those I’d found earlier, my second search made up a total of nine candidates---fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail and upop. The one I first settled on was ‘fetchpop’ by Seung-Hong Oh. I put my header-rewrite feature in it, and made various other improvements which the author accepted into his 1.9 release.

그리고 그것은 나에게 효과가 있었다. 앞서 찾았던 것들과 함께 두 번째 검색을 통해 총 9개의 후보를 찾았다. fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail, upop. 내가 처음 정착한 것은 Seung-Hong Oh의 ‘fetchpop’이었다. 거기에 헤더 재작성 기능을 넣었고, 저자가 1.9 릴리스에 포함하도록 다양한 개선을 수행했다.

A few weeks later, though, I stumbled across the code for popclient by Carl Harris, and found I had a problem. Though fetchpop had some good original ideas in it (such as its background-daemon mode), it could only handle POP3 and was rather amateurishly coded (Seung-Hong was at that time a bright but inexperienced programmer, and both traits showed). Carl’s code was better, quite professional and solid, but his program lacked several important and rather tricky-to-implement fetchpop features (including those I’d coded myself).

몇 주 후, Carl Harris의 popclient 코드를 우연히 발견했는데 문제가 있었습니다. fetchpop에는 몇 가지 좋은 독창적인 아이디어가 있었지만(예: 백그라운드 데몬 모드), POP3만 처리할 수 있었고 코딩이 다소 아마추어적이었습니다(당시 승홍은 똑똑하지만 경험이 부족한 프로그래머였고, 두 가지 특징이 모두 드러났습니다). Carl의 코드는 더 나았고, 꽤 전문적이고 견고했지만, 그의 프로그램에는 몇 가지 중요한 fetchpop 기능(제가 직접 코딩한 기능 포함)이 부족했습니다.

Stay or switch? If I switched, I’d be throwing away the coding I’d already done in exchange for a better development base.

유지할까 아니면 바꿀까? 만약 바꾼다면, 더 나은 개발 기반을 얻는 대신 이미 작성한 코딩을 버리는 셈이 될 것이다.

A practical motive to switch was the presence of multiple-protocol support. POP3 is the most commonly used of the post-office server protocols, but not the only one. Fetchpop and the other competition didn’t do POP2, RPOP, or APOP, and I was already having vague thoughts of perhaps adding IMAP (Internet Message Access Protocol, the most recently designed and most powerful post-office protocol) just for fun.

전환의 실질적인 동기는 다중 프로토콜 지원이 존재했기 때문입니다. POP3는 우체국 서버 프로토콜 중에서 가장 일반적으로 사용되지만 유일한 것은 아닙니다. Fetchpop과 다른 경쟁 제품들은 POP2, RPOP 또는 APOP를 지원하지 않았고, 저는 이미 재미로 IMAP(인터넷 메시지 액세스 프로토콜, 가장 최근에 설계되었고 가장 강력한 우체국 프로토콜)를 추가할까 하는 막연한 생각을 하고 있었습니다.

But I had a more theoretical reason to think switching might be as good an idea as well, something I learned long before Linux.

하지만 전환이 좋은 생각일 수도 있다고 생각할 만한 더 이론적인 이유가 있었는데, 그것은 리눅스 이전부터 제가 오랫동안 알고 있던 것이었습니다.

“Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)

“하나를 버릴 계획을 세우십시오. 어쨌든 그렇게 될 것입니다.” (프레드 브룩스, 신화적인 맨먼스, 11장)

Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once [JB].

또는 다른 말로 하자면, 해결책을 처음 구현할 때까지는 문제에 대해 제대로 이해하지 못하는 경우가 많습니다. 두 번째에는 제대로 할 수 있을 만큼 충분히 알게 될 수도 있습니다. 따라서 제대로 하고 싶다면 최소한 한 번은 다시 시작할 준비를 하십시오 [JB].

Well (I told myself) the changes to fetchpop had been my first try. So I switched.

음 (혼잣말로) fetchpop에 대한 변경 사항은 나의 첫 번째 시도였어. 그래서 갈아탔지.

After I sent my first set of popclient patches to Carl Harris on 25 June 1996, I found out that he had basically lost interest in popclient some time before. The code was a bit dusty, with minor bugs hanging out. I had many changes to make, and we quickly agreed that the logical thing for me to do was take over the program.

1996년 6월 25일에 Carl Harris에게 첫 번째 popclient 패치 세트를 보낸 후, 그는 이미 얼마 전에 popclient에 대한 관심을 잃었다는 것을 알게 되었습니다. 코드는 약간 먼지가 쌓여 있었고, 사소한 버그들이 남아 있었죠. 수정해야 할 사항이 많았고, 제가 프로그램을 인수하는 것이 논리적이라는 데 빠르게 동의했습니다.

Without my actually noticing, the project had escalated. No longer was I just contemplating minor patches to an existing POP client. I took on maintaining an entire one, and there were ideas bubbling in my head that I knew would probably lead to major changes.

제가 실제로 알아차리지 못하는 사이에 프로젝트가 확대되었습니다. 더 이상 기존 POP 클라이언트에 대한 사소한 패치를 고려하는 것이 아니었습니다. 저는 전체 클라이언트를 유지 관리하게 되었고, 아마도 주요 변경으로 이어질 것이라는 것을 알고 있는 아이디어가 머릿속에서 맴돌고 있었습니다.

In a software culture that encourages code-sharing, this is a natural way for a project to evolve. I was acting out this principle:

코드 공유를 장려하는 소프트웨어 문화에서 이것은 프로젝트가 발전하는 자연스러운 방식입니다. 저는 이 원칙에 따라 행동하고 있었습니다.

If you have the right attitude, interesting problems will find you.

올바른 태도를 가지면 흥미로운 문제가 당신을 찾아올 것입니다.

But Carl Harris’s attitude was even more important. He understood that

그러나 Carl Harris의 태도는 훨씬 더 중요했습니다. 그는 다음과 같은 점을 이해했습니다.

When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

프로그램에 대한 흥미를 잃었을 때, 그것에 대한 당신의 마지막 의무는 유능한 후임자에게 넘겨주는 것입니다.

Without ever having to discuss it, Carl and I knew we had a common goal of having the best solution out there. The only question for either of us was whether I could establish that I was a safe pair of hands. Once I did that, he acted with grace and dispatch. I hope I will do as well when it comes my turn.

이에 대해 논의할 필요도 없이, Carl과 저는 최고의 솔루션을 내놓는다는 공통 목표를 가지고 있다는 것을 알았습니다. 우리 둘에게 유일한 질문은 내가 안전한 사람임을 증명할 수 있는지였습니다. 일단 제가 그것을 증명하자 그는 품위 있고 신속하게 행동했습니다. 제 차례가 왔을 때 저도 그만큼 잘할 수 있기를 바랍니다.

The Importance of Having Users

사용자 확보의 중요성

And so I inherited popclient. Just as importantly, I inherited popclient’s user base. Users are wonderful things to have, and not just because they demonstrate that you’re serving a need, that you’ve done something right. Properly cultivated, they can become co-developers.

그래서 저는 popclient를 물려받았습니다. 그에 못지않게 중요한 것은 popclient의 사용자 기반을 물려받았다는 것입니다. 사용자는 훌륭한 존재입니다. 이는 여러분이 필요를 충족하고 있고, 무언가를 제대로 해냈다는 것을 보여줄 뿐만 아니라, 제대로 육성하면 공동 개발자가 될 수도 있기 때문입니다.

Another strength of the Unix tradition, one that Linux pushes to a happy extreme, is that a lot of users are hackers too. Because source code is available, they can be effective hackers. This can be tremendously useful for shortening debugging time. Given a bit of encouragement, your users will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided.

유닉스 전통의 또 다른 강점은 리눅스가 행복할 정도로 극단적으로 밀어붙이는 것인데, 많은 사용자가 해커이기도 하다는 점입니다. 소스 코드를 사용할 수 있기 때문에 효과적인 해커가 될 수 있습니다. 이것은 디버깅 시간을 단축하는 데 엄청나게 유용할 수 있습니다. 약간의 격려만 있다면 사용자는 여러분이 혼자서는 할 수 있는 것보다 훨씬 빠르게 문제를 진단하고, 수정 사항을 제안하고, 코드 개선을 도울 것입니다.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

사용자를 공동 개발자로 대하는 것이 가장 간편하게 코드 개선을 신속하게 하고 효과적으로 디버깅하는 방법입니다.

The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently.

이 효과의 힘은 과소평가하기 쉽습니다. 사실, 오픈 소스 세계에 있는 우리 모두는 Linus Torvalds가 우리에게 다른 모습을 보여주기 전까지 사용자 수와 시스템 복잡성에 따라 얼마나 잘 확장될지 극적으로 과소평가했습니다.

In fact, I think Linus’s cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: “I’m basically a very lazy person who likes to get credit for things other people actually do.” Lazy like a fox. Or, as Robert Heinlein famously wrote of one of his characters, too lazy to fail.

사실, Linus의 가장 영리하고 중대한 해킹은 Linux 커널 자체가 아니라 Linux 개발 모델을 발명한 것이라고 생각합니다. 이 의견을 그의 면전에서 표현했을 때, 그는 미소를 지으며 자신이 자주 말했던 내용을 조용히 반복했습니다. “저는 기본적으로 다른 사람들이 실제로 하는 일에 대해 공을 인정받고 싶어하는 매우 게으른 사람입니다.” 여우처럼 게으르다는 뜻입니다. 또는 Robert Heinlein이 자신의 등장인물 중 한 명에 대해 유명하게 썼듯이, 실패하기에는 너무 게으른 것입니다.

In retrospect, one precedent for the methods and success of Linux can be seen in the development of the GNU Emacs Lisp library and Lisp code archives. In contrast to the cathedral-building style of the Emacs C core and most other GNU tools, the evolution of the Lisp code pool was fluid and very user-driven. Ideas and prototype modes were often rewritten three or four times before reaching a stable final form. And loosely-coupled collaborations enabled by the Internet, a la Linux, were frequent.

돌이켜보면 Linux의 방법과 성공에 대한 선례는 GNU Emacs Lisp 라이브러리 및 Lisp 코드 아카이브 개발에서 볼 수 있습니다. Emacs C 코어 및 대부분의 다른 GNU 도구의 대성당 건축 스타일과는 대조적으로 Lisp 코드 풀의 진화는 유동적이고 매우 사용자 중심적이었습니다. 아이디어와 프로토타입 모드는 안정적인 최종 형태에 도달하기 전에 3~4번 다시 작성되는 경우가 많았습니다. 그리고 Linux처럼 인터넷을 통해 느슨하게 연결된 협업이 빈번했습니다.

Indeed, my own most successful single hack previous to fetchmail was probably Emacs VC (version control) mode, a Linux-like collaboration by email with three other people, only one of whom (Richard Stallman, the author of Emacs and founder of the Free Software Foundation) I have met to this day. It was a front-end for SCCS, RCS and later CVS from within Emacs that offered “one-touch” version control operations. It evolved from a tiny, crude sccs.el mode somebody else had written. And the development of VC succeeded because, unlike Emacs itself, Emacs Lisp code could go through release/test/improve generations very quickly.

실제로 fetchmail 이전에 제가 가장 성공적으로 해낸 단일 해킹은 Emacs VC (버전 제어) 모드였을 것입니다. 이는 다른 세 사람과 이메일을 통해 Linux와 유사하게 협업한 것이며, 그 중 한 명 (Emacs의 저자이자 Free Software Foundation의 설립자인 Richard Stallman) 만을 현재까지 만났습니다. 이는 Emacs 내에서 SCCS, RCS 및 이후 CVS에 대한 프런트 엔드였으며 “원터치” 버전 제어 작업을 제공했습니다. 다른 사람이 작성한 작고 조잡한 sccs.el 모드에서 발전했습니다. 그리고 VC 개발이 성공한 이유는 Emacs 자체와 달리 Emacs Lisp 코드는 릴리스/테스트/개선 단계를 매우 빠르게 거칠 수 있었기 때문입니다.

The Emacs story is not unique. There have been other software products with a two-level architecture and a two-tier user community that combined a cathedral-mode core and a bazaar-mode toolbox. One such is MATLAB, a commercial data-analysis and visualization tool. Users of MATLAB and other products with a similar structure invariably report that the action, the ferment, the innovation mostly takes place in the open part of the tool where a large and varied community can tinker with it.

Emacs 이야기는 유일하지 않습니다. 대성당 모드 코어와 바자회 모드 툴박스를 결합한 2단계 아키텍처와 2단계 사용자 커뮤니티를 갖춘 다른 소프트웨어 제품도 있었습니다. 그 중 하나는 상업용 데이터 분석 및 시각화 도구인 MATLAB입니다. MATLAB 및 유사한 구조를 가진 다른 제품의 사용자는 변함없이 활동, 발효, 혁신이 대부분 크고 다양한 커뮤니티가 자유롭게 사용할 수 있는 도구의 공개된 부분에서 발생한다고 보고합니다.

Release Early, Release Often

자주 배포하라, 일찍 배포하라

Early and frequent releases are a critical part of the Linux development model. Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don’t want to wear out the patience of your users.

이르고 잦은 배포는 리눅스 개발 모델의 중요한 부분입니다. 대부분의 개발자(저를 포함하여)는 이것이 사소한 프로젝트보다 큰 프로젝트에는 나쁜 정책이라고 믿었습니다. 왜냐하면 초기 버전은 거의 정의상 버그가 있는 버전이고 사용자의 인내심을 소모시키고 싶지 않기 때문입니다.

This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you’d only release a version every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not---because there were active Lisp archives outside the FSF’s control, where you could go to find new and development code versions independently of Emacs’s release cycle [QR].

이러한 믿음은 성당 건축 스타일의 개발에 대한 일반적인 헌신을 강화했습니다. 최우선 목표가 사용자가 가능한 한 적은 버그를 보도록 하는 것이라면 6개월(또는 그보다 덜 자주)마다 버전을 배포하고 릴리스 사이에 디버깅하는 데 개처럼 일할 것입니다. Emacs C 코어가 이런 식으로 개발되었습니다. 사실상 Lisp 라이브러리는 그렇지 않았습니다. 왜냐하면 FSF의 통제를 벗어난 활성 Lisp 아카이브가 있었고, 그곳에서 Emacs의 릴리스 주기와 독립적으로 새로운 개발 코드 버전을 찾을 수 있었기 때문입니다[QR].

The most important of these, the Ohio State Emacs Lisp archive, anticipated the spirit and many of the features of today’s big Linux archives. But few of us really thought very hard about what we were doing, or about what the very existence of that archive suggested about problems in the FSF’s cathedral-building development model. I made one serious attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs Lisp library. I ran into political trouble and was largely unsuccessful.

이 중 가장 중요한 오하이오 주립 Emacs Lisp 아카이브는 오늘날의 대규모 Linux 아카이브의 정신과 많은 기능을 예상했습니다. 그러나 우리 중 소수는 우리가 무엇을 하고 있는지, 또는 해당 아카이브의 존재가 FSF의 성당 건축 개발 모델의 문제점에 대해 무엇을 암시하는지에 대해 진지하게 생각했습니다. 저는 1992년경에 오하이오 코드를 공식 Emacs Lisp 라이브러리에 공식적으로 병합하려는 심각한 시도를 했습니다. 저는 정치적 문제에 부딪혀 크게 성공하지 못했습니다.

But by a year later, as Linux became widely visible, it was clear that something different and much healthier was going on there. Linus’s open development policy was the very opposite of cathedral-building. Linux’s Internet archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases.

그러나 1년 후 리눅스가 널리 알려지면서 뭔가 다르고 훨씬 건전한 일이 벌어지고 있다는 것이 분명해졌습니다. 리누스의 개방형 개발 정책은 대성당 건설과는 정반대였습니다. 리눅스의 인터넷 아카이브는 급증하고 있었고, 여러 배포판이 떠돌아다니고 있었습니다. 그리고 이 모든 것은 전례 없는 빈도의 핵심 시스템 릴리스에 의해 주도되었습니다.

Linus was treating his users as co-developers in the most effective possible way:

리누스는 사용자들을 가능한 한 효과적인 방법으로 공동 개발자로서 대우하고 있었습니다.

Release early. Release often. And listen to your customers.

일찍 릴리스하라. 자주 릴리스하라. 그리고 고객의 의견을 경청하라.

Linus’s innovation wasn’t so much in doing quick-turnaround releases incorporating lots of user feedback (something like this had been Unix-world tradition for a long time), but in scaling it up to a level of intensity that matched the complexity of what he was developing. In those early times (around 1991) it wasn’t unknown for him to release a new kernel more than once a day! Because he cultivated his base of co-developers and leveraged the Internet for collaboration harder than anyone else, this worked.

리누스의 혁신은 많은 사용자 피드백을 통합한 빠른 턴어라운드 릴리스를 수행하는 데 있다기보다는 (이와 비슷한 것은 오랫동안 유닉스 세계의 전통이었습니다), 그가 개발하고 있는 것의 복잡성에 맞는 강도로 그것을 확장하는 데 있었습니다. 초기 시절(1991년경)에는 하루에 한 번 이상 새로운 커널을 릴리스하는 것이 드문 일이 아니었습니다! 그는 공동 개발자 기반을 육성하고 다른 누구보다 인터넷을 활용하여 협업했기 때문에 이것이 가능했습니다.

But how did it work? And was it something I could duplicate, or did it rely on some unique genius of Linus Torvalds?

그런데 그건 어떻게 작동했을까? 그리고 내가 복제할 수 있는 것일까, 아니면 리누스 토르발즈의 독특한 천재성에 의존하는 것일까?

I didn’t think so. Granted, Linus is a damn fine hacker. How many of us could engineer an entire production-quality operating system kernel from scratch? But Linux didn’t represent any awesome conceptual leap forward. Linus is not (or at least, not yet) an innovative genius of design in the way that, say, Richard Stallman or James Gosling (of NeWS and Java) are. Rather, Linus seems to me to be a genius of engineering and implementation, with a sixth sense for avoiding bugs and development dead-ends and a true knack for finding the minimum-effort path from point A to point B. Indeed, the whole design of Linux breathes this quality and mirrors Linus’s essentially conservative and simplifying design approach.

저는 그렇게 생각하지 않았습니다. 물론, 리누스는 정말 뛰어난 해커입니다. 우리 중 몇 명이나 처음부터 완전한 상용 수준의 운영 체제 커널을 설계할 수 있을까요? 하지만 리눅스는 엄청난 개념적 도약을 나타내지는 않았습니다. 리누스는 리처드 스톨먼이나 (NeWS와 Java의) 제임스 고슬링처럼 혁신적인 디자인 천재는 아닙니다 (적어도 아직까지는). 오히려 리누스는 버그와 개발의 막다른 골목을 피하는 육감과 A 지점에서 B 지점으로 가는 최소 노력 경로를 찾는 진정한 재능을 가진 엔지니어링 및 구현의 천재인 것 같습니다. 실제로 리눅스의 전체 디자인은 이러한 품질을 나타내며 리누스의 본질적으로 보수적이고 단순화하는 디자인 접근 방식을 반영합니다.

So, if rapid releases and leveraging the Internet medium to the hilt were not accidents but integral parts of Linus’s engineering-genius insight into the minimum-effort path, what was he maximizing? What was he cranking out of the machinery?

그렇다면 빠른 릴리스와 인터넷 매체를 최대한 활용하는 것이 우연이 아니라 최소 노력 경로에 대한 리누스의 엔지니어링 천재성의 필수적인 부분이었다면, 그는 무엇을 극대화하고 있었을까요? 그는 기계에서 무엇을 쏟아내고 있었을까요?

Put that way, the question answers itself. Linus was keeping his hacker/users constantly stimulated and rewarded---stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work.

그렇게 말하면 질문은 스스로 답을 합니다. 리누스는 자신의 해커/사용자들이 자존심을 만족시키는 활동에 참여할 수 있다는 기대감으로 끊임없이 자극하고 보상했습니다. 또한 자신의 작업이 지속적으로 (심지어 매일) 개선되는 것을 보면서 보상했습니다.

Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:

리누스는 심각한 버그가 해결 불가능한 것으로 판명될 경우 코드의 불안정성과 사용자 기반의 소진이라는 가능한 비용을 감수하더라도 디버깅 및 개발에 투입되는 인시(人時)의 수를 극대화하는 것을 직접적으로 목표로 했습니다. 리누스는 다음과 같은 것을 믿는 것처럼 행동했습니다.

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

충분히 큰 베타 테스터 및 공동 개발자 기반이 있다면 거의 모든 문제가 빠르게 파악되고 해결 방법이 누군가에게는 분명해질 것입니다.

Or, less formally, Given enough eyeballs, all bugs are shallow. I dub this: “Linus’s Law”.

또는 좀 더 격식 없이 말하면, 충분한 눈이 있다면 모든 버그는 얕다. 나는 이것을 “리누스의 법칙”이라고 부른다.

My original formulation was that every problem “will be transparent to somebody”. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. “Somebody finds the problem,” he says, “and somebody else understands it. And I’ll go on record as saying that finding it is the bigger challenge.” That correction is important; we’ll see how in the next section, when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.

나의 원래 공식은 모든 문제가 “누군가에게는 투명할 것”이라는 것이었습니다. 리누스는 문제를 이해하고 해결하는 사람이 반드시 문제를 처음 파악하는 사람은 아니라고 이의를 제기했습니다. 그는 “누군가가 문제를 발견하고 다른 누군가가 그것을 이해합니다. 그리고 문제를 찾는 것이 더 큰 도전이라고 기록할 것입니다.”라고 말합니다. 그 수정은 중요합니다. 다음 섹션에서 디버깅의 실제 사례를 더 자세히 살펴볼 때 그 이유를 알게 될 것입니다. 그러나 핵심은 프로세스의 두 부분(찾기와 수정) 모두 빠르게 발생하는 경향이 있다는 것입니다.

In Linus’s Law, I think, lies the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

리누스의 법칙에는 성당 건축가 스타일과 바자회 스타일의 근본적인 차이가 있다고 생각합니다. 성당 건축가 관점에서 프로그래밍에서 버그와 개발 문제는 까다롭고, 교활하며, 심오한 현상입니다. 모든 버그를 찾아냈다는 확신을 얻으려면 헌신적인 소수의 사람들이 몇 달 동안 면밀히 조사해야 합니다. 따라서 릴리스 간격이 길어지고 오랫동안 기다려온 릴리스가 완벽하지 않을 때 불가피한 실망감이 생깁니다.

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena---or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.

반면에 바자회 관점에서는 버그가 일반적으로 피상적인 현상이라고 가정합니다. 적어도 수천 명의 열성적인 공동 개발자들이 모든 새로운 릴리스를 두드리면 버그는 매우 빠르게 피상적으로 변합니다. 따라서 더 많은 수정을 얻기 위해 자주 릴리스하며, 가끔 실수가 발생하더라도 잃을 것이 적다는 이점이 있습니다.

And that’s it. That’s enough. If “Linus’s Law” is false, then any system as complex as the Linux kernel, being hacked over by as many hands as the that kernel was, should at some point have collapsed under the weight of unforseen bad interactions and undiscovered “deep” bugs. If it’s true, on the other hand, it is sufficient to explain Linux’s relative lack of bugginess and its continuous uptimes spanning months or even years.

그게 전부입니다. 그것으로 충분합니다. 만약 “리누스의 법칙”이 거짓이라면, 리눅스 커널만큼 복잡하고 많은 사람들이 해킹하는 시스템은 예측하지 못한 나쁜 상호 작용과 발견되지 않은 “깊은” 버그의 무게로 인해 어느 시점에서 무너졌어야 합니다. 반면에 그것이 사실이라면 리눅스의 상대적인 버그 부족과 몇 달 또는 심지어 몇 년에 걸친 지속적인 가동 시간을 설명하기에 충분합니다.

Maybe it shouldn’t have been such a surprise, at that. Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect. It appears that what Linus has shown is that this applies even to debugging an operating system---that the Delphi effect can tame development complexity even at the complexity level of an OS kernel [CV].

어쩌면 그렇게 놀라운 일도 아니었을 것입니다. 사회학자들은 오래전에 동일하게 전문적인 (또는 동일하게 무지한) 관찰자들의 평균적인 의견이 무작위로 선택된 단일 관찰자의 의견보다 훨씬 더 신뢰할 수 있는 예측 변수라는 것을 발견했습니다. 그들은 이것을 델파이 효과라고 불렀습니다. 리누스가 보여준 것은 이것이 운영 체제 디버깅에도 적용된다는 것, 즉 델파이 효과가 OS 커널 수준의 개발 복잡성도 길들일 수 있다는 것입니다 [CV].

One special feature of the Linux situation that clearly helps along the Delphi effect is the fact that the contributors for any given project are self-selected. An early respondent pointed out that contributions are received not from a random sample, but from people who are interested enough to use the software, learn about how it works, attempt to find solutions to problems they encounter, and actually produce an apparently reasonable fix. Anyone who passes all these filters is highly likely to have something useful to contribute.

델파이 효과를 명확하게 돕는 리눅스 상황의 한 가지 특별한 특징은 주어진 프로젝트에 대한 기여자가 자발적으로 선택된다는 사실입니다. 초기 응답자는 기여가 무작위 표본에서 오는 것이 아니라 소프트웨어를 사용하고, 작동 방식을 배우고, 발생하는 문제에 대한 해결책을 찾고, 실제로 합리적인 수정 사항을 생성할 만큼 충분히 관심 있는 사람들로부터 받는다는 점을 지적했습니다. 이러한 모든 필터를 통과하는 사람은 유용한 것을 기여할 가능성이 매우 높습니다.

Linus’s Law can be rephrased as “Debugging is parallelizable”. Although debugging requires debuggers to communicate with some coordinating developer, it doesn’t require significant coordination between debuggers. Thus it doesn’t fall prey to the same quadratic complexity and management costs that make adding developers problematic.

리누스 법칙은 “디버깅은 병렬화할 수 있다”로 바꿔 말할 수 있습니다. 디버깅은 디버거가 조정 개발자와 통신해야 하지만, 디버거 간의 상당한 조정을 필요로 하지는 않습니다. 따라서 개발자를 추가하는 것을 어렵게 만드는 동일한 이차 복잡성과 관리 비용의 영향을 받지 않습니다.

In practice, the theoretical loss of efficiency due to duplication of work by debuggers almost never seems to be an issue in the Linux world. One effect of a “release early and often” policy is to minimize such duplication by propagating fed-back fixes quickly [JH].

실제로 디버거의 작업 중복으로 인한 이론적인 효율성 손실은 Linux 세계에서는 거의 문제가 되지 않는 것 같습니다. “일찍 자주 릴리스” 정책의 한 가지 효과는 피드백된 수정 사항을 빠르게 전파하여 이러한 중복을 최소화하는 것입니다[JH].

Brooks (the author of The Mythical Man-Month) even made an off-hand observation related to this: “The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly this cost is strongly affected by the number of users. More users find more bugs.” [emphasis added].

브룩스(The Mythical Man-Month의 저자)는 심지어 이와 관련된 다음과 같은 즉흥적인 언급을 했습니다. “널리 사용되는 프로그램을 유지 관리하는 총 비용은 일반적으로 개발 비용의 40% 이상입니다. 놀랍게도 이 비용은 사용자 수에 크게 영향을 받습니다. 사용자가 많을수록 더 많은 버그를 찾습니다.” [강조 추가].

More users find more bugs because adding more users adds more different ways of stressing the program. This effect is amplified when the users are co-developers. Each one approaches the task of bug characterization with a slightly different perceptual set and analytical toolkit, a different angle on the problem. The “Delphi effect” seems to work precisely because of this variation. In the specific context of debugging, the variation also tends to reduce duplication of effort.

사용자가 많을수록 프로그램을 스트레스하는 더 다양한 방법이 추가되기 때문에 더 많은 버그를 찾습니다. 이러한 효과는 사용자가 공동 개발자인 경우 증폭됩니다. 각 사용자는 약간 다른 인지적 집합과 분석 도구 키트, 문제에 대한 다른 관점을 가지고 버그 특성화 작업에 접근합니다. “델파이 효과”는 바로 이러한 변동성 때문에 작동하는 것 같습니다. 디버깅이라는 특정 맥락에서 변동성은 노력의 중복을 줄이는 경향도 있습니다.

So adding more beta-testers may not reduce the complexity of the current “deepest” bug from the developer’s point of view, but it increases the probability that someone’s toolkit will be matched to the problem in such a way that the bug is shallow to that person.

따라서 베타 테스터를 더 추가한다고 해서 개발자 관점에서 현재 “가장 심각한” 버그의 복잡성이 줄어들지는 않겠지만, 누군가의 툴킷이 문제에 맞춰져서 그 사람에게는 버그가 얕게 보일 가능성이 높아집니다.

Linus coppers his bets, too. In case there are serious bugs, Linux kernel version are numbered in such a way that potential users can make a choice either to run the last version designated “stable” or to ride the cutting edge and risk bugs in order to get new features. This tactic is not yet systematically imitated by most Linux hackers, but perhaps it should be; the fact that either choice is available makes both more attractive [HBS].

리누스도 만약의 사태에 대비합니다. 심각한 버그가 발생할 경우에 대비하여 리눅스 커널 버전은 잠재적 사용자가 “안정적”으로 지정된 최신 버전을 실행하거나 최첨단을 따라가면서 새로운 기능을 얻기 위해 버그 위험을 감수할 수 있도록 번호가 매겨집니다. 이 전략은 아직 대부분의 리눅스 해커들이 체계적으로 모방하고 있지는 않지만, 그렇게 해야 할 수도 있습니다. 둘 중 하나의 선택이 가능하다는 사실은 둘 다 더 매력적으로 만듭니다 [HBS].

How Many Eyeballs Tame Complexity

얼마나 많은 눈이 복잡성을 길들이는가

It’s one thing to observe in the large that the bazaar style greatly accelerates debugging and code evolution. It’s another to understand exactly how and why it does so at the micro-level of day-to-day developer and tester behavior. In this section (written three years after the original paper, using insights by developers who read it and re-examined their own behavior) we’ll take a hard look at the actual mechanisms. Non-technically inclined readers can safely skip to the next section.

바자 스타일이 디버깅과 코드 발전을 크게 가속화한다는 것을 거시적으로 관찰하는 것은 한 가지입니다. 그것이 정확히 어떻게 그리고 왜 일상적인 개발자와 테스터 행동의 미시적 수준에서 그렇게 하는지 이해하는 것은 또 다른 문제입니다. 이 섹션에서는 (원래 논문이 나온 후 3년 뒤에 그것을 읽고 자신의 행동을 재검토한 개발자들의 통찰력을 사용하여 작성됨) 실제 메커니즘을 자세히 살펴볼 것입니다. 기술에 익숙하지 않은 독자는 다음 섹션으로 건너뛰어도 안전합니다.

One key to understanding is to realize exactly why it is that the kind of bug report non—source-aware users normally turn in tends not to be very useful. Non—source-aware users tend to report only surface symptoms; they take their environment for granted, so they (a) omit critical background data, and (b) seldom include a reliable recipe for reproducing the bug.

이해의 핵심은 소스 코드를 모르는 사용자가 일반적으로 제출하는 버그 보고서가 왜 그다지 유용하지 않은지 정확히 깨닫는 것입니다. 소스 코드를 모르는 사용자는 표면적인 증상만 보고하는 경향이 있습니다. 그들은 자신의 환경을 당연하게 여기기 때문에 (a) 중요한 배경 데이터를 생략하고 (b) 버그를 재현하기 위한 신뢰할 수 있는 방법을 거의 포함하지 않습니다.

The underlying problem here is a mismatch between the tester’s and the developer’s mental models of the program; the tester, on the outside looking in, and the developer on the inside looking out. In closed-source development they’re both stuck in these roles, and tend to talk past each other and find each other deeply frustrating.

여기서 근본적인 문제는 테스터와 개발자의 프로그램에 대한 멘탈 모델 간의 불일치입니다. 테스터는 외부에서 안을 들여다보고, 개발자는 내부에서 밖을 내다보는 식입니다. 폐쇄형 소스 개발에서는 그들 모두 이러한 역할에 갇혀서 서로 소통이 잘 안 되고 서로에게 깊은 좌절감을 느끼는 경향이 있습니다.

Open-source development breaks this bind, making it far easier for tester and developer to develop a shared representation grounded in the actual source code and to communicate effectively about it. Practically, there is a huge difference in leverage for the developer between the kind of bug report that just reports externally-visible symptoms and the kind that hooks directly to the developer’s source-code—based mental representation of the program.

오픈 소스 개발은 이러한 속박을 깨고 테스터와 개발자가 실제 소스 코드에 기반한 공유된 표현을 개발하고 효과적으로 소통하는 것을 훨씬 쉽게 만듭니다. 실제로 외부적으로 보이는 증상만을 보고하는 버그 보고와 개발자의 소스 코드 기반 프로그램에 대한 멘탈 표현에 직접 연결되는 버그 보고 사이에는 개발자에게 엄청난 레버리지 차이가 있습니다.

Most bugs, most of the time, are easily nailed given even an incomplete but suggestive characterization of their error conditions at source-code level. When someone among your beta-testers can point out, “there’s a boundary problem in line nnn”, or even just “under conditions X, Y, and Z, this variable rolls over”, a quick look at the offending code often suffices to pin down the exact mode of failure and generate a fix.

대부분의 버그는 대부분의 경우 소스 코드 수준에서 오류 조건에 대한 불완전하지만 시사하는 특성만 주어져도 쉽게 해결됩니다. 베타 테스터 중 누군가가 “nnn번째 줄에 경계 문제가 있습니다” 또는 “X, Y, Z 조건에서 이 변수가 롤오버됩니다”라고 지적할 수 있다면 문제의 코드를 빠르게 살펴보는 것만으로도 정확한 실패 모드를 파악하고 수정 사항을 생성하는 데 충분합니다.

Thus, source-code awareness by both parties greatly enhances both good communication and the synergy between what a beta-tester reports and what the core developer(s) know. In turn, this means that the core developers’ time tends to be well conserved, even with many collaborators.

따라서 양측의 소스 코드 인식은 훌륭한 의사 소통과 베타 테스터가 보고하는 내용과 핵심 개발자가 알고 있는 내용 간의 시너지 효과를 크게 향상시킵니다. 결과적으로 핵심 개발자의 시간은 많은 협력자가 있더라도 잘 보존되는 경향이 있습니다.

Another characteristic of the open-source method that conserves developer time is the communication structure of typical open-source projects. Above I used the term “core developer”; this reflects a distinction between the project core (typically quite small; a single core developer is common, and one to three is typical) and the project halo of beta-testers and available contributors (which often numbers in the hundreds).

오픈 소스 방식이 개발자 시간을 절약하는 또 다른 특징은 일반적인 오픈 소스 프로젝트의 커뮤니케이션 구조입니다. 위에서 저는 “핵심 개발자”라는 용어를 사용했습니다. 이는 프로젝트 코어(일반적으로 매우 작음, 단일 핵심 개발자가 일반적이며 1~3명이 일반적임)와 베타 테스터 및 사용 가능한 기여자(종종 수백 명에 달함)로 구성된 프로젝트 헤일로 간의 구분을 반영합니다.

The fundamental problem that traditional software-development organization addresses is Brook’s Law: “Adding more programmers to a late project makes it later.” More generally, Brooks’s Law predicts that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly.

전통적인 소프트웨어 개발 조직이 해결하는 근본적인 문제는 브룩스의 법칙입니다. “늦은 프로젝트에 더 많은 프로그래머를 투입하면 프로젝트가 더 늦어진다.” 더 일반적으로, 브룩스의 법칙은 프로젝트의 복잡성과 커뮤니케이션 비용이 개발자 수의 제곱에 비례하여 증가하는 반면, 수행되는 작업은 선형적으로만 증가한다고 예측합니다.

Brooks’s Law is founded on experience that bugs tend strongly to cluster at the interfaces between code written by different people, and that communications/coordination overhead on a project tends to rise with the number of interfaces between human beings. Thus, problems scale with the number of communications paths between developers, which scales as the square of the number of developers (more precisely, according to the formula N*(N - 1)/2 where N is the number of developers).

브룩스의 법칙은 버그가 서로 다른 사람이 작성한 코드 간의 인터페이스에 집중되는 경향이 강하고 프로젝트의 커뮤니케이션/조정 오버헤드가 사람 간의 인터페이스 수에 따라 증가한다는 경험에 기초합니다. 따라서 문제는 개발자 간의 통신 경로 수에 따라 확장되며, 이는 개발자 수의 제곱에 따라 확장됩니다(더 정확하게는 N*(N - 1)/2 공식에 따름, 여기서 N은 개발자 수).

The Brooks’s Law analysis (and the resulting fear of large numbers in development groups) rests on a hidden assummption: that the communications structure of the project is necessarily a complete graph, that everybody talks to everybody else. But on open-source projects, the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only within that small core group do we pay the full Brooksian overhead [SU].

브룩스의 법칙 분석(및 개발 그룹에서 많은 수에 대한 결과적인 두려움)은 프로젝트의 통신 구조가 필연적으로 완전한 그래프, 즉 모든 사람이 다른 모든 사람과 통신한다는 숨겨진 가정에 기반합니다. 그러나 오픈 소스 프로젝트에서 헤일로 개발자는 사실상 분리 가능한 병렬 하위 작업에서 작업하고 서로 거의 상호 작용하지 않습니다. 코드 변경 및 버그 보고서는 핵심 그룹을 통해 스트리밍되며, 그 작은 핵심 그룹 내에서만 우리는 완전한 브룩스식 오버헤드를 지불합니다[SU].

There are are still more reasons that source-code—level bug reporting tends to be very efficient. They center around the fact that a single error can often have multiple possible symptoms, manifesting differently depending on details of the user’s usage pattern and environment. Such errors tend to be exactly the sort of complex and subtle bugs (such as dynamic-memory-management errors or nondeterministic interrupt-window artifacts) that are hardest to reproduce at will or to pin down by static analysis, and which do the most to create long-term problems in software.

소스 코드 수준의 버그 보고가 매우 효율적인 이유는 여전히 많습니다. 이는 하나의 오류가 사용자 사용 패턴 및 환경의 세부 사항에 따라 다르게 나타나는 여러 가지 가능한 증상을 가질 수 있다는 사실에 집중되어 있습니다. 이러한 오류는 동적 메모리 관리 오류 또는 비결정적 인터럽트 창 Artifacts와 같이 임의로 재현하거나 정적 분석으로 찾아내기 가장 어렵고 소프트웨어에서 장기적인 문제를 일으키는 복잡하고 미묘한 버그일 가능성이 높습니다.

A tester who sends in a tentative source-code—level characterization of such a multi-symptom bug (e.g.”It looks to me like there’s a window in the signal handling near line 1250” or “Where are you zeroing that buffer?”) may give a developer, otherwise too close to the code to see it, the critical clue to a half-dozen disparate symptoms. In cases like this, it may be hard or even impossible to know which externally-visible misbehaviour was caused by precisely which bug---but with frequent releases, it’s unnecessary to know. Other collaborators will be likely to find out quickly whether their bug has been fixed or not. In many cases, source-level bug reports will cause misbehaviours to drop out without ever having been attributed to any specific fix.

여러 증상이 나타나는 버그에 대한 잠정적인 소스 코드 수준 특징(예: “1250번 줄 근처의 신호 처리에서 윈도가 있는 것 같습니다.” 또는 “어느 버퍼를 0으로 설정하고 있습니까?“)을 보내는 테스터는 코드가 너무 가까워서 보지 못하는 개발자에게 6개의 이질적인 증상에 대한 중요한 단서를 제공할 수 있습니다. 이와 같은 경우, 어떤 외부적으로 보이는 오작동이 정확히 어떤 버그로 인해 발생했는지 알기가 어렵거나 불가능할 수도 있지만, 잦은 릴리스를 통해 알 필요가 없습니다. 다른 협력자는 자신의 버그가 수정되었는지 여부를 신속하게 알 수 있을 것입니다. 많은 경우, 소스 수준의 버그 보고서는 특정 수정 사항에 기인하지 않고 오작동이 사라지게 할 것입니다.

Complex multi-symptom errors also tend to have multiple trace paths from surface symptoms back to the actual bug. Which of the trace paths a given developer or tester can chase may depend on subtleties of that person’s environment, and may well change in a not obviously deterministic way over time. In effect, each developer and tester samples a semi-random set of the program’s state space when looking for the etiology of a symptom. The more subtle and complex the bug, the less likely that skill will be able to guarantee the relevance of that sample.

복잡한 다중 증상 오류는 표면적인 증상에서 실제 버그로 이어지는 여러 추적 경로를 갖는 경향이 있습니다. 주어진 개발자 또는 테스터가 추적할 수 있는 추적 경로는 해당 개인의 환경의 미묘한 차이에 따라 달라질 수 있으며, 시간이 지남에 따라 명백하게 결정적인 방식으로 변할 수 있습니다. 사실상 각 개발자와 테스터는 증상의 원인을 찾을 때 프로그램 상태 공간의 준-임의 집합을 샘플링합니다. 버그가 더 미묘하고 복잡할수록 기술이 해당 샘플의 관련성을 보장할 가능성이 줄어듭니다.

For simple and easily reproducible bugs, then, the accent will be on the “semi” rather than the “random”; debugging skill and intimacy with the code and its architecture will matter a lot. But for complex bugs, the accent will be on the “random”. Under these circumstances many people running traces will be much more effective than a few people running traces sequentially---even if the few have a much higher average skill level.

따라서 간단하고 쉽게 재현 가능한 버그의 경우 “임의적”이기보다는 “준(semi)“에 중점을 둘 것입니다. 디버깅 기술과 코드 및 아키텍처에 대한 친숙도가 매우 중요합니다. 그러나 복잡한 버그의 경우 “임의적”에 중점을 둘 것입니다. 이러한 상황에서는 소수의 사람들이 순차적으로 추적하는 것보다 많은 사람들이 추적을 실행하는 것이 훨씬 더 효과적입니다. 심지어 소수의 사람들의 평균 기술 수준이 훨씬 더 높더라도 마찬가지입니다.

This effect will be greatly amplified if the difficulty of following trace paths from different surface symptoms back to a bug varies significantly in a way that can’t be predicted by looking at the symptoms. A single developer sampling those paths sequentially will be as likely to pick a difficult trace path on the first try as an easy one. On the other hand, suppose many people are trying trace paths in parallel while doing rapid releases. Then it is likely one of them will find the easiest path immediately, and nail the bug in a much shorter time. The project maintainer will see that, ship a new release, and the other people running traces on the same bug will be able to stop before having spent too much time on their more difficult traces [RJ].

다양한 표면 증상에서 버그로 이어지는 추적 경로를 따르는 어려움이 증상을 보고 예측할 수 없는 방식으로 크게 달라지는 경우 이 효과는 크게 증폭됩니다. 단일 개발자가 이러한 경로를 순차적으로 샘플링하면 쉬운 추적 경로와 마찬가지로 어려운 추적 경로를 처음 시도할 가능성이 높습니다. 반면에 많은 사람들이 빠른 릴리스를 수행하면서 병렬로 추적 경로를 시도하고 있다고 가정해 보겠습니다. 그러면 그들 중 한 명이 즉시 가장 쉬운 경로를 찾아 훨씬 짧은 시간에 버그를 잡을 가능성이 높습니다. 프로젝트 관리자는 이를 확인하고 새 릴리스를 제공하며 동일한 버그에 대해 추적을 실행하는 다른 사람들은 더 어려운 추적에 너무 많은 시간을 들이기 전에 중단할 수 있습니다[RJ].

When Is a Rose Not a Rose?

장미가 장미가 아닐 때는 언제인가?

Having studied Linus’s behavior and formed a theory about why it was successful, I made a conscious decision to test this theory on my new (admittedly much less complex and ambitious) project.

리누스의 행동을 연구하고 그것이 성공한 이유에 대한 이론을 형성한 후, 나는 이 이론을 나의 새로운 (솔직히 훨씬 덜 복잡하고 야심 찬) 프로젝트에서 테스트하기로 의식적으로 결정했습니다.

But the first thing I did was reorganize and simplify popclient a lot. Carl Harris’s implementation was very sound, but exhibited a kind of unnecessary complexity common to many C programmers. He treated the code as central and the data structures as support for the code. As a result, the code was beautiful but the data structure design ad-hoc and rather ugly (at least by the high standards of this veteran LISP hacker).

그러나 내가 가장 먼저 한 일은 popclient를 많이 재구성하고 단순화하는 것이었습니다. Carl Harris의 구현은 매우 건전했지만 많은 C 프로그래머에게서 흔히 볼 수 있는 불필요한 복잡성을 보였습니다. 그는 코드를 중심으로, 데이터 구조를 코드 지원으로 취급했습니다. 그 결과 코드는 아름다웠지만 데이터 구조 설계는 임시방편적이고 다소 보기 흉했습니다 (적어도 이 베테랑 LISP 해커의 높은 기준으로는).

I had another purpose for rewriting besides improving the code and the data structure design, however. That was to evolve it into something I understood completely. It’s no fun to be responsible for fixing bugs in a program you don’t understand.

그러나 코딩과 데이터 구조 설계를 개선하는 것 외에 또 다른 리라이팅 목적이 있었습니다. 그것은 내가 완전히 이해하는 것으로 발전시키는 것이었습니다. 이해하지 못하는 프로그램의 버그를 수정하는 것은 재미가 없습니다.

For the first month or so, then, I was simply following out the implications of Carl’s basic design. The first serious change I made was to add IMAP support. I did this by reorganizing the protocol machines into a generic driver and three method tables (for POP2, POP3, and IMAP). This and the previous changes illustrate a general principle that’s good for programmers to keep in mind, especially in languages like C that don’t naturally do dynamic typing:

따라서 처음 한 달 정도 동안은 Carl의 기본 설계가 의미하는 바를 따르고 있었습니다. 내가 만든 첫 번째 중요한 변경 사항은 IMAP 지원을 추가하는 것이었습니다. 프로토콜 머신을 일반 드라이버와 세 개의 메서드 테이블(POP2, POP3 및 IMAP용)로 재구성하여 이 작업을 수행했습니다. 이것과 이전의 변경 사항은 프로그래머가 명심해야 할 일반적인 원칙을 보여줍니다. 특히 동적 타이핑을 자연스럽게 수행하지 않는 C와 같은 언어에서는 더욱 그렇습니다.

Smart data structures and dumb code works a lot better than the other way around.

‘9. 똑똑한 데이터 구조와 멍청한 코드는 그 반대보다 훨씬 더 효과적입니다.’

Brooks, Chapter 9: “Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.” Allowing for thirty years of terminological/cultural shift, it’s the same point.

브룩스, 9장: “당신의 순서도를 보여주고 테이블을 숨기면, 나는 계속해서 혼란스러울 것입니다. 당신의 테이블을 보여주면, 나는 보통 당신의 순서도가 필요 없을 것입니다. 그것은 명백할 것입니다.” 30년간의 용어/문화적 변화를 고려하면, 그것은 같은 요점입니다.

At this point (early September 1996, about six weeks from zero) I started thinking that a name change might be in order---after all, it wasn’t just a POP client any more. But I hesitated, because there was as yet nothing genuinely new in the design. My version of popclient had yet to develop an identity of its own.

이 시점(1996년 9월 초, 제로에서 약 6주 후)에 나는 이름 변경이 필요할 수도 있다고 생각하기 시작했습니다. 결국 그것은 더 이상 단순한 POP 클라이언트가 아니었기 때문입니다. 그러나 나는 주저했습니다. 왜냐하면 아직 디자인에 진정으로 새로운 것이 없었기 때문입니다. 내 버전의 popclient는 아직 자체적인 정체성을 개발하지 못했습니다.

That changed, radically, when popclient learned how to forward fetched mail to the SMTP port. I’ll get to that in a moment. But first: I said earlier that I’d decided to use this project to test my theory about what Linus Torvalds had done right. How (you may well ask) did I do that? In these ways:

그것은 popclient가 가져온 메일을 SMTP 포트로 전달하는 방법을 알게 되면서 근본적으로 바뀌었습니다. 그건 잠시 후에 다루겠습니다. 하지만 먼저: 나는 이 프로젝트를 통해 리누스 토발즈가 옳았던 점에 대한 내 이론을 테스트하기로 결정했다고 앞서 말했습니다. (여러분은 당연히) 어떻게 그렇게 했습니까? 다음과 같은 방법으로:

I released early and often (almost never less often than every ten days; during periods of intense development, once a day).

저는 일찍 그리고 자주 출시했습니다(거의 10일에 한 번 이하로 출시하는 경우는 거의 없었고, 집중 개발 기간에는 하루에 한 번 출시했습니다).

I grew my beta list by adding to it everyone who contacted me about fetchmail.

저는 fetchmail에 대해 저에게 연락한 모든 사람을 베타 목록에 추가하여 베타 목록을 늘렸습니다.

I sent chatty announcements to the beta list whenever I released, encouraging people to participate.

저는 사람들의 참여를 장려하기 위해 출시할 때마다 베타 목록에 수다스러운 공지를 보냈습니다.

And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.

그리고 저는 베타 테스터들의 의견을 경청하며, 디자인 결정에 대해 여론을 수렴하고 패치와 피드백을 보낼 때마다 그들을 격려했습니다.

The payoff from these simple measures was immediate. From the beginning of the project, I got bug reports of a quality most developers would kill for, often with good fixes attached. I got thoughtful criticism, I got fan mail, I got intelligent feature suggestions. Which leads to:

이러한 간단한 조치들의 결과는 즉각적이었습니다. 프로젝트 시작부터 저는 대부분의 개발자들이 탐낼 만한 수준의 버그 보고서를 받았고, 종종 훌륭한 수정 사항이 첨부되어 있었습니다. 사려 깊은 비판, 팬 메일, 지능적인 기능 제안을 받았습니다. 이는 다음으로 이어집니다.

If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.

베타 테스터를 가장 귀중한 자원처럼 대하면, 그들은 가장 귀중한 자원이 됨으로써 응답할 것입니다.

One interesting measure of fetchmail’s success is the sheer size of the project beta list, fetchmail-friends. At the time of latest revision of this paper (November 2000) it has 287 members and is adding two or three a week.

fetchmail의 성공에 대한 흥미로운 척도 중 하나는 프로젝트 베타 목록인 fetchmail-friends의 엄청난 크기입니다. 이 논문의 최신 개정판 (2000년 11월) 당시에는 287명의 회원이 있었고 매주 2~3명씩 추가되고 있습니다.

Actually, when I revised in late May 1997 I found the list was beginning to lose members from its high of close to 300 for an interesting reason. Several people have asked me to unsubscribe them because fetchmail is working so well for them that they no longer need to see the list traffic! Perhaps this is part of the normal life-cycle of a mature bazaar-style project.

사실, 1997년 5월 말에 수정했을 때 목록이 300명에 가까운 최고점에서 회원을 잃기 시작했다는 것을 알게 되었습니다. 흥미로운 이유는 여러 사람들이 fetchmail이 너무 잘 작동하여 더 이상 목록 트래픽을 볼 필요가 없기 때문에 구독 취소를 요청했기 때문입니다! 아마도 이것은 성숙한 바자 스타일 프로젝트의 정상적인 수명 주기의 일부일 것입니다.

Popclient becomes Fetchmail

Popclient가 Fetchmail이 됨

The real turning point in the project was when Harry Hochheiser sent me his scratch code for forwarding mail to the client machine’s SMTP port. I realized almost immediately that a reliable implementation of this feature would make all the other mail delivery modes next to obsolete.

프로젝트의 진정한 전환점은 Harry Hochheiser가 메일을 클라이언트 머신의 SMTP 포트로 전달하기 위한 스크래치 코드를 보냈을 때였습니다. 이 기능의 안정적인 구현이 다른 모든 메일 전송 모드를 거의 쓸모없게 만들 것이라는 것을 거의 즉시 깨달았습니다.

For many weeks I had been tweaking fetchmail rather incrementally while feeling like the interface design was serviceable but grubby---inelegant and with too many exiguous options hanging out all over. The options to dump fetched mail to a mailbox file or standard output particularly bothered me, but I couldn’t figure out why.

몇 주 동안 저는 fetchmail을 조금씩 수정하면서 인터페이스 디자인이 그럭저럭 쓸만하지만 지저분하다고 느꼈습니다. 우아하지 않고 너무 많은 미미한 옵션들이 여기저기 흩어져 있었습니다. 특히 가져온 메일을 메일박스 파일이나 표준 출력으로 덤프하는 옵션들이 저를 괴롭혔지만, 그 이유를 알 수 없었습니다.

(If you don’t care about the technicalia of Internet mail, the next two paragraphs can be safely skipped.)

(인터넷 메일의 기술적인 내용에 관심이 없다면 다음 두 단락은 건너뛰어도 됩니다.)

What I saw when I thought about SMTP forwarding was that popclient had been trying to do too many things. It had been designed to be both a mail transport agent (MTA) and a local delivery agent (MDA). With SMTP forwarding, it could get out of the MDA business and be a pure MTA, handing off mail to other programs for local delivery just as sendmail does.

SMTP 포워딩에 대해 생각했을 때 제가 본 것은 popclient가 너무 많은 일을 하려고 했다는 것입니다. 메일 전송 에이전트(MTA)와 로컬 배달 에이전트(MDA) 둘 다가 되도록 설계되었습니다. SMTP 포워딩을 통해 MDA 업무에서 벗어나 순수한 MTA가 되어 sendmail처럼 로컬 배달을 위해 다른 프로그램에 메일을 넘겨줄 수 있었습니다.

Why mess with all the complexity of configuring a mail delivery agent or setting up lock-and-append on a mailbox when port 25 is almost guaranteed to be there on any platform with TCP/IP support in the first place? Especially when this means retrieved mail is guaranteed to look like normal sender-initiated SMTP mail, which is really what we want anyway.

포트 25가 TCP/IP 지원이 있는 모든 플랫폼에서 거의 확실히 존재하는데, 왜 메일 배달 에이전트 구성이나 메일박스에 대한 잠금 및 추가 설정의 복잡성을 감수해야 할까요? 특히 이것이 검색된 메일이 어쨌든 우리가 원하는 일반적인 발신자 시작 SMTP 메일처럼 보이도록 보장할 때 말입니다.

(Back to a higher level…)

(더 높은 수준으로 돌아가서…)

Even if you didn’t follow the preceding technical jargon, there are several important lessons here. First, this SMTP-forwarding concept was the biggest single payoff I got from consciously trying to emulate Linus’s methods. A user gave me this terrific idea---all I had to do was understand the implications.

앞선 기술 용어를 이해하지 못했더라도 여기서 얻을 수 있는 몇 가지 중요한 교훈이 있습니다. 첫째, 이 SMTP 전달 개념은 제가 의식적으로 리누스의 방법을 모방하려고 노력한 결과 얻은 가장 큰 성과였습니다. 한 사용자가 저에게 이 훌륭한 아이디어를 주었고 저는 그 의미를 이해하기만 하면 되었습니다.

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

좋은 아이디어를 갖는 것 다음으로 좋은 것은 사용자로부터 좋은 아이디어를 알아보는 것입니다. 때로는 후자가 더 나을 수도 있습니다.

Interestingly enough, you will quickly find that if you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you as though you did every bit of the invention yourself and are just being becomingly modest about your innate genius. We can all see how well this worked for Linus!

흥미롭게도, 다른 사람들에게 얼마나 많은 빚을 지고 있는지에 대해 완전히 솔직하고 자신을 낮추어 말하면 세상은 당신이 모든 발명을 스스로 한 것처럼 대하고 당신의 타고난 천재성에 대해 겸손하게 행동한다고 생각할 것입니다. 이것이 리누스에게 얼마나 잘 통했는지 우리 모두가 알 수 있습니다!

(When I gave my talk at the first Perl Conference in August 1997, hacker extraordinaire Larry Wall was in the front row. As I got to the last line above he called out, religious-revival style, “Tell it, tell it, brother!“. The whole audience laughed, because they knew this had worked for the inventor of Perl, too.)

(1997년 8월에 열린 첫 번째 Perl 컨퍼런스에서 강연을 할 때, 해커계의 거장 래리 월이 맨 앞줄에 앉아 있었습니다. 제가 위의 마지막 줄에 도달했을 때 그는 종교 부흥회 스타일로 “말씀하세요, 형제님!”이라고 외쳤습니다. 청중 전체가 웃었는데, 그들은 이것이 Perl 발명가에게도 효과가 있었다는 것을 알았기 때문입니다.)

After a very few weeks of running the project in the same spirit, I began to get similar praise not just from my users but from other people to whom the word leaked out. I stashed away some of that email; I’ll look at it again sometime if I ever start wondering whether my life has been worthwhile :-).

같은 정신으로 프로젝트를 몇 주 동안 운영한 후, 저는 사용자뿐만 아니라 소문이 새어 나간 다른 사람들로부터도 비슷한 칭찬을 받기 시작했습니다. 저는 그 이메일 중 일부를 보관해 두었습니다. 언젠가 제 삶이 가치가 있었는지 궁금해지면 다시 한번 살펴볼 것입니다 :-).

But there are two more fundamental, non-political lessons here that are general to all kinds of design.

그러나 여기에는 모든 종류의 디자인에 일반적인 두 가지 더 근본적이고 비정치적인 교훈이 있습니다.

Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

종종 가장 놀랍고 혁신적인 해결책은 문제에 대한 당신의 개념이 틀렸다는 것을 깨닫는 데서 나옵니다.

I had been trying to solve the wrong problem by continuing to develop popclient as a combined MTA/MDA with all kinds of funky local delivery modes. Fetchmail’s design needed to be rethought from the ground up as a pure MTA, a part of the normal SMTP-speaking Internet mail path.

저는 모든 종류의 엉뚱한 로컬 전송 모드를 갖춘 결합된 MTA/MDA로서 popclient를 계속 개발함으로써 잘못된 문제를 해결하려고 했습니다. Fetchmail의 디자인은 순수한 MTA, 즉 일반적인 SMTP 통신 인터넷 메일 경로의 일부로서 근본적으로 재고되어야 했습니다.

When you hit a wall in development---when you find yourself hard put to think past the next patch---it’s often time to ask not whether you’ve got the right answer, but whether you’re asking the right question. Perhaps the problem needs to be reframed.

개발에서 벽에 부딪혔을 때, 즉 다음 패치를 넘어 생각하기 어려울 때, 종종 올바른 답을 얻었는지 묻기보다는 올바른 질문을 하고 있는지 자문해야 할 때입니다. 어쩌면 문제를 재구성해야 할 수도 있습니다.

Well, I had reframed my problem. Clearly, the right thing to do was (1) hack SMTP forwarding support into the generic driver, (2) make it the default mode, and (3) eventually throw out all the other delivery modes, especially the deliver-to-file and deliver-to-standard-output options.

음, 저는 제 문제를 재구성했습니다. 분명히 올바른 방법은 (1) 제네릭 드라이버에 SMTP 포워딩 지원을 해킹하고, (2) 이를 기본 모드로 만들고, (3) 결국 다른 모든 전송 모드, 특히 파일로 전송 및 표준 출력으로 전송 옵션을 버리는 것이었습니다.

I hesitated over step 3 for some time, fearing to upset long-time popclient users dependent on the alternate delivery mechanisms. In theory, they could immediately switch to .forward files or their non-sendmail equivalents to get the same effects. In practice the transition might have been messy.

대체 전송 메커니즘에 의존하는 오랜 popclient 사용자들을 혼란스럽게 할까 봐 3단계를 한동안 망설였습니다. 이론적으로는 .forward 파일이나 sendmail에 상응하는 파일로 즉시 전환하여 동일한 효과를 얻을 수 있습니다. 실제로는 전환이 엉망이 될 수도 있었습니다.

But when I did it, the benefits proved huge. The cruftiest parts of the driver code vanished. Configuration got radically simpler---no more grovelling around for the system MDA and user’s mailbox, no more worries about whether the underlying OS supports file locking.

하지만 막상 해보니 이점이 엄청났습니다. 드라이버 코드에서 가장 조잡한 부분이 사라졌습니다. 구성이 훨씬 간단해졌습니다. 더 이상 시스템 MDA와 사용자 사서함을 찾을 필요도 없고, 기본 OS가 파일 잠금을 지원하는지 걱정할 필요도 없습니다.

Also, the only way to lose mail vanished. If you specified delivery to a file and the disk got full, your mail got lost. This can’t happen with SMTP forwarding because your SMTP listener won’t return OK unless the message can be delivered or at least spooled for later delivery.

또한 메일을 잃어버릴 유일한 방법도 사라졌습니다. 파일로 배달을 지정했는데 디스크가 꽉 차면 메일이 손실되었습니다. SMTP 전달을 사용하면 메시지를 배달하거나 나중에 배달할 수 있도록 스풀하지 않는 한 SMTP 수신기가 OK를 반환하지 않으므로 이런 일이 발생할 수 없습니다.

Also, performance improved (though not so you’d notice it in a single run). Another not insignificant benefit of this change was that the manual page got a lot simpler.

또한 성능도 향상되었습니다(단일 실행에서는 눈에 띄지 않음). 이 변경의 또 다른 중요한 이점은 매뉴얼 페이지가 훨씬 간단해졌다는 것입니다.

Later, I had to bring delivery via a user-specified local MDA back in order to allow handling of some obscure situations involving dynamic SLIP. But I found a much simpler way to do it.

나중에, 동적 SLIP과 관련된 몇 가지 모호한 상황을 처리할 수 있도록 사용자 지정 로컬 MDA를 통해 배달을 다시 가져와야 했습니다. 그러나 훨씬 더 간단한 방법을 찾았습니다.

The moral? Don’t hesitate to throw away superannuated features when you can do it without loss of effectiveness. Antoine de Saint-Exupéry (who was an aviator and aircraft designer when he wasn’t authoring classic children’s books) said:

교훈은? 효과를 잃지 않고 할 수 있을 때 노후화된 기능을 버리는 것을 주저하지 마십시오. 앙투안 드 생텍쥐페리(고전 아동 도서를 집필하지 않을 때는 비행사이자 항공기 설계자였습니다)는 다음과 같이 말했습니다.

“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”

“완벽(디자인에서)은 더 이상 더할 것이 없을 때가 아니라 더 이상 뺄 것이 없을 때 달성됩니다.”

When your code is getting both better and simpler, that is when you know it’s right. And in the process, the fetchmail design acquired an identity of its own, different from the ancestral popclient.

코드가 더 나아지고 단순해질 때, 그것이 옳다는 것을 알게 됩니다. 그리고 그 과정에서 fetchmail 디자인은 조상인 popclient와는 다른 독자적인 정체성을 얻었습니다.

It was time for the name change. The new design looked much more like a dual of sendmail than the old popclient had; both are MTAs, but where sendmail pushes then delivers, the new popclient pulls then delivers. So, two months off the blocks, I renamed it fetchmail.

이제 이름을 변경할 때가 되었습니다. 새로운 디자인은 기존의 popclient보다 sendmail과 훨씬 더 유사해 보였습니다. 둘 다 MTA이지만, sendmail은 푸시 후 전송하는 반면, 새로운 popclient는 풀 후 전송합니다. 그래서 두 달 후, 저는 이름을 fetchmail로 변경했습니다.

There is a more general lesson in this story about how SMTP delivery came to fetchmail. It is not only debugging that is parallelizable; development and (to a perhaps surprising extent) exploration of design space is, too. When your development mode is rapidly iterative, development and enhancement may become special cases of debugging---fixing “bugs of omission” in the original capabilities or concept of the software.

SMTP 전송이 fetchmail에 적용된 방법에 대한 이 이야기에는 더 일반적인 교훈이 있습니다. 병렬화할 수 있는 것은 디버깅뿐만이 아닙니다. 개발과 (어쩌면 놀라울 정도로) 설계 공간 탐색도 마찬가지입니다. 개발 모드가 빠르게 반복되는 경우, 개발과 개선은 디버깅의 특수한 경우가 될 수 있습니다. 즉, 소프트웨어의 원래 기능이나 개념에서 “누락된 버그”를 수정하는 것입니다.

Even at a higher level of design, it can be very valuable to have lots of co-developers random-walking through the design space near your product. Consider the way a puddle of water finds a drain, or better yet how ants find food: exploration essentially by diffusion, followed by exploitation mediated by a scalable communication mechanism. This works very well; as with Harry Hochheiser and me, one of your outriders may well find a huge win nearby that you were just a little too close-focused to see.

더 높은 수준의 설계에서도, 제품 주변의 설계 공간을 무작위로 탐색하는 많은 공동 개발자가 있는 것이 매우 유용할 수 있습니다. 물웅덩이가 배수구를 찾는 방식이나 개미가 음식을 찾는 방식을 생각해 보십시오. 확산에 의한 탐색 후 확장 가능한 통신 메커니즘을 통해 매개되는 활용이 이어집니다. 이것은 매우 효과적입니다. Harry Hochheiser와 저처럼, 당신의 선발대 중 한 명이 당신이 너무 집중해서 보지 못했던 큰 이점을 발견할 수 있습니다.

Fetchmail Grows Up

There I was with a neat and innovative design, code that I knew worked well because I used it every day, and a burgeoning beta list. It gradually dawned on me that I was no longer engaged in a trivial personal hack that might happen to be useful to few other people. I had my hands on a program that every hacker with a Unix box and a SLIP/PPP mail connection really needs.

저는 깔끔하고 혁신적인 디자인, 제가 매일 사용하기 때문에 잘 작동한다고 알고 있는 코드, 그리고 급증하는 베타 목록을 가지고 있었습니다. 점차적으로 저는 더 이상 소수의 다른 사람들에게 유용할 수 있는 사소한 개인 해킹에 관여하고 있지 않다는 것을 깨달았습니다. 저는 유닉스 박스와 SLIP/PPP 메일 연결을 가진 모든 해커에게 정말로 필요한 프로그램을 손에 쥐고 있었습니다.

With the SMTP forwarding feature, it pulled far enough in front of the competition to potentially become a “category killer”, one of those classic programs that fills its niche so competently that the alternatives are not just discarded but almost forgotten.

SMTP 전달 기능 덕분에 경쟁에서 훨씬 앞서 나가 잠재적으로 “카테고리 킬러”가 될 수 있었습니다. 카테고리 킬러란 틈새 시장을 매우 효율적으로 채워 대안이 폐기될 뿐만 아니라 거의 잊혀지는 고전적인 프로그램을 의미합니다.

I think you can’t really aim or plan for a result like this. You have to get pulled into it by design ideas so powerful that afterward the results just seem inevitable, natural, even foreordained. The only way to try for ideas like that is by having lots of ideas---or by having the engineering judgment to take other peoples’ good ideas beyond where the originators thought they could go.

이런 결과는 목표를 정하거나 계획한다고 얻을 수 있는 것이 아니라고 생각합니다. 너무나 강력한 설계 아이디어에 이끌려 가야 하며, 그러면 결과는 필연적이고 자연스러우며 심지어 예정된 것처럼 보입니다. 그런 아이디어를 얻으려면 아이디어가 많거나, 다른 사람들의 좋은 아이디어를 원래 제안자가 생각했던 것 이상으로 발전시킬 수 있는 엔지니어링적 판단력이 있어야 합니다.

Andy Tanenbaum had the original idea to build a simple native Unix for IBM PCs, for use as a teaching tool (he called it Minix). Linus Torvalds pushed the Minix concept further than Andrew probably thought it could go---and it grew into something wonderful. In the same way (though on a smaller scale), I took some ideas by Carl Harris and Harry Hochheiser and pushed them hard. Neither of us was “original” in the romantic way people think is genius. But then, most science and engineering and software development isn’t done by original genius, hacker mythology to the contrary.

앤디 타넨바움은 IBM PC용 간단한 네이티브 유닉스를 교육 도구로 사용하기 위해 구축하려는 독창적인 아이디어를 가지고 있었습니다(그는 그것을 Minix라고 불렀습니다). 리누스 토르발스는 앤드류가 생각했던 것보다 Minix 개념을 더 발전시켰고, 그것은 훌륭한 것으로 성장했습니다. 같은 방식으로 (비록 더 작은 규모이지만) 칼 해리스와 해리 호흐하이저의 아이디어를 가져와서 열심히 밀어붙였습니다. 우리 둘 다 사람들이 천재라고 생각하는 낭만적인 의미에서 “독창적”이지는 않았습니다. 그러나 대부분의 과학, 공학 및 소프트웨어 개발은 해커 신화와는 반대로 독창적인 천재에 의해 이루어지지 않습니다.

The results were pretty heady stuff all the same---in fact, just the kind of success every hacker lives for! And they meant I would have to set my standards even higher. To make fetchmail as good as I now saw it could be, I’d have to write not just for my own needs, but also include and support features necessary to others but outside my orbit. And do that while keeping the program simple and robust.

결과는 꽤나 흥분되는 것이었습니다. 사실, 모든 해커가 갈망하는 바로 그런 종류의 성공이었습니다! 그리고 그것은 제가 제 기준을 훨씬 더 높여야 한다는 것을 의미했습니다. fetchmail을 제가 지금 생각하는 만큼 좋게 만들려면, 저는 제 자신의 필요뿐만 아니라 다른 사람들에게 필요하지만 제 궤도 밖에 있는 기능들을 포함하고 지원하기 위해 작성해야 했습니다. 그리고 프로그램을 간단하고 견고하게 유지하면서 그렇게 해야 했습니다.

The first and overwhelmingly most important feature I wrote after realizing this was multidrop support---the ability to fetch mail from mailboxes that had accumulated all mail for a group of users, and then route each piece of mail to its individual recipients.

이것을 깨달은 후 제가 작성한 첫 번째이자 압도적으로 가장 중요한 기능은 멀티드롭 지원이었습니다. 이는 사용자 그룹의 모든 메일을 축적한 메일함에서 메일을 가져와 각 메일을 개별 수신자에게 라우팅하는 기능입니다.

I decided to add the multidrop support partly because some users were clamoring for it, but mostly because I thought it would shake bugs out of the single-drop code by forcing me to deal with addressing in full generality. And so it proved. Getting RFC 822 address parsing right took me a remarkably long time, not because any individual piece of it is hard, but because it involved a pile of interdependent and fussy details.

제가 멀티드롭 지원을 추가하기로 결정한 것은 부분적으로는 일부 사용자들이 그것을 요구했기 때문이지만, 주로 완전한 일반성으로 주소 지정을 다루도록 강요함으로써 싱글드롭 코드에서 버그를 제거할 것이라고 생각했기 때문입니다. 그리고 그것은 증명되었습니다. RFC 822 주소 구문 분석을 올바르게 수행하는 데는 상당히 오랜 시간이 걸렸습니다. 개별적인 부분이 어렵기 때문이 아니라, 상호 의존적이고 까다로운 세부 사항들이 쌓여 있었기 때문입니다.

But multidrop addressing turned out to be an excellent design decision as well. Here’s how I knew:

하지만 멀티드롭 어드레싱은 훌륭한 설계 결정으로 판명되었습니다. 내가 어떻게 알았는지 알려드리겠습니다.

Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

모든 도구는 예상되는 방식으로 유용해야 하지만 진정으로 훌륭한 도구는 예상치 못한 용도로도 활용될 수 있습니다.

The unexpected use for multidrop fetchmail is to run mailing lists with the list kept, and alias expansion done, on the client side of the Internet connection. This means someone running a personal machine through an ISP account can manage a mailing list without continuing access to the ISP’s alias files.

fetchmail 멀티드롭의 예상치 못한 용도는 목록 보관 및 별칭 확장이 인터넷 연결의 클라이언트 측에서 수행되는 메일링 리스트를 실행하는 것입니다. 이는 ISP 계정을 통해 개인 컴퓨터를 실행하는 사람이 ISP의 별칭 파일에 계속 액세스하지 않고도 메일링 리스트를 관리할 수 있음을 의미합니다.

Another important change demanded by my beta-testers was support for 8-bit MIME (Multipurpose Internet Mail Extensions) operation. This was pretty easy to do, because I had been careful to keep the code 8-bit clean (that is, to not press the 8th bit, unused in the ASCII character set, into service to carry information within the program). Not because I anticipated the demand for this feature, but rather in obedience to another rule:

베타 테스터들이 요구한 또 다른 중요한 변경 사항은 8비트 MIME(Multipurpose Internet Mail Extensions) 작동 지원이었습니다. 코드를 8비트 클린 상태로 유지하도록 주의했기 때문에 (즉, ASCII 문자 집합에서 사용되지 않는 8번째 비트를 프로그램 내에서 정보를 전달하는 데 사용하지 않도록) 이는 매우 쉽게 수행할 수 있었습니다. 이 기능에 대한 수요를 예상했기 때문이 아니라 다른 규칙을 준수했기 때문입니다.

When writing gateway software of any kind, take pains to disturb the data stream as little as possible---and never throw away information unless the recipient forces you to!

어떤 종류의 게이트웨이 소프트웨어를 작성하든 데이터 스트림을 최대한 적게 변경하도록 노력하십시오. 수신자가 강요하지 않는 한 정보를 버리지 마십시오!

Had I not obeyed this rule, 8-bit MIME support would have been difficult and buggy. As it was, all I had to do is read the MIME standard (RFC 1652) and add a trivial bit of header-generation logic.

이 규칙을 지키지 않았다면 8비트 MIME 지원이 어렵고 버그가 많았을 것입니다. 다행히도 MIME 표준 (RFC 1652)을 읽고 간단한 헤더 생성 로직을 추가하기만 하면 되었습니다.

Some European users bugged me into adding an option to limit the number of messages retrieved per session (so they can control costs from their expensive phone networks). I resisted this for a long time, and I’m still not entirely happy about it. But if you’re writing for the world, you have to listen to your customers---this doesn’t change just because they’re not paying you in money.

일부 유럽 사용자들이 세션당 검색되는 메시지 수를 제한하는 옵션을 추가하도록 저를 괴롭혔습니다 (비싼 전화 네트워크 비용을 제어할 수 있도록). 저는 오랫동안 이에 저항했고 여전히 완전히 만족스럽지는 않습니다. 하지만 전 세계를 대상으로 글을 쓰는 경우 고객의 의견을 경청해야 합니다. 고객이 돈을 지불하지 않는다고 해서 바뀌는 것은 아닙니다.

A Few More Lessons from Fetchmail

Fetchmail에서 얻은 몇 가지 교훈

Before we go back to general software-engineering issues, there are a couple more specific lessons from the fetchmail experience to ponder. Nontechnical readers can safely skip this section.

일반적인 소프트웨어 엔지니어링 문제로 돌아가기 전에 fetchmail 경험에서 얻을 수 있는 몇 가지 구체적인 교훈이 더 있습니다. 비기술적인 독자는 이 섹션을 건너뛰어도 좋습니다.

The rc (control) file syntax includes optional “noise” keywords that are entirely ignored by the parser. The English-like syntax they allow is considerably more readable than the traditional terse keyword-value pairs you get when you strip them all out.

rc(제어) 파일 구문에는 파서에서 완전히 무시되는 선택적 “노이즈” 키워드가 포함되어 있습니다. 이러한 키워드를 사용하면 모든 키워드를 제거했을 때 얻을 수 있는 간결한 키워드-값 쌍보다 영어와 유사한 구문이 훨씬 더 읽기 쉽습니다.

These started out as a late-night experiment when I noticed how much the rc file declarations were beginning to resemble an imperative minilanguage. (This is also why I changed the original popclient “server” keyword to “poll”).

이것은 rc 파일 선언이 명령형 미니 언어와 얼마나 유사해지기 시작했는지 알았을 때 늦은 밤 실험으로 시작되었습니다. (이것이 원래 popclient “server” 키워드를 “poll”로 변경한 이유이기도 합니다.)

It seemed to me that trying to make that imperative minilanguage more like English might make it easier to use. Now, although I’m a convinced partisan of the “make it a language” school of design as exemplified by Emacs and HTML and many database engines, I am not normally a big fan of “English-like” syntaxes.

저는 그 명령형 미니 언어를 영어처럼 만들면 사용하기가 더 쉬워질 것이라고 생각했습니다. 이제 저는 Emacs와 HTML 및 많은 데이터베이스 엔진에서 예시된 “언어로 만들기” 디자인 학파의 확신에 찬 지지자이지만, 일반적으로 “영어와 유사한” 구문을 그다지 좋아하지 않습니다.

Traditionally programmers have tended to favor control syntaxes that are very precise and compact and have no redundancy at all. This is a cultural legacy from when computing resources were expensive, so parsing stages had to be as cheap and simple as possible. English, with about 50% redundancy, looked like a very inappropriate model then.

전통적으로 프로그래머들은 매우 정확하고 간결하며 중복성이 전혀 없는 제어 구문을 선호하는 경향이 있었습니다. 이는 컴퓨팅 자원이 비쌌던 시대의 문화적 유산으로, 파싱 단계가 가능한 저렴하고 간단해야 했습니다. 약 50%의 중복성을 가진 영어는 당시 매우 부적절한 모델처럼 보였습니다.

This is not my reason for normally avoiding English-like syntaxes; I mention it here only to demolish it. With cheap cycles and core, terseness should not be an end in itself. Nowadays it’s more important for a language to be convenient for humans than to be cheap for the computer.

이것이 제가 보통 영어와 유사한 구문을 피하는 이유는 아닙니다. 단지 그것을 무너뜨리기 위해 여기서 언급하는 것입니다. 저렴한 사이클과 코어를 사용하면 간결함 자체가 목적이 되어서는 안 됩니다. 오늘날에는 언어가 컴퓨터에게 저렴한 것보다 인간에게 편리한 것이 더 중요합니다.

There remain, however, good reasons to be wary. One is the complexity cost of the parsing stage---you don’t want to raise that to the point where it’s a significant source of bugs and user confusion in itself. Another is that trying to make a language syntax English-like often demands that the “English” it speaks be bent seriously out of shape, so much so that the superficial resemblance to natural language is as confusing as a traditional syntax would have been. (You see this bad effect in a lot of so-called “fourth generation” and commercial database-query languages.)

그러나 경계해야 할 충분한 이유가 여전히 남아 있습니다. 그중 하나는 파싱 단계의 복잡성 비용입니다. 이로 인해 버그의 중요한 원인이 되거나 사용자에게 혼란을 야기하는 것을 원하지 않을 것입니다. 또 다른 이유는 언어 구문을 영어와 유사하게 만들려고 하면 종종 해당 언어가 심각하게 왜곡되어야 한다는 것입니다. 따라서 자연어와의 피상적인 유사성이 기존 구문만큼이나 혼란스러울 수 있습니다. (이러한 나쁜 영향은 소위 “4세대” 및 상용 데이터베이스 쿼리 언어에서 볼 수 있습니다.)

The fetchmail control syntax seems to avoid these problems because the language domain is extremely restricted. It’s nowhere near a general-purpose language; the things it says simply are not very complicated, so there’s little potential for confusion in moving mentally between a tiny subset of English and the actual control language. I think there may be a broader lesson here:

fetchmail 제어 구문은 언어 도메인이 극도로 제한되어 있기 때문에 이러한 문제를 피하는 것 같습니다. 범용 언어와는 거리가 멉니다. 그것이 말하는 것들은 매우 복잡하지 않으므로 영어의 작은 하위 집합과 실제 제어 언어 사이를 정신적으로 이동할 때 혼란이 발생할 가능성이 거의 없습니다. 여기에서 더 광범위한 교훈을 얻을 수 있다고 생각합니다.

When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

당신의 언어가 튜링 완전과 거리가 멀리 떨어져 있다면, 신택스 슈가는 당신의 친구가 될 수 있습니다.

Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store passwords encrypted in the rc file, so snoopers wouldn’t be able to casually see them.

또 다른 교훈은 난독화를 통한 보안에 관한 것입니다. 일부 fetchmail 사용자는 스누퍼가 무심코 암호를 볼 수 없도록 rc 파일에 암호화된 암호를 저장하도록 소프트웨어를 변경해 달라고 요청했습니다.

I didn’t do it, because this doesn’t actually add protection. Anyone who’s acquired permissions to read your rc file will be able to run fetchmail as you anyway---and if it’s your password they’re after, they’d be able to rip the necessary decoder out of the fetchmail code itself to get it.

나는 그렇게 하지 않았습니다. 왜냐하면 이것은 실제로 보호 기능을 추가하지 않기 때문입니다. rc 파일을 읽을 권한을 얻은 사람은 누구든지 어쨌든 fetchmail을 실행할 수 있으며, 만약 그들이 당신의 암호를 노리고 있다면 fetchmail 코드 자체에서 필요한 디코더를 뜯어내서 얻을 수 있을 것입니다.

All .fetchmailrc password encryption would have done is give a false sense of security to people who don’t think very hard. The general rule here is:

모든 .fetchmailrc 비밀번호 암호화는 깊이 생각하지 않는 사람들에게 잘못된 보안 의식을 심어주는 것밖에 되지 않았을 것입니다. 일반적인 규칙은 다음과 같습니다.

A security system is only as secure as its secret. Beware of pseudo-secrets.

보안 시스템은 비밀만큼 안전합니다. 유사 비밀을 조심하십시오.

Necessary Preconditions for the Bazaar Style

바자회 스타일을 위한 필수 전제 조건

Early reviewers and test audiences for this essay consistently raised questions about the preconditions for successful bazaar-style development, including both the qualifications of the project leader and the state of code at the time one goes public and starts to try to build a co-developer community.

이 에세이에 대한 초기 검토자 및 테스트 대상은 프로젝트 리더의 자격과 공개적으로 협력 개발자 커뮤니티를 구축하기 시작할 때의 코드 상태를 포함하여 성공적인 바자회 스타일 개발을 위한 전제 조건에 대해 지속적으로 질문을 제기했습니다.

It’s fairly clear that one cannot code from the ground up in bazaar style [IN]. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn’t try it. I didn’t either. Your nascent developer community needs to have something runnable and testable to play with.

바자회 스타일[IN]로 처음부터 코딩할 수는 없다는 것이 꽤 분명합니다. 바자회 스타일로 테스트하고, 디버그하고, 개선할 수는 있지만, 바자회 모드로 프로젝트를 시작하기는 매우 어려울 것입니다. 리누스도 그렇게 하지 않았고, 저도 마찬가지였습니다. 당신의 초기 개발자 커뮤니티는 가지고 놀 수 있는 실행 가능하고 테스트 가능한 무언가가 필요합니다.

When you start community-building, what you need to be able to present is a plausible promise. Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.

커뮤니티 구축을 시작할 때 제시할 수 있어야 하는 것은 그럴듯한 약속입니다. 당신의 프로그램이 특별히 잘 작동할 필요는 없습니다. 조잡하고, 버그가 많고, 불완전하고, 문서화가 잘 안 되어 있을 수도 있습니다. 하지만 (a) 실행되고, (b) 잠재적인 공동 개발자들에게 가까운 미래에 정말 멋진 것으로 발전할 수 있다고 확신시켜야 합니다.

Linux and fetchmail both went public with strong, attractive basic designs. Many people thinking about the bazaar model as I have presented it have correctly considered this critical, then jumped from that to the conclusion that a high degree of design intuition and cleverness in the project leader is indispensable.

Linux와 fetchmail 모두 강력하고 매력적인 기본 디자인으로 공개되었습니다. 제가 제시한 것처럼 바자 모델에 대해 생각하는 많은 사람들이 이것이 중요하다고 올바르게 생각한 다음, 프로젝트 리더의 높은 수준의 디자인 직관과 영리함이 필수적이라는 결론으로 뛰어넘었습니다.

But Linus got his design from Unix. I got mine initially from the ancestral popclient (though it would later change a great deal, much more proportionately speaking than has Linux). So does the leader/coordinator for a bazaar-style effort really have to have exceptional design talent, or can he get by through leveraging the design talent of others?

하지만 리누스는 유닉스에서 그의 디자인을 가져왔습니다. 저는 원래 조상인 popclient에서 (나중에 리눅스보다 훨씬 더 비례적으로 많이 바뀌겠지만) 가져왔습니다. 그렇다면 바자 스타일 노력의 리더/코디네이터는 정말 뛰어난 디자인 재능을 가져야 할까요, 아니면 다른 사람들의 디자인 재능을 활용하여 헤쳐나갈 수 있을까요?

I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others.

코디네이터가 뛰어난 독창적인 디자인을 만들 수 있는 것은 중요하지 않지만, 코디네이터가 다른 사람들의 좋은 디자인 아이디어를 인식할 수 있는 것은 절대적으로 중요하다고 생각합니다.

Both the Linux and fetchmail projects show evidence of this. Linus, while not (as previously discussed) a spectacularly original designer, has displayed a powerful knack for recognizing good design and integrating it into the Linux kernel. And I have already described how the single most powerful design idea in fetchmail (SMTP forwarding) came from somebody else.

리눅스와 fetchmail 프로젝트 모두 이것에 대한 증거를 보여줍니다. 리누스는 (앞서 논의한 바와 같이) 눈에 띄게 독창적인 디자이너는 아니지만, 훌륭한 디자인을 인식하고 리눅스 커널에 통합하는 강력한 재능을 보여주었습니다. 그리고 저는 fetchmail에서 가장 강력한 디자인 아이디어(SMTP 포워딩)가 다른 사람에게서 나왔는지 이미 설명했습니다.

Early audiences of this essay complimented me by suggesting that I am prone to undervalue design originality in bazaar projects because I have a lot of it myself, and therefore take it for granted. There may be some truth to this; design (as opposed to coding or debugging) is certainly my strongest skill.

이 에세이의 초기 독자들은 제가 바자 프로젝트에서 디자인의 독창성을 과소평가하는 경향이 있다고 칭찬해 주었는데, 이는 제가 스스로 많은 독창성을 가지고 있기 때문에 당연하게 여기기 때문일 수 있습니다. 어느 정도 사실일 수 있습니다. (코딩이나 디버깅과 반대로) 디자인은 확실히 제 가장 강력한 기술입니다.

But the problem with being clever and original in software design is that it gets to be a habit---you start reflexively making things cute and complicated when you should be keeping them robust and simple. I have had projects crash on me because I made this mistake, but I managed to avoid this with fetchmail.

하지만 소프트웨어 설계에서 영리하고 독창적인 것은 습관이 되기 쉽다는 문제가 있습니다. 견고하고 단순하게 유지해야 할 때 귀엽고 복잡하게 만드는 것을 반사적으로 시작합니다. 이런 실수를 저질러서 프로젝트가 망가진 적도 있지만, fetchmail에서는 이런 실수를 피할 수 있었습니다.

So I believe the fetchmail project succeeded partly because I restrained my tendency to be clever; this argues (at least) against design originality being essential for successful bazaar projects. And consider Linux. Suppose Linus Torvalds had been trying to pull off fundamental innovations in operating system design during the development; does it seem at all likely that the resulting kernel would be as stable and successful as what we have?

그래서 저는 fetchmail 프로젝트가 성공한 부분적인 이유는 제가 영리해지려는 경향을 억제했기 때문이라고 생각합니다. 이는 (적어도) 성공적인 바자회 프로젝트에 디자인 독창성이 필수적이지 않다는 것을 입증합니다. 그리고 리눅스를 생각해 보십시오. 리누스 토발즈가 개발 중에 운영체제 설계에서 근본적인 혁신을 시도했었다면, 결과적으로 지금 우리가 가지고 있는 것만큼 안정적이고 성공적인 커널이 나올 가능성이 있을까요?

A certain base level of design and coding skill is required, of course, but I expect almost anybody seriously thinking of launching a bazaar effort will already be above that minimum. The open-source community’s internal market in reputation exerts subtle pressure on people not to launch development efforts they’re not competent to follow through on. So far this seems to have worked pretty well.

물론 특정 수준의 기본적인 설계 및 코딩 기술은 필요하지만, 바자회 노력을 시작하려고 진지하게 생각하는 사람은 거의 누구나 이미 그 최소 수준 이상일 것이라고 예상합니다. 오픈 소스 커뮤니티의 내부적인 평판 시장은 사람들이 감당할 수 없는 개발 노력을 시작하지 않도록 미묘한 압력을 가합니다. 지금까지는 꽤 잘 작동하는 것 같습니다.

There is another kind of skill not normally associated with software development which I think is as important as design cleverness to bazaar projects---and it may be more important. A bazaar project coordinator or leader must have good people and communications skills.

바자회 프로젝트에는 디자인의 영리함만큼 중요한, 또는 그보다 더 중요할 수 있는 소프트웨어 개발과 일반적으로 관련이 없는 또 다른 종류의 기술이 있습니다. 바자회 프로젝트 코디네이터 또는 리더는 훌륭한 대인 관계 및 커뮤니케이션 기술을 갖추고 있어야 합니다.

This should be obvious. In order to build a development community, you need to attract people, interest them in what you’re doing, and keep them happy about the amount of work they’re doing. Technical sizzle will go a long way towards accomplishing this, but it’s far from the whole story. The personality you project matters, too.

이는 당연한 이야기입니다. 개발 커뮤니티를 구축하려면 사람들을 끌어모아 여러분이 하는 일에 관심을 갖게 하고, 그들이 하는 일의 양에 만족하도록 해야 합니다. 기술적인 매력은 이를 달성하는 데 큰 도움이 되지만, 그것이 전부는 아닙니다. 여러분이 보여주는 개성도 중요합니다.

It is not a coincidence that Linus is a nice guy who makes people like him and want to help him. It’s not a coincidence that I’m an energetic extrovert who enjoys working a crowd and has some of the delivery and instincts of a stand-up comic. To make the bazaar model work, it helps enormously if you have at least a little skill at charming people.

리누스가 사람들에게 호감을 주고 그를 돕고 싶게 만드는 좋은 사람이라는 것은 우연이 아닙니다. 제가 활기찬 외향적인 사람으로서 사람들과 어울리는 것을 즐기고 스탠드업 코미디언과 같은 전달력과 직감을 가지고 있다는 것도 우연이 아닙니다. 바자회 모델이 작동하려면 사람들을 매료시키는 데 약간의 기술이라도 있는 것이 엄청난 도움이 됩니다.

On Management and the Maginot Line

경영과 마지노선에 대하여

The original Cathedral and Bazaar paper of 1997 ended with the vision above---that of happy networked hordes of programmer/anarchists outcompeting and overwhelming the hierarchical world of conventional closed software.

1997년의 원래 성당과 시장 논문은 행복한 네트워크 프로그래머/무정부주의자 무리가 기존의 폐쇄형 소프트웨어의 계층적 세계를 능가하고 압도한다는 위의 비전으로 끝맺었습니다.

A good many skeptics weren’t convinced, however; and the questions they raise deserve a fair engagement. Most of the objections to the bazaar argument come down to the claim that its proponents have underestimated the productivity-multiplying effect of conventional management.

하지만 많은 회의론자들은 납득하지 못했고, 그들이 제기하는 질문들은 공정한 검토를 받을 만합니다. 바자회 주장에 대한 대부분의 반론은 그 주창자들이 기존 관리 방식의 생산성 배가 효과를 과소평가했다는 주장으로 귀결됩니다.

Traditionally-minded software-development managers often object that the casualness with which project groups form and change and dissolve in the open-source world negates a significant part of the apparent advantage of numbers that the open-source community has over any single closed-source developer. They would observe that in software development it is really sustained effort over time and the degree to which customers can expect continuing investment in the product that matters, not just how many people have thrown a bone in the pot and left it to simmer.

전통적인 소프트웨어 개발 관리자들은 오픈 소스 세계에서 프로젝트 그룹이 형성, 변경, 해체되는 방식의 무심함이 오픈 소스 커뮤니티가 단일 폐쇄 소스 개발자보다 갖는 수적 이점의 상당 부분을 상쇄한다고 이의를 제기하는 경우가 많습니다. 그들은 소프트웨어 개발에서 중요한 것은 얼마나 많은 사람들이 냄비에 뼈를 던져 넣고 끓도록 내버려 두었는지가 아니라 시간이 지남에 따라 지속적인 노력과 고객이 제품에 대한 지속적인 투자를 기대할 수 있는 정도라고 말할 것입니다.

There is something to this argument, to be sure; in fact, I have developed the idea that expected future service value is the key to the economics of software production in the essay The Magic Cauldron.

물론 이 주장에도 일리가 있습니다. 사실, 저는 예상되는 미래 서비스 가치가 소프트웨어 생산 경제의 핵심이라는 아이디어를 “마법의 가마솥”이라는 에세이에서 발전시켰습니다.

But this argument also has a major hidden problem; its implicit assumption that open-source development cannot deliver such sustained effort. In fact, there have been open-source projects that maintained a coherent direction and an effective maintainer community over quite long periods of time without the kinds of incentive structures or institutional controls that conventional management finds essential. The development of the GNU Emacs editor is an extreme and instructive example; it has absorbed the efforts of hundreds of contributors over 15 years into a unified architectural vision, despite high turnover and the fact that only one person (its author) has been continuously active during all that time. No closed-source editor has ever matched this longevity record.

그러나 이 주장에는 또한 중요한 숨겨진 문제가 있습니다. 즉, 오픈 소스 개발이 그러한 지속적인 노력을 제공할 수 없다는 암묵적인 가정이 있습니다. 실제로 기존 관리 방식에서 필수적이라고 생각하는 인센티브 구조나 제도적 통제 없이도 상당히 오랜 기간 동안 일관된 방향과 효과적인 유지 관리자 커뮤니티를 유지해 온 오픈 소스 프로젝트가 있었습니다. GNU Emacs 편집기의 개발은 극단적이고 교훈적인 예입니다. 높은 이직률과 그 기간 동안 단 한 사람(작성자)만이 지속적으로 활동했다는 사실에도 불구하고 15년 이상에 걸쳐 수백 명의 기여자의 노력을 통합된 아키텍처 비전으로 흡수했습니다. 어떤 폐쇄 소스 편집기도 이 수명 기록에 필적한 적이 없습니다.

This suggests a reason for questioning the advantages of conventionally-managed software development that is independent of the rest of the arguments over cathedral vs.bazaar mode. If it’s possible for GNU Emacs to express a consistent architectural vision over 15 years, or for an operating system like Linux to do the same over 8 years of rapidly changing hardware and platform technology; and if (as is indeed the case) there have been many well-architected open-source projects of more than 5 years duration — then we are entitled to wonder what, if anything, the tremendous overhead of conventionally-managed development is actually buying us.

이는 대성당 모드 대 바자 모드에 대한 다른 논쟁과는 독립적으로 기존 방식으로 관리되는 소프트웨어 개발의 장점에 의문을 제기할 만한 이유를 제시합니다. GNU Emacs가 15년 동안 일관된 아키텍처 비전을 표현할 수 있거나, Linux와 같은 운영 체제가 급변하는 하드웨어 및 플랫폼 기술 환경에서 8년 동안 동일한 작업을 수행할 수 있다면, 그리고 5년 이상 지속된 잘 설계된 오픈 소스 프로젝트가 많이 있다면 (실제로 그렇듯이) 기존 방식으로 관리되는 개발의 엄청난 오버헤드가 실제로 우리에게 무엇을 제공하는지 궁금해할 자격이 있습니다.

Whatever it is certainly doesn’t include reliable execution by deadline, or on budget, or to all features of the specification; it’s a rare “managed” project that meets even one of these goals, let alone all three. It also does not appear to be ability to adapt to changes in technology and economic context during the project lifetime, either; the open-source community has proven far more effective on that score (as one can readily verify, for example, by comparing the 30-year history of the Internet with the short half-lives of proprietary networking technologies---or the cost of the 16-bit to 32-bit transition in Microsoft Windows with the nearly effortless upward migration of Linux during the same period, not only along the Intel line of development but to more than a dozen other hardware platforms, including the 64-bit Alpha as well).

그것이 무엇이든 간에 마감일 또는 예산 내 또는 사양의 모든 기능에 대한 안정적인 실행을 확실히 포함하지 않습니다. 이러한 목표 중 하나라도 충족하는 “관리되는” 프로젝트는 드물고, 세 가지 모두를 충족하는 경우는 더욱 드뭅니다. 또한 프로젝트 수명 동안 기술 및 경제적 환경 변화에 적응하는 능력도 포함하지 않는 것 같습니다. 오픈 소스 커뮤니티는 그 점에서 훨씬 더 효과적인 것으로 입증되었습니다(예를 들어, 인터넷의 30년 역사와 독점 네트워킹 기술의 짧은 수명 또는 Microsoft Windows의 16비트에서 32비트 전환 비용과 동일 기간 동안 Intel 라인의 개발뿐만 아니라 64비트 Alpha를 포함한 12개 이상의 다른 하드웨어 플랫폼으로의 Linux의 거의 손쉬운 상향 마이그레이션을 비교하여 쉽게 확인할 수 있습니다).

One thing many people think the traditional mode buys you is somebody to hold legally liable and potentially recover compensation from if the project goes wrong. But this is an illusion; most software licenses are written to disclaim even warranty of merchantability, let alone performance---and cases of successful recovery for software nonperformance are vanishingly rare. Even if they were common, feeling comforted by having somebody to sue would be missing the point. You didn’t want to be in a lawsuit; you wanted working software.

많은 사람들이 전통적인 방식이 제공한다고 생각하는 한 가지는 프로젝트가 잘못될 경우 법적 책임을 물고 잠재적으로 보상을 받을 수 있는 사람입니다. 그러나 이것은 환상입니다. 대부분의 소프트웨어 라이선스는 성능은 고사하고 상품성에 대한 보증조차 부인하도록 작성되었으며 소프트웨어 성능 불량에 대한 성공적인 보상 사례는 극히 드뭅니다. 흔하다고 해도 소송을 걸 사람이 있다는 사실에 위안을 받는 것은 핵심을 놓치는 것입니다. 소송을 원한 것이 아니라 작동하는 소프트웨어를 원했습니다.

So what is all that management overhead buying?

그렇다면 이 모든 관리 오버헤드는 무엇을 제공하는 것일까요?

In order to understand that, we need to understand what software development managers believe they do. A woman I know who seems to be very good at this job says software project management has five functions:

그것을 이해하려면 소프트웨어 개발 관리자가 자신이 무엇을 한다고 생각하는지 이해해야 합니다. 이 일을 매우 잘하는 것 같은 제가 아는 한 여성은 소프트웨어 프로젝트 관리에 다섯 가지 기능이 있다고 말합니다.

To define goals and keep everybody pointed in the same direction

목표를 정의하고 모든 사람이 같은 방향을 향하도록 유지합니다.

To monitor and make sure crucial details don’t get skipped

중요한 세부 사항이 누락되지 않도록 모니터링하고 확인합니다.

To motivate people to do boring but necessary drudgework

지루하지만 필요한 고된 작업을 수행하도록 사람들에게 동기를 부여합니다.

To organize the deployment of people for best productivity

최고의 생산성을 위해 인력 배치를 구성합니다.

To marshal resources needed to sustain the project

프로젝트를 유지하는 데 필요한 자원을 확보합니다.

Apparently worthy goals, all of these; but under the open-source model, and in its surrounding social context, they can begin to seem strangely irrelevant. We’ll take them in reverse order.

겉보기에는 모두 가치 있는 목표이지만, 오픈 소스 모델과 그 주변의 사회적 맥락에서는 이상하게 부적절해 보일 수 있습니다. 역순으로 살펴보겠습니다.

My friend reports that a lot of resource marshalling is basically defensive; once you have your people and machines and office space, you have to defend them from peer managers competing for the same resources, and from higher-ups trying to allocate the most efficient use of a limited pool.

내 친구는 많은 리소스 마샬링이 기본적으로 방어적이라고 보고합니다. 일단 인력, 장비, 사무 공간을 확보하면 동일한 리소스를 놓고 경쟁하는 동료 관리자와 제한된 풀을 가장 효율적으로 사용하려고 하는 상위 관리자로부터 이를 방어해야 합니다.

But open-source developers are volunteers, self-selected for both interest and ability to contribute to the projects they work on (and this remains generally true even when they are being paid a salary to hack open source.) The volunteer ethos tends to take care of the “attack” side of resource-marshalling automatically; people bring their own resources to the table. And there is little or no need for a manager to “play defense” in the conventional sense.

그러나 오픈 소스 개발자는 자원봉사자이며, 자신이 작업하는 프로젝트에 대한 관심과 기여 능력 모두를 스스로 선택합니다(오픈 소스를 해킹하기 위해 급여를 받는 경우에도 일반적으로 마찬가지입니다). 자원봉사 정신은 자원 동원의 “공격” 측면을 자동으로 처리하는 경향이 있습니다. 사람들은 자신의 자원을 테이블에 가져옵니다. 그리고 관리자가 기존의 의미에서 “수비”를 할 필요가 거의 또는 전혀 없습니다.

Anyway, in a world of cheap PCs and fast Internet links, we find pretty consistently that the only really limiting resource is skilled attention. Open-source projects, when they founder, essentially never do so for want of machines or links or office space; they die only when the developers themselves lose interest.

어쨌든, 저렴한 PC와 빠른 인터넷 링크가 있는 세상에서, 우리는 숙련된 관심만이 진정으로 제한적인 자원이라는 것을 꽤 일관되게 발견합니다. 오픈 소스 프로젝트가 실패할 때, 기본적으로 기계나 링크 또는 사무실 공간의 부족으로 실패하는 경우는 결코 없습니다. 개발자 자신이 흥미를 잃을 때만 실패합니다.

That being the case, it’s doubly important that open-source hackers organize themselves for maximum productivity by self-selection---and the social milieu selects ruthlessly for competence. My friend, familiar with both the open-source world and large closed projects, believes that open source has been successful partly because its culture only accepts the most talented 5% or so of the programming population. She spends most of her time organizing the deployment of the other 95%, and has thus observed first-hand the well-known variance of a factor of one hundred in productivity between the most able programmers and the merely competent.

그렇기 때문에 오픈 소스 해커가 자기 선택에 의해 생산성을 극대화하도록 스스로를 조직하는 것이 두 배로 중요합니다. 그리고 사회적 환경은 역량에 대해 가차 없이 선택합니다. 오픈 소스 세계와 대규모 폐쇄 프로젝트 모두에 익숙한 제 친구는 오픈 소스가 성공한 부분적인 이유가 문화적으로 가장 재능 있는 프로그래밍 인구의 약 5%만을 수용하기 때문이라고 생각합니다. 그녀는 나머지 95%의 배치를 조직하는 데 대부분의 시간을 보내므로, 가장 유능한 프로그래머와 그저 유능한 프로그래머 사이의 생산성 차이가 100배나 된다는 잘 알려진 사실을 직접 관찰했습니다.

The size of that variance has always raised an awkward question: would individual projects, and the field as a whole, be better off without more than 50% of the least able in it? Thoughtful managers have understood for a long time that if conventional software management’s only function were to convert the least able from a net loss to a marginal win, the game might not be worth the candle.

그 차이의 크기는 항상 불편한 질문을 제기했습니다. 개별 프로젝트와 전체 분야가 가장 무능한 사람들의 50% 이상이 없으면 더 나아질까요? 사려 깊은 관리자들은 기존 소프트웨어 관리의 유일한 기능이 가장 무능한 사람들을 순손실에서 한계 이익으로 전환하는 것이라면 그 게임은 노력할 가치가 없을 수도 있다는 것을 오랫동안 이해해 왔습니다.

The success of the open-source community sharpens this question considerably, by providing hard evidence that it is often cheaper and more effective to recruit self-selected volunteers from the Internet than it is to manage buildings full of people who would rather be doing something else.

오픈 소스 커뮤니티의 성공은 인터넷에서 스스로 선택한 자원봉사자를 모집하는 것이 다른 일을 하고 싶어 하는 사람들로 가득 찬 건물을 관리하는 것보다 종종 더 저렴하고 효과적이라는 확실한 증거를 제공함으로써 이 질문을 상당히 날카롭게 합니다.

Which brings us neatly to the question of motivation. An equivalent and often-heard way to state my friend’s point is that traditional development management is a necessary compensation for poorly motivated programmers who would not otherwise turn out good work.

이 점은 자연스럽게 동기 부여에 대한 질문으로 이어집니다. 제 친구의 주장을 표현하는 동등하고 흔히 들을 수 있는 방식은 전통적인 개발 관리는 양질의 작업을 하지 않는 동기 부여가 부족한 프로그래머에 대한 필요한 보상이라는 것입니다.

This answer usually travels with a claim that the open-source community can only be relied on only to do work that is “sexy” or technically sweet; anything else will be left undone (or done only poorly) unless it’s churned out by money-motivated cubicle peons with managers cracking whips over them. I address the psychological and social reasons for being skeptical of this claim in Homesteading the Noosphere. For present purposes, however, I think it’s more interesting to point out the implications of accepting it as true.

이 답변은 일반적으로 오픈 소스 커뮤니티는 “섹시”하거나 기술적으로 매력적인 작업만 수행하도록 의존할 수 있다는 주장과 함께 제공됩니다. 다른 모든 작업은 돈에 동기 부여된 큐비클 직원들이 관리자의 채찍질 아래에서 만들어내지 않으면 완료되지 않거나 (또는 제대로 수행되지 않음) 방치될 것입니다. 저는 Homesteading the Noosphere에서 이 주장에 대해 회의적인 심리적, 사회적 이유를 다룹니다. 그러나 현재의 목적을 위해 이를 사실로 받아들이는 것의 의미를 지적하는 것이 더 흥미롭다고 생각합니다.

If the conventional, closed-source, heavily-managed style of software development is really defended only by a sort of Maginot Line of problems conducive to boredom, then it’s going to remain viable in each individual application area for only so long as nobody finds those problems really interesting and nobody else finds any way to route around them. Because the moment there is open-source competition for a “boring” piece of software, customers are going to know that it was finally tackled by someone who chose that problem to solve because of a fascination with the problem itself---which, in software as in other kinds of creative work, is a far more effective motivator than money alone.

기존의 폐쇄형 소스, 과도하게 관리되는 소프트웨어 개발 스타일이 지루함을 유발하는 문제의 마지노선에 의해서만 실제로 방어된다면, 누군가가 그 문제를 정말 흥미롭게 여기지 않고 다른 사람이 그 문제를 우회할 방법을 찾지 못하는 한 각 개별 응용 분야에서만 실행 가능할 것입니다. 왜냐하면 “지루한” 소프트웨어에 대한 오픈 소스 경쟁이 생기는 순간 고객은 그 문제가 문제 자체에 대한 매력 때문에 그 문제를 해결하기로 선택한 사람이 마침내 다루었다는 것을 알게 될 것이기 때문입니다. 그리고 이는 소프트웨어뿐만 아니라 다른 종류의 창의적인 작업에서도 돈보다 훨씬 더 효과적인 동기 부여 요인입니다.

Having a conventional management structure solely in order to motivate, then, is probably good tactics but bad strategy; a short-term win, but in the longer term a surer loss.

따라서 동기 부여만을 위해 기존의 관리 구조를 갖는 것은 아마도 좋은 전술이지만 나쁜 전략일 것입니다. 단기적으로는 이익이지만 장기적으로는 확실한 손실입니다.

So far, conventional development management looks like a bad bet now against open source on two points (resource marshalling, organization), and like it’s living on borrowed time with respect to a third (motivation). And the poor beleaguered conventional manager is not going to get any succour from the monitoring issue; the strongest argument the open-source community has is that decentralized peer review trumps all the conventional methods for trying to ensure that details don’t get slipped.

지금까지 기존의 개발 관리는 두 가지 측면(자원 동원, 조직)에서 오픈 소스에 비해 나쁜 선택으로 보이며, 세 번째 측면(동기 부여)에서는 시간 낭비처럼 보입니다. 그리고 불쌍한 기존 관리자는 모니터링 문제로부터 어떤 도움도 받지 못할 것입니다. 오픈 소스 커뮤니티가 가진 가장 강력한 주장은 분산된 동료 검토가 세부 사항이 누락되지 않도록 하기 위한 모든 기존 방법을 능가한다는 것입니다.

Can we save defining goals as a justification for the overhead of conventional software project management? Perhaps; but to do so, we’ll need good reason to believe that management committees and corporate roadmaps are more successful at defining worthy and widely shared goals than the project leaders and tribal elders who fill the analogous role in the open-source world.

기존 소프트웨어 프로젝트 관리의 오버헤드를 정당화하기 위해 목표 정의를 유지할 수 있을까요? 아마도 가능할 것입니다. 그러나 그렇게 하려면 관리 위원회와 기업 로드맵이 오픈 소스 세계에서 유사한 역할을 수행하는 프로젝트 리더와 부족 지도자보다 가치 있고 널리 공유되는 목표를 정의하는 데 더 성공적이라고 믿을 만한 충분한 이유가 있어야 합니다.

That is on the face of it a pretty hard case to make. And it’s not so much the open-source side of the balance (the longevity of Emacs, or Linus Torvalds’s ability to mobilize hordes of developers with talk of “world domination”) that makes it tough. Rather, it’s the demonstrated awfulness of conventional mechanisms for defining the goals of software projects.

겉으로 보기에는 꽤 어려운 주장이다. 그리고 균형의 오픈 소스 측면(Emacs의 수명, 또는 Linus Torvalds가 “세계 정복”에 대한 이야기로 수많은 개발자를 동원하는 능력)이 어려운 점은 아니다. 오히려 소프트웨어 프로젝트의 목표를 정의하는 기존 메커니즘의 입증된 끔찍함 때문이다.

One of the best-known folk theorems of software engineering is that 60% to 75% of conventional software projects either are never completed or are rejected by their intended users. If that range is anywhere near true (and I’ve never met a manager of any experience who disputes it) then more projects than not are being aimed at goals that are either (a) not realistically attainable, or (b) just plain wrong.

소프트웨어 공학에서 가장 잘 알려진 민간 어원 중 하나는 기존 소프트웨어 프로젝트의 60%에서 75%가 완료되지 않거나 의도한 사용자가 거부한다는 것입니다. 그 범위가 어느 정도 사실에 가깝다면 (그리고 경험이 있는 관리자 중에 이의를 제기하는 사람을 본 적이 없습니다) 대부분의 프로젝트는 (a) 현실적으로 달성할 수 없거나 (b) 완전히 잘못된 목표를 지향하고 있습니다.

This, more than any other problem, is the reason that in today’s software engineering world the very phrase “management committee” is likely to send chills down the hearer’s spine---even (or perhaps especially) if the hearer is a manager. The days when only programmers griped about this pattern are long past; Dilbert cartoons hang over executives’ desks now.

다른 어떤 문제보다 이것이 오늘날 소프트웨어 엔지니어링 세계에서 “관리 위원회”라는 문구만 들어도 듣는 사람의 등골을 오싹하게 만드는 이유입니다. 듣는 사람이 관리자일지라도 (특히) 그렇습니다. 프로그래머만 이 패턴에 불만을 토로하던 시대는 오래 전에 지났습니다. 이제 임원 책상 위에는 Dilbert 만화가 걸려 있습니다.

Our reply, then, to the traditional software development manager, is simple---if the open-source community has really underestimated the value of conventional management, why do so many of you display contempt for your own process?

그렇다면 기존 소프트웨어 개발 관리자에 대한 우리의 답변은 간단합니다. 오픈 소스 커뮤니티가 기존 관리의 가치를 정말로 과소평가했다면 왜 그렇게 많은 사람들이 자신의 프로세스를 경멸하는 모습을 보일까요?

Once again the example of the open-source community sharpens this question considerably---because we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We’re proving not only that we can do better software, but that joy is an asset.

다시 한번 오픈 소스 커뮤니티의 예는 이 질문을 상당히 날카롭게 합니다. 왜냐하면 우리는 우리가 하는 일을 즐기기 때문입니다. 우리의 창의적인 활동은 놀라운 속도로 기술, 시장 점유율 및 마음 점유율 성공을 거두고 있습니다. 우리는 더 나은 소프트웨어를 만들 수 있을 뿐만 아니라 기쁨이 자산이라는 것을 증명하고 있습니다.

Two and a half years after the first version of this essay, the most radical thought I can offer to close with is no longer a vision of an open-source—dominated software world; that, after all, looks plausible to a lot of sober people in suits these days.

이 에세이의 첫 번째 버전이 나온 지 2년 반이 지난 지금, 결론적으로 제시할 수 있는 가장 급진적인 생각은 더 이상 오픈 소스가 지배하는 소프트웨어 세계에 대한 비전이 아닙니다. 결국, 요즘에는 많은 점잖은 사람들이 정장을 입고 그럴듯하다고 생각합니다.

Rather, I want to suggest what may be a wider lesson about software, (and probably about every kind of creative or professional work). Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency.

오히려 저는 소프트웨어(그리고 아마도 모든 종류의 창의적 또는 전문적인 작업)에 대한 더 넓은 교훈이 될 수 있는 것을 제시하고 싶습니다. 인간은 일반적으로 작업이 일종의 최적의 도전 영역에 속할 때 즐거움을 느낍니다. 너무 쉬워서 지루하지도 않고, 달성하기가 너무 어렵지도 않습니다. 행복한 프로그래머는 활용도가 낮지도 않고, 잘못된 목표와 스트레스가 많은 프로세스 마찰로 인해 부담을 느끼지도 않는 사람입니다. 즐거움은 효율성을 예측합니다.

Relating to your own work process with fear and loathing (even in the displaced, ironic way suggested by hanging up Dilbert cartoons) should therefore be regarded in itself as a sign that the process has failed. Joy, humor, and playfulness are indeed assets; it was not mainly for the alliteration that I wrote of “happy hordes” above, and it is no mere joke that the Linux mascot is a cuddly, neotenous penguin.

자신의 작업 과정과 두려움과 혐오감을 느끼며 관계를 맺는 것(딜버트 만화를 걸어 놓는 것으로 암시되는 전치되고 아이러니한 방식으로도)은 그 과정이 실패했다는 신호로 간주되어야 합니다. 기쁨, 유머, 장난기는 실제로 자산입니다. 제가 위에서 “행복한 무리”에 대해 쓴 것은 주로 두운 때문이 아니었고, 리눅스 마스코트가 귀엽고 유아적인 펭귄이라는 것은 단순한 농담이 아닙니다.

It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work.

오픈 소스의 성공으로 인한 가장 중요한 효과 중 하나는 놀이가 창의적인 작업의 가장 경제적으로 효율적인 방식이라는 것을 우리에게 가르쳐주는 것임이 밝혀질 수 있습니다.

Epilog: Netscape Embraces the Bazaar

에필로그: 넷스케이프, 바자회를 수용하다

It’s a strange feeling to realize you’re helping make history…

역사를 만드는 데 일조하고 있다는 사실을 깨닫는 것은 묘한 기분이다…

On January 22 1998, approximately seven months after I first published The Cathedral and the Bazaar, Netscape Communications, Inc.announced plans to give away the source for Netscape Communicator. I had had no clue this was going to happen before the day of the announcement.

1998년 1월 22일, 제가 처음 ‘성당과 시장’을 발표한 지 약 7개월 후, 넷스케이프 커뮤니케이션즈(Netscape Communications, Inc.)는 넷스케이프 커뮤니케이터(Netscape Communicator)의 소스 코드를 공개할 계획을 발표했습니다. 발표 당일까지 저는 이런 일이 일어날 줄 전혀 몰랐습니다.

Eric Hahn, executive vice president and chief technology officer at Netscape, emailed me shortly afterwards as follows: “On behalf of everyone at Netscape, I want to thank you for helping us get to this point in the first place. Your thinking and writings were fundamental inspirations to our decision.”

넷스케이프의 수석 부사장 겸 최고 기술 책임자인 에릭 한(Eric Hahn)은 발표 직후 다음과 같은 이메일을 보내왔습니다. “넷스케이프의 모든 사람을 대표하여, 우리가 이 지점에 도달하는 데 도움을 주셔서 감사합니다. 당신의 생각과 글은 우리의 결정에 근본적인 영감을 주었습니다.”

The following week I flew out to Silicon Valley at Netscape’s invitation for a day-long strategy conference (on 4 Feb 1998) with some of their top executives and technical people. We designed Netscape’s source-release strategy and license together.

그 다음 주에 나는 Netscape의 초대로 실리콘 밸리로 날아가 그들의 최고 임원진 및 기술 담당자들과 함께 하루 종일 전략 회의(1998년 2월 4일)를 가졌습니다. 우리는 Netscape의 소스 공개 전략과 라이선스를 함께 설계했습니다.

A few days later I wrote the following:

며칠 후 나는 다음과 같이 썼습니다.

Netscape is about to provide us with a large-scale, real-world test of the bazaar model in the commercial world. The open-source culture now faces a danger; if Netscape’s execution doesn’t work, the open-source concept may be so discredited that the commercial world won’t touch it again for another decade.

Netscape는 상업 세계에서 바자 모델에 대한 대규모 실제 테스트를 우리에게 제공하려고 합니다. 오픈 소스 문화는 이제 위험에 직면해 있습니다. Netscape의 실행이 제대로 작동하지 않으면 오픈 소스 개념이 너무 불신을 받아 상업 세계가 향후 10년 동안 다시는 이를 건드리지 않을 수 있습니다.

On the other hand, this is also a spectacular opportunity. Initial reaction to the move on Wall Street and elsewhere has been cautiously positive. We’re being given a chance to prove ourselves, too. If Netscape regains substantial market share through this move, it just may set off a long-overdue revolution in the software industry.

반면에 이것은 또한 엄청난 기회이기도 합니다. 월스트리트 및 다른 곳에서의 이번 조치에 대한 초기 반응은 조심스럽게 긍정적이었습니다. 우리는 우리 자신을 증명할 기회를 얻고 있습니다. Netscape가 이 움직임을 통해 상당한 시장 점유율을 회복한다면 소프트웨어 업계에서 오래 지연된 혁명을 촉발할 수도 있습니다.

The next year should be a very instructive and interesting time.

내년은 매우 유익하고 흥미로운 시간이 될 것입니다.

And indeed it was. As I write in mid-2000, the development of what was later named Mozilla has been only a qualified success. It achieved Netscape’s original goal, which was to deny Microsoft a monopoly lock on the browser market. It has also achieved some dramatic successes (notably the release of the next-generation Gecko rendering engine).

그리고 실제로 그러했습니다. 2000년 중반에 이 글을 쓰는 시점에서, 나중에 모질라라고 명명된 것의 개발은 제한적인 성공에 그쳤습니다. 이는 넷스케이프의 원래 목표, 즉 마이크로소프트가 브라우저 시장을 독점하는 것을 막는 데 성공했습니다. 또한 몇 가지 극적인 성공(특히 차세대 Gecko 렌더링 엔진 출시)을 거두었습니다.

However, it has not yet garnered the massive development effort from outside Netscape that the Mozilla founders had originally hoped for. The problem here seems to be that for a long time the Mozilla distribution actually broke one of the basic rules of the bazaar model; it didn’t ship with something potential contributors could easily run and see working. (Until more than a year after release, building Mozilla from source required a license for the proprietary Motif library.)

그러나 모질라 창립자들이 원래 희망했던 것만큼 넷스케이프 외부로부터의 대규모 개발 노력을 아직 얻지 못했습니다. 여기서 문제는 모질라 배포판이 오랫동안 바자 모델의 기본 규칙 중 하나를 실제로 위반했다는 것입니다. 잠재적 기여자들이 쉽게 실행하고 작동하는 것을 볼 수 있는 것이 함께 제공되지 않았습니다. (출시 후 1년 이상 동안 모질라를 소스에서 빌드하려면 독점 Motif 라이브러리에 대한 라이선스가 필요했습니다.)

Most negatively (from the point of view of the outside world) the Mozilla group didn’t ship a production-quality browser for two and a half years after the project launch---and in 1999 one of the project’s principals caused a bit of a sensation by resigning, complaining of poor management and missed opportunities. “Open source,” he correctly observed, “is not magic pixie dust.”

가장 부정적인 점은 (외부 세계의 관점에서) 모질라 그룹이 프로젝트 시작 후 2년 반 동안 생산 품질의 브라우저를 출시하지 않았다는 것입니다. 그리고 1999년에 프로젝트의 주요 책임자 중 한 명이 열악한 관리와 놓친 기회에 대해 불만을 토로하며 사임하여 약간의 센세이션을 일으켰습니다. 그는 “오픈 소스는 마법의 요술 가루가 아니다”라고 정확하게 지적했습니다.

And indeed it is not. The long-term prognosis for Mozilla looks dramatically better now (in November 2000) than it did at the time of Jamie Zawinski’s resignation letter---in the last few weeks the nightly releases have finally passed the critical threshold to production usability. But Jamie was right to point out that going open will not necessarily save an existing project that suffers from ill-defined goals or spaghetti code or any of the software engineering’s other chronic ills. Mozilla has managed to provide an example simultaneously of how open source can succeed and how it could fail.

그리고 실제로 그렇지 않습니다. 모질라의 장기적인 전망은 Jamie Zawinski의 사임 편지 당시보다 지금(2000년 11월) 훨씬 더 나아 보입니다. 지난 몇 주 동안 매일 릴리스되는 버전이 마침내 생산 사용성을 위한 중요한 임계값을 통과했습니다. 그러나 Jamie는 오픈 소스로 전환하는 것이 불분명한 목표나 스파게티 코드 또는 소프트웨어 엔지니어링의 다른 만성적인 문제로 고통받는 기존 프로젝트를 반드시 구제하지는 않을 것이라고 지적한 것은 옳았습니다. 모질라는 오픈 소스가 어떻게 성공할 수 있는지, 그리고 어떻게 실패할 수 있는지에 대한 예를 동시에 제공하는 데 성공했습니다.

In the mean time, however, the open-source idea has scored successes and found backers elsewhere. Since the Netscape release we’ve seen a tremendous explosion of interest in the open-source development model, a trend both driven by and driving the continuing success of the Linux operating system. The trend Mozilla touched off is continuing at an accelerating rate.

하지만 그 동안 오픈 소스 아이디어는 성공을 거두었고 다른 곳에서 후원자를 찾았습니다. 넷스케이프 출시 이후 오픈 소스 개발 모델에 대한 엄청난 관심이 폭발적으로 증가했으며, 이는 리눅스 운영 체제의 지속적인 성공에 의해 주도되고 추진되는 추세입니다. 모질라가 촉발한 추세는 가속화된 속도로 계속되고 있습니다.

Notes

[JB]:

In Programing Pearls, the noted computer-science aphorist Jon Bentley comments on Brooks’s observation with “If you plan to throw one away, you will throw away two.”. He is almost certainly right. The point of Brooks’s observation, and Bentley’s, isn’t merely that you should expect first attempt to be wrong, it’s that starting over with the right idea is usually more effective than trying to salvage a mess.

프로그래밍 펄스에서 유명한 컴퓨터 과학 어록 작가인 존 벤틀리는 브룩스의 관찰에 대해 “하나를 버릴 계획이라면 두 개를 버리게 될 것이다.”라고 논평합니다. 그는 거의 확실히 옳습니다. 브룩스와 벤틀리의 관찰 요점은 첫 번째 시도가 잘못될 것이라고 예상해야 한다는 것뿐만 아니라 올바른 아이디어로 다시 시작하는 것이 엉망진창을 수습하려고 하는 것보다 일반적으로 더 효과적이라는 것입니다.

[QR]:

Examples of successful open-source, bazaar development predating the Internet explosion and unrelated to the Unix and Internet traditions have existed. The development of the info-Zip compression utility during 1990—x1992, primarily for DOS machines, was one such example. Another was the RBBS bulletin board system (again for DOS), which began in 1983 and developed a sufficiently strong community that there have been fairly regular releases up to the present (mid-1999) despite the huge technical advantages of Internet mail and file-sharing over local BBSs. While the info-Zip community relied to some extent on Internet mail, the RBBS developer culture was actually able to base a substantial on-line community on RBBS that was completely independent of the TCP/IP infrastructure.

인터넷 폭발 이전과 유닉스 및 인터넷 전통과 관련 없는 성공적인 오픈 소스, 바자 개발의 예가 존재했습니다. 1990-x1992년 동안 주로 DOS 시스템용으로 개발된 info-Zip 압축 유틸리티가 그 한 예였습니다. 또 다른 예는 1983년에 시작된 RBBS 게시판 시스템(역시 DOS용)으로, 인터넷 메일 및 파일 공유의 막대한 기술적 이점에도 불구하고 현재(1999년 중반)까지 상당히 규칙적인 릴리스가 있을 정도로 강력한 커뮤니티를 개발했습니다. info-Zip 커뮤니티는 어느 정도 인터넷 메일에 의존했지만, RBBS 개발자 문화는 실제로 TCP/IP 인프라와 완전히 독립적인 RBBS를 기반으로 상당한 온라인 커뮤니티를 구축할 수 있었습니다.

[CV]:

That transparency and peer review are valuable for taming the complexity of OS development turns out, after all, not to be a new concept. In 1965, very early in the history of time-sharing operating systems, Corbató and Vyssotsky, co-designers of the Multics operating system, wrote

OS 개발의 복잡성을 길들이는 데 투명성과 동료 검토가 중요하다는 것은 결국 새로운 개념이 아닌 것으로 밝혀졌습니다. 1965년, 시분할 운영 체제의 역사 초기에 Multics 운영 체제의 공동 설계자인 Corbató와 Vyssotsky는 다음과 같이 썼습니다.

It is expected that the Multics system will be published when it is operating substantially… Such publication is desirable for two reasons: First, the system should withstand public scrutiny and criticism volunteered by interested readers; second, in an age of increasing complexity, it is an obligation to present and future system designers to make the inner operating system as lucid as possible so as to reveal the basic system issues.

Multics 시스템은 실질적으로 작동될 때 공개될 것으로 예상된다… 그러한 공개는 두 가지 이유로 바람직하다. 첫째, 시스템은 관심 있는 독자들이 자발적으로 제공하는 대중의 면밀한 조사와 비판에 견딜 수 있어야 한다. 둘째, 복잡성이 증가하는 시대에 기본 시스템 문제를 드러내기 위해 내부 운영 체제를 가능한 한 명확하게 만들어 현재 및 미래의 시스템 설계자에게 제시하는 것이 의무이다.

[JH]:

John Hasler has suggested an interesting explanation for the fact that duplication of effort doesn’t seem to be a net drag on open-source development. He proposes what I’ll dub “Hasler’s Law”: the costs of duplicated work tend to scale sub-qadratically with team size---that is, more slowly than the planning and management overhead that would be needed to eliminate them.

John Hasler는 중복된 노력에도 불구하고 오픈 소스 개발에 순 손실이 발생하지 않는 이유에 대한 흥미로운 설명을 제시했습니다. 그는 제가 “Hasler의 법칙”이라고 부를 만한 것을 제안합니다. 중복 작업 비용은 팀 규모에 따라 이차 함수보다 느리게 증가하는 경향이 있습니다. 즉, 이를 제거하는 데 필요한 계획 및 관리 오버헤드보다 느리게 증가합니다.

This claim actually does not contradict Brooks’s Law. It may be the case that total complexity overhead and vulnerability to bugs scales with the square of team size, but that the costs from duplicated work are nevertheless a special case that scales more slowly. It’s not hard to develop plausible reasons for this, starting with the undoubted fact that it is much easier to agree on functional boundaries between different developers’ code that will prevent duplication of effort than it is to prevent the kinds of unplanned bad interactions across the whole system that underly most bugs.

이 주장은 실제로 브룩스의 법칙과 모순되지 않습니다. 총 복잡성 오버헤드 및 버그에 대한 취약성은 팀 규모의 제곱에 따라 증가할 수 있지만, 중복 작업으로 인한 비용은 더 느리게 증가하는 특별한 경우일 수 있습니다. 이를 뒷받침할 만한 타당한 이유를 제시하는 것은 어렵지 않습니다. 우선, 다양한 개발자의 코드 간의 기능적 경계를 합의하여 노력의 중복을 방지하는 것이 전체 시스템에 걸쳐 발생하는 계획되지 않은 잘못된 상호 작용을 방지하는 것보다 훨씬 쉽다는 것은 의심할 여지가 없습니다. 이러한 상호 작용이 대부분의 버그의 근본 원인입니다.

The combination of Linus’s Law and Hasler’s Law suggests that there are actually three critical size regimes in software projects. On small projects (I would say one to at most three developers) no management structure more elaborate than picking a lead programmer is needed. And there is some intermediate range above that in which the cost of traditional management is relatively low, so its benefits from avoiding duplication of effort, bug-tracking, and pushing to see that details are not overlooked actually net out positive.

리누스의 법칙과 해슬러의 법칙의 조합은 소프트웨어 프로젝트에서 실제로 세 가지 중요한 규모 체제가 있음을 시사합니다. 소규모 프로젝트(저는 최대 3명의 개발자라고 생각합니다)에서는 리드 프로그래머를 선정하는 것보다 더 정교한 관리 구조가 필요하지 않습니다. 그리고 그 이상의 중간 범위에서는 전통적인 관리 비용이 비교적 낮아서 노력의 중복 방지, 버그 추적, 세부 사항 간과 방지를 위한 추진 등의 이점이 실제로 긍정적인 결과를 가져옵니다.

Above that, however, the combination of Linus’s Law and Hasler’s Law suggests there is a large-project range in which the costs and problems of traditional management rise much faster than the expected cost from duplication of effort. Not the least of these costs is a structural inability to harness the many-eyeballs effect, which (as we’ve seen) seems to do a much better job than traditional management at making sure bugs and details are not overlooked. Thus, in the large-project case, the combination of these laws effectively drives the net payoff of traditional management to zero.

그러나 그 이상에서는 리누스의 법칙과 해슬러의 법칙의 조합은 전통적인 관리의 비용과 문제가 노력의 중복으로 인한 예상 비용보다 훨씬 빠르게 증가하는 대규모 프로젝트 범위가 있음을 시사합니다. 이러한 비용 중 가장 적지 않은 것은 많은 눈 효과를 활용할 수 없는 구조적 무능력입니다. 이는 (이미 보았듯이) 버그와 세부 사항이 간과되지 않도록 하는 데 전통적인 관리보다 훨씬 더 나은 역할을 하는 것으로 보입니다. 따라서 대규모 프로젝트의 경우 이러한 법칙의 조합은 전통적인 관리의 순이익을 효과적으로 0으로 만듭니다.

[HBS]:

The split between Linux’s experimental and stable versions has another function related to, but distinct from, hedging risk. The split attacks another problem: the deadliness of deadlines. When programmers are held both to an immutable feature list and a fixed drop-dead date, quality goes out the window and there is likely a colossal mess in the making. I am indebted to Marco Iansiti and Alan MacCormack of the Harvard Business School for showing me me evidence that relaxing either one of these constraints can make scheduling workable.

리눅스의 실험 버전과 안정 버전 간의 분리는 위험 회피와 관련이 있지만 뚜렷하게 다른 기능도 가지고 있습니다. 이 분리는 또 다른 문제, 즉 마감일의 치명성을 해결합니다. 프로그래머가 변경 불가능한 기능 목록과 고정된 마감일에 모두 묶여 있으면 품질은 창밖으로 던져지고 엄청난 혼란이 발생할 가능성이 높습니다. 하버드 경영대학원의 마르코 이안시티와 앨런 맥코맥 덕분에 이러한 제약 조건 중 하나를 완화하면 일정을 조정할 수 있다는 증거를 보았습니다.

One way to do this is to fix the deadline but leave the feature list flexible, allowing features to drop off if not completed by deadline. This is essentially the strategy of the “stable” kernel branch; Alan Cox (the stable-kernel maintainer) puts out releases at fairly regular intervals, but makes no guarantees about when particular bugs will be fixed or what features will beback-ported from the experimental branch.

이를 수행하는 한 가지 방법은 마감일을 정하되 기능 목록을 유연하게 유지하여 마감일까지 완료되지 않은 기능은 제거하는 것입니다. 이것은 본질적으로 “안정적인” 커널 브랜치의 전략입니다. Alan Cox(안정적인 커널 유지 관리자)는 상당히 규칙적인 간격으로 릴리스를 발표하지만 특정 버그가 언제 수정될지 또는 어떤 기능이 실험 브랜치에서 백포트될지에 대해서는 보장하지 않습니다.

The other way to do this is to set a desired feature list and deliver only when it is done. This is essentially the strategy of the “experimental” kernel branch. De Marco and Lister cited research showing that this scheduling policy (“wake me up when it’s done”) produces not only the highest quality but, on average, shorter delivery times than either “realistic” or “aggressive” scheduling.

이를 수행하는 다른 방법은 원하는 기능 목록을 설정하고 완료되었을 때만 제공하는 것입니다. 이것은 본질적으로 “실험적인” 커널 브랜치의 전략입니다. De Marco와 Lister는 이러한 스케줄링 정책(“완료되면 깨워줘”)이 최고 품질을 산출할 뿐만 아니라 평균적으로 “현실적인” 또는 “공격적인” 스케줄링보다 더 짧은 배송 시간을 산출한다는 연구 결과를 인용했습니다.

I have come to suspect (as of early 2000) that in earlier versions of this essay I severely underestimated the importance of the “wake me up when it’s done” anti-deadline policy to the open-source community’s productivity and quality. General experience with the rushed GNOME 1.0 release in 1999 suggests that pressure for a premature release can neutralize many of the quality benefits open source normally confers.

저는 (2000년 초부터) 이 에세이의 이전 버전에서 오픈 소스 커뮤니티의 생산성과 품질에 대한 “완료되면 깨워줘” 마감일 반대 정책의 중요성을 심각하게 과소평가했다고 의심하게 되었습니다. 1999년 서둘러 출시된 GNOME 1.0의 일반적인 경험은 조기 릴리스에 대한 압력이 오픈 소스가 일반적으로 제공하는 많은 품질 이점을 무효화할 수 있음을 시사합니다.

It may well turn out to be that the process transparency of open source is one of three co-equal drivers of its quality, along with “wake me up when it’s done” scheduling and developer self-selection.

오픈 소스의 프로세스 투명성이 “완료되면 깨워줘” 스케줄링 및 개발자 자가 선택과 함께 품질의 세 가지 동등한 동인 중 하나임이 밝혀질 수도 있습니다.

[SU]:

It’s tempting, and not entirely inaccurate, to see the core-plus-halo organization characteristic of open-source projects as an Internet-enabled spin on Brooks’s own recommendation for solving the N-squared complexity problem, the “surgical-team” organization---but the differences are significant. The constellation of specialist roles such as “code librarian” that Brooks envisioned around the team leader doesn’t really exist; those roles are executed instead by generalists aided by toolsets quite a bit more powerful than those of Brooks’s day. Also, the open-source culture leans heavily on strong Unix traditions of modularity, APIs, and information hiding---none of which were elements of Brooks’s prescription.

오픈 소스 프로젝트의 핵심-플러스-헤일로 조직 특성을 브룩스가 N제곱 복잡성 문제를 해결하기 위해 제시한 “수술팀” 조직의 인터넷 지원 버전으로 보는 것은 솔깃하고 완전히 틀린 말은 아니지만, 차이점은 상당합니다. 브룩스가 팀 리더 주변에 구상했던 “코드 사서”와 같은 전문 역할 그룹은 실제로 존재하지 않습니다. 이러한 역할은 대신 브룩스 시대보다 훨씬 더 강력한 툴셋의 도움을 받는 제너럴리스트가 수행합니다. 또한 오픈 소스 문화는 모듈성, API 및 정보 은닉에 대한 강력한 Unix 전통에 크게 의존합니다. 이러한 요소는 브룩스의 처방에는 없었습니다.

[RJ]:

The respondent who pointed out to me the effect of widely varying trace path lengths on the difficulty of characterizing a bug speculated that trace-path difficulty for multiple symptoms of the same bug varies “exponentially” (which I take to mean on a Gaussian or Poisson distribution, and agree seems very plausible). If it is experimentally possible to get a handle on the shape of this distribution, that would be extremely valuable data. Large departures from a flat equal-probability distribution of trace difficulty would suggest that even solo developers should emulate the bazaar strategy by bounding the time they spend on tracing a given symptom before they switch to another. Persistence may not always be a virtue…

다양한 추적 경로 길이가 버그를 특징짓는 데 미치는 영향에 대해 지적한 응답자는 동일한 버그의 여러 증상에 대한 추적 경로 난이도가 “기하급수적으로” 달라진다고 추측했습니다 (이는 가우스 또는 푸아송 분포를 의미하는 것으로 해석하며, 매우 그럴듯하다고 생각합니다). 이 분포의 형태를 실험적으로 파악할 수 있다면 매우 귀중한 데이터가 될 것입니다. 추적 난이도의 평평한 등확률 분포에서 크게 벗어나면 솔로 개발자조차도 주어진 증상 추적에 소비하는 시간을 제한하고 다른 증상으로 전환하여 바자 전략을 모방해야 함을 시사합니다. 끈기가 항상 미덕은 아닐 수 있습니다…

[IN]:

An issue related to whether one can start projects from zero in the bazaar style is whether the bazaar style is capable of supporting truly innovative work. Some claim that, lacking strong leadership, the bazaar can only handle the cloning and improvement of ideas already present at the engineering state of the art, but is unable to push the state of the art. This argument was perhaps most infamously made by the Halloween Documents, two embarrassing internal Microsoft memoranda written about the open-source phenomenon. The authors compared Linux’s development of a Unix-like operating system to “chasing taillights”, and opined (once a project has achieved “parity” with the state-of-the-art), the level of management necessary to push towards new frontiers becomes massive.

바자 스타일로 프로젝트를 처음부터 시작할 수 있는지 여부와 관련된 문제는 바자 스타일이 진정으로 혁신적인 작업을 지원할 수 있는지 여부입니다. 일부에서는 강력한 리더십이 없으면 바자가 엔지니어링 최첨단 기술 수준에 이미 존재하는 아이디어를 복제하고 개선하는 것만 처리할 수 있지만 최첨단 기술을 발전시킬 수는 없다고 주장합니다. 이 주장은 아마도 오픈 소스 현상에 대해 작성된 당혹스러운 Microsoft 내부 메모인 Halloween Documents에서 가장 악명 높게 제기되었을 것입니다. 작성자들은 Unix와 유사한 운영 체제를 개발하는 Linux를 “미등 쫓기”에 비유했으며 (프로젝트가 최첨단 기술과 “동일성”을 달성하면) 새로운 영역으로 나아가기 위해 필요한 관리 수준이 막대해진다고 언급했습니다.

There are serious errors of fact implied in this argument. One is exposed when the Halloween authors themseselves later observe that often […] new research ideas are first implemented and available on Linux before they are available / incorporated into other platforms.

이 논쟁에는 심각한 사실 오류가 내포되어 있습니다. 할로윈 저자들 스스로가 나중에 종종 […] 새로운 연구 아이디어가 다른 플랫폼에 제공/통합되기 전에 먼저 Linux에서 구현되고 사용 가능하다는 점을 관찰할 때 드러납니다.

If we read “open source” for “Linux”, we see that this is far from a new phenomenon. Historically, the open-source community did not invent Emacs or the World Wide Web or the Internet itself by chasing taillights or being massively managed---and in the present, there is so much innovative work going on in open source that one is spoiled for choice. The GNOME project (to pick one of many) is pushing the state of the art in GUIs and object technology hard enough to have attracted considerable notice in the computer trade press well outside the Linux community. Other examples are legion, as a visit to Freshmeat on any given day will quickly prove.

“Linux” 대신 “오픈 소스”라고 읽으면 이것이 새로운 현상과는 거리가 멀다는 것을 알 수 있습니다. 역사적으로 오픈 소스 커뮤니티는 미등을 쫓거나 대규모로 관리되는 방식으로 Emacs, 월드 와이드 웹 또는 인터넷 자체를 발명하지 않았습니다. 그리고 현재 오픈 소스에는 매우 혁신적인 작업이 많이 진행되고 있어 선택의 폭이 넓습니다. (수많은 예 중 하나인) GNOME 프로젝트는 GUI 및 객체 기술 분야에서 최첨단을 추진하고 있으며, Linux 커뮤니티 외부의 컴퓨터 업계 언론에서도 상당한 주목을 받고 있습니다. 다른 예는 매우 많으며, Freshmeat에 방문하면 금방 알 수 있습니다.

But there is a more fundamental error in the implicit assumption that the cathedral model (or the bazaar model, or any other kind of management structure) can somehow make innovation happen reliably. This is nonsense. Gangs don’t have breakthrough insights---even volunteer groups of bazaar anarchists are usually incapable of genuine originality, let alone corporate committees of people with a survival stake in some status quo ante. Insight comes from individuals. The most their surrounding social machinery can ever hope to do is to be responsive to breakthrough insights---to nourish and reward and rigorously test them instead of squashing them.

그러나 대성당 모델(또는 바자 모델 또는 다른 종류의 관리 구조)이 어떻게든 혁신을 안정적으로 발생시킬 수 있다는 암묵적인 가정에는 더 근본적인 오류가 있습니다. 이는 말도 안 됩니다. 갱단은 획기적인 통찰력을 갖지 못합니다. 심지어 바자 아나키스트의 자원 봉사 그룹조차도 진정한 독창성을 발휘할 수 없는 경우가 많으며, 일부 현상 유지에 대한 생존 지분을 가진 기업 위원회는 말할 것도 없습니다. 통찰력은 개인에게서 나옵니다. 주변의 사회적 기계가 할 수 있는 최선은 획기적인 통찰력에 반응하고, 그것을 억압하는 대신 육성하고 보상하며 엄격하게 테스트하는 것입니다.

Some will characterize this as a romantic view, a reversion to outmoded lone-inventor stereotypes. Not so; I am not asserting that groups are incapable of <;em>developing breakthrough insights once they have been hatched; indeed, we learn from the peer-review process that such development groups are essential to producing a high-quality result. Rather I am pointing out that every such group development starts from---is necessarily sparked by---one good idea in one person’s head. Cathedrals and bazaars and other social structures can catch that lightning and refine it, but they cannot make it on demand.

어떤 사람들은 이것을 낭만적인 견해, 시대에 뒤떨어진 외로운 발명가에 대한 복귀로 특징지을 것입니다. 그렇지 않습니다. 저는 그룹이 일단 부화한 획기적인 통찰력을 개발할 수 없다고 주장하는 것이 아닙니다. 실제로 우리는 동료 검토 과정을 통해 이러한 개발 그룹이 고품질 결과를 생성하는 데 필수적이라는 것을 알게 됩니다. 오히려 저는 그러한 모든 그룹 개발이 한 사람의 머릿속에 있는 하나의 좋은 아이디어에서 시작된다는 점을 지적하고 있습니다. 대성당과 바자 및 기타 사회 구조는 그 번개를 포착하고 개선할 수 있지만, 수요에 따라 만들 수는 없습니다.

Therefore the root problem of innovation (in software, or anywhere else) is indeed how not to squash it---but, even more fundamentally, it is how to grow lots of people who can have insights in the first place.

따라서 (소프트웨어를 포함하여) 혁신의 근본적인 문제는 실제로 혁신을 억압하지 않는 방법이지만, 더욱 근본적으로는 통찰력을 가질 수 있는 많은 사람들을 어떻게 키워낼 것인가 하는 것입니다.

To suppose that cathedral-style development could manage this trick but the low entry barriers and process fluidity of the bazaar cannot would be absurd. If what it takes is one person with one good idea, then a social milieu in which one person can rapidly attract the cooperation of hundreds or thousands of others with that good idea is going inevitably to out-innovate any in which the person has to do a political sales job to a hierarchy before he can work on his idea without risk of getting fired.

성당 스타일 개발이 이 문제를 해결할 수 있지만, 바자회의 낮은 진입 장벽과 프로세스 유동성이 해결할 수 없다고 가정하는 것은 터무니없습니다. 필요한 것이 좋은 아이디어를 가진 한 사람이라면, 한 사람이 수백 또는 수천 명의 다른 사람들의 협력을 빠르게 얻을 수 있는 사회적 환경은 필연적으로 아이디어를 실현하기 전에 해고될 위험 없이 계층 구조에 정치적 판매를 해야 하는 환경보다 혁신적일 것입니다.

And, indeed, if we look at the history of software innovation by organizations using the cathedral model, we quickly find it is rather rare. Large corporations rely on university research for new ideas (thus the Halloween Documents authors’ unease about Linux’s facility at coopting that research more rapidly). Or they buy out small companies built around some innovator’s brain. In neither case is the innovation native to the cathedral culture; indeed, many innovations so imported end up being quietly suffocated under the “massive level of management” the Halloween Documents’ authors so extol.

그리고 실제로, 성당 모델을 사용하는 조직의 소프트웨어 혁신 역사를 살펴보면, 그것이 매우 드물다는 것을 금방 알 수 있습니다. 대기업은 새로운 아이디어를 얻기 위해 대학 연구에 의존합니다 (따라서 Halloween Documents 작성자들이 Linux가 그 연구를 더 빠르게 가로채는 능력에 대해 불안감을 느끼는 것입니다). 아니면 혁신가의 두뇌를 중심으로 구축된 소규모 회사를 인수합니다. 어느 경우든 혁신은 성당 문화 고유의 것이 아닙니다. 실제로 그렇게 수입된 많은 혁신은 Halloween Documents 작성자들이 그토록 칭찬하는 “대규모 관리 수준” 하에서 조용히 질식되는 것으로 끝납니다.

That, however, is a negative point. The reader would be better served by a positive one. I suggest, as an experiment, the following:

하지만 그것은 부정적인 측면입니다. 독자는 긍정적인 측면에서 더 나은 서비스를 받을 수 있을 것입니다. 실험으로서 다음을 제안합니다.

Pick a criterion for originality that you believe you can apply consistently. If your definition is “I know it when I see it”, that’s not a problem for purposes of this test.
일관성 있게 적용할 수 있다고 생각하는 독창성 기준을 선택하십시오. 귀하의 정의가 “보면 안다”라면 이 테스트 목적에는 문제가 되지 않습니다.

Pick any closed-source operating system competing with Linux, and a best source for accounts of current development work on it.

Linux와 경쟁하는 모든 상용 운영 체제와 해당 운영 체제에 대한 현재 개발 작업에 대한 최상의 소스를 선택하십시오.

Watch that source and Freshmeat for one month. Every day, count the number of release announcements on Freshmeat that you consider “original” work. Apply the same definition of “original” to announcements for that other OS and count them.

해당 소스와 Freshmeat을 한 달 동안 지켜보십시오. 매일 “독창적인” 작업이라고 생각하는 Freshmeat의 릴리스 발표 수를 세십시오. 다른 OS에 대한 발표에도 동일한 “독창적인” 정의를 적용하고 수를 세십시오.

Thirty days later, total up both figures.

30일 후에 두 수치를 모두 합산합니다.

The day I wrote this, Freshmeat carried twenty-two release announcements, of which three appear they might push state of the art in some respect, This was a slow day for Freshmeat, but I will be astonished if any reader reports as many as three likely innovations a month in any closed-source channel.

제가 이 글을 쓴 날, Freshmeat에는 22개의 릴리스 발표가 있었고, 그 중 3개는 어떤 면에서 최첨단을 밀어붙일 수 있을 것으로 보입니다. Freshmeat에게는 느린 날이었지만, 어떤 독자라도 폐쇄 소스 채널에서 한 달에 3개나 되는 혁신을 보고한다면 저는 놀랄 것입니다.

[EGCS]:

We now have history on a project that, in several ways, may provide a more indicative test of the bazaar premise than fetchmail; EGCS, the Experimental GNU Compiler System.

이제 fetchmail보다 바자회 전제를 더 잘 보여주는 프로젝트의 역사가 있습니다. EGCS, Experimental GNU Compiler System입니다.

This project was announced in mid-August of 1997 as a conscious attempt to apply the ideas in the early public versions of The Cathedral and the Bazaar. The project founders felt that the development of GCC, the Gnu C Compiler, had been stagnating. For about twenty months afterwards, GCC and EGCS continued as parallel products---both drawing from the same Internet developer population, both starting from the same GCC source base, both using pretty much the same Unix toolsets and development environment. The projects differed only in that EGCS consciously tried to apply the bazaar tactics I have previously described, while GCC retained a more cathedral-like organization with a closed developer group and infrequent releases.

이 프로젝트는 1997년 8월 중순에 초기 공개 버전의 “성당과 시장”에 있는 아이디어를 적용하려는 의식적인 시도로 발표되었습니다. 프로젝트 창립자들은 Gnu C 컴파일러인 GCC의 개발이 정체되었다고 느꼈습니다. 그 후 약 20개월 동안 GCC와 EGCS는 병렬 제품으로 계속되었습니다. 둘 다 동일한 인터넷 개발자 집단에서 끌어오고, 동일한 GCC 소스 기반에서 시작하고, 거의 동일한 Unix 툴셋과 개발 환경을 사용했습니다. 프로젝트는 EGCS가 이전에 설명한 바자회 전략을 의식적으로 적용하려고 시도한 반면, GCC는 폐쇄적인 개발자 그룹과 드문 릴리스를 통해 더 성당과 같은 조직을 유지했다는 점에서만 달랐습니다.

This was about as close to a controlled experiment as one could ask for, and the results were dramatic. Within months, the EGCS versions had pulled substantially ahead in features; better optimization, better support for FORTRAN and C++. Many people found the EGCS development snapshots to be more reliable than the most recent stable version of GCC, and major Linux distributions began to switch to EGCS.

이것은 통제된 실험에 최대한 가까웠고, 그 결과는 극적이었습니다. 몇 달 안에 EGCS 버전은 기능 면에서 상당히 앞서 나갔습니다. 더 나은 최적화, FORTRAN 및 C++에 대한 더 나은 지원 등이 있었습니다. 많은 사람들이 EGCS 개발 스냅샷이 GCC의 최신 안정 버전보다 더 안정적이라고 생각했으며, 주요 Linux 배포판이 EGCS로 전환하기 시작했습니다.

In April of 1999, the Free Software Foundation (the official sponsors of GCC) dissolved the original GCC development group and officially handed control of the project to the the EGCS steering team.

1999년 4월, 자유 소프트웨어 재단(GCC의 공식 후원 기관)은 원래의 GCC 개발 그룹을 해체하고 프로젝트 제어권을 공식적으로 EGCS 운영 팀에 넘겼습니다.

[SP]:

Of course, Kropotkin’s critique and Linus’s Law raise some wider issues about the cybernetics of social organizations. Another folk theorem of software engineering suggests one of them; Conway’s Law---commonly stated as “If you have four groups working on a compiler, you’ll get a 4-pass compiler”. The original statement was more general: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” We might put it more succinctly as “The means determine the ends”, or even “Process becomes product”.

물론 크로포트킨의 비판과 리누스의 법칙은 사회 조직의 사이버네틱스에 대한 더 넓은 문제를 제기합니다. 소프트웨어 엔지니어링의 또 다른 민간 정리는 그 중 하나를 제시합니다. 컨웨이의 법칙은 일반적으로 “컴파일러 작업을 하는 네 그룹이 있다면 4단계 컴파일러를 얻게 될 것이다”라고 표현됩니다. 원래의 진술은 더 일반적이었습니다. “시스템을 설계하는 조직은 이러한 조직의 통신 구조의 복사본인 설계를 생산하도록 제약을 받는다.” 우리는 그것을 “수단이 목적을 결정한다” 또는 심지어 “프로세스가 제품이 된다”라고 더 간결하게 표현할 수 있습니다.

It is accordingly worth noting that in the open-source community organizational form and function match on many levels. The network is everything and everywhere: not just the Internet, but the people doing the work form a distributed, loosely coupled, peer-to-peer network that provides multiple redundancy and degrades very gracefully. In both networks, each node is important only to the extent that other nodes want to cooperate with it.

따라서 오픈 소스 커뮤니티에서 조직의 형태와 기능이 여러 수준에서 일치한다는 점은 주목할 가치가 있습니다. 네트워크는 모든 것이고 모든 곳에 있습니다. 인터넷뿐만 아니라 작업을 수행하는 사람들은 분산되고 느슨하게 결합된 피어 투 피어 네트워크를 형성하여 다중 중복성을 제공하고 매우 부드럽게 저하됩니다. 두 네트워크 모두에서 각 노드는 다른 노드가 협력하기를 원하는 정도에 따라서만 중요합니다.

The peer-to-peer part is essential to the community’s astonishing productivity. The point Kropotkin was trying to make about power relationships is developed further by the “SNAFU Principle”: “True communication is possible only between equals, because inferiors are more consistently rewarded for telling their superiors pleasant lies than for telling the truth.” Creative teamwork utterly depends on true communication and is thus very seriously hindered by the presence of power relationships. The open-source community, effectively free of such power relationships, is teaching us by contrast how dreadfully much they cost in bugs, in lowered productivity, and in lost opportunities.

피어 투 피어(peer-to-peer) 방식은 커뮤니티의 놀라운 생산성에 필수적입니다. 크로포트킨이 권력 관계에 대해 이야기하려 했던 요점은 “SNAFU 원칙”에 의해 더욱 발전됩니다. “진정한 소통은 동등한 사람들 사이에서만 가능한데, 그 이유는 하급자는 상급자에게 진실을 말하는 것보다 듣기 좋은 거짓말을 하는 것에 대해 더 일관되게 보상받기 때문입니다.” 창의적인 팀워크는 진정한 소통에 절대적으로 의존하며, 따라서 권력 관계의 존재에 의해 심각하게 저해됩니다. 오픈 소스 커뮤니티는 이러한 권력 관계가 사실상 없기 때문에 버그, 생산성 저하 및 기회 상실에 얼마나 큰 비용이 드는지 대조적으로 우리에게 가르쳐주고 있습니다.

Further, the SNAFU principle predicts in authoritarian organizations a progressive disconnect between decision-makers and reality, as more and more of the input to those who decide tends to become pleasant lies. The way this plays out in conventional software development is easy to see; there are strong incentives for the inferiors to hide, ignore, and minimize problems. When this process becomes product, software is a disaster.

더 나아가, SNAFU 원칙은 권위주의적 조직에서 의사 결정자와 현실 사이의 점진적인 단절을 예측하는데, 이는 의사 결정자에게 전달되는 입력이 점점 더 듣기 좋은 거짓말이 되는 경향이 있기 때문입니다. 이러한 현상이 기존의 소프트웨어 개발에서 나타나는 방식은 쉽게 알 수 있습니다. 하급자들은 문제를 숨기고, 무시하고, 최소화하려는 강력한 동기를 갖습니다. 이러한 과정이 제품이 되면 소프트웨어는 재앙이 됩니다.

Bibliography

I quoted several bits from Frederick P. Brooks’s classic The Mythical Man-Month because, in many respects, his insights have yet to be improved upon. I heartily recommend the 25th Anniversary edition from Addison-Wesley (ISBN 0-201-83595-9), which adds his 1986 “No Silver Bullet” paper.

저는 Frederick P. Brooks의 고전 “The Mythical Man-Month”에서 여러 부분을 인용했는데, 그 이유는 여러 면에서 그의 통찰력이 아직까지 개선되지 않았기 때문입니다. Addison-Wesley에서 출판된 25주년 기념판(ISBN 0-201-83595-9)을 적극 추천합니다. 이 책에는 그의 1986년 논문 “No Silver Bullet”이 추가되었습니다.

The new edition is wrapped up by an invaluable 20-years-later retrospective in which Brooks forthrightly admits to the few judgements in the original text which have not stood the test of time. I first read the retrospective after the first public version of this essay was substantially complete, and was surprised to discover that Brooks attributed bazaar-like practices to Microsoft! (In fact, however, this attribution turned out to be mistaken. In 1998 we learned from the Halloween Documents that Microsoft’s internal developer community is heavily balkanized, with the kind of general source access needed to support a bazaar not even truly possible.)

새로운 에디션은 Brooks가 원본 텍스트에서 시간의 시험을 견디지 못한 몇 가지 판단을 솔직하게 인정하는 귀중한 20년 후 회고로 마무리됩니다. 저는 이 에세이의 첫 번째 공개 버전이 거의 완성된 후에 회고를 처음 읽었고, Brooks가 바자회와 같은 관행을 Microsoft의 것으로 돌렸다는 사실을 알고 놀랐습니다! (그러나 사실, 이 귀속은 잘못된 것으로 판명되었습니다. 1998년, 우리는 Halloween Documents에서 Microsoft의 내부 개발자 커뮤니티가 심하게 발칸화되어 바자회를 지원하는 데 필요한 일반적인 소스 액세스가 실제로 불가능하다는 것을 알게 되었습니다.)

Gerald M. Weinberg’s The Psychology Of Computer Programming (New York, Van Nostrand Reinhold 1971) introduced the rather unfortunately-labeled concept of “egoless programming”. While he was nowhere near the first person to realize the futility of the “principle of command”, he was probably the first to recognize and argue the point in particular connection with software development.

Gerald M. Weinberg의 “The Psychology Of Computer Programming”(New York, Van Nostrand Reinhold 1971)은 다소 불행하게 명명된 “자아 없는 프로그래밍”이라는 개념을 소개했습니다. 그는 “명령의 원칙”의 무용성을 처음으로 깨달은 사람은 아니었지만, 아마도 소프트웨어 개발과 관련하여 그 점을 인식하고 주장한 첫 번째 사람이었을 것입니다.

Richard P. Gabriel, contemplating the Unix culture of the pre-Linux era, reluctantly argued for the superiority of a primitive bazaar-like model in his 1989 paper “LISP: Good News, Bad News, and How To Win Big”. Though dated in some respects, this essay is still rightly celebrated among LISP fans (including me). A correspondent reminded me that the section titled “Worse Is Better” reads almost as an anticipation of Linux. The paper is accessible on the World Wide Web at http://www.naggum.no/worse-is-better.html.

‘Richard P. Gabriel은 Linux 시대 이전의 Unix 문화를 고찰하면서 1989년 논문 “LISP: Good News, Bad News, and How To Win Big”에서 마지못해 원시적인 바자회 모델의 우월성을 주장했습니다. 일부 측면에서는 구식이지만, 이 에세이는 여전히 LISP 팬들(저를 포함하여) 사이에서 정당하게 찬사를 받고 있습니다. 한 통신원은 “Worse Is Better”라는 제목의 섹션이 Linux를 거의 예상한 것처럼 읽힌다고 상기시켜 주었습니다. 해당 논문은 http://www.naggum.no/worse-is-better.html%EC%97%90%EC%84%9C 웹상으로 접근할 수 있습니다.’

De Marco and Lister’s Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6) is an underappreciated gem which I was delighted to see Fred Brooks cite in his retrospective. While little of what the authors have to say is directly applicable to the Linux or open-source communities, the authors’ insight into the conditions necessary for creative work is acute and worthwhile for anyone attempting to import some of the bazaar model’s virtues into a commercial context.

‘De Marco와 Lister의 Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6)는 제가 Fred Brooks가 회고록에서 인용한 것을 보고 기뻤던 과소평가된 보석입니다. 저자들이 말하는 내용 중 Linux 또는 오픈 소스 커뮤니티에 직접적으로 적용될 수 있는 것은 거의 없지만, 창의적인 작업을 위한 필수 조건에 대한 저자들의 통찰력은 날카로우며 바자회 모델의 장점을 상업적 맥락으로 가져오려는 모든 사람에게 가치가 있습니다.’

Finally, I must admit that I very nearly called this essay “The Cathedral and the Agora”, the latter term being the Greek for an open market or public meeting place. The seminal “agoric systems” papers by Mark Miller and Eric Drexler, by describing the emergent properties of market-like computational ecologies, helped prepare me to think clearly about analogous phenomena in the open-source culture when Linux rubbed my nose in them five years later. These papers are available on the Web at http://www.agorics.com/agorpapers.html.

‘마지막으로, 저는 이 에세이를 “대성당과 아고라”라고 부르려고 거의 결정했었다는 것을 인정해야 합니다. 후자는 열린 시장 또는 공공 회의 장소를 의미하는 그리스어입니다. Mark Miller와 Eric Drexler의 획기적인 “아고릭 시스템” 논문은 시장과 유사한 계산 생태계의 창발적 속성을 설명함으로써 Linux가 5년 후 저의 코를 그 속에 박았을 때 오픈 소스 문화의 유사한 현상에 대해 명확하게 생각할 수 있도록 준비하는 데 도움을 주었습니다. 이러한 논문은 웹사이트 http://www.agorics.com/agorpapers.html%EC%97%90%EC%84%9C 확인할 수 있습니다.‘

Acknowledgements

This essay was improved by conversations with a large number of people who helped debug it. Particular thanks to Jeff Dutky, who suggested the “debugging is parallelizable” formulation, and helped develop the analysis that proceeds from it. Also to Nancy Lebovitz for her suggestion that I emulate Weinberg by quoting Kropotkin. Perceptive criticisms also came from Joan Eslinger and Marty Franz of the General Technics list. Glen Vandenburg pointeed out the importance of self-selection in contributor populations and suggested the fruitful idea that much development rectifies “bugs of omission”; Daniel Upper suggested the natural analogies for this. I’m grateful to the members of PLUG, the Philadelphia Linux User’s group, for providing the first test audience for the first public version of this essay. Paula Matuszek enlightened me about the practice of software management. Phil Hudson reminded me that the social organization of the hacker culture mirrors the organization of its software, and vice-versa. John Buck pointed out that MATLAB makes an instructive parallel to Emacs. Russell Johnston brought me to consciousness about some of the mechanisms discussed in “How Many Eyeballs Tame Complexity.” Finally, Linus Torvalds’s comments were helpful and his early endorsement very encouraging.

이 에세이는 디버깅을 도와준 많은 사람들과의 대화를 통해 개선되었습니다. “디버깅은 병렬화할 수 있다”는 표현을 제안하고 그로부터 진행되는 분석을 개발하는 데 도움을 준 Jeff Dutky에게 특별한 감사를 드립니다. 또한 Kropotkin을 인용하여 Weinberg를 모방하라는 제안을 해준 Nancy Lebovitz에게도 감사드립니다. General Technics 목록의 Joan Eslinger와 Marty Franz로부터도 통찰력 있는 비판을 받았습니다. Glen Vandenburg는 기여자 집단에서 자기 선택의 중요성을 지적하고 많은 개발이 “누락된 버그”를 수정한다는 유익한 아이디어를 제시했습니다. Daniel Upper는 이에 대한 자연스러운 비유를 제시했습니다. PLUG (Philadelphia Linux User’s group) 회원들에게 이 에세이의 첫 번째 공개 버전에 대한 첫 번째 테스트 청중을 제공해 주셔서 감사합니다. Paula Matuszek은 소프트웨어 관리 실무에 대해 저를 깨우쳐 주었습니다. Phil Hudson은 해커 문화의 사회 조직이 소프트웨어 조직을 반영하고 그 반대도 마찬가지라는 점을 상기시켜 주었습니다. John Buck은 MATLAB이 Emacs에 대한 유익한 유사점을 제시한다고 지적했습니다. Russell Johnston은 “How Many Eyeballs Tame Complexity”에서 논의된 일부 메커니즘에 대한 의식을 일깨워주었습니다. 마지막으로 Linus Torvalds의 논평은 도움이 되었고 그의 초기 지지는 매우 고무적이었습니다.

junghanacs🧠

Table of Contents

Backlinks

@에릭레이먼드 성당과 시장 리눅스 오픈소스 해커 - 철학

BIBLIOGRAPHY

History

에릭 레이먼드 Eric Steven Raymond

성당과 시장 The Cathedral and the Bazaar

성당과 시장 - 우연한 혁명으로 일어난 리눅스와 오픈소스에 대한 생각 해커

원문: The Cathedral and the Bazaar 성당과 시장

Copyright

Abstract

Introduction

The Mail Must Get Through

The Importance of Having Users

Release Early, Release Often

How Many Eyeballs Tame Complexity

When Is a Rose Not a Rose?

Popclient becomes Fetchmail

Fetchmail Grows Up

A Few More Lessons from Fetchmail

Necessary Preconditions for the Bazaar Style

On Management and the Maginot Line

Epilog: Netscape Embraces the Bazaar

Notes

[JB]:

[QR]:

[CV]:

[JH]:

[HBS]:

[SU]:

[RJ]:

[IN]:

[EGCS]:

[SP]:

Bibliography

Acknowledgements

Graph View

Explorer

Backlinks

junghanacs🧠

Table of Contents

Backlinks

@에릭레이먼드 성당과 시장 리눅스 오픈소스 해커 - 철학

BIBLIOGRAPHY

History

Related-Notes

에릭 레이먼드 Eric Steven Raymond

성당과 시장 The Cathedral and the Bazaar

성당과 시장 - 우연한 혁명으로 일어난 리눅스와 오픈소스에 대한 생각 해커

원문: The Cathedral and the Bazaar 성당과 시장

Copyright

Abstract

Introduction

The Mail Must Get Through

The Importance of Having Users

Release Early, Release Often

How Many Eyeballs Tame Complexity

When Is a Rose Not a Rose?

Popclient becomes Fetchmail

Fetchmail Grows Up

A Few More Lessons from Fetchmail

Necessary Preconditions for the Bazaar Style

On Management and the Maginot Line

Epilog: Netscape Embraces the Bazaar

Notes

[JB]:

[QR]:

[CV]:

[JH]:

[HBS]:

[SU]:

[RJ]:

[IN]:

[EGCS]:

[SP]:

Bibliography

Acknowledgements

Graph View

Explorer

Backlinks