Live data from Hacker News

A Generation Lost in the Bazaar

queue.acm.org

231–240 of 353 posts

Re: A Generation Lost in the Bazaar

#231
post #218

Earlier quoted context omitted.

The problem is that coherent vision and a prior design are NOT equivalent. Obviously, I cannot know what was going through the head of ESR when he wrote the original essay, but what I've always taken from it is that a priori design is inherently inflexible, prone to becoming disconnected from reality, and ultimately less inviting to creativity. If the suggestion of the article is that the only way to retain quality i…

Brooks spends some time discussing these issues in the book, and I'm pretty much aligned with him: Nobody belives in "a priori design" and I somehow doubt that anybody did. Brooks points out that the original publication of the "waterfall model" was meant as "how not to..." and people got that wrong. But cathedrals are not about a priori design, they are about style, elegance, economy of means and coherency of design…

But did they grow up in the Bazaar? or in the Mad House?

ESRs original prototype for the "Bazaar" was Linux. Do you feel that Linux is lacking in coherency of design? You refer to the dot-com bubble, but the problem with the bubble wasn't, I think, that it was the "Bazaar". Indeed, I don't think the dot-com bubble of the late 90s was characterized by much open source development at all!

It was, rather, consumed with "flashiness" and "wow factor". I definitely see the continued obsession with these things as a problem. I would say that, for example, much of the obsession with Node.js today is a consequence of this obsession. But that isn't a Bazaar.

It's a disco.

Re: A Generation Lost in the Bazaar

#232

Earlier quoted context omitted.

> Coherent vision and a priori design are not the same thing. Apple has coherent vision. Bazaars can have coherent vision (should have coherent vision if they hope to be successful). But that's not the same thing as a Cathedral's a priori design... A priori design can adapt to new ideas. I'd argue that's what Apple did/does, in many cases. Likewise, I'd argue that the truly ad-hoc bazaar development is responsible fo…

If a priori design adapts, then it was never more than a coherent vision to begin with. The notion of a priori design is "we're going to do A, B, and C, and don't even think of changing the plan until those are done". As ESR talks about in his original essay, the "Cathedrals" were mostly developed in chunks. What was different about the Linux "Bazaar" was the way everyone could see and give input to the development a…

That's a false dichotomy -- a straw-man -- that's you're using to discredit the idea of planning ahead.

Compare FreeBSD kernel design versus Linux.

kqueue vs. dnotify/inotify/???

Mach-descended VM vs. a string of linux-vms

BSD scheduler, ULE scheduler vs. how many different schedulers?

Linux churns through ill-conceived solutions to problems until they find one acceptable enough. FreeBSD grinds on one until it definitively works.

FreeBSD almost invariably winds up with the better solution, in less time. See kqueue, for example -- the foundation upon which Apple's GCD is built.

Re: A Generation Lost in the Bazaar

#233
post #230

Nature does pretty well with bazaar style development and she usually wins doesn't she? There's a lot to be said about building via rapidly iterating around feedback.

But that process has a way of ruthlessly culling the herd. Does not seem to be happening in this world of infinite backwards compatibility.

And I have a tail-bone, but no tail ...

Re: A Generation Lost in the Bazaar

#234

Earlier quoted context omitted.

I read ESR's essay. He was protesting how hard GNU makes it for outside contributors such as himself. Somehow the essay got construed as open source vs. closed source, and ESR pivoted to align with the popular interpretation of his essay. I've never read the book (someone would have to give me a really good reason), but I assume it doesn't focus on GNU. You're calling a ot of people out on using Microsoft as a cathed…

In a world where software is designed by cathedrals, there is no need for autoconf. You read the POSIX spec and write software that conforms to it.

That is true. But the article decries autoconf's implementation, not just the need for it. It implies that cathedral designers would never implement it, or if they did implement it, do a better job.

Re: A Generation Lost in the Bazaar

#235

Earlier quoted context omitted.

If a priori design adapts, then it was never more than a coherent vision to begin with. The notion of a priori design is "we're going to do A, B, and C, and don't even think of changing the plan until those are done". As ESR talks about in his original essay, the "Cathedrals" were mostly developed in chunks. What was different about the Linux "Bazaar" was the way everyone could see and give input to the development a…

That's a false dichotomy -- a straw-man -- that's you're using to discredit the idea of planning ahead. Compare FreeBSD kernel design versus Linux. kqueue vs. dnotify/inotify/??? Mach-descended VM vs. a string of linux-vms BSD scheduler, ULE scheduler vs. how many different schedulers? Linux churns through ill-conceived solutions to problems until they find one acceptable enough. FreeBSD grinds on one until it defini…

It's very interesting that you bring up kqueue. I was about to bring up kqueue, but for a different reason.

Planning ahead can lead to great things. The Notre Dame, and the dozens of other cathedrals throughout Europe are positively stunning...

I love and I hate kqueue. I mean, I love kqueue. I love the way it can be used from C, I love the way it's integrated in MacRuby...I spent the weekend studying Clojure's reducers and was dying to have some time to work on ClojureC just so I could implement reducers with kqueue...

I hate kqueue because, in all likelihood, I'll never get to use it in a production system, because it's not in Linux.

Cathedrals can be nice to look at. Bazaars are often more functional.

Re: A Generation Lost in the Bazaar

#236
post #21

As someone who grew up as a programmer with assembly language, C, and C++, learning the good practices needed to make a 1 million lines of code C++ application work and be maintainable: I've been equally disgusted by the evolution of programming in the last few years. HTML - which is, to a first approximation, always invalid. JS - which needs jQuery to make it mostly-but-not-completely cross-compatible among browsers…

>And now Google translates text statistically, without even trying to understand things.

This comment seems to mostly be, "I'm going to complain about software disciplines and lines of CS research that I don't understand because their practical approaches don't conform to my finicky aesthetics."

If you want to formulate Strong AI to solve NLP as a problem, go for it. The rest of us are happy to use Google as it is.

Re: A Generation Lost in the Bazaar

#237
post #166

Earlier quoted context omitted.

You know, first time I encountered the "M$" shorthand was in a TELEX (look it up if you don't know what that is) from Commodore Corporate about pricing of the the PC10 computer. I have used it ever since, based in part on what was not very diplomatically expressed in that missive about M$'s attitude to licensing.

as long as I can use the term I coined: "open shit"

Actually, the proper traditional way to insult Open Source is "Open Sores". Use that and the feeling I got during flame wars between high schoolers on IRC channels in the late nineties will be complete.

Re: A Generation Lost in the Bazaar

#238
post #166

Earlier quoted context omitted.

M$? Really? I thought HN and seasoned OSS developers were above this kind of petty name calling and sneering.

You know, first time I encountered the "M$" shorthand was in a TELEX (look it up if you don't know what that is) from Commodore Corporate about pricing of the the PC10 computer. I have used it ever since, based in part on what was not very diplomatically expressed in that missive about M$'s attitude to licensing.

Just because you read it a long time ago doesn't make it less petty or silly.

Re: A Generation Lost in the Bazaar

#239
I doubt the dichotomy is between the cathedral and the bazaar.

All software projects have a list of gatekeepers or maintainers, who decide which changes should go in and which ones shouldn't. Some of them have a long list of people with commit access (like Subversion), while others have a handful of maintainers (like Linux). Some of them have grand roadmaps and bug trackers (like Firefox), while others have no agenda or bug trackers (like Git). Some projects have many dependencies, use libtool and a lot of auto-magic (like Subversion), while others are still adamant about not having a configure script, maintaining a handwritten Makefile, and having 1~2 dependencies (like Git).

From what I've noticed, as a general rule of thumb, the projects with few strict maintainers are better off than those who give away commit access easily/ have lazy maintainers. It seems obvious when I put it like that.

The way I understand it, the cathedral model is about carefully planning out the project, assigning various people chunks of the total work. The bazaar model is open to accepting random contributions from a wider audience, and runs on a looser agenda. It's just that the cathedral model works better for certain kinds of software (games, office suites, professional audio/ video suites), while the bazaar model works better for other kinds of software (web servers, version control systems, development toolchains). When it comes to an operating system, having a curator decide APIs and standards (OS X) certainly wins over an mashup of billions of packages (Debian).

Re: A Generation Lost in the Bazaar

#240

Earlier quoted context omitted.

That's a false dichotomy -- a straw-man -- that's you're using to discredit the idea of planning ahead. Compare FreeBSD kernel design versus Linux. kqueue vs. dnotify/inotify/??? Mach-descended VM vs. a string of linux-vms BSD scheduler, ULE scheduler vs. how many different schedulers? Linux churns through ill-conceived solutions to problems until they find one acceptable enough. FreeBSD grinds on one until it defini…

It's very interesting that you bring up kqueue. I was about to bring up kqueue, but for a different reason. Planning ahead can lead to great things. The Notre Dame, and the dozens of other cathedrals throughout Europe are positively stunning ... I love and I hate kqueue. I mean, I love kqueue. I love the way it can be used from C, I love the way it's integrated in MacRuby...I spent the weekend studying Clojure's redu…

> I hate kqueue because, in all likelihood, I'll never get to use it in a production system, because it's not in Linux. Cathedrals can be nice to look at. Bazaars are often more functional.

Except that FreeBSD is functional in production, so what is the actual problem? That market effects and accidents of history resulted in Linux becoming more widely adopted?

What does that argue for, exactly?

Post reply on HN