12 ms·

OK, I'll make a couple of general observations here. First: It would be a big help for this discussion, if we could have the informal convention that people wh

• xaa 14y ago
  To reply to point three, which is the only one not containing an ad hominem... There exist several larger OSS projects, such as Apache, Boost, the Kernel, etc, which accept contributions but are also curated. Thus they represent sort of hybrid between cathedral and bazaar. People who use these projects know they are getting some (varying) standard of quality. I think these sorts of projects -- often shepherded by some kind of noncommercial Foundation or Organization -- are the best way to get a mix of openness and quality going forward.
  • ef4 14y ago
    Those are essentially ESR's original, canonical examples of "bazaar" projects. They're not middle-of-the-road. They're precisely what he meant by "bazaar".
• davidw 14y ago
  Why don't you talk about a few current "Cathedrals" and how they're different from "Bazaars", that might help the discussion too. The only example that jumps out at me is the original Unix, and I think you'll agree that comparing software from 30 years ago that does vastly less than ... pretty much anything out there these days is not an entirely fair, nor useful comparison.
  • phkamp 14y ago
    The fact that you and others cannot even spot any more recent cathedrals is sort of my entire point here...
    • podperson 14y ago
      I held IT jobs before 1990. Might I make the observation that when a software project is no longer able to be maintained by a single person or dynamic duo, it will tend to become a bazaar, no matter how cathedral-like it may have been before, and that the alternative is stagnation. I will cite as evidence two of my favorite programs ever: WriteNow (for Macintosh) an excellent early word-processor written entirely in assembler. Unequaled for many years for its combination of stability, raw performance, and ease of use, ultimately it simply could not add new features (let alone make the jump to PowerPC) and died on the vine. HyperCard, which was perhaps one of the most dazzling, innovative, and influential products ever to ship, which pretty much stopped evolving once its original programmer lost interest. Today we have the phenomenon of the incredible version one product, usually developed by one person, which never really makes it to 2.0. These seem very much like cathedrals.
      • yxhuvud 14y ago
        There is a third alternative - split the project into manageable parts.
        • podperson 14y ago
          Good point but the problem is fundamentally fractal. For any project P it will either (a) stagnate, (b) go bazaar, or (c) be split into new sub-projects. Most projects go nowhere, but once a project gains momentum it's going to split into pieces and each piece has a chance of "going bazaar" at each step.
    • davidw 14y ago
      I most certainly can think of some things that would qualify in my mind, but since we're talking about rather vague notions, why don't you go ahead and name some projects you think are good examples? You seem like a bright guy; I'm trying to understand your point of view better, and so far, you are failing to communicate it very well.
• jballanc 14y ago
  First: Have you ever looked at a plot of people for/against mariage rights for gays vs age? I suspect that the clear divergence does exist, but may not mean what you think it means... Second: I worked on OS X. In fact, I worked on Snow Leopard, and the start of Lion. What's interesting about that, is that Snow Leopard was the last version of OS X developed according to the "Cathedral" model. Also, while the Snow Leopard cathedral was being built, iOS was being developed firmly using the bazaar model... Third: You know, I wonder if you've ever been to a bazaar before? I live in Turkey, where the bazaar is a way of life (and where one of the largest, oldest bazaars in the world is located). I've never found "spare parts" at a bazaar. What I have found is some of the highest quality jewelry, tapestries, rugs, and other hand-made goods you'll find anywhere. Fourth: I think you're conflating "good quality"=>Cathedral and "poor quality"=>Bazaar. The only thing that distinguishes the Cathedral and the Bazaar is whether or not there is one single individual in whose head the only valid vision of the completed project exists. You might do well to read up a bit on the history of Kapalıcarşı. Throughout its history there were guilds to enforce authenticity and all manner of quality control mechanisms. It is possible to have a Bazaar and a very high quality product.
  • thebooktocome 14y ago
    According to phkamp, iOS is a cathedral kind of project. I was hoping someone would bring up OS X and how horrible its cathedral-born API became around 10.5, but I was born in '85 and therefore have no right to speak in this thread.
    • jballanc 14y ago
      While Apple would certainly like you to believe that the image of iOS sprang, fully-formed, from the mind of Steve Jobs like some sort of medieval cathedral, the reality is anything but. In fact, much of Apple's success is due to the extent to which it functions like a confederation of very well funded startups. Cupertino is very much a bazaar, wherein a shopper with very refined tastes (Jobs, for example) can pick and choose the finest wares. This article concludes that quality only happens if someone takes responsibility for it. Yes. You'll find no argument on that point from me. But cathedral's are not (edit: should say "not only") about one person taking responsibility for quality. They are about a priori design. Quality control can happen ex post facto but creativity, once strangled, dies.
• chimi 14y ago
  I think a lot of people, especially around here, eschew college education in the computer sciences, because you can get a job without it and you can build a website without it, but I really think the decline of formal education in computer programming concepts has led to a lack of cathedral thinking. Of course, I'm biased, because I have such a degree. However, when I compare what I build to what is built by a business school grad who thinks anyone can learn computers, so everyone should be taught business, I really cringe at loss of formality in the industry. Needing to build a computer processor from AND and OR gates really drives the concepts home. Building an operating system in C++ really drives the concepts home and creates a framework for thinking about computer based problem solving that's lost in many of the systems I look at today.
  • chawco 14y ago
    I'm going to go ahead and strongly disagree on this first point -- I've seen no correlation whatsoever between education background and propensity for strong system design. In fact, my background is mathematics with very little formal CS-related education and I'm firmly in the cathedral camp. I really think it is a matter of exposure -- at one time all anyone ever saw were cathedrals, and so that was all anyone ever built. I feel now we've swung too far the other way, where there are many in the craft who've never seen a cathedral and have only known the bazaars. The reality is we need both, and the craft of building cathedrals is becoming endangered.
    • Zimahl 14y ago
      my background is mathematics You are a terrible example because you come from a formal background of a hard science. Even worse, you come from one where proofs (the cathedral in the mathematics sense) are required or you aren't taken seriously. The parent was talking about joe schmo off the street or the high school wunderkind who is building "twitter for teens" or "pinterest for social good". They are just slapping it together from the get go without thinking about any aspect of the design. Eventually they'll have to hire the formally schooled to come in and clean it all up, if they actually get anywhere with it. Which makes me wonder, if more formally educated individuals were in the start up game would the failure rate be so high as it is now?
• toyg 14y ago
  Pretty much all your arguments about the Cathedral model being superior fail in the face of the most common cathedrals known to man: Microsoft Windows and Office. Their inscrutable beauty is buried under tons of libraries nobody will ever touch for fear of breaking 20 years of development efforts, exactly like what happens in the Unix world. Their move to the 64-bit world was painfully slower than what their fellow merchants accomplished in the Unix bazaar. They still provide compatibility layers for programs built with technologies that have been thought of as extinct, like monks still praying to the gods of ancient Greece. Whenever they went for the "total reuse" mantra, they built terrible and insecure specifications (DCOM) that still saddle us 20 years later. And let's not even talk about portability, which is anathema: to each his own Cathedral and his own Faith, touch ye not any unbelievers! So yeah, making mistakes and keeping around the cruft is something every long-running IT project can experience. Unixes are, arguably, the longest of them all, so the ones that naturally tend to show it more. Besides, there's a whole new world of applications to be built out there, if we were rewriting libtool every three months we'd move even more slowly than we do now. <ad-hominem>Oh, and I wish I could say your rant is unbefitting of professionals of your age, but I'm afraid it's actually quite matching the grumpy-old-man stereotype you're clearly striving for.</ad-hominem> Hey look, I can do ad-hominem too, and I was born in the late 70s!
  • phkamp 14y ago
    Windows and Office are actually not examples of cathedrals, because the architectural focus of Microsoft was not on software but on a near-monopoly market. You diagnosis of its qualities are spot on. "ad hominem" means to "attack the man", ie: I single identified man, saying some generalities about identifiable groups is not "ad hominem". And yes, I am a grump old man, and a surprisingly cheerful one at that.
    • jsight 14y ago
      This sounds a bit "No True Scotsman" to me. Most commercial projects that I've seen eventually grapple with the same sorts of issues that you mention. When they've faced diverse deployment environments, the results have often been worse than autoconfigure, from what I've seen. I guess that's because they aren't cathedrals, since the businesses behind them were focusing on market-demands instead of whatever it is that Cathedrals focus on? Your remarks are essentially Ad Hominem regardless of whether you single out 1 man or 100 individual men.
• ChuckMcM 14y ago
  Ok, pre-1990 person here, and the piece resonated quite strongly with me. But I note that there is a third axis which isn't well covered, which is 'volunteer' vs 'paid'. It is important to note the distinction between FreeBSD's package system and say Debian apt. In FreeBSD I can make from source some package, and in Debian I can apt-get install a package, because the Debian packages are prebuilt it just comes over in several chunks and doesn't need to build. (yes you can pull prebuilt packages for FreeBSD too). But my point is that the packaging system of FreeBSD, as used, conflates building the packages and using the packages. So if I write a perl script that goes through the source code and changes all the calls to fstat() to match your configuration then to build I need perl even though you do not need perl. (as an example). But to run I don't care if you have perl or not. But lets get back to the volunteer/paid thing again. People who volunteer rarely volunteer to clean the shit out of the horse stalls, no they volunteer to ride in the races and build a new horse. So you end up with a lot of stuff around you don't want. Sadly for operating systems, and the original rant is really operating systems, there really isn't a cathedral/bazaar model, its more of a democracy / feudalism kind of thing. Nobody 'owns' the final user experience for the OS in FreeBSD/Linux discussions.
  • csense 14y ago
    > conflates building the packages and using the packages. Yes. Much of his poor experience is due to build systems. Anyone who's developed anything can tell you how fragile and finicky build systems can be. Since build systems are used by developers, who can deal with complexity much better than "ordinary" users, they tend to be rough around the edges. They're also unglamorous infrastructure, so volunteers tend not to spend time on them if they're not paid. And they have a tendency to break the entire application if broken, and are often part of the "interface" of the software (since every distro who builds package X from source uses build scripts that rely on for example ./configure with particular options), so maintainers tend to take an "if it's not broke, don't fix it" attitude. GNU projects in particular -- whose autoconf the author complains of -- have quite a bit of built-up cruft since many of them are very old, and also vital infrastructure of most FOSS OS'es.
  • tytso 14y ago
    Yes. This. It's also a matter of what people are willing to pay for. Even (or perhaps especially) in commercially supported software, cleanups only happen if there is a strong business case for the cleanups. And if the cost of buying an extra build machine to run long complicated configure scripts is significantly less than the engineer time to re-engineer a new autoconf system from scratch, in many companies (and certainly most starupts) --- it won't happen. The OP cares very much about code quality as a good and important thing in and of itself. But that view isn't shared by many business people, or by many programmers in general, for better or for worse. Some have argued that OSS code tends to actually be _better_ about code cleanliness, because it's public, and people do care about making sure that their code is clean. (I've never seen the proprietary source code for the Oracle DB, but there are many stories out there about how horrible it is from a code cleanliness perspective.) Also, the OP seems to care a lot of lots of extra library dependencies. The big problem here is that a lot of people don't really care if their package uses perl or python as part of their build scripts/makefiles --- or even if their package uses perl _and_ python scripts. The OP cares, but for better or for worse, most people don't. And I would wager this is likely true at most companies where programmers are paid to maintain the source tree as well!
• jwm 14y ago
  > Fourth: Related to point two really: A lot of you seem to have little actual ambition of making things better, I guess that is what happens if you grow up in a bazaar and never even experience a cathedral. I pity you. I think people do want to make things better, but its happening much more decentralized, with small teams taking small safe steps on tools, libraries & frameworks. Media, on-line banking, 3d printing, accessible hardware hacking, e-commerce sites, scientific/engineering software. The majority of these things are made by small teams plugging the best libraries and platforms out there together, where they already solves part of their software problem. Android, Cloud, Linux etc. It would be silly to say these were without ambition and don't contribute to the community. (The average software devs Impact Factor may be diluted by the increasing number of people working with computers, but computers are so globally useful its inevitable. If good things are still getting made then who cares.)
• gonzo 14y ago
  Started in IT in 1980. I'm 50 this year. First FOSS contributions were in Nov 87 (patches to gcc/gdb/emacs for convex machines). This pre-dates any contribution by ESR, and it enrages him when I point it out. :-) My company ships quite a bit of FreeBSD (as pfSense). Could have gone linux, but linux is a mess (much worse than ports.) I think OpenBSD is a mistake, at best it belongs as a group focused on security inside the netbsd project, but of course, Theo got kicked out of netbsd, thus: OpenBSD. I'm also the guy who appointed Russ Nelson the "patron saint of bike shedding." Just FYI. :-) (None of Eric Raymond, Russ Nelson or Theo de Raat like me much.) The first time I read of 'Cathedral & Bazaar' I thought ESR was illustrating and contrasting the BSD .vs linux development model. Only later did I understand that he was pointing fingers at GNU/FSF, not BSD.
• ucee054 14y ago
  I think you are missing a couple of things. In this comment I will equate "Rug Market" with "Ready, Fire, Aim" and "Cathedral" with "4 Year Plan". Firstly, the "Rug Market" beats the "Cathedral" when you haven't formulated the problem properly, and so you have bad specs. Secondly, the "Rug Market" beats the "Cathedral" when bad software is more profitable than good software. Google for "Worse Is Better" and "The Innovator's Dilemma". Sad but true.
• revorad 14y ago
  Instead of giving us pity and RTFM, it would help if you clearly specify what you think are the defining and distinguishing features of the cathedral and the bazaar models. There seems to be a lot of confusion around that.