The cathedral and the bazaar

from Wikipedia, the free encyclopedia
This article or the following section is not adequately provided with supporting documents ( e.g. individual evidence ). Information without sufficient evidence could be removed soon. Please help Wikipedia by researching the information and including good evidence.

The Cathedral and the Bazaar ( English "The Cathedral and the Bazaar" ) is a well-known essay on open source software . It was written by Eric S. Raymond , who presented it to the public for the first time at the fourth International Linux Congress on May 22, 1997 in Würzburg . In it he describes the advantages and disadvantages of the development method of the bazaar , which has meanwhile become widespread in the open source area, compared to the previously common method he calls the cathedral .

cathedral

With the cathedral model , the source code of a program is not made available to the public at all, or only with every new software release. In the development periods between releases, new source code can only be programmed by a single developer group or a single developer who is typically employed by a software manufacturer . In this case, the source code is often treated as a trade secret and not published at all. The way in which a cathedral is built symbolizes the traditional way of development: a chief architect oversees a hierarchically organized group of initiated specialists. Only they can and may contribute to the work. There is a blueprint and when it is completed the building is finished.

bazaar

With the bazaar model , on the other hand, the source code can be viewed on the Internet at any stage. The development of many open source programs follows this pattern. According to the author, this model has proven to be more successful than the cathedral model: many people sell their wares in a bazaar without one being more powerful than the other. This is also how large projects are coordinated; the best example is the Linux kernel , which is maintained by Linus Torvalds . There is usually a person who ensures that market law is observed. In addition, the bazaar is made up of many small parts - if one of the stands is not represented, the bazaar as such is still complete.

Transferred to software development are the dealers who offer their goods for sale, the programmers who add new program parts or make improvements and want to integrate them into the project; the guardian of market law, in turn, corresponds to the maintainer of a software project. What should actually end in a shambles, grows into big software through self-organization .

You can never say that the software is "ready". Raymond therefore speaks of the fact that the software industry is not a manufacturing, but a service industry.

Development model

The essay contains 19 guidelines on how good open source software can be programmed:

  1. All good software is written by a developer who has a personal problem to solve.
  2. Good programmers know what to write. Brilliant know what to rewrite (and what to reuse).
  3. Plan to ditch a version; you will do it anyway.
  4. If you have the right mindset, you will find interesting problems.
  5. If you lose interest in a program, it is your responsibility to hand it over to a competent successor.
  6. Viewing your users as co-programmers is the easiest route to faster improvement and efficient debugging .
  7. Post early. Publish often. And listen to the users.
  8. With a sufficiently large group of beta testers and co-developers, almost every problem is quickly identified and the solution is found by someone.
  9. Smart data structures and simple code (in the original: "dumb code") work much better than the other way around.
  10. If you treat your beta testers like your most valuable resource, they will be.
  11. Almost as good as having good ideas of your own is recognizing good ideas from users. Sometimes the latter is better.
  12. Most of the time, the brilliant solutions emerge from the knowledge that the problem has been misunderstood.
  13. Perfection (in design) is not achieved when nothing more can be added, but when nothing can be removed.
  14. Every tool should work as expected. But a really good tool enables uses you never thought of.
  15. When you write interface code, prevent the data stream from being changed at all costs - and only discard something if the recipient requests it.
  16. If your programming language isn't anywhere near Turing-complete , syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Avoid pseudo-secrets.
  18. To solve an interesting problem, find one.
  19. With sufficiently good communication, such as on the Internet, and leadership without coercion, many heads are always better than one.

See also

Web links