Master

group 12 merge request

README.md

@@ -821,7 +821,7 @@ Perhaps in the end the open-source culture will triumph not because cooperation
 
 ## 관리와 그 마지노선
 
-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.
+(최준영) 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년 발행된 성당과 시장 논문은 기꺼이 네트워크를 형성한 프로그래머/무정부주의자들이 기존의 폐쇠형 소프트웨어 체계의 세계를 압도하고 경쟁을 끝낸다는 비전으로 끝났습니다.
 
@@ -845,7 +845,7 @@ This suggests a reason for questioning the advantages of conventionally-managed
 
 이는 성당 방식과 시장 방식에 대한 나머지 논쟁과 무관하게 전통적으로 관리되는 소프트웨어 개발의 이점에 대한 질문에 이유를 제시합니다. GNU Emacs가 15년 동안 일관된 아키텍처 비전을 표현할 수 있거나 Linux와 같은 운영체제가 8년동안 급변한 하드웨어 및 플랫폼 기술을 통해 동일한 아키텍처 비전을 제시할 수 있거나, 또 만약 (실제로) 5년 이상의 기간 동안 잘 설계된 오픈소스 프로젝트가 많다면, 그렇다면 우리는 전통적으로 관리되는 개발이 우리를 사들이는데에 얼마나 많은 간접적 비용을 사용하고 있는지 궁금해 할 자격이 있습니다.
 
-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개이상의 다른 하드웨어 플랫폼에서 사람들은 쉽게 알 수 있듯이)