The Cathedral and the Bazaar (the cathedral and the Bazaar) reading notes

The cathedral and the Bazaar the cathedral and the Bazaar, a computer book not like computer

As long as the eyes, bugs easy to find

Hacker Open Source: product-related abundance, win respect not because of possession of what, but contribute to what
If you take it as a resource, it will be your precious resource.

If you don't want to do it, it's a good idea to find a suitable successor and know when to close your hands.
"I am a very lazy person, others work, I have to honor" Linus

If you take a serious attitude, chances will come naturally. Do something worthwhile, do it all the time, and you'll reap it sooner or later. Although the value of labor comes from scarcity

Development software does not have to start from scratch, there is a foundation, although the code will be replaced sooner or later, but it would be a good scaffold

Early release, multi-release. Encourage user feedback to collaborate with developers on the attitude and user interaction, there will be a scarce bug to find resources

No user willing to wait half a year for a bug

Python,perl,c,c++,java
Perl code can be used without, but to be able to read the code

Consider the problem in a way that is out of the language

Learning programming languages, not just learning tools, but thinking.

Key summary of the original text: 1, every good work of the software starts by scratching a developer ' s personal itch. Every good software cause is a scratch on the developer's itch. 2, good programmers know what to write. Great ones know to rewrite (and reuse). Good programmers know what to write. Great programmers know what to rewrite (and reuse). 3, "plan to throw one away;you will,anyhow" (Fred brooks,the mythical man-month,chapter 11) "plans to throw away A; In any case you will throw away one." (Fred Brock, 11th chapter of the People's Month myth) 4, if you have the right attitude,interesting problems will find you. If you are in the correct attitude, the interesting question is to find you. 5, when you lose interest in a program,your the last duty to it was to hand it off to a competent successor. If you lose interest in a project, your final responsibility is to give it to a competent successor. 6, treating your users as Co-developers is your least-hassle route to rapid code improvement and effective debugging. Put the user like a partner The best Channel 7, Release early that leads to rapid improvement code and effective commissioning. Release often. And listen to your customers. Early release. Often published. Listen to the user's comments. 8, Given a large enough beta-tester and co-developer base,almost every problem would be characterized quickly and the fix OB Vious to someone. If the beta testers and co-developer groups are large enough, almost every problem will be quickly revealed and someone can easily solve it. 9. Smart Data StRuctures and Dumb code works a lot better than the other way around. Clever data structures and stupid code are much better than the reverse. 10, if you treat your beat-testers as if they ' re your most valuable resource,they would respond by becoming your most VALUAB Le resource. If you treat your beta testers with "the most valuable resources", they will respond with the "Most valuable resource". 11, the next best thing to have good ideas is recongizing good ideas from your users. Sometimes the latter is better. After having a good idea is to recognize a good idea from the user. Sometimes the latter is better. 12. Often,the most striking and innovative solutions come from realizing, your concept of the problem was wrong. Breakthrough and Innovation Often comes from the realization that you have mistaken the model of the problem. 13, "Perfection (in design) are achieved not when there are nothing more than add,but rather when there are nothing more than take Away. "" When the design is perfect, it can not be increased, but it can be reduced less. " 14. Any tool should is useful in the expected way,but a truly great tool lends itself to uses you never expected To the expected effect, but a really great tool will bring you the usefulness you never expected. 15. When writing gateway software of any kind,take pains to disturb the data stream as little as Possible-and never throW away information unless the recipient forces you to! when writing any gateway software, take a bit of effort not to interfere with traffic-unless the user forces you, never throw away any information! 16. When your language is nowhere close turing-complete,syntactic sugar can be your friend. It can be helpful to add flavor to the grammar when your language is far from the Turing's exhaustion. 17, A security system is only as secure as its secret. Beware of pseudo-secrets. The security of a security system depends on the security of its conservative secrets. Beware of false secrets. 18, to solve an interesting problem,start by finding a problem that's interesting to you. In order to solve an interesting problem, first find a question you think is interesting. 19, provided the development coordinator have a communications medium at least as good as the Internet,and Without coercion,many heads is inevitably better than one. If the development coordinator has a communication medium that is at least as good as the internet and knows how to lead without coercion, multiple minds are inevitably superior to a single mind.
I read this article a few years ago when I was a programmer, but I didn't feel much at all, but it just inspired me to do what I wanted to do in the open source world. Because is to do C # reason, at that time found a lot of C # open source software, want to find an opportunity to participate in, finally selected DNN. 06 did the dnnfamily website to carry out DNN technology promotion work, and provide DNN host services, and later because of the work of the cause of this thing will be nothing. This reread, less the impulse of the year, more practical thinking. My current job is enterprise IT department management, involving software development management work, the development team last year, the transformation of agile development. Therefore, I want to combine the enterprise internal project software development Management and agile development of two aspects of my comment on this article.

First, the Imagination "Enterprise internal system Open source"
Enterprise internal software projects often involve business processes, not open to the outside, and because of the differences in business, open source after the value of other users is not small. How can enterprise internal software projects enjoy the benefits of "fair"? I have several ideas:
1, the middleware, public components open source, this type of code does not involve specific business, and strong reusability, can bring value for more people.
2, the enterprise to share the code, everyone can access all the code, record everyone's contribution as a means of encouragement.
3, as far as possible the application of open source systems, middleware, for employees to create exposure to open source projects opportunities.
4, learn from good practices, such as "early release." Often published. Listen to the user's comments. such as

Second, "Open source" and "agile", engineers-based software development model
In the past two years agile in the domestic unusually hot, we also had the honor to introduce the agile development in 11 (Yuan Bin teacher is our Enlightenment teacher). Engineers are a special kind of people, they have a wide range of interests, but they can focus on what they like, they like to hide their anger, but they want to be recognized; "Give me a fulcrum, I can pry the Earth", they believe that through their own hands they can achieve any miracle; they have their own beliefs, They crave perfection.
It is the nature of engineers to have countless people who have not met to selflessly contribute their time and code to open source projects. They can't stand being imperfect, they want to make miracles, they want to be recognized. "Open source" and "agile" are successful and popular because they create "engineers ' Paradise".

Eric Raymond has a famous article "The Cathedral and the Bazaar" (the Cathedral and the Bazaar).

He said that the world's buildings can be divided into two kinds: a market, open every day there, from scratch, from small to large, there is a cathedral, several generations of painstaking work, decades to build, put into use.

When you build a new building, you can use the model of the market or the cathedral. Generally speaking, the market is characterized by open construction, low cost, short cycle, mediocre quality; The cathedral is characterized by closed construction, high cost, long cycle and excellent quality.

Eric Raymond asked a question, is it possible to build a cathedral in the form of a bazaar?

I read this article many years ago, and when I discussed it with my friends in email last week, I thought of it all of a sudden.

Our problem is that there is a project, plan A is carefully prepared and then put into use, Plan B is to open the semi-finished products first, and then gradually improve. It made me think of the metaphor of "the Cathedral and the Bazaar".

We want to build a cathedral, but there's only one market right now.

I found out Eric Raymond's article and reread it, and a lot of vague impressions suddenly became clear. In the end is a classic article Ah, although written 10 years ago, but a lot of questions he took into account.

He said that the market to become a cathedral, there are several prerequisites:

1) You cannot build a bazaar from scratch, you must first have an original project. (It's fairly clear that one cannot code from the ground to Bazaar style.)

2) Your original project can be defective, but it must be able to run. (It can be crude, buggy, incomplete, and poorly documented.) What it must does is run.)

3) You must show the user a viable prospect and let potential collaborators believe it will become a truly beautiful thing in the foreseeable future. (When you start community-building, what are need to being able to present are a plausible promise, and convince potential co- Developers that it can is evolved into something really neat on the foreseeable future.)

4) The host of the project is not necessarily a genius, but he must be able to identify the good ideas of others. (It isn't critical that the coordinator was able to originate designs of exceptional brilliance, but it's absolutely crit ical that the coordinator is able to recognize good design ideas from others.)

5) The host of the project must have good interpersonal, communication skills and personality charm. This will attract others, make others interested in what you are doing, and be willing to help you. (A Bazaar Project coordinator or leader must has good people and communications skills.)

4.

These are some of the prerequisites, Eric Raymond also summarizes some of the conditions for success.

1) The project must first of all be of interest to you, but it will ultimately be useful to other people.

2) Use the user as a partner.

3) as soon as possible and constantly make improvements, listen to the views of users.

4) A robust structure is far more important than an ingenious design. In other words, the structure is the first, the function is the second bit.

5) Maintain the simplicity of the project. When the design is perfect, it is not impossible to add more things, but can no longer reduce the things.

5.

Eric Raymond The original purpose of this article is to analyze the success of Linux. Why did an undergraduate's amateur work finally become one of the most popular operating systems in the world? How did a humble bazaar become a magnificent cathedral? Is this process replicable and generalized?

This, he argues, is the power of openness. An open project, if well managed and operated, can achieve much greater success than an equivalent closed project.

He sees the rivalry between the cathedral and the Bazaar:

I think the future will be more of the people who say goodbye to the cathedral and embrace the bazaar.

This is not to say that personal vision and talent are no longer important, but in my view, the future of success will only start from their own vision and talent to work, and then through effective community cooperation, and constantly magnified.

The open culture will eventually win, perhaps not because "openness" is morally right, or "closed" morally wrong, but only because open cooperation can put more than a few orders of technical work on one issue, and the closed world cannot win such competition.

The Cathedral and the Bazaar (the cathedral and the Bazaar) reading notes