>I suppose you might mean that there isn't much coordination between >any two of those projects, but you ought to realize that your own dev >team probably has no idea what the NDS team is doing right now, nor >what the SuSE team is doing, etc., etc.. In fact it's at least as >difficult for teams in a company to coordinate as it is for open >source projects to coordinate where needed. The fact that there isn't >a CEO at the top trying to keep investors, customers, and market >analysts happy (not a bad thing) doesn't mean that there won't be >cooperation between projects where needed. For an example see >freedesktop.org which is actively coordinating efforts of KDE and >GNOME so that they can be in many ways compatible. Well, that's what I mean, there is not as much coordination between projects. Of course Open Source development has projects leaders and stuff. And of course I've no clue what the NDS or the SuSE team is working on right now as I have my own projects to worry about. But my point does not have to do with having a CEO on top. Consider 2 things: 1)Having a whole QA Testing branch in your company that will make sure everything works with everything (I should know that, I have done a little bit of that testing myself, and I have friends in the Engineering QA team). If not, ask Dr. Knutson of the CS Dept., he worked as Testing manager here a few years ago. 2)There is a CIO that takes decision on standards for the company (if you want to know, Novell has officially adopted Firefox 0.9 as the official browser, and we test our web applications against it more than with IE, Mozilla Navigator and other browsers). This influences what technologies will be pushed by a company and will determine eventually what components, programs, libraries, technologies, etc are expected to have in the box when running our software. For example, in the case of a Mac, you can almost for sure expect to have MacOS, Photoshop and Dreamweaver and an expected set of libraries. In Windows or Linux, since there are so many third-party vendors/Open Source development groups making things for it, it is less certain what they have in their boxes and what versions of a specific library will work with your software and which newer versions won't. Don't misundertand me; many vendors are good(competition = lower prices) and Open Source development is the best thing to ever happen, but the problems described in the article are side-effects of it, and they are preventable by putting an extra effort. There is nothing wrong with the we-have-a-nice-command-line-program-let's-make-a-GUI-for-it paradigm. It has any advantages, and as long as we are careful when making these front-ends, we keep all of those features (just the ol' good Model-View-Controller approach) -Chris Alvarez
____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
