Corrected grammatical errors

README.md

@@ -1007,7 +1007,7 @@ In the mean time, however, the open-source idea has scored successes and found b
 
 [QR] Examples of successful open-source, bazaar development predating the Internet explosion and unrelated to the Unix and Internet traditions have existed. The development of the info-Zip compression utility during 1990–x1992, primarily for DOS machines, was one such example. Another was the RBBS bulletin board system (again for DOS), which began in 1983 and developed a sufficiently strong community that there have been fairly regular releases up to the present (mid-1999) despite the huge technical advantages of Internet mail and file-sharing over local BBSs. While the info-Zip community relied to some extent on Internet mail, the RBBS developer culture was actually able to base a substantial on-line community on RBBS that was completely independent of the TCP/IP infrastructure.  
 
-[QR] 인터넷의 폭발적 증가 이전에 발생하고 유닉스, 인터넷의 전통과는 관련없는 성공적인 오픈소스의 예시는 존재한다. 그러한 하나의 예는 1990-x1992년에 주로 DOS 머신을 위한 info-Zip 압축 유틸리티의 개발이다. 다른 예는 RBBS 게시판 시스템이다(또 DOS를 위한 것이다). 1983년에 시작되었고 인터넷 메일과 로컬 BBS를 통한 파일 공유가 더 큰 기술적인 장점이 있음에도 불구하고 현재(1999년 중반)까지 꽤 주기적인 배포가 있는 충분히 강한 커뮤니티가 발달되었다. info-Zip 커뮤니티는 어느 정도 인터넷 메일에 의존하게 된 반면에 실제로 RBBS 개발 문화는 TCP/IP 인프라와 완전하게 독립적으로 RBBS의 단단한 온라인 커뮤니티에 기반으로 할 수 있었다.
+[QR] 인터넷의 폭발적 증가 이전에 발생하고 유닉스, 인터넷의 전통과는 관련없는 성공적인 오픈소스의 예시는 존재한다. 그러한 하나의 예는 1990-x1992년에 주로 DOS 머신을 위한 info-Zip 압축 유틸리티의 개발이다. 다른 예는 RBBS 게시판 시스템이다(또 DOS를 위한 것이다). 1983년에 시작되었고 인터넷 메일과 로컬 BBS를 통한 파일 공유가 더 큰 기술적인 장점이 있음에도 불구하고 현재(1999년 중반)까지 꽤 주기적인 배포가 있는 충분히 강한 커뮤니티가 발달되었다. info-Zip 커뮤니티는 어느 정도 인터넷 메일에 의존하게 된 반면에 실제로 RBBS 개발 문화는 TCP/IP 인프라와 완전하게 독립적으로 RBBS의 단단한 온라인 커뮤니티에 기반할 수 있었다.
 
 [CV] That transparency and peer review are valuable for taming the complexity of OS development turns out, after all, not to be a new concept. In 1965, very early in the history of time-sharing operating systems, Corbató and Vyssotsky, co-designers of the Multics operating system, wrote
 
@@ -1018,11 +1018,11 @@ In the mean time, however, the open-source idea has scored successes and found b
 
 [JH] John Hasler has suggested an interesting explanation for the fact that duplication of effort doesn't seem to be a net drag on open-source development. He proposes what I'll dub **Hasler's Law**: the costs of duplicated work tend to scale sub-quadratically with team size—that is, more slowly than the planning and management overhead that would be needed to eliminate them.
 
-[JH] John Hasler는 노력의 중복이 오픈소스 개발에 걸림돌이 되지 않는 것처럼 보인다는 사실에 대한 흥미로운 설명을 제시했다. 그는 내가 **Hasler의 법칙**이라고 이름 붙인 것을 제안했다: 중복된 작업의 비용은 팀 규모에 따라 부차적으로 증가되는 경향이 있다. 이 비용은 제거될 필요가 있는 계획하고 관리하는 오버헤드보다 더 느리게 증가한다.
+[JH] John Hasler는 노력의 중복이 오픈소스 개발에 걸림돌이 되지 않는 것처럼 보인다는 사실에 대한 흥미로운 설명을 제시했다. 그는 내가 **Hasler의 법칙**이라고 이름 붙인 것을 제안했다: 중복된 작업의 비용은 팀 규모에 따라 부차적으로 증가되는 경향이 있다. 이 비용은 제거될 필요가 있는 계획과 관리의 오버헤드보다 더 느리게 증가한다.
 
 This claim actually does not contradict Brooks's Law. It may be the case that total complexity overhead and vulnerability to bugs scales with the square of team size, but that the costs from duplicated work are nevertheless a special case that scales more slowly. It's not hard to develop plausible reasons for this, starting with the undoubted fact that it is much easier to agree on functional boundaries between different developers' code that will prevent duplication of effort than it is to prevent the kinds of unplanned bad interactions across the whole system that underly most bugs.  
 
-사실 이 주장은 Brooks의 법칙과 모순되지 않는다. 전체 복잡도 오버헤드와 버그에 대한 취약성은 팀 크기의 제곱으로 증가하지만 그럼에도 불구하고 중복 작업에 따른 비용은 더 느리게 증가하는 특수한 경우일 수 있다. 이것에 대한 그럴듯한 이유를 드는 것은 어렵지 않다. 대부분의 버그들이 있는 시스템 전반적으로 계획되지 않은 나쁜 상호작용을 막는 것에 비해 노력의 중복을 예방하는 다른 개발자들의 코드들 사이의 기능적 경계를 합의하는 것이 훨씬 쉬운 일임은 의심할 여지가 없는 사실로 부터 시작할 수 있다.
+사실 이 주장은 Brooks의 법칙과 모순되지 않는다. 전체 복잡도 오버헤드와 버그에 대한 취약성은 팀 크기의 제곱으로 증가하지만 그럼에도 불구하고 중복 작업에 따른 비용은 더 느리게 증가하는 특수한 경우일 수 있다. 이것에 대한 그럴듯한 이유를 드는 것은 어렵지 않다. 대부분의 버그들이 있는 시스템 전체에서 계획되지 않은 나쁜 상호작용을 막는 것에 비해 노력의 중복을 방지하는 다른 개발자들의 코드들 사이의 기능적 경계를 합의하는 것이 훨씬 쉬운 일임은 의심할 여지가 없다는 사실로 부터 시작할 수 있다.
 
 The combination of Linus's Law and Hasler's Law suggests that there are actually three critical size regimes in software projects. On small projects (I would say one to at most three developers) no management structure more elaborate than picking a lead programmer is needed. And there is some intermediate range above that in which the cost of traditional management is relatively low, so its benefits from avoiding duplication of effort, bug-tracking, and pushing to see that details are not overlooked actually net out positive.