@@ -878,18 +878,33 @@ My friend reports that a lot of resource marshalling is basically defensive; onc
...
@@ -878,18 +878,33 @@ My friend reports that a lot of resource marshalling is basically defensive; onc
(박진호)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의 '공격적인' 측면을 자동으로 처리하는 경향이 있다. 사람들은 자신의 자원들을 오픈소스로 가져온다. 그리고 관습적인 의미에서, 사용자가 가져온 자원들을 '수비'해야만 할 의무를 가진 관리자는 필요하지 않다.
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.
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.
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%의 배치를 조직하는 데 대부분의 시간을 할애했고, 따라서 가장 유능한 프로그래머와 덜 유능한 프로그래머들 사이의 생산성 차이를 직접 관찰해 왔다.
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.
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.
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.
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.
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.
(유영우)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.
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.
