Update

bazaar.md

@@ -6,4 +6,4 @@ Watch out: Raymond used to be an oldschool [hacker](hacking.md) who however, lik
 
 { The online version is not very long, the writing style is good and there are nice, catchy observations about software development, however it's still quite shitty, towards the end I was falling asleep, only the capitalist trigger words kept me awake eventually. But there are some nice things, like "plan to throw one away", i.e. when you want to write something, you'll probably have to write it once badly, by which you really understand the issue, then you throw it away and implement it again, this time well. ~drummyfish }
 
-Here is a small **summary**: ESR used to believe software beyond some complexity threshold (e.g. [operating system](os.md) kernel or a big text editor) has to be developed mainly by a small team that closely communicates, carefully fixes bugs that users report and releases stable versions once in relatively long time -- yes, even if the software is [FOSS](foss.md) and development is transparent. This is called the *Cathedral* method as the development is similar to the careful, highly centrally planned building of a cathedral -- one example was e.g. [gcc](gcc.md) (and any proprietary software, as they basically have no other option). However after seeing [Linux](linux.md) (a very complex project) being developed by great many people in a very decentralized manner, with the central coordinator doing relatively little work, and having very short release cycles (even of buggy, unstable versions), he concluded it can work differently -- he called this the *Bazaar* method, i.e. one that looks a bit [chaotic](chaos.md) at first, but which statistically still converges to establishing good design in the end. He says the biggest invention of [Linus Torvalds](torvalds.md) isn't Linux but its development model. He examines how and why it works because he sees it as the superior method, and he also tests the method on his own project ([fetchmail](fetchmail.md)) with which he immediately sees a great success. He notes several things, e.g. the following. Users being at the same time programmers (codevelopers) and vice versa is key because firstly programmers really care about what they write (because they use it) and secondly we get nice bug reports (in programmer terms). "Given enough eyeballs, all bugs are shallow" says that with many users/programmers basically all bugs get spotted and fixed quickly, which is helped by the rapid release cycles -- if someone fixes it quickly, others see it's fixed and stop working on their more complicated fixes. This kind of parallelizes [debugging](debugging.md) (and also other things such as design change exploration). Quick releases reward contributors, they see their fixes immediately, contributors get motivated ("Treat your testers as your most valuable resource and they will respond by becoming your most valuable resource."), even the "work no one wants to do" gets done. Bazaar project needs several things. Firstly good Internet (that's why Linux coincided with cheap access to Internet). Secondly it can't be started from scratch, someone has to make some basic project basically alone, and it should be some truly honest project (not something that just aims for profit), usually starting with a programmer "scratching his [own itch](own_itch.md)" -- it's enough to make a project that shows promise so that people start jumping in. The ["leader"](bdfl.md) doesn't have to be genius but he has to be able to recognize good design choices of contributors and he must be "good with people". Then he goes on to compare it to free market and other crap, he basically concludes managers are useless and they just pretend to be useful :D
+Here is a small **summary**: ESR used to believe software beyond some complexity threshold (e.g. [operating system](os.md) kernel or a big text editor) has to be developed mainly by a small team that closely communicates, carefully fixes bugs that users report and releases stable versions once in relatively long time -- yes, even if the software is [FOSS](foss.md) and development is transparent. This is called the *Cathedral* method as the development is similar to the careful, highly centrally planned building of a cathedral -- one example was e.g. [gcc](gcc.md) (and any proprietary software, as they basically have no other option). However after seeing [Linux](linux.md) (a very complex project) being developed by great many people in a very decentralized manner, with the central coordinator doing relatively little work, and having very short release cycles (even of buggy, unstable versions), he concluded it can work differently -- he called this the *Bazaar* method, i.e. one that looks a bit [chaotic](chaos.md) at first, but which statistically still converges to establishing good design in the end. He says the biggest invention of [Linus Torvalds](torvalds.md) isn't Linux but its development model. He examines how and why it works because he sees it as the superior method, and he also tests the method on his own project ([fetchmail](fetchmail.md)) with which he immediately sees a great success. He notes several things, e.g. the following. Users being at the same time programmers (codevelopers) and vice versa is key because firstly programmers really care about what they write (because they use it) and secondly we get nice bug reports (in programmer terms). "Given enough eyeballs, all bugs are shallow" (*Linus's law*) says that with many users/programmers basically all bugs get spotted and fixed quickly, which is helped by the rapid release cycles -- if someone fixes it quickly, others see it's fixed and stop working on their more complicated fixes. This kind of parallelizes [debugging](debugging.md) (and also other things such as design change exploration). Quick releases reward contributors, they see their fixes immediately, contributors get motivated ("Treat your testers as your most valuable resource and they will respond by becoming your most valuable resource."), even the "work no one wants to do" gets done. Bazaar project needs several things. Firstly good Internet (that's why Linux coincided with cheap access to Internet). Secondly it can't be started from scratch, someone has to make some basic project basically alone, and it should be some truly honest project (not something that just aims for profit), usually starting with a programmer "scratching his [own itch](own_itch.md)" -- it's enough to make a project that shows promise so that people start jumping in. The ["leader"](bdfl.md) doesn't have to be genius but he has to be able to recognize good design choices of contributors and he must be "good with people". Then he goes on to compare it to free market and other crap, he basically concludes managers are useless and they just pretend to be useful :D