diff --git a/README.md b/README.md index 031e7d0bd0aedc0ba21a3825ccc91078736f92e4..0ec61330863a4016d773cd34f6c9ae43475c1b70 100644 --- a/README.md +++ b/README.md @@ -950,7 +950,7 @@ In the mean time, however, the open-source idea has scored successes and found b 반면에 볼만한 기회가 될 수도 있다. 월스트리트 등의 첫 반응은 조심스럽지만 긍정적이었다. 우리 자신을 증명할 기회를 얻은 것이다. 만일 넷스케이프가 이번 행보로 상당한 양의 시장점유율을 끌어올린다면 컴퓨터 산업에서 오래 전에 이루어졌어야 했던 혁명을 시작하게 되는 것이다. 다음 한 해는 매우 교육적이며 재미있는 한 해가 될 것이다. ## Notes - +[한지은] [JB] In Programing Pearls, the noted computer-science aphorist Jon Bentley comments on Brooks's observation with ``If you plan to throw one away, you will throw away two.''. He is almost certainly right. The point of Brooks's observation, and Bentley's, isn't merely that you should expect first attempt to be wrong, it's that starting over with the right idea is usually more effective than trying to salvage a mess. [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. @@ -967,7 +967,8 @@ The combination of Linus's Law and Hasler's Law suggests that there are actually Above that, however, the combination of Linus's Law and Hasler's Law suggests there is a large-project range in which the costs and problems of traditional management rise much faster than the expected cost from duplication of effort. Not the least of these costs is a structural inability to harness the many-eyeballs effect, which (as we've seen) seems to do a much better job than traditional management at making sure bugs and details are not overlooked. Thus, in the large-project case, the combination of these laws effectively drives the net payoff of traditional management to zero. -[HBS] The split between Linux's experimental and stable versions has another function related to, but distinct from, hedging risk. The split attacks another problem: the deadliness of deadlines. When programmers are held both to an immutable feature list and a fixed drop-dead date, quality goes out the window and there is likely a colossal mess in the making. I am indebted to Marco Iansiti and Alan MacCormack of the Harvard Business School for showing me me evidence that relaxing either one of these constraints can make scheduling workable. +--- +[윤준석][HBS] The split between Linux's experimental and stable versions has another function related to, but distinct from, hedging risk. The split attacks another problem: the deadliness of deadlines. When programmers are held both to an immutable feature list and a fixed drop-dead date, quality goes out the window and there is likely a colossal mess in the making. I am indebted to Marco Iansiti and Alan MacCormack of the Harvard Business School for showing me me evidence that relaxing either one of these constraints can make scheduling workable. One way to do this is to fix the deadline but leave the feature list flexible, allowing features to drop off if not completed by deadline. This is essentially the strategy of the "stable" kernel branch; Alan Cox (the stable-kernel maintainer) puts out releases at fairly regular intervals, but makes no guarantees about when particular bugs will be fixed or what features will beback-ported from the experimental branch. @@ -983,7 +984,8 @@ It may well turn out to be that the process transparency of open source is one o [IN] An issue related to whether one can start projects from zero in the bazaar style is whether the bazaar style is capable of supporting truly innovative work. Some claim that, lacking strong leadership, the bazaar can only handle the cloning and improvement of ideas already present at the engineering state of the art, but is unable to push the state of the art. This argument was perhaps most infamously made by the Halloween Documents, two embarrassing internal Microsoft memoranda written about the open-source phenomenon. The authors compared Linux's development of a Unix-like operating system to ``chasing taillights'', and opined ``(once a project has achieved "parity" with the state-of-the-art), the level of management necessary to push towards new frontiers becomes massive.'' -There are serious errors of fact implied in this argument. One is exposed when the Halloween authors themseselves later observe that ``often [...] new research ideas are first implemented and available on Linux before they are available / incorporated into other platforms.'' +--- +[박현경]There are serious errors of fact implied in this argument. One is exposed when the Halloween authors themseselves later observe that ``often [...] new research ideas are first implemented and available on Linux before they are available / incorporated into other platforms.'' If we read ``open source'' for ``Linux'', we see that this is far from a new phenomenon. Historically, the open-source community did not invent Emacs or the World Wide Web or the Internet itself by chasing taillights or being massively managed—and in the present, there is so much innovative work going on in open source that one is spoiled for choice. The GNOME project (to pick one of many) is pushing the state of the art in GUIs and object technology hard enough to have attracted considerable notice in the computer trade press well outside the Linux community. Other examples are legion, as a visit to Freshmeat on any given day will quickly prove. @@ -1007,15 +1009,23 @@ Watch that source and Freshmeat for one month. Every day, count the number of re Thirty days later, total up both figures. +---- +(김윤환) The day I wrote this, Freshmeat carried twenty-two release announcements, of which three appear they might push state of the art in some respect, This was a slow day for Freshmeat, but I will be astonished if any reader reports as many as three likely innovations a month in any closed-source channel. +내가 이글을 쓴 날, Freshmeat은 22 개의 출시 발표를했는데, 그중 3 개는 어떤면에서 최첨단 기술을 밀어 붙이는 것 같았습니다. 비공개 소스 채널에서 한 달에 혁신 가능성이 있습니다. [EGCS] We now have history on a project that, in several ways, may provide a more indicative test of the bazaar premise than fetchmail; EGCS, the Experimental GNU Compiler System. +이제 우리는 fetchmail보다 시장 전제에 대한 더 많은 지표 테스트를 제공 할 수있는 여러 가지 방법으로 프로젝트에 대한 역사를 가지고 있습니다. 실험용 GNU 컴파일러 시스템 인 EGCS. This project was announced in mid-August of 1997 as a conscious attempt to apply the ideas in the early public versions of The Cathedral and the Bazaar. The project founders felt that the development of GCC, the Gnu C Compiler, had been stagnating. For about twenty months afterwards, GCC and EGCS continued as parallel products—both drawing from the same Internet developer population, both starting from the same GCC source base, both using pretty much the same Unix toolsets and development environment. The projects differed only in that EGCS consciously tried to apply the bazaar tactics I have previously described, while GCC retained a more cathedral-like organization with a closed developer group and infrequent releases. +이 프로젝트는 1997 년 8 월 중순에 The Cathedral and the Bazaar의 초기 공개 버전에 아이디어를 적용하려는 의식적인 시도로 발표되었습니다. 프로젝트 창립자들은 GNU C 컴파일러 인 GCC의 개발이 정체되었다고 느꼈습니다. 그 후 약 20 개월 동안 GCC와 EGCS는 동일한 인터넷 개발자 집단에서 시작하여 동일한 GCC 소스 기반에서 시작하여 거의 동일한 Unix 도구 세트와 개발 환경을 사용하는 병렬 제품으로 계속되었습니다. 프로젝트는 EGCS가 이전에 설명한 바자 전략을 의식적으로 적용하려고 시도한 반면 GCC는 폐쇄 된 개발자 그룹과 드물게 출시되는 성당과 같은 조직을 유지한다는 점에서만 다릅니다. + +This was about as close to a controlled experiment as one could ask for, and the results were dramatic. Within months, the EGCS versions had pulled substantially ahead in features; better optimization, better support for FORTRAN and C++. Many people found the EGCS development snapshots to be more reliable than the most recent stable version of GCC, and major Linux distributions began to switch to EGCS.---// +이것은 사람들이 요구할 수있는 통제 된 실험에 가깝고 그 결과는 극적이었습니다. 몇 달 만에 EGCS 버전은 기능면에서 상당히 앞섰습니다. 더 나은 최적화, FORTRAN 및 C++에 대한 더 나은 지원과 많은 사람들이 EGCS 개발 스냅 샷이 가장 최근의 안정된 GCC 버전보다 더 안정적이라는 것을 알게되었고 주요 Linux 배포판이 EGCS로 전환되기 시작했습니다. -This was about as close to a controlled experiment as one could ask for, and the results were dramatic. Within months, the EGCS versions had pulled substantially ahead in features; better optimization, better support for FORTRAN and C++. Many people found the EGCS development snapshots to be more reliable than the most recent stable version of GCC, and major Linux distributions began to switch to EGCS. +--- -In April of 1999, the Free Software Foundation (the official sponsors of GCC) dissolved the original GCC development group and officially handed control of the project to the the EGCS steering team. +(장동훈) In April of 1999, the Free Software Foundation (the official sponsors of GCC) dissolved the original GCC development group and officially handed control of the project to the the EGCS steering team. [SP] Of course, Kropotkin's critique and Linus's Law raise some wider issues about the cybernetics of social organizations. Another folk theorem of software engineering suggests one of them; Conway's Law—commonly stated as ``If you have four groups working on a compiler, you'll get a 4-pass compiler''. The original statement was more general: ``Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.'' We might put it more succinctly as ``The means determine the ends'', or even ``Process becomes product''.