Merge branch 'revert-6d0c8be3' into 'master'

Revert "my part - jinho"

See merge request gogod23/the-cathedral-and-the-bazaar!1

README.md

@@ -818,7 +818,7 @@ Perhaps in the end the open-source culture will triumph not because cooperation
 아마 최종적으로는 협동이 더 도덕적이라거나 소프트웨어 ``매점'' 이 덜 도덕적이라서가 아니라 단지 닫혀진 소스 측과 오픈 소스 공동체와의 군비경쟁에서 오픈 소스 측이 한 문제에 훨씬 큰 비율로 숙련된 사람의 시간을 쏟을 수 있기 때문에 오픈 소스 문화가 승리를 거둘 것이라는 얘기다.
 
 ## 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.
 
 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.
@@ -831,52 +831,26 @@ But this argument also has a major hidden problem; its implicit assumption that
 
 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.
 
--> 김수연
 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년 역사를 독점적 네트워트 기술의 짧은 반감기를 비교함으로써 또는 동일한 시기 동안 마이크로 소프트의 Window에서 16비트에서 32비트로 전환 비용을 거의 노력을 기울이지 않은 리눅스의 상향 이동을 비교함으로써, Intel의 제품군들 뿐만 아니라 64비트 Alpha 또한 포함하는 12개이상의 다른 하드웨어 플랫폼에서 사람들은 쉽게 알 수 있듯이)
-
 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:
 
-그것을 이해하기 위해서, 우리는 소프트웨어개발 경영자들이 그들이 하는 것에 대해 믿는 것을 이해할 필요가 있다. 이 일에 매우 잘하는 것처럼 보이는 내가 아는 한 여자는 소프트웨어 프로젝트 경영이 5개의 기능있다고 말한다.
-
 * 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.
+(박진호)
+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.
 
 하지만 오픈소스 개발자들은 그들이 속한 프로젝트에 기여하기 위한 관심과 능력을 위해 스스로 선발된 자원봉사자들이다. (그리고 이것은 일반적으로, 그들이 오픈소스를 해킹하기 위해 급여를 받고 있을 때도 사실인 부분이다.) 자원봉사자 정신은 resource-marshalling의 '공격적인' 측면을 자동으로 처리하는 경향이 있다. 사람들은 자신의 자원들을 오픈소스로 가져온다. 그리고 관습적인 의미에서, 사용자가 가져온 자원들을 '수비'해야만 할 의무를 가진 관리자는 필요하지 않다.
 
@@ -888,6 +862,7 @@ That being the case, it's doubly important that open-source hackers organize the
 
 그렇기에 오픈소스 해커들이 자기 선택을 통해 생산성을 극대화하기 위해 조직화하는 것과 사회적 환경이 사용자들의 무자비한 경쟁을 선택하는 것이 더욱 중요하다. 오픈소스 세계와 대규모 폐쇄 프로젝트에 익숙한 내 친구는 오픈소스가 성공한 것은 부분적으로 그것의 문화가 프로그래밍 인구 중 가장 재능 있는 5% 정도만을 받아들이기 때문이라고 믿는다. 그녀는 나머지 95%의 배치를 조직하는 데 대부분의 시간을 할애했고, 따라서 가장 유능한 프로그래머와 덜 유능한 프로그래머들 사이의 생산성 차이를 직접 관찰해 왔다.
 
+
 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 % 이상이 없으면 더 나은 것인가? 생각 깊은 관리자들은 기존 소프트웨어 관리의 유일한 기능이, 가장 작은 할 수 있는 일을 순 손실에서 근소한 승리로 전환하는 것이라면 그 일이 그만한 가치가 없을 수도 있다는 것을 오랫동안 이해해 왔다.
@@ -904,10 +879,7 @@ This answer usually travels with a claim that the open-source community can only
 
 이 답변은 일반적으로 오픈 소스 커뮤니티가 '멋지거나' 기술적으로 달콤한 작업을 수행하는 데에만 의존 할 수 있다는 주장과 함께 전달된다. 관리자가 채찍을 휘갈기고 돈을 현혹된 큐비클 직원에 의해 쫓겨나지 않는 한 다른 모든 것은 실행 취소되거나 제대로 수행되지 않는다. 나는 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.
+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.
 
@@ -917,7 +889,7 @@ Can we save defining goals as a justification for the overhead of conventional s
 
 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.
 
-(임지나)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.
+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.
 
 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.