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'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 entities⁴ 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.⁵ 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,⁶ 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

• Warnings
• Table of Contents
• Foreword

About Eric S. Raymond's Articles

• The Cathedral Cleric and the Bazaar Preacher

Homesteading the Ergosphere

• An Introductory Confusion
• Varieties of Ideological Bias
• Accurate Practice, Mistaken Theory
• Freedom against Software Ownership
• Projects' Nature and Ownership
• The Value of Promise
• Ergospheric Property and Promise Incentives
• The Software Economy is Not a Gift Culture
• Evaluation Mechanisms and the Link to Academia
• Customary Laws and Conflict Avoidance
• Causes of Conflict among Hacker Ideologies
• Assertions for Further Action

The Scientific Flask

• Distinguishing Science from Magic
• Beyond a Gifted Geek's Explanation
• The Immutable Reality
• The «``Information wants to be free'' Myth» Myth
• Union is Force
• Passions for Opening Source
• Why All Value is Ultimately Use-Value
• When To Be Public, When To Be Secret
• Coping With Adversity
• Open R&D and the Reinvention of Investment
• Conclusion: Life in the Permanent Revolution

• These are a few remarks about incorrect things that I think lie in Eric S. Raymond's otherwise fine and deservedly well-known articles. I sent these remarks to ESR first, but he in his full mind and his full right chose to not take them into account. As I fear this makes his articles propagate a few noticeably bad ideas as parasites to the main, correct, ideas that these articles demonstrate, I feel like I must denounce them, which I do here. Of course, these remarks are best read after knowing ESR's articles, but I've tried to make all my arguments self-contained, so that this article might stand by itself.

• Actually, if we replace in Eric's article any reference to ownership of programs into reference to ownership of projects (Eric himself sometimes uses this correct expression), then the article becomes essentially correct. Then, we can't say that programmers homestead the noosphere, the sphere of programs, which is false; programs are inherently immaterial, and no amount of homesteading or any activity can create ownership in the noosphere beyond any "magical" point. Instead programmers homestead the "dual of the noosphere", the sphere of programming projects, that are physical explorations of the immaterial noosphere.

• To me, the reason why the "industrial-capitalist production model" does not match "production of software" well, is not, as suggests Eric, because software is a world of abundance rather than scarcity, but because software is nothing that is physical and ownable, but something intrinsically immaterial and sharable, to which the very notion of production does not apply. What the production model perfectly matches is production of software-related services, and this model justifies freedom of information rather than protectionist information hoarding.

• I, among others, proposed that the right phenomenon to which to compare free software development be theoretical scientific research, which Eric did in latter versions of his article. Indeed, both free software development and academic research proceed from the same generalized phenomenon: systematic creation of new information that describes generic processes. The two phenomena are also historically related, since free-software hackerdom was born in Internet-connected universities, by students and teachers in computer science, mathematics, physics, chemistry, et al (and this relation is not fortuitous, since it were those scientists who invented everything about computer science, beginning with computers themselves). In such fields, people explore a space of purely informational objects, that intrinsically can't be owned; but they do fight for reputation and "promise", for attracting other people's interest in their own subfield, so as to have their secondary problems solved, and so as to obtain subsidies. My opinion is that unlike what Eric suggests, the sharing of adaptative patterns between academia and hacker culture may be due both to their having a continued common history and to their sharing similar structural constraints, without incompatibility, and with a deep correlation instead. All in all, I conceive that whatever to say about hacker culture should apply to theoretical scientific culture as well, and conversely.

• As for conflicts, lots of projects have developped their own day-to-day conflict avoidance methods; mostly consisting in communicating through adequate mailing lists, with some way or another of designing people in charge. For instance, the Perl patch-pumpkin is an efficient way to avoid conflicts, combining time-sharing with classical centralism. Methods for conflict resolution has been developed, too, and at least my own TUNES Project includes a formal written Charter describing sensible mechanisms to resolve conflicts, that I believe can be observed as being in actual informal use by other projects.

When a Bazaar is no Longer a Bazaar

• WHEN A BAZAAR IS NO LONGER A BAZAAR -- a very interesting and ironic critique from Turner

• ...

  Eric Raymond is going to be a Netceleb. Marc Andreesen virtually guarantees this. The developer consensus within Netscape will propel the author of "The Cathedral and The Bazaar" almost to household-name level of public visibility. Netscape will publish its browser source, Agoric processes will save the day, Microsoft's tidal advance will be stemmed.

  Or will it?

  I have mused on Eric Raymond's choice of "Cathedral" and "Bazaar" as juxtaposed metaphors for the two different styles. Historically, the one is Christian, the other Islamic.

  Religious Architecture and Social Archetypes

  In Christian countries, the Cathedral was the source of ecclesiastical power, and to some extent it remains so. As a political power, however, its role has gone from nearly central to nearly non-existent. Nobody is building Cathedrals anymore, so that pork-barrel is long empty. And nothing has taken its place.

  In Islamic countries, the bazaar - which is seldom, if ever, co-located with any related job-producing construction projects - remains the center of ecclesiastical power. In self-styled Islamic Republics, the bazaar is therefore the center of power, period.

  Perhaps the theocratic overtones in the choice of the term Cathedral was Eric Raymond's allusion to what many see as the doctrinaire and sanctimonious rumblings from RMS the Pope, versus the more freewheeling and (in strict GNU terms) easily-corrupted style of Linux development. And perhaps in choosing the term "bazaar" Raymond meant only to suggest something more social and economic and mundane; something that was, architecturally, at least, more low-to-the-ground. He refers to Eric Drexler's notions of Agoric systems, saying that he thought of entitling the essay "The Cathedral and the Agora." So maybe none of this has anything to do with the taint of theocracy.

  But maybe everyone should (re)read God and Golem, a book written Norbert Wiener, the coiner of the term "cybernetics." In all things computer-related, ecclesiarchs are not far off.

  If you want evidence that the bazaar style is easily corrupted and/or prone to its own problems of self-destructive, dogma-inspired holy wars, you need look no further than Microsoft itself.

  Yes, Microsoft.

  The Gospel According to Fred

  Eric Raymond apparently has glanced as far afield as Redmond in seeking precedents, though apparently with only a shudder and a giggle so far. "For Further Reading" leads off with this:

  I quoted several bits from Frederick P. Brooks's classic The Mythical Man-Month because, in many respects, his insights have yet to be improved upon.... The new edition is wrapped up by an invaluable 20-years-later retrospective in which Brooks forthrightly admits to the few judgements in the original text which have not stood the test of time. I first read the retrospective after this paper was substantially complete, and was surprised to discover that Brooks attributes bazaar-like practices to Microsoft!

  A careful reading of Brooks's 25-year retrospective turns up another, crueler, irony. One of the few points where Brooks concedes a probable error of judgment is in his original insistence that all the information about OS/360 development be made available to everyone on the project.

  Information should be free. At IBM. In the mid-60s.

  Well. How clueful.

  But now he says he was wrong?

  CWareWhite Paper

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 ([email protected]). See also interesting comments after the editorial. The author argues that "Software needs to be free, not just open".

• Netscape was planning to release the source code of their browser after reading Mr. Raymonds essay, and I felt certain a revolution was underway. Think we would soon be able to cut'n paste all interesting source code from Netscape into our own software projects, we would be able to get it to integrate much better with our desktop environments and other applications. And never again would we be left with a bug ridden binary unable to take action. And this would just be the beginning, this was the sign of a tidal wave which would cause most software to be released under the (L)GPL or a Berkeley style license.

  How wrong and how naive. Soon the Netscape browser was released under the NPL. There was some critical voices, but they drowned in the jubilant cries as we felt we had won our first big victory. How true and how false it would turn out to be.

  Truly enough, the mozilla release was the first in a long row of Open Source announcements. We were soon bathed in the light of software source code either being released with the endorsement of the OSI or just unauthorized calling themselves open source software. Having seen that Netscape had been well received, and was actually having some success due to its source release other companies threw themselves on the bandwagon.

  Unfortunately they learned more from the Netscape event than just to release their sourcecode. They learned that the community of hackers that existed in the BSD/Linux vicinity, was willing to accept that the source code was bound by special reservations, benefiting the original author much more than all other contributors. It seemed like the community did not put so much value in the fact that the licenses they had built their systems around until that time had been equal opportunity licenses, where everybody could mold the code any way they wanted, and even try making a living of selling their modified versions.or simply sell support for those versions..

  So one by one they made their own licenses, each with its own restrictions and quirks. Troll Tech invented the patchware system and Sun the pay-if-you-play system. But the best of them all is the latest; Apple taking a bunch of software released under the BSD-license, re-releasing it under an all power to Apple license, and expecting us to thank them for it.

  I heard many people saying we should be grateful to these companies for allowing us to see the sourcecode and even fix their bugs. Many even said that it would be very unkind of us to try to make competing products to be released under true free software licenses, when these companies had been so gracious towards us. One of the casualties of this opinion was of course the Harmony project, which aimed to make a LGPL'ed Qt clone.

  Well, now that we have this Open Source OS from Apple I guess these people feel that we should bury the Linux project. I mean to follow your logic it is only fair that Apple is allowed to make money on their system, and Linux and FreeBSD are a direct threat to that.

  Some might claim that the release of all this software will lead to something good, that all the best ideas and best code will end up being melded into one great piece of software. They are wrong. These licenses pose a direct threat to the community, they are not a boon. If this development is allowed to continue unchecked we will soon find ourselves almost unable to continue forward.

  When we take different pieces of software and try to meld them together into products of our own vision, we will find that for each new inclusion a new license needs to be added, and the code will get a new restriction. And just like the Harmony project we will never know when we infringe upon somebodies copyright or at least their claim of having copyright.

  A nice experiment would be to mix some of Apples code with Qt code from Troll Tech. That way Apple can claim ownership of Qt and Troll Tech can claim ownership of MacOS X. And we can sit back an watch them fight. A funny though, but of course without roots in the real world, what we would see in the real world is a clear example of free software being made impossible by conflicting licenses, and the first glimpse of a future where free software developers are crawling through an increasingly more hostile jungle of source code licenses.

  I implore the developers of the free software community to not let Eric Raymond lead the community down this road of self-destruction, but fight him with every fiber in your body. 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 <[email protected]>

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

.

In this paper, I postulate that

• The size of the bazaar (number of participants) affects the "health" and success of the bazaar, even if not a pre-condition to successful bazaar startup.
  
• Not simply "size" but "effective working size" has important implications for the continued progress of the product and strength of the bazaar.
  
• Debugging by testing includes factors which give the bazaar a very much smaller "effective working size"
  
• There are alternative debugging methods which might be used to counter a small "effective working size."
  
• There are activities and natural progression which tend to erode the "effective working size" of the bazaar over time.
  

Etc

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard 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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019