The problem here is IS management. They are increasingly clueless and are easy prey for vendors who claim that the difficult and complex task of systems development can easily be solved by mediocre developers with a souped-up IDE. Ask the average "VB guy" if they know what a finite state machine or Statechart is. Or if they know how to elicit data requirements from users and end up with a normalized ERD. Usually, I get some guy who can make an entry in a grid become deleted by dragging the entry to a trash can and have a flame pop out of the top of the can followed by a puff of smoke. But when I tell him that the file I'm sending him is sorted and that he should use a binary search to quickly look things up in it, he tells me VB can't do that. Oh well...
Is it fair to characterize the Linux development process/community as communistic? Lets see... centralized control (what puts the "red" in Redmond anyway?), iron curtain erected around their source code - exposing to the world what they want it to see and covering up deficiencies, rolling over dissenters (isn't this what the monopoly trial is all about), resulting in a bloated, inflexible, lumbering, bureaucratic morass that never quite works as expected but there's not a whole hell of a lot you can do about it. Sound familliar?
I loved the insight about Linux returning us to the '80's. I might add that this time - rather than having a more expensive and better alternative to the PC/DOS configuration, now - with Linux - there is a cheaper and better alternative. Also, the 30 year old technology issue I believe is right on. The same concept can be applied to the automobile engine. Open Source for tools like OS's, programming languages, email, etc. works because these items are well understood. With Linux, Perl, etc. we have well crafted tools for software engineers based on the best practices in our field.
Slashdot Mirror
The problem here is IS management. They are increasingly clueless and are easy prey for vendors who claim that the difficult and complex task of systems development can easily be solved by mediocre developers with a souped-up IDE. Ask the average "VB guy" if they know what a finite state machine or Statechart is. Or if they know how to elicit data requirements from users and end up with a normalized ERD. Usually, I get some guy who can make an entry in a grid become deleted by dragging the entry to a trash can and have a flame pop out of the top of the can followed by a puff of smoke. But when I tell him that the file I'm sending him is sorted and that he should use a binary search to quickly look things up in it, he tells me VB can't do that. Oh well...
Is it fair to characterize the Linux development process/community as communistic? Lets see... centralized control (what puts the "red" in Redmond anyway?), iron curtain erected around their source code - exposing to the world what they want it to see and covering up deficiencies, rolling over dissenters (isn't this what the monopoly trial is all about), resulting in a bloated, inflexible, lumbering, bureaucratic morass that never quite works as expected but there's not a whole hell of a lot you can do about it. Sound familliar?
Hey Bill, I got your fancy standards right here. You made your bed, now piss yourself in it.
I loved the insight about Linux returning us to the '80's. I might add that this time - rather than having a more expensive and better alternative to the PC/DOS configuration, now - with Linux - there is a cheaper and better alternative. Also, the 30 year old technology issue I believe is right on. The same concept can be applied to the automobile engine. Open Source for tools like OS's, programming languages, email, etc. works because these items are well understood. With Linux, Perl, etc. we have well crafted tools for software engineers based on the best practices in our field.