3 ms·

> 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 h

> 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 for some of the worst ideas and bad code that can be found at Apple. The historical lack of good centralized vision on aspects of the Core OS -- such as Objective-C -- has led to staggering missteps and ridiculous inefficiencies on behalf of both the framework and compiler teams. This has been to nobody's benefit and the sum result is clearly inferior to better-designed language work done elsewhere (eg, MS). Likewise, the ability for applications teams to drive forward ill-conceived OS and framework hacks has led to some terrible long-lasting implementation failures, which is something a coherent top-down vision could have prevented. However, the fact is that products can succeed despite of their poor implementation. Costs may be higher, bug counts may be higher, and user satisfaction may be lower, but that hasn't always stopped Apple from building successful products. Where I take umbrage is in the notion that there's a dichotomy -- either you do things poorly and let intellectual lazy engineers take the lead, or your product does not succeed. That's not accurate. I don't think Apple is a good case study for your point.

jballanc 14y ago
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 along the way.
- flatline3 14y ago
  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.
  - jballanc 14y ago
    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.
    - flatline3 14y ago
      > 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?
      - jballanc 14y ago
        If Linux became more popular/more widely supported by mere chance, then there's nothing to argue about, and nothing to learn...
        flatline3 14y ago
        It's not chance, but it was very likely due to market conditions that have little to do with development methodologies or outright code quality. http://en.wikipedia.org/wiki/USL_v._BSDi http://en.wikipedia.org/wiki/USL_v._BSDi was hugely crippling at a very critical moment. In a similar vein, PostgreSQL lost out to MySQL in no small part due to: - PHP supported MySQL out of the box. - MySQL was slightly easier to get running. If there's a lesson we ought to learn, it's that market success may be partially or fully disassociated from actual merit relative to other market entrants. We've seen this in commercial software. It would be foolish to think it doesn't apply to open-source.

jballanc 14y ago

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 along the way.

flatline3 14y ago
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.
- jballanc 14y ago
  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.
  - flatline3 14y ago
    > 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?
    - jballanc 14y ago
      If Linux became more popular/more widely supported by mere chance, then there's nothing to argue about, and nothing to learn...
      - flatline3 14y ago
        It's not chance, but it was very likely due to market conditions that have little to do with development methodologies or outright code quality. http://en.wikipedia.org/wiki/USL_v._BSDi http://en.wikipedia.org/wiki/USL_v._BSDi was hugely crippling at a very critical moment. In a similar vein, PostgreSQL lost out to MySQL in no small part due to: - PHP supported MySQL out of the box. - MySQL was slightly easier to get running. If there's a lesson we ought to learn, it's that market success may be partially or fully disassociated from actual merit relative to other market entrants. We've seen this in commercial software. It would be foolish to think it doesn't apply to open-source.