The Cathedral and the Bazaar report	The pager mainly talk about two different development styles : the “cathedral” model of most of the commercial world versus and the “bazaar” model of the Linux world. And the author gave an example of his successful project “fetchmail” to support his point of view that “bazaar” style in the open-source community is very powerful and stable.	“Every good work of software starts by scratching a developer's personal itch” he author simply wants to receive and sent his email in his house , so he decided to start a project to implement the goal. This is the start of the successful project “fetchmail”. 	Firstly the author thinking about how to start to build a mail client : “Good programmers know what to write. Great ones know what to rewrite (and reuse)” , he searched the solutions of other people instead of simply start the coding to reusing the code and ideas of the other people.	When he started coding based on someone’s project , soon he encounter another project witch is better and professional , and can somehow resolve his problem. “Plan to throw one away; you will, anyhow. (Fred Brooks, The Mythical Man-Month, Chapter 11)” and he switched his project to the latter.	Without the author’s actually notice , the project has escalated , and he soon took on maintaining the entire project. “if you have right attitude , interesting problems will find you” . then carl noticed the author’s ability and passion about the project , so he decided to hand it to him. “when you lost interest in program , your last duty to it is to hand it off to a competent successor”.	So the author inherited the project , and most importantly , the users of the project. It’s very important to have users. “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging” 	The bazaar style it mainly about a group of users (as many as possible) work together to contribute to one project. So the more often the project releases , the more helpful other developers will be . “release early , release often. And listen to your customers” the users(customers) are actually use the project , so they are more likely to find a bug. As many as the users are , less bugs remains. “Given a large enough beta-tester and co-developer base ,  almost every problem will be characterized quickly and the fix obvious to someone”.	As for the programming style , “smart data structures and dumb code works a lot better than the other way around” when you have to choose between better data structure  and better code style, smart data structures should be the first choice. 	In the bazaar style , the beta testers are very important to the release of the project. “if you treat you beta-testers as if they are your most valuable resources , they will response by becoming your most valuable resources”. By doing this form the beginning of the project , the author get the reports of a quality most developers would kill for , often with good fixes attached. He got thoughtful criticism , fun mail , and intelligent features. “the next best thing to having good ideas is recognizing good ideas from your users , the latter the batter.”	Then the project (popclient) becomes fetchmail witch turned out to be a better project , and soon fetchmail grew up , have more and more users and developers , who continue contribute to fetchmail to make it better and better. Thanks to the bazaar style , the fetchmail have more and more users to maintain , and hardly have any bugs , so it becomes a very successful project.	The Cathedral and the Bazaar review
Merge pull request #44 from ninjahzw/master

The Cathedral and the Bazaar report