@@ -834,23 +834,48 @@ This suggests a reason for questioning the advantages of conventionally-managed
-> 김수연
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.
- 12조 박진호
내 친구는 많은 자원 수집은 기본적으로 방어적이라고 보고했다; 일단 네가 너의 팀원들과 기계들 그리고 사무실 공간을 가지고 있다면, 너는 그들을 동료 경영자들로부터, 동일한 자원에 대해 경쟁하는 동료 경영자들로부터, 그리고 제한된 공동기금의 가장 효율적인 사용을 할당하려고 노력하는 상위 계층으로부터 방어해야한다
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.
