Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Webliography of the early critique of  "The Cathedral and the Bazaar"

This webliography contains paper that were available on the Net before October 1999. Some (but not all, see comments by Dave Winer to which ESR responded, but forgot to include them into the list) of comments are cited in CatB  section "Commentary and Argument":

Forrest J. Cavalier III has attempted to elaborate some of CatB's central ideas in Some Implications of Bazaar Size. Randy Boring has replied.

Clay Shirky has expanded on the value of rapid evolution and the design of systems that encourage it in an excellent paper, In Praise of Evolvable Systems; also in View Source: Lessons from the Web's Massively Parallel Development

The first critique of this paper to appear, When a Bazaar is Not a Bazaar, was thought-provoking but (IMO) basically wrongheaded. There is better commentary available, and a very thoughtful critique in Beyond the Cathedral, Beyond The Bazaar. The Linux Storm attempts to situate this paper within a larger analysis.

Below is the list of the commentaries that IMHO provide an important insight into the flaws of CatB and can contribute to the understanding of OSS as a social movement:

Allman Critique Beyond the Cathedral, Beyond The Bazaar Critique by Francois-Rene Rideau

When a Bazaar is no Longer a Bazaar

Open Source Software Causing More Harm Than Good
CWareWhite Paper Comments on Cathedrals and Bazaars  by Dave Winer Comments by Chuck Cranor Halloween Papers Some Implications of Bazaar Size
(not really critique)

Allman's Critique

[Dec. 11, 1999] TheStandard.com ARTICLE DISPLAY[roundtable with Eric Allman, Richard Stallamn and Eric Raymond, Feed, February 05, 1999] -- I found this important paper rather late, after I finished the second paper; otherwise my argumentation would be stronger and some points of my paper could be made clearer.

FEED: The Cathedral and the Bazaar makes a convincing argument in favor of "co-operative" software development – the bazaar – as opposed to proprietary, top-down processes – the cathedral. But there are evident limitations to the bazaar model – how do you attract and motivate strictly volunteer programmers? Is "egoboo," as Eric calls it, enough to get crack talent?

ALLMAN: In my experience, the "cathedral" and the "bazaar" are endpoints on a continuum, and neither really works well in its pure form. Successful bazaar products have a "pope" of some sort, an arbiter of good taste, if nothing else. This leader may be a small group (such as the Apache core team) or an individual (such as Linus Torvalds), but without a person or small team providing focus, such projects tend to splinter.

The bazaar model can fail when software authors graduate or change jobs or just get bored. There isn't always the stick-to-it ethos that a company can engender. But the cathedral has its own set of problems. Companies may fail, cut off low-performing product lines or be acquired by companies that chop out competing products, which leaves customers in the lurch.

I'm hoping that the hybrid model will give us the best of both worlds. As Eric Raymond has observed, we need real marketing in order to get into commodity markets, and the pure open-source community hasn't been good at that. Hybrids like Red Hat, Scriptics and Sendmail can continue to give away the source code to their core products and still have sufficient marketing dollars to get noticed by the folks in corner offices. Even the most dedicated crack open-source developers like to get paid in rent- paying-dollars as well as "egoboo."

RAYMOND: It's just that we don't need more than one open-source C compiler, one open-source network OS and so on. Hackers tend to seek novelty, not copycat projects.

ALLMAN: I agree that hackers seek novelty as a tendency, but one of the great joys of open-source code is that groups can fork off variants and compete without having to start from square one. Or to use an old quote, we can stand on each other's shoulders instead of each other's toes.

There are many open-source mail-user agents available, many mail servers, several TCP stacks, a bunch of BSD distributions, multiple scripting languages, at least two popular text editors, countless window managers and so forth. Sorry, Eric, I don't think this argument flies.

FEED: Eric, what prompted you to move from the bazaar model to the hybrid you've now got with Sendmail, a more cathedral-like private company?

ALLMAN: Sendmail had gotten to the point where, even with a team of volunteers, it was taking more time to support and enhance it than I had time to give. I tried to find some alternate funding method that would permit me to work on it full time, but that never worked out. This was a way to make sure that our software moved forward without sacrificing the openness of it. I'm not sure that it is appropriate to say that Sendmail (the company) has made Sendmail (the product) more cathedral-like. Most companies behave this way, yes, but

I don't think this is inevitable. Look at it this way: We are giving out the source code. If you don't like what we are doing, you can write us off and do it yourself. Thus, we have an incredible incentive to work closely with our customers. We have a huge number of potential "competitors," and hence have every reason to avoid descent into arrogance. It keeps us honest.

STALLMAN: Allman's message is based on a peculiar assumption that identifies the "cathedral" with companies and the "bazaar" with noncommercial projects.

The cathedral and bazaar are two ways of organizing a team to work together. Noncommercial free software projects have extensively used both methods, as well as points in between, and companies developing free software can do likewise. Both the cathedral and the bazaar are approaches for developing free software; choosing between them is a technical matter.

There have always been people who contribute to free software and also write nonfree software – but in the past, they generally did not try to link these two activities. Hybrid companies do just the opposite: They strive to link their free and nonfree software activities, hoping that the favorable opinion their free software deserves will rub off on their nonfree proprietary software products.

Typically, the proprietary software is designed to work with or add to free software, and the company markets to free software users. Their activity promotes the idea that once you have finally installed a free operating system, once you finally have the freedom that the GNU Project has worked for 15 years to make possible, you should clap some chains on to have additional convenience.

Companies describe these products as "value added," which assumes certain values are esteemed. I have different values, so I call these programs "freedom-subtracted packages." Be assured, they won't get a chance to subtract any freedom on my computer.

FEED: The free Sendmail software, according to estimates, is already installed on 60 percent to 80 percent of mail servers. Why would a company that has the free Sendmail already working fine purchase the commercial versions, Sendmail Pro or Sendmail NT? How do you convince them to switch?

ALLMAN: Well, the NT product has an easy answer. Sendmail isn't yet available for free on NT, and companies often like to run the same software on all their platforms. Sendmail Pro has a more subtle answer. The Internet has been exploding, and there just aren't enough experienced system administrators to go around. Paying a relatively small amount for some software that makes it easier to manage your servers is a good trade-off in many cases. In some very real sense, you are paying for the GUI administration tool, the integration into the local environment, compiled binaries and phone support. And all this adds value, although it's not strictly part of the mail server, to customers who aren't hackers.

Beyond the Cathedral, Beyond The Bazaar

Research Note by Jonathan Eunice (Beyond the Cathedral, Beyond the Bazaar)

The reality is that Microsoft turns out highly-capable programs, which it rapidly refines. While they do have a certain all-singing, all-dancing abundance of features, they are also unusually modular and cross-leveraged. Redmond's development model emphasizes many of those very attributes Raymond identifies with the Bazaar: quick turnaround, modular construction techniques, a large and active user base, many entities4 striving to improve it in a thousand parallel dimensions, and a strong feedback loop.

Yet Microsoft is not a Bazaar. The one-voice, one-goal nature of the Cathedral equally applies. Bill Gates has himself participated in what must be a record-setting number of project meetings, and the company enjoys a singularly disciplined and unified investment strategy. As with any dominant organization there is a propensity to encroach on others' turf, to redefine standards and interfaces on its own terms, to present the available options as its way or the highway.5 Yet these all relate to goals and attitudes, not to development mechanisms. And if a Cathedral risks becoming rigid, dogmatic, and insular, it also has an upside: a unified architecture, cohesive attitudes and approaches, strong motivations, and concentrated efforts.

The problem is not that it reaches wrong conclusions, but rather that it assumes an open-is-good/commercial-is-bad worldview that we doubt most IT managers share. Beyond proselytizing, it also paints all of software development against just two exemplars. The Cathedral represents a monolithic, highly planned, top-down style of software development. The Bazaar, which he recommends, represents a chaotic, evolutionary, market-driven model. Rarely do such simple categorizations do justice to reality. Finally, the combination of Netscape's strategic shift and the anti-Microsoft tone of the open source community lead one to assume that Netscape exemplifies the Bazaar, leaving Microsoft as the regressive, dogma-driven Cathedral. But that too is oversimplified.

...Raymond's paper touches upon, but never highlights, the synthesis of his antipodes: "when you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is convince potential co-developers that it can be evolved into something really neat in the foreseeable future."

What a perfect explanation of the Microsoft juggernaut! As Redmond understands,6 your product need not be strong at first shipment as long as one has a "plausible premise" of later product strength, of setting a standard, or of uniquely satisfying a pressing need--and as long as the early versions provide a foundation of revenue, user base, and an investment pool that is wisely reinvested to achieve continual improvement and eventual leadership. The units of measurements may differ between the open source and commercial communities, but the concept of economic foundation is identical.

That Microsoft--the antithesis of the Linux/freeware/open source community--can so effectively utilize the same Bazaar principles suggests two conclusions. First, that the Cathedral and the Bazaar provide too few data points to use in plotting the programming process. Second, that there are a set of surprisingly universal guidelines involving flexibility, modularity, and an aggressive feedback loop that all software developers should seriously consider adopting as their guiding principles.

 

Critique by Francois-Rene Rideau

About ESR's Articles -- by Francois-Rene Rideau (see also SlashdotA Critique of ESR's articles)

Table of Contents

About This Article
About Eric S. Raymond's Articles
Homesteading the Ergosphere
The Scientific Flask

 

 

When a Bazaar is no Longer a Bazaar

 

3. The Marc Andreesen Reformed Church of the Almighty Dollar Church-Social Bazaar Model

All bazaar booths are allocated by Netscape.

All bazaar merchandise must be tagged "brought to you by Netscape." Special branding irons are used in the case of cotton candy.

Modest-sized vendors who don't sign license agreements with weasel-wording will be strapped into the "dunk bozo" seat, and the top-intellectual property law firms of the Valley will take turns pitching the baseballs to see who can tank them.

Most people still need day jobs, though. How will it all work out?

Easy. Just remember:

"God is cool."

Now let us pray.

 

A cWare White Paper was one of the first documents to describe Microsoft as an important organizing force in the OSS movement:

"In the early days of the Internet, it was IBM and mainframe hegemony. Today it is Microsoft. Just as the German Reformation enfranchised specific groups previously disaffected (specifically, Luther and the German princes), the Internet empowered individuals and groups previously outside the traditionally well funded technocracy that supported and in turn was nurtured by IBM. Linux has been propelled by the same forces. Currently, a major share of commercial software resources is concentrated around Microsoft products like a large low pressure area. However, such a coalescence of power and influence disenfranchises many for whom high cost and restrictive licenses (lack of freedom really) prevent full and easy access to computing resources. So alternative paths are sought. Like the weather, alternatives may appear randomly and then dissipate. Typically, an additional sustaining force, an opposing low pressure area, is required. For Luther this pressure was provided by the German princes, for the early days of the Internet it was provided by ARPA, and for Linux, it has been provided by the Internet community itself. In the case of Linux, the Internet community desperately needed a competent OS platform. AT&T had shut out many Unix users with restrictive licenses and high fees. UC Berkeley had crippled BSD by removing all vendor proprietary code which adapted it to the underlying hardware: you could study it but not run it! Many saw a potential in Andy Tanenbaum's Minix to counterbalance an increasingly unfree Unix. But Minix was incomplete, did not have critical mass and its source distribution became too restrictive. These conditions inspired the community OS effort, initially derived from Minix, which produced Linux. Linux became readily available and increasingly capable. When it aligned with FSF licensing and could support the powerful GNU tools as well as run on a wide range of inexpensive hardware, a truly useful operating system platform was born. The Internet community finally had a way to run a fully networked Unix cheaply and reliably with no strings attached.

Linux appeared almost randomly on the scene but quickly gathered into a well organized storm because it had a powerful force to react against. It also had a sponsor.

Therefore, the Linux "Bazaar" is not simply a loose collection of vendors and other proponents, motivated only by mutual recognition. The "Bazaar" really operates on a larger stage. When forces of the larger stage organize around a dominant restrictive group, a reactionary force is generated in the remaining community. Over time, this reactive force propels various alternatives. If one or more of these alternatives can find support (the Internet community in the case of Linux), then a new "movement" is born which is sustained and even enriched by the powerful forces of the larger stage. Ironically the more dominant Microsoft becomes, the more powerful the reactive forces become, and the more fuel is fed to movements such as Linux. If an unencumbered BSD had been available earlier running on inexpensive Intel hardware, BSD might have become the seed for this storm. But the same drama would have unfolded: thesis and antithesis on a dialectic stage whose imperative will persist until Microsoft runs out of energy or dissipates its focus. Microsoft has only to look over its shoulder at the cycle of hegemony and superannuation revealed by a once almost omnipotent old technocrat: IBM."

 

 

 

Open Source Software Causing More Harm Than Good
 by Christian Schaller

linuxpower.org -- Open Source Software Causing More Harm Than Good by Christian Schaller (frostking@linuxrising.com). See also interesting comments after the editorial. The author argues that "Software needs to be free, not just open".

Comments on Cathedrals and Bazaars  by Dave Winer

Dave Winer authored two very interesting responses to CatB that Eric Raymond fail to acknowledge in his list of responses. They were probably the first (and very insightful) comments about CatB (he was probably to point out, that a "platform without a platform vendor" is the most compelling part of Linux, the first to notice religious overtones in CatB, the fact the users are distinct from customers and this two categories are mixed in CatB).

Unfortunately I found them only on Dec. 4, 1999.


Comments on Cathedrals and Bazaars -- this is probably the first response to the CatB(Feb.18, 1998). See also Eric Raymond Responds. Some insightful comments form the readers are on the mail site.

...Think about Larry Wall's role in the Perl community and Linus Torvalds's role in the Linux world. Listen to how Raymond talks about them. Is it that much different than the role Bill Gates plays in the Windows world?

But the worlds are different too. Have they built a base of commercial-quality apps around the Linux operating system or other GPL software? That's a serious question. If not, can they?

I wonder if people mind paying $100 for software that they want support for? Can the bazaar method really support a community of millions of users? We can't possibly know if it can or can't.

However, maybe I'm obsolete or old-fashioned, but I haven't found a way to work with great programmers without paying them a lot of money. I don't think the system Raymond outlines would work for Frontier because it's built by a team of professionals, who are passionate about what they do, but also have mortgages, wives, kids, take vacations, go out to eat, (or even just eat).

Life costs money. If you're serious about doing a piece of software, money has to flow. Or the promise of money flowing soon has to be there for the people providing the money (this is called investing).

The lessons Mr. Raymond has learned are available in the commercial world. He's a great writer, and thinks clearly. His rules are worth studying by everyone who hopes to make software, either as an individual effort or as part of a commercial team.

...Customers

Raymond refers to his users as customers, but I don't agree with this characterization.

Money and customerhood are irrevocably linked. It's a priviledge to pay money for a product, because that guarantees that you will be treated as a customer.

The people who use free software are not customers, since they didn't pay any money to use the software.

People who use free software are peers of the people who developed it. They must take responsibility for their own success with the software. This is a very different model.

The bazaar model

I don't believe in the bazaar model that Raymond talks about.

I prefer the Windows world, where people want to pay money for software, and where users don't expect to have an emotional relationship with the people who develop the software.

On the other hand, there are things I don't like about the Windows world, mostly the constant concern about how you're going to co-exist with Microsoft. So I'm interested in seeing if there are ways around that.

There's also a religious undertone to the bazaar idea. Listen to how Raymond talks about Linus. Some of my users treat me that way, and it always makes me uncomfortable. I'd prefer to meet them as peers, not as a god. This whole bazaar thing reeks of religion and parental projection. This makes me queasy!

I'd much rather think of the people who use my software as accomplished professionals who use my product the same way I use Michael Dell's computers, or Steve Dorner's email program or Chuck Shotton's web server. People I admire because they make useful products, but the relationship stops there.

Software makers can only teach you about software, to assume a bigger role, is to be religious about it, and I don't enjoy that. We don't make using Frontier a religion. Other people see that, that's their affair. I view the people who use my software as skilled people I can learn from, I don't want them to see me as a teacher or a guru.

Dell doesn't ask for my spirit or my soul, just for my money. I'm comfortable with that.

second letter see also mail discussion that includes ESR's response to the second letter Mail Starting 2-8-98

...I agree with part of his argument, in my experience, great programmers are great whether or not they are paid for their work. Lots of programmers say they want to get rich, but the really good ones do it for the juice of creating something wonderful to play with and to express themselves.

http://www.scripting.com/davenet/97/05/Programmers.html

I think programmers are truth seekers, scientists who know how to ask questions and solve problems. Money doesn't make them tick. But read on, money *is* part of the programming world.

No panacea

I've lived in a world of public collaborative programming for eight years, not a lifetime, but enough time to have learned some about it. In many ways our world is quite similar to the one Raymond describes.

From my point of view, it's no panacea. People come and go, as Raymond explains in his piece. If they decide to pass off, then progress might continue, depending on the quality of the work, and the commitment of the new owner of the code.

But the pass-off point can be a difficult time. Big pieces of functionality freeze while you wait to find out if the author is coming back into the loop. Sometimes when you ask for custody, they yell at you! I often back off when that happens. Or if you ask people to stay out of your way, they don't. And sometimes they ask me to back off, and I forget. Collisions. Flames. Anger! Human nature...

Also being the leader of a development community can be a mixed experience. People tend to give you a lot of their angst. The failings of the team or community are sometimes passed up the hierarchy. It gets old quickly, especially when you've already learned the lessons from the last generation, and a new one wants to take you thru it all over again. Sometimes I wish the superstars would just stick around to coach the new superstars on how to deal with me. [Mason, are you listening? Meet Preston, Seth, Matt, Jim, Bijan, Phil, and...]

Eventually, we learned it's our responsibility to make sure we can move forward. If we want our software to be used, we have to invest in usability. Software design issues become more complex when user interfaces appear. Matters of taste matter less, and the judgement of a designer must take over. Community is a very weak environment for tweaking a user interface to make it more accessible to new users. The community is already up the learning curve. The things you give to new users often break the systems built by the established users.

But I'm not giving up on collaborative programming. No way! I feel in many ways we're just getting started.

The role of money

I've learned that people I've been able to rely most on are the ones I pay salaries to. I don't think this should come as a surprise. The net is wonderful, but it didn't change the economy. People still have to eat, and programmers in Silicon Valley can eat well if they shop for jobs. In other words, programmers can do work they love *and* make good money. Why should they work for free?

Sometimes teamwork is required to make something happen. That means people have to accept the judgement of someone else. This works better when the person making the call is paying the person implementing the decision. It may work other ways, your mileage may vary, I know at times it can be incredibly difficult to get people on a payroll to move. Just ask anyone who managed at Apple. Read Jim Carlton's book. No matter what, teamwork is hard to attain in the software world of the late 1990s. It's just easier if people are being paid. Maybe not all people, maybe not at all times.

... ... ...

The high road

...I'd like to see if we can get our interests aligned, so that our power can connect to their power and vice versa. We share an interest in having a platform without a platform vendor. To the extent that they have set up a system that operates differently from Apple's, Microsoft's and Sun's (and Macromedia, Oracle and AOL too), I wish them more power.

On the other hand, if a requirement to being friends is that I adopt their philosophy in total, the answer is no. That was Java's message. I'd rather take my chances with Windows, where the market is proven and the platform vendor will talk and listen to me, without forcing me to change my model, and (important!) where my software already works.

Community

Part of what we do belongs in the world that Raymond describes, and part of it belongs in the commercial world. Where are the lines? With Frontier it's pretty simple, I think. Everything that ships with Frontier is on our side of the line. Everything that's available thru other servers and mail lists follows the rules established by their authors. They can choose to use any model they like.

In other words, we make our product, and we do the best we can to say what that is. There are huge places where we don't develop, where we don't have the people or money to develop. Those places are relatively safe. Then there are areas where we focus, like content management systems, and anything that relates to those areas being worked on by salaried people who are responsible to a company's management for producing results.

Our community is an incubator for defining these lines. We're at another transition point, it's an interesting time. I'd like to extend an offer to people to work with us not only as a software company, but as a community of users, of peers. People making products.

... ... ...

Netscape

Finally, Netscape, apparently, is shopping for someone to buy them. Perhaps, instead of disappearing inside another big corporation, Netscape could leverage its reputation for leadership in open software by becoming the corporate caretaker of Linux?

... ... ...

[Dec. 12, 1999] Comments by Chuck Cranor <chuck@ccrc.wustl.edu>

I decided to read Eric Raymond's article "The Cathedral and the Bazaar" a while back because it relates to my long standing interest in free software (or "open source software," as Eric would put it) and because I kept seeing references to the article on the network. Although I agree with the general gist of the article, I do not think it lives up to the level of hype surrounding it (which, at this point, would be hard for anyone to do). Here are some of my thoughts on the article after reading it.

First, I found that the article was lacking in focus, and I found that distracting. I believe the main point of the article is to compare the "cathedral" development model with the "bazaar" model. The first four sections of the article certainly echo this theme. However, there is also a strong mix of Linux advocacy and (for lack of a better term) "Linus worship" in those sections as well. Although I certainly respect Linus and support the development of free operating systems such as Linux, I would have preferred a broader and less biased presentation of the main theme (with a wider variety of examples presented). Sections 5 to 8 of the article don't really fit with either the main theme or the Linux advocacy theme presented in Sections 1 to 4. These middle sections focus on the story of fetchmail and general advice for free software developers (although some of the general advice, such as rule 15 only applies to specific types of gateway software). I believe that either eliminating or shortening these sections would lead to a more clean and concise article that focuses on the main theme. (The reduced sections could be the start of another paper focusing on advice for developers based on the fetchmail experience.) The final three sections return to the main theme (with the Linux advocacy theme mixed in again). If I were rewriting this article, I would have cleanly separated these three themes either into separate papers or separate sections that refer to each other. I would have also tried to include a wider range of examples than just Linux, FSF, and fetchmail.

Second, I noticed that the article repeatedly praises the high average quality of software originating in the Linux community, and yet it never offers any examples of such software. This made me wonder if the article was implying that the average quality of software originating outside of the Linux community is low? What is the Linux-originated software being compared to? The article does not offer us any explanation for this statement and assumes that the reader will take it on faith that the statement is true. I know that in my case a lot of the free software that I use originated outside of the Linux community (e.g. XFree86, gcc/ecgs, GNU Emacs, xfig, and LaTeX). The article also advises us to follow Linux's "release early, release often" model even if the released software has bugs and is not perfect. Couldn't doing this actually lower the average quality of released software if one was not careful?

...Finally, Section 4 of the article advises us to "release early, release often." For the Linux kernel, this is typically accomplished by releasing a series of kernel-source tar files on a standard set of ftp sites. This mechanism is actually quite primitive and limiting when you compare it to related work in the area (which the article did not). For example, the BSD projects use the CMU-Mach based Software Upgrade Protocol (SUP) to provide daily access to the most recent source files. Unlike Linux's tar files, SUP only downloaded files that have changed (not the entire source tree). In addition to anonymous ftp and SUP, many projects support other more advanced forms of source tree access. For example, in 1995 Theo de Raadt and I created an innovative new "Anonymous CVS" system that allows anyone on the internet to have anonymous read-only access to a CVS repository (see "The History of Anonymous CVS" for details). Anonymous CVS was a radical concept at the time we invented it because many projects were very reluctant to allow outsiders to have access to their source repositories. But eventually the idea has become accepted. Since the creation of anonymous CVS, other projects have built on our work. For example, Bill Fenner created "CVS WEB" (a software tool that allows anonymous CVS access through a web browser) and placed several source repositories on the FreeBSD web server (see http://www.freebsd.org/cgi/cvsweb.cgi). Cyclic Software (the maintainers of CVS) added the "pserver" access mechanism to CVS after reviewing our work on anonymous CVS. The "pserver" mechanism provides an alternate way to support anonymous CVS access. Many projects such as Mozilla, ecgs, FreeBSD, OpenBSD and at least one branch of Linux kernel development now use some form of anonymous CVS as a mechanism for allowing users to anonymously access source repository information. I believe that both SUP and anonymous CVS based distribution mechanism are far superior to the tar-file based distribution mechanism so heavily praised in "The Cathedral and the Bazaar."


 

Some Implications of Bazaar Size

Third Draft. Aug 11, 1998
Copyright 1997-1998, Forrest J. Cavalier, III Mib Software
All rights reserved. Comments welcome!

.

In this paper, I postulate that



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 07, 2013