Master
Compare changes
+ 44
− 5
@@ -840,21 +840,34 @@ Perhaps in the end the open-source culture will triumph not because cooperation
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.
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.
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.
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).
-> 김수연 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개이상의 다른 하드웨어 플랫폼에서 사람들은 쉽게 알 수 있듯이)
@@ -929,30 +942,56 @@ This answer usually travels with a claim that the open-source community can only
(유영우)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.
만약 기존의 폐쇄적이고, 관리도가 높은 소프트웨어 개발 방식이 지루함을 유발하는 일종의 문제들에 의해서만 옹호된다면, 그것은 각 개별 애플리케이션 영역에서 실행 가능한 상태로 유지될 것이다. 아무도 그러한 문제들이 정말로 흥미롭다고 생각하지 않고 다른 누구도 그 문제를 해결할 방법을 찾지 않는 한 말이다.em. 왜냐하면 '지루한' 소프트웨어를 위한 오픈소스 경쟁이 있는 순간에, 고객들은 그것이 마침내 문제 자체에 대한 매혹 때문에 문제를 해결하려고한 누군가에 의해 태클이 걸어질 것임을 알게 될 것이다. 그것은 다른 종류의 창조적인 작업에서와 마찬가지로 소프트웨어에서, 돈 자체보다 훨씬 더 효과적인 동기부여가 된다.
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.
(임지나)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.
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.
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.