성당과시장추가분

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.

어쨌거나 상당히 많은 수의 회의주의자들은 납득하지 않았다. 그들이 제기한 의문은 상당히 타당한 것들이었다. 시장 논리에 대한 대부분의 반대들은 시장 논리의 주창자들이 일반적인 경영(관리? DeleteMe)의 생산성 증대 (productivity-multiplying) 효과를 과소평가하고 있다는 것으로 귀결되고 있었다.

상당히 많은 수의 회의주의자들은 이에 타당한 의문들을 제기하며 납득하려하지 않았다. 시장논리를 펴는 사람들이 기존 경영방식의 생산증대 효과는 무시하고 있다는 것이다.

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 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 fifteen 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 에디터 개발은 그 극단적이면서 교육적인 예이다. GNU Emacs 개발은 15 년 이상 수백명의 공헌자들의 노력을 받아들여 단일한 구조적 비전을 만들어 냈다. 그 기간동안 단 한 사람 (저자) 만이 지속적으로 활동했으며 공헌자들은 계속해서 바뀌어 나갔다. 폐쇄소스로 만들어진 에디터들 중 Emacs 의 장수 기록에 비교할 만한 것은 없다.

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 fifteen years, or for an operating system like Linux to do the same over eight 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 five years duration -- then we are entitled to wonder what, if anything, the tremendous overhead of conventionally-managed development is actually buying us.

이것은 성당과 시장 모드에 대한 나머지 논란과는 독립적인 일반적으로 경영된(DeleteMe "인습적으로 관리된" 이라 번역함이 더 마땅치 않을까요?) 소프트웨어 개발의 장점에 의심을 품게되는 이유를 제시한다. 만약 GUN Emacs 가 15년 넘게 지속적인 설계의 전망을 보이는 것이 가능하다면, 또는 Linux 와 같은 operating system 이 8년을 넘게 빠르게 변화하는 하드웨어와 플랫폼 기술에 대해서 이와 같이 할 수 있다면, 그리고 만약 (이것은 실제 경우이다.) 5년 이상의 기간보다 더 오래된 많은 잘 설계된 오픈소스 프로젝트들이 있다면, 인습적으로 관리되어온 개발의 거대한 비용이 실제로 우리를 매수하고 있다는 것이 놀랄 만하다고 하게 될 것이다. (DeleteMe 마지막 문장 검토해 주세요.)

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 thirty-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 up-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).

그것이 어떤 것이건 deadline 에 의해서나 예산, 또는 설계서의 모든 특징들에 대해서 확실한 수행을 보장하지 않는다. 세가지는 말할 것도 없이, 심지어 이러한 목표들의 하나를 충족시키는 '관리된' project 도 드물다. 그것은 프로젝트의 수행기간동안 기술이나 경제적인 배경 어느 것의 변화에도 또한 적응하는 능력을 가진 것으로 보이지 않는다. Open-source community 는 그 점에서는 보다 효율적인 것으로 증명되었다. (우리는 예를 들어, 30년의 역사를 가지는 인터넷과 6개월의 독점적인 네트워크 기술을 비교함으로써 쉽게 증명할 수 있다. 아니면 마이크로소프트 윈도우에서의 16 bit에서 32 bit 로의 이행의 비용과 같은 기간에 거의 노력이 들지 않은 Linux 의 이행을 비교할 수 있다. 이것은 Intel 계열의 발전 뿐 아니라, 64-bit Alpha를 포함하는 많은 다른 하드웨어 플랫폼도 역시 같다.)

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.

많은 사람들이 생각하는 하나는 당신이 구입하는 전통적인 방식이 만약 프로젝트가 잘못되었을 때 누군가가 법적으로 책임을 지고 보상을 해 주는 것이라는 것이다. 그러나 이것은 환상이다. 대부분의 소프트웨어 라이센스는 performance 에 대한 것은 말할 필요도 없이, 심지어 판매할 수 있는 보증조차도 부인하기 위해서 쓰여진다. 그리고 소프트웨어가 제대로 동작하지 않는데 대한 성공적인 복구의 경우는 극히 드물다. 심지어 그것들이 흔하다고 하더라도, 누군가를 고소하면 그만이라는 것은 요점을 잃은 것이다. 당신은 소송을 원하는 것이 아니었다. 당신은 작동하는 소프트웨어를 원했다.

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 drudge work.
사람들이 지겹지만 필요한 지겨운 일들을 하도록 동기를 부여한다.

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 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 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.

이 답은 보통 Open-source 커뮤니티는 단지 섹시하고 기술적으로 신선한 일을 할 때에만 믿을 수 있다는 주장과 함께 한다. 그것이 돈에 의해서 동기가 부여된 노동자와 그들을 추동하는 관리자에 의해서 몰아부쳐지지 않으면 다른 것들은 이루어지지 않은 상태로 남겨질 것이다. (혹은 단지 조잡하게 되던지.) 나는 인지권 개간하기 에서 이 주장에 대해서 회의적인 것에 대한 심리적이고 사회적인 이유를 언급한다. 그러나, 현재의 목적을 위해서 그것의 함의를 사실로 지적하는 것이 보다 흥미롭다고 생각한다.

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.

만약 인습적인, 닫힌 소스의, 관리가 심한 스타일의 소프트웨어 개발이 진정으로 지루한 일에 이바지하는 문제점들의 마지노선과 같은 종류에 의해서 방어된다면, 아무도 그러한 문제들을 정말 흥미롭다고 하지 않고, 아무도 그것들 주위의 길을 찾지 않는 한 각각 개별적인 활용 분야에서 존속하게 될 것이다. 왜냐하면, 소프트웨어의 '지루한' 일부분을 위한 오픈소스의 경쟁이 있는 순간, 고객들은 그 문제 자체에 대한 끌림 때문에 그 문제를 풀려고 하는 누군가에 의해 결국 해결된다는 것을 알 것이다. 이것은 다른 창조적인 작업의 종류와 같이 소프트웨어에서도 단독적인 돈보다는 훨씬 더 효율적인 동기이다.

DeleteMe 시제도 잘 일치하지 않는 것 같고, 문장도 이상하고, 내용도 어려워요. 나만 그런가?

(DeleteMe 인습적인 소스 비공개의, 집중관리식의 소프트웨어 개발방식을 지켜주는것이 지겨움을 불러 일으키는 문제들로 구성된 (DeleteMe 그러니까 sexy 하지 않아서 오픈소스계에서 꺼리는) 마지노선 같은 거라면, 그런 것은 각각의 응용분야에서 그 분야에 관심을 가진 사람들이 나타나고, 또 다른 사람들이 그런 사람과 연락하는 길을 찾는 순간까지만 유효할것이다. 바로 그 순간 소프트웨어의 그 '지겨운' 부분에 대한 오픈소스형태의 경쟁상대가 나타나는 것이며, 고객들은 드디어 누군가 그 문제에 문제 자체에 대한 열정으로, 이 열정이라는 것은 다른 종류의 창조적 작업에서와 마찬가지로 소프트웨어 분야에서도 돈 그자체 보다는 훨씬 더 효과적인 동기인데, 도전하는 사람이 나타났음을 알게 될 것이기 때문이다. 대략 이런건 어떨까요? 저는 영문전공은 아닙니다만.)

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.

인습적인 소프트웨어 프로젝트 관리에서 생기는 추가부담이 목표를 정해준다는 사실로 정당화될 수 있을 것인가? (DeleteMe 목표 결정하는 것을 인습적인 소프트웨어 프로젝트 관리의 오버헤드를 위한 정당화로 삼을 수 있을까?) 아마도 그럴 것이다. 하지만 그렇게 하기 위해서, 관리 위원회와 협동 지도가 오픈소스 세계에서 유사한 역할을 하는 프로젝트 지휘자와 부족의 연장자보다 가치 있고 널리 공유된 목표를 정하는 데 보다 성공적이라고 믿을 충분한 이유가 필요할 것이다.

DeleteMe save as 가 그 save as... 의 의미로 밖에 해석이 안되는데 맞는 걸까요? 맞는 것 같습니다

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.

그렇게 말하기는 굉장히 힘들다 (DeleteMe 그것은 매우 하기 어려운 경우의 위에 있다.) 힘든 이유가 오픈소스 쪽의 능력 (이맥스의 장수라든가, 세계정복 이라는 말로 많은 개발자들에게 동기부여를 하는 리누스 토발즈의 능력) 때문인 것 같지는 않다. 오히려 소프트웨어 프로젝트의 목표를 정하기 위한 인습적인 기작이 아주 형편없다는 점 때문이다.

DeleteMe 영어에 나오는 대명사의 80% 정도는 우리말로 번역할 때 삭제하거나 원래 그 대명사가 가리키는 명사로 바꿔주어야 합니다.

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.

하나의 가장 잘 알려진 소프트웨어 기술의 법칙 (DeleteMe folk theorem : 개똥철학?) 은 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.

다른 문제보다 이것이 오늘날의 소프트웨어 기술 세계에서 바로 관리 위원회라는 그 어구가 심지어 (아마도 특별히) 듣는 사람이 관리자일 경우에도 척추에 오한을 일으키게 하는 이유일 것이다. 프로그래머들만이 이 패턴을 이해하고 있었던 때는 예전에 지나갔다. 지금은 '딜버트' 만화가 지금 간부들의 책상에도 걸려있다.

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 existence 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.

당신 자신의 일의 과정을 두려움과 내키지 않음과 관련시키는 것은 (심지어 위치를 벗어나 Dilbert cartoons을 매닮으로써 반어적으로 제안되었을 때에도) 그 자체로 과정이 실패했다는 신호로 간주되어야 한다. 기쁨, 유머, 유희적인 것은 정말로 가치 있는 것이다. 그것은 내가 위에 "happy hordes" 라고 쓴 두운법(alliteration)을 위해서 뿐 아니라, 리눅스 마스코트가 귀엽고 참신한 펭귄인 것도 단순한 조크가 아니다.

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.

오픈소스 성공의 가장 중요한 효과의 하나는 우리에게 유희가 창조적인 일을 하는데 경제적으로 가장 효과적인 방법이라는 것을 가르쳐 준다는 것이 잘 판명될 수 있을 것이다.

중간 중간 번역글에 영어가 보이는데, 모든 번역의 기본은 동일 문자 체계로 옮기는 것입니다. 약간 기준을 느슨하게 하면, 관용적으로 영어로도 많이 쓰이는 대명사는 제외할 수 있을 겁니다 -- 그래도 가능하다면 한글로 적고(로마자 표기법) 괄호 속에 영어를 적어주는 게 좋겠죠. deadline, project 등은 각각 마감일, 프로젝트 등으로 바꿔주는 게 좋겠습니다. --김창준

가능하면 한자어보다 우리말을 사용하는 것이 문장을 더 자연스럽게 만들고 부드럽게 만듭니다. 억지로 만든 듯한 딱딱하고 부자연스러운 문장을 피해가려면, 어순을 바꾸거나 문장구조를 바꾸는 것이 필요하리라 생각됩니다. --Aragorn

반드시 그런것은 아니지만, 주어를 생략해서 적을 수 있으면 번역문 처럼 보이지 않아 보일듯 싶습니다. 우리말에는 주어를 생략해서 쓰기 편한 말이 의외로 많습니다. 하지만, 영어류는 주어가 없으면 명령문이 되어버리니깐요 ^^: 하지만 개인적인 생각일 뿐 절대 공식따윈 아닙니다! -- NeoHind

컴퓨터분류~경영분류