but garage mechanics don't get the treatment programmers think they deserve
You can see in a lot of the comments on Slashdot that many programmers are adjusting their expectations as a result of the bubble bursting, regardless of what they may think they deserve.
I've met some pretty clueless programmers who wouldn't know how to meet a deadline if it kicked them up the arse.
Man oh man, so have I! And who hired them? Some manager with a hiring schedule he felt he had to meet, even it meant just taking the next available body. Or some manager who just wanted enough direct reports to justify having managers reporting to her. That's clueless in my book.
The typical syndrome is the belief that programming is an art and other people "wouldn't understand".
Whether programming is an art is debatable, and depends a lot on what kind of programming we're talking about. But that "other people" don't understand is fairly well supported by empirical evidence.
OSS political advocacy just digs a deeper ditch frankly.
Not sure I know what you mean there. But my reference to advocacy was intended to more general than that. Specifically I was imagining the situation where you find yourself on a team at the beginning of a project. Because your manager is clueless, s/he has turned over decisions about what language and tools to use to the team as a whole, rather than making an intelligent choice or delegating the choice to a senior developer. So the members of the team need to have the social skills to advocate for the tools they feel are best suited for the project, be they OSS or not. In my mind, this accounts for why so much code is written in Perl these days.:-)
But as the article shows, only 16% of them know how to do this.
If 16% of garage mechanics really knew what they were doing, I would have found one who could fix my car by now. For the proportion of doctors who can do something more than prescribe what the drug companies tell them to, 16% sounds about right. And similarly for most other professions.
I agree with you that the skill that used to be required more is "SOLVING PROBLEMS". That's what I meant when I said it was like solving a puzzle.
These days a lot more knowledge is required. For the problem space you suggested, you would have to be familiar with PHP, HTML, SQL, an operating system, a database, a web server, and maybe even HTTP, CGI, and non-standard behaviors of various browsers. You probably wouldn't need to be expert at any of these, but even a "PHP-kiddie" would need some knowledge of each.
Today it's all about how much knowledge of various components you have. Just look at the typical job posting. Unlike problem solving skills, such knowledge has a tendency to become obsolete rather quickly, as versions or fashions change. (Trying to keep current with all the different components was what brought me to Slashdot.)
Today's programmers also need more social skills to deal with clueless managers, and to advocate effectively for using their favorite language, operating system, etc, etc. In the old days, it was easier to be a (successful) lone wolf. And also in the old days, there were no software patents to worry about.
In the old days of machines of 8KB of memory and sub-Mips processors, programming was easier. The space of what programs you could potentially implement was much more limited than today (although both are obviously very large spaces). Most of the development time back then was devoted to figuring out how to implement a program, e.g. how to fit it in memory and make it fast. The was no operating system and the language was assembly (for the 8KB sub-Mips machines anyway).
Today we spend a great deal more time deciding what a program should do, since better machines have expanded the possibilities to an extent we could scarely imagine 35 years ago. But we also spend more time deciding how to implement programs, though for different reasons than before. Now we choose languages, databases, GUI frameworks, and on and on. And the basis for making those choices intelligently involves much more knowledge than was needed before, i.e. not just knowledge of the target machine, but knowledge of the capabilities of the potential languages, operating systems, databases, etc. So the how part is now much more knowledge intensive, whereas it used to be more like solving a puzzle.
So programming really has gotten harder! Is it really any wonder it takes longer and is so often screwed up?
How to improve the situation? Well, the what part is only going to get worse, and we want it to, because that means we can do more with computers. The how part, on the other hand, can and probably will get easier. Standardization is the easiest way that can happen, though I wouldn't call standardization "easy". Using higher levels of abstraction is another way, but the current means of achieving this is mostly through components, the use of which narrows the spaces of both what and how. The problem is that component packages often make incompatible decisions about the how of their implementation, which often makes it difficult to combine multiple packages. And that gets back to the need for standardization.
One way to answer the question of who or what you really are is to do a thought experiment where you imagine various physical and mental attributes being taken away from you.
Would you still be you without arms? Without legs? Without sight? In a different body? As the opposite gender?
Would you still be you if you lost certain memories, or knowledge? What if you lost the ability to form new memories or to learn new things?
Would you still be you without language?
In the end, you are what you define yourself to be, and that definition may have shades of grey. For myself, as long as there are geeks in the world, I am (in a sense) immortal.
In 30 years your computer(s) will initiate physical interaction with you, instead of you interacting with a passive box. We're talking robots of various sorts, some of which have been imagined, and some not. Software complexity will be about 2 to 4 times what it is today, which will put much of it beyond the understanding of a single human mind.
The central issue for users will be trust. How much do you trust the capabilities and responses of the various robotic devices, particularly in novel or extreme situations? And consider the potential for malware with robots...
If the goal is to express programs more briefly, presumably at a "higher level", then I don't believe an extensible language alone can solve the problem. After all, we already have languages which are extensible to varying degrees. In my experience, code that maximizes the use of language extensibility tends to be the most cryptic to read, at least until you thoroughly understand all the extensions used. Witness C++ code that makes heavy use of overloading and templates.
A large part of the problem (IMHO) is the slowness of developers in standardizing common data types and programming idioms. I'm not a linguist, but there must be some interesting parallels here with the development of human language. However, there is one important difference: programmers are usually more concerned about getting a computer to understand their programs than getting other programmers to understand them. Thus, there isn't the same motivation that Tak and Nog would have had to agree on the linguistic expressions and social conventions that would allow them to hunt the woolly mammoth and divide up the women.
In fact, experienced programmers do tend to standardize their own use of language extensions, libraries, and program development tools, as this does enable them to program more efficiently. Many software companies do the same, which is probably how they manage to accomplish anything at all. But most software companies place very little priority on creating industry standards (unless, of course, they think they can own them).
The broader issue here is: who is responsible for what?
LLBean really should not be acting as if it owns the content of your desktop when you visit their site, because it doesn't. However, it is responsible for defending its trademark in a new environment where the applicability of previous legal precedents may be unclear. If we say that LLBean shouldn't defend its trademark in this way, then we must also agree that these tactics of its competitors should not jeopardize the trademark.
And who is responsible for the spyware? Not Gator, because everyone knows that manufacturers of software are not responsible for anything, whether the user has to acknowledge this by clicking "Agree" on a EULA or not. And for the same reason, Microsoft is not responsible for the loose security that often facilitates the perpetration of spyware on the unwitting.
I mean, really, what software manufacturers would have us believe is that they have no responsibility for what their software does or doesn't do, perhaps with the exception of specifically advertised features. Likewise developers of free software certainly don't want any (legal) responsibility for what they produce, since most can't defend a lawsuit. [You read it here first: common ground between free software developers, Gator, and Microsoft!]
So who is responsible? Well, at the moment it must be the users who are responsible for their own desktops, as difficult as that is these days. There might also be some responsibility with the legislature (and by implication, voters, including the many who are MIA) for not passing appropriate laws to clarify the situation. But some might argue that many of the laws already passed regarding the use of computers and the internet were premature, and as a result, made the situation worse. Personally I think it's because many of them were motivated by greed and fear, with the dependable support of the ignorant.
Better yet, buy a lottery ticket, and only put the gun to your head and pull the trigger if you don't win. If MWI is correct, you'll be rich in most(*) of the universes in which you continue to exist. We suspect Bill Gates may be using a more refined variation of this.
(*) There would be a relatively smaller number of instances of you who lost but could not get the gun to function correctly.
[Moderators, please don't moderate this as informative, or some nitwit may actually try it!]
The central debate here is about how to best use F/OSS development resources (people and code). The assumption seems to be that everyone who cares about F/OSS should come together on a single strategy for dealing with Microsoft. But a monoculture within the F/OSS community is exactly what we're fighting against in Microsoft! Must we become the enemy to defeat the enemy?
Most F/OSS developers want to see GNU/Linux succeed in the sense of becoming a widespread desktop alternative. Those who bother thinking about why they want this are most likely to come up with a fundamental reason: choice.
Survival for GNU/Linux is a question of the niches it is able to successfully occupy. For the moment these niches include the desktops of F/OSS developers and Internet server farms. The problem with the general user desktop niche is first that it's not really a niche per se, but more importantly, it's completely dominated by Microsoft. GNU/Linux is like a small mammal running around near the end of the age of dinosaurs. What it has going for it is adaptibility. Rather than give up adaptibility and become just another dinosaur, GNU/Linux needs to find another way to occupy the general desktop niche.
What I'd like to suggest is that the desktop niche really needs to be bifurcated in such a way that GNU/Linux can survive there as a small mammal, without needing to become a dinosaur. That is, it needs a place on the desktop where it can run without necessarily displacing Windows. One way this could be done is though a Windows port of User Mode Linux, but that's not really going far enough in my opinion.
What is really needed is an OSS virtual machine monitor (VMM) for PCs, under control of which both Windows and GNU/Linux (and any other OS!) could run separately and equally. Vmware shows what this might look like, but with Vmware the host operating system runs along side the VMM rather than on top of it. It sort of achieves "separate" but not "equal".
The problem with current approaches to PC VMMs is that they suffer from certain
architectural limitations
in virtualizing the CPU. These limitations probably could have been eliminated several hardware generations ago, were it not for the unholy alliance of Microsoft and Intel. But there is some hope that that alliance could be broken, if AMD would implement virtualizability in its CPUs and/or IBM would apply carrots and sticks to Intel on behalf of GNU/Linux.
The ultimate goal is freedom to innovate from the lowest levels of software on up. This can only be truely achieved by a complete OSS platform, as access to the source is what enables the kind of innovation that does not require reinventing the wheel when something at a lower level doesn't work the way you want it to. On the other hand, some F/OSS developers may be perfectly happy developing on top of Windows or some OS-independent application platform. Indeed, there's no reason to believe that.NET isn't "good enough" for some of them.
Basically things got out of control between 98 and 2001 as venture capital flowed into companies that were required to grow quickly by the venture capital. All of the good talent was hired quickly, and then some of the average talent was hired. All that was left was the basic low-no skill talent.
Another interesting thing that happened was that good talent became diluted across the many new companies that were started. Each one of these companies would compete fiercely for at least one good person, and as a result, not too many companies managed to have entire teams of mostly good people.
I would credit that for many of the dotcom failures.
A couple minutes with a spreadsheet will show that 1 - 1% is.99, and 99 - 99% is also 0.99... but 50 - 50% is 25! It's a bell curve, and there's definitely a sweet spot there.
its kinda like putting a million bucks in the bank and living off the interest, but also putting aside enough of the interest to increase your returns.
Pardon my going off-topic, but, what bank is that? I'm only getting 2%, and that's not enough to live on, let alone enough to put any aside.
This course has 100% confirmed by belief that the industry wants nothing to do with craft programming. They want what they call "ego-less" programmers that don't care about their own work as much as the group as a whole's work.
I don't disagree with what you're saying, but I think part of the reason industry is going this way has to do with the meaning of "ego-less". There are good and bad aspects to having your ego involved in your work. Obviously it's good when it results in you caring about the quality of your work. But it can also be bad when a programmer is so ego-invested that they want all the credit for a group project, or become blind to or defensive about the possibility of bugs in their own code. I've seen this happen many times. I've actually known of certain corporate cultures (**cough** Ora **cough** cle) where this kind of immaturity seemed to be encouraged.
The ideal (IMHO) is something like the ideal for a sports team, where you have a group of people, each with different talents that are needed at different times in a game. "Ego-less" in that context means someone who will use their unique talent to the fullest at the appropriate times, but will step back and support the others to the best of their ability at other times, always remembering that the goal is for the team to win the game. Such a person is usually both highly valued by team owners and well respected by their peers.
The trick, I think, is to put your ego into creating the best "you" you can be. Make yourself the work of art more than the code.
Absolutely this will happen, and I don't think it's arrogance but greed that drives the executives making the outsourcing decisions. They figure to be retired by the time it's an issue.
I don't believe there is any inherent difference in the raw talent between Indian (or any other ethnicity) programmers and American. However, at the moment I believe American programmers are generally better (but still not particulaly well) trained. That will change as Indian education gets better and American education gets worse.
There actually may be cultural differences that give American programmers an advantage with respect to their ability to innovate. But we can already see that culture is going to become less geographic and more virtual, just by looking at Slashdot. So that will not be a long-term obstacle.
Other than that, there may be infrastructure differences that could hold back independent Indian software companies, but probably not for long.
I believe globalization is inevitable and has the potential to be a positive development for the human race. But I'm not so sure that globalization in the form of raw, unchecked capitalism would be a good thing. And the process of globalization seems likely to be detrimental to some people's standard of living for perhaps several generations.
Agreed, and well said. Submitted for your approval, the conservative's version of the Serenity Prayer:
God grant me the serenity to accept the changes I cannot stop
Courage to maintain unchanged the things I can
And the wisdom to know the difference
Those of us who fondly remember pre-spam email should remember that it existed mostly before the commercialization of the Internet. To follow the biological metaphor a little further: the gene for spam was always present in SMTP email, but it only became expressed when the environment in which SMTP operated changed. Spam is what you get when you mix SMTP and human beings in the environment of the commercial Internet. Laws are not going to stop it, any more than laws are going to stop P2P.
Technological developments cause change, sometimes for better, sometimes for worse, and sometimes both at once. Our ability to control the impact of technological change depends not only on our ability to predict the impact, but also on our ability to grasp the consequences for our daily lives. And apparently we aren't very good at that.
Consider the background technology in the movie, "Minority Report" (realtime audio/visual spam enabled by wireless and ubiquitous computing, coupled with biometric identification). Does anyone think that's not going to happen? Yet we are happily advancing these technologies as quickly as possible.
Not that I think technological change can really be stopped by anything short of a civilization-busting disaster, but it seems like we'd be better off if we spent more time thinking about and preparing for the consequences of technological development.
As a Canadian, I have to agree with Cringley, we were all laughing during the election of 2000 and still laugh at the e-voting system.
Given Canada's proximity to the US, I wouldn't think that you'd find the potential collapse of democracy in the US any funnier than they do. Actually proximity may not even matter that much.
First, M$ might not make very secure software, but they sure got a load of
talented people working there, and even if their software is crap they know how
to do some things right, the NT kernel is not all that bad(after all, it's just
VMS;)), and they did put a *load* of effort in making drivers compatible, and
they had the src for all the OSes they wanted to make compatible, and they
still failed miserably, other efforts by a bunch of amateur kids aren't going
to work much better(and if you do some research, you will find that some other
people have tried, and failed too).
The problem Microsoft tried to solve was actually a different problem. They were trying virtualize an internal OS driver API, rather than virtualize an API to the hardware itself. That's a harder problem, but I'll still not accept their failure as proof of impossibility.
I was aware of the Uniform Driver Interface (UDI) project, but again, I don't think their goal was exactly what I had in mind. They specify a "UDI environment", which is an API to be provided by any OS that wants to support UDI drivers. What I'm talking about is making the proprietary driver code present an API much more like a device BIOS interface.
And yes, I *really* need to know how to interface with my hardware, and no,
adding a layer of proprietary software on top of proprietary hardware is *not*
OK, for *many* reasons, for example security, stability, CPU and OS
portability, etc...
Yes, you do need to know how to interface with your hardware, and so does everyone else who wants develop an OS. Issues of security and stability apply to hardware as well as software. Although I am addressing OS portability, CPU portability would remain an issue. It could be addressed by releasing proprietary code in some low-level intermediate code, or by the device manufacturer simply responding to reasonable requests from developers.
In all cases specs are withheld to screw the user, and nothing else, which is
*exactly* what Open Source tries to avoid.
Chill. It's not that black and white, as several other posters have pointed out.
You have to remember that in Open Source, we are all the developers, and M$ got
access to the src of all their drivers(their license for hardware vendors force
them to give the src to M$), and we at the very least need the same.
M$ no doubt also agreed not to disclose the vendors' source to the whole world. Open Source can't make that same agreement by its very nature. Nevertheless, I won't claim that even that concession was necessary, given M$'s monopoly power. I certainly would encourage you to go back to the hardware vendors and try again as soon as Open Source takes over the world (which would be fine with me).
And don't even tell me about those "cross-platform-driver-interfaces", what a
joke... FYI, that didn't work for M$, and it wont work for anyone else, M$
tried to make a "standard" driver interface to allow win9x drivers to work on NT,
it was a *DISASTER*; there are loads of hardware out there that didn't make the
transition and has *no* drivers for WinNT/2k/xp, because the manufacturers were
bankrupt, because they were clueless, because they wanted you to buy new
hardware; do you want the same to happen with Linux?
Yes, and M$ keeps trying to make a secure version of Windows and so far that's a disaster too. You aren't seriously suggesting that if M$ can't do something then it can't be done? Hardware can be virtualized in software.
If I buy something, I have a *right* to know how it works and how I can use it
in any OS I like.
I sympathize, but how many device manufacturers provide hardware schematics. Don't you really need those to really know how it works? Providing proprietary software with the proprietary hardware is just drawing the line a little higher. If the proprietary software is buggy, don't buy the product (just as you wouldn't buy buggy hardware). And you'd find out real quick whether the software is buggy if Windows were using the same proprietary binary.
An even better alternative would be for the proprietary part of the driver to be a provider of a public, documented API, so that anyone could write a driver for it for any OS, instead of it being a consumer of some particular OS driver API. This would completely eliminate the need to use any GPL'd code in the proprietary driver binary.
Such an API could (and in many cases should) conceal proprietary aspects of the associated hardware, and in so doing perhaps remain stable for more than one generation of the hardware. Also, such an API could (but in most cases should not) have hidden functionality (e.g. "reserved" arguments to functions) that could be transparently used by proprietary application code (assuming the driver for a particular OS passes the arguments through unchanged).
Slashdot Mirror
You can see in a lot of the comments on Slashdot that many programmers are adjusting their expectations as a result of the bubble bursting, regardless of what they may think they deserve.
Man oh man, so have I! And who hired them? Some manager with a hiring schedule he felt he had to meet, even it meant just taking the next available body. Or some manager who just wanted enough direct reports to justify having managers reporting to her. That's clueless in my book.
Whether programming is an art is debatable, and depends a lot on what kind of programming we're talking about. But that "other people" don't understand is fairly well supported by empirical evidence.
Not sure I know what you mean there. But my reference to advocacy was intended to more general than that. Specifically I was imagining the situation where you find yourself on a team at the beginning of a project. Because your manager is clueless, s/he has turned over decisions about what language and tools to use to the team as a whole, rather than making an intelligent choice or delegating the choice to a senior developer. So the members of the team need to have the social skills to advocate for the tools they feel are best suited for the project, be they OSS or not. In my mind, this accounts for why so much code is written in Perl these days. :-)
If 16% of garage mechanics really knew what they were doing, I would have found one who could fix my car by now. For the proportion of doctors who can do something more than prescribe what the drug companies tell them to, 16% sounds about right. And similarly for most other professions.I agree with you that the skill that used to be required more is "SOLVING PROBLEMS". That's what I meant when I said it was like solving a puzzle.
These days a lot more knowledge is required. For the problem space you suggested, you would have to be familiar with PHP, HTML, SQL, an operating system, a database, a web server, and maybe even HTTP, CGI, and non-standard behaviors of various browsers. You probably wouldn't need to be expert at any of these, but even a "PHP-kiddie" would need some knowledge of each.
Today it's all about how much knowledge of various components you have. Just look at the typical job posting. Unlike problem solving skills, such knowledge has a tendency to become obsolete rather quickly, as versions or fashions change. (Trying to keep current with all the different components was what brought me to Slashdot.)
Today's programmers also need more social skills to deal with clueless managers, and to advocate effectively for using their favorite language, operating system, etc, etc. In the old days, it was easier to be a (successful) lone wolf. And also in the old days, there were no software patents to worry about.
In the old days of machines of 8KB of memory and sub-Mips processors, programming was easier. The space of what programs you could potentially implement was much more limited than today (although both are obviously very large spaces). Most of the development time back then was devoted to figuring out how to implement a program, e.g. how to fit it in memory and make it fast. The was no operating system and the language was assembly (for the 8KB sub-Mips machines anyway).
Today we spend a great deal more time deciding what a program should do, since better machines have expanded the possibilities to an extent we could scarely imagine 35 years ago. But we also spend more time deciding how to implement programs, though for different reasons than before. Now we choose languages, databases, GUI frameworks, and on and on. And the basis for making those choices intelligently involves much more knowledge than was needed before, i.e. not just knowledge of the target machine, but knowledge of the capabilities of the potential languages, operating systems, databases, etc. So the how part is now much more knowledge intensive, whereas it used to be more like solving a puzzle.
So programming really has gotten harder! Is it really any wonder it takes longer and is so often screwed up?
How to improve the situation? Well, the what part is only going to get worse, and we want it to, because that means we can do more with computers. The how part, on the other hand, can and probably will get easier. Standardization is the easiest way that can happen, though I wouldn't call standardization "easy". Using higher levels of abstraction is another way, but the current means of achieving this is mostly through components, the use of which narrows the spaces of both what and how. The problem is that component packages often make incompatible decisions about the how of their implementation, which often makes it difficult to combine multiple packages. And that gets back to the need for standardization.
One way to answer the question of who or what you really are is to do a thought experiment where you imagine various physical and mental attributes being taken away from you.
Would you still be you without arms? Without legs? Without sight? In a different body? As the opposite gender?
Would you still be you if you lost certain memories, or knowledge? What if you lost the ability to form new memories or to learn new things?
Would you still be you without language?
In the end, you are what you define yourself to be, and that definition may have shades of grey. For myself, as long as there are geeks in the world, I am (in a sense) immortal.
In 30 years your computer(s) will initiate physical interaction with you, instead of you interacting with a passive box. We're talking robots of various sorts, some of which have been imagined, and some not. Software complexity will be about 2 to 4 times what it is today, which will put much of it beyond the understanding of a single human mind.
The central issue for users will be trust. How much do you trust the capabilities and responses of the various robotic devices, particularly in novel or extreme situations? And consider the potential for malware with robots...
If the goal is to express programs more briefly, presumably at a "higher level", then I don't believe an extensible language alone can solve the problem. After all, we already have languages which are extensible to varying degrees. In my experience, code that maximizes the use of language extensibility tends to be the most cryptic to read, at least until you thoroughly understand all the extensions used. Witness C++ code that makes heavy use of overloading and templates.
A large part of the problem (IMHO) is the slowness of developers in standardizing common data types and programming idioms. I'm not a linguist, but there must be some interesting parallels here with the development of human language. However, there is one important difference: programmers are usually more concerned about getting a computer to understand their programs than getting other programmers to understand them. Thus, there isn't the same motivation that Tak and Nog would have had to agree on the linguistic expressions and social conventions that would allow them to hunt the woolly mammoth and divide up the women.
In fact, experienced programmers do tend to standardize their own use of language extensions, libraries, and program development tools, as this does enable them to program more efficiently. Many software companies do the same, which is probably how they manage to accomplish anything at all. But most software companies place very little priority on creating industry standards (unless, of course, they think they can own them).
The broader issue here is: who is responsible for what?
LLBean really should not be acting as if it owns the content of your desktop when you visit their site, because it doesn't. However, it is responsible for defending its trademark in a new environment where the applicability of previous legal precedents may be unclear. If we say that LLBean shouldn't defend its trademark in this way, then we must also agree that these tactics of its competitors should not jeopardize the trademark.
And who is responsible for the spyware? Not Gator, because everyone knows that manufacturers of software are not responsible for anything, whether the user has to acknowledge this by clicking "Agree" on a EULA or not. And for the same reason, Microsoft is not responsible for the loose security that often facilitates the perpetration of spyware on the unwitting.
I mean, really, what software manufacturers would have us believe is that they have no responsibility for what their software does or doesn't do, perhaps with the exception of specifically advertised features. Likewise developers of free software certainly don't want any (legal) responsibility for what they produce, since most can't defend a lawsuit. [You read it here first: common ground between free software developers, Gator, and Microsoft!]
So who is responsible? Well, at the moment it must be the users who are responsible for their own desktops, as difficult as that is these days. There might also be some responsibility with the legislature (and by implication, voters, including the many who are MIA) for not passing appropriate laws to clarify the situation. But some might argue that many of the laws already passed regarding the use of computers and the internet were premature, and as a result, made the situation worse. Personally I think it's because many of them were motivated by greed and fear, with the dependable support of the ignorant.
Better yet, buy a lottery ticket, and only put the gun to your head and pull the trigger if you don't win. If MWI is correct, you'll be rich in most(*) of the universes in which you continue to exist. We suspect Bill Gates may be using a more refined variation of this.
(*) There would be a relatively smaller number of instances of you who lost but could not get the gun to function correctly.
[Moderators, please don't moderate this as informative, or some nitwit may actually try it!]
The central debate here is about how to best use F/OSS development resources (people and code). The assumption seems to be that everyone who cares about F/OSS should come together on a single strategy for dealing with Microsoft. But a monoculture within the F/OSS community is exactly what we're fighting against in Microsoft! Must we become the enemy to defeat the enemy?
Most F/OSS developers want to see GNU/Linux succeed in the sense of becoming a widespread desktop alternative. Those who bother thinking about why they want this are most likely to come up with a fundamental reason: choice.
Survival for GNU/Linux is a question of the niches it is able to successfully occupy. For the moment these niches include the desktops of F/OSS developers and Internet server farms. The problem with the general user desktop niche is first that it's not really a niche per se, but more importantly, it's completely dominated by Microsoft. GNU/Linux is like a small mammal running around near the end of the age of dinosaurs. What it has going for it is adaptibility. Rather than give up adaptibility and become just another dinosaur, GNU/Linux needs to find another way to occupy the general desktop niche.
What I'd like to suggest is that the desktop niche really needs to be bifurcated in such a way that GNU/Linux can survive there as a small mammal, without needing to become a dinosaur. That is, it needs a place on the desktop where it can run without necessarily displacing Windows. One way this could be done is though a Windows port of User Mode Linux, but that's not really going far enough in my opinion.
What is really needed is an OSS virtual machine monitor (VMM) for PCs, under control of which both Windows and GNU/Linux (and any other OS!) could run separately and equally. Vmware shows what this might look like, but with Vmware the host operating system runs along side the VMM rather than on top of it. It sort of achieves "separate" but not "equal".
The problem with current approaches to PC VMMs is that they suffer from certain architectural limitations in virtualizing the CPU. These limitations probably could have been eliminated several hardware generations ago, were it not for the unholy alliance of Microsoft and Intel. But there is some hope that that alliance could be broken, if AMD would implement virtualizability in its CPUs and/or IBM would apply carrots and sticks to Intel on behalf of GNU/Linux.
The ultimate goal is freedom to innovate from the lowest levels of software on up. This can only be truely achieved by a complete OSS platform, as access to the source is what enables the kind of innovation that does not require reinventing the wheel when something at a lower level doesn't work the way you want it to. On the other hand, some F/OSS developers may be perfectly happy developing on top of Windows or some OS-independent application platform. Indeed, there's no reason to believe that .NET isn't "good enough" for some of them.
Another interesting thing that happened was that good talent became diluted across the many new companies that were started. Each one of these companies would compete fiercely for at least one good person, and as a result, not too many companies managed to have entire teams of mostly good people.
I would credit that for many of the dotcom failures.
Actually it's a quadratic function:
yielding an inflection point at x=50.Pardon my going off-topic, but, what bank is that? I'm only getting 2%, and that's not enough to live on, let alone enough to put any aside.
I don't disagree with what you're saying, but I think part of the reason industry is going this way has to do with the meaning of "ego-less". There are good and bad aspects to having your ego involved in your work. Obviously it's good when it results in you caring about the quality of your work. But it can also be bad when a programmer is so ego-invested that they want all the credit for a group project, or become blind to or defensive about the possibility of bugs in their own code. I've seen this happen many times. I've actually known of certain corporate cultures (**cough** Ora **cough** cle) where this kind of immaturity seemed to be encouraged.
The ideal (IMHO) is something like the ideal for a sports team, where you have a group of people, each with different talents that are needed at different times in a game. "Ego-less" in that context means someone who will use their unique talent to the fullest at the appropriate times, but will step back and support the others to the best of their ability at other times, always remembering that the goal is for the team to win the game. Such a person is usually both highly valued by team owners and well respected by their peers.
The trick, I think, is to put your ego into creating the best "you" you can be. Make yourself the work of art more than the code.
Absolutely this will happen, and I don't think it's arrogance but greed that drives the executives making the outsourcing decisions. They figure to be retired by the time it's an issue.
I don't believe there is any inherent difference in the raw talent between Indian (or any other ethnicity) programmers and American. However, at the moment I believe American programmers are generally better (but still not particulaly well) trained. That will change as Indian education gets better and American education gets worse.
There actually may be cultural differences that give American programmers an advantage with respect to their ability to innovate. But we can already see that culture is going to become less geographic and more virtual, just by looking at Slashdot. So that will not be a long-term obstacle.
Other than that, there may be infrastructure differences that could hold back independent Indian software companies, but probably not for long.
I believe globalization is inevitable and has the potential to be a positive development for the human race. But I'm not so sure that globalization in the form of raw, unchecked capitalism would be a good thing. And the process of globalization seems likely to be detrimental to some people's standard of living for perhaps several generations.
Agreed, and well said. Submitted for your approval, the conservative's version of the Serenity Prayer:
Those of us who fondly remember pre-spam email should remember that it existed mostly before the commercialization of the Internet. To follow the biological metaphor a little further: the gene for spam was always present in SMTP email, but it only became expressed when the environment in which SMTP operated changed. Spam is what you get when you mix SMTP and human beings in the environment of the commercial Internet. Laws are not going to stop it, any more than laws are going to stop P2P.
Technological developments cause change, sometimes for better, sometimes for worse, and sometimes both at once. Our ability to control the impact of technological change depends not only on our ability to predict the impact, but also on our ability to grasp the consequences for our daily lives. And apparently we aren't very good at that.
Consider the background technology in the movie, "Minority Report" (realtime audio/visual spam enabled by wireless and ubiquitous computing, coupled with biometric identification). Does anyone think that's not going to happen? Yet we are happily advancing these technologies as quickly as possible.
Not that I think technological change can really be stopped by anything short of a civilization-busting disaster, but it seems like we'd be better off if we spent more time thinking about and preparing for the consequences of technological development.
Given Canada's proximity to the US, I wouldn't think that you'd find the potential collapse of democracy in the US any funnier than they do. Actually proximity may not even matter that much.
I was aware of the Uniform Driver Interface (UDI) project, but again, I don't think their goal was exactly what I had in mind. They specify a "UDI environment", which is an API to be provided by any OS that wants to support UDI drivers. What I'm talking about is making the proprietary driver code present an API much more like a device BIOS interface.
Yes, you do need to know how to interface with your hardware, and so does everyone else who wants develop an OS. Issues of security and stability apply to hardware as well as software. Although I am addressing OS portability, CPU portability would remain an issue. It could be addressed by releasing proprietary code in some low-level intermediate code, or by the device manufacturer simply responding to reasonable requests from developers.
Chill. It's not that black and white, as several other posters have pointed out.
M$ no doubt also agreed not to disclose the vendors' source to the whole world. Open Source can't make that same agreement by its very nature. Nevertheless, I won't claim that even that concession was necessary, given M$'s monopoly power. I certainly would encourage you to go back to the hardware vendors and try again as soon as Open Source takes over the world (which would be fine with me).
Yes, and M$ keeps trying to make a secure version of Windows and so far that's a disaster too. You aren't seriously suggesting that if M$ can't do something then it can't be done? Hardware can be virtualized in software.
I sympathize, but how many device manufacturers provide hardware schematics. Don't you really need those to really know how it works? Providing proprietary software with the proprietary hardware is just drawing the line a little higher. If the proprietary software is buggy, don't buy the product (just as you wouldn't buy buggy hardware). And you'd find out real quick whether the software is buggy if Windows were using the same proprietary binary.
An even better alternative would be for the proprietary part of the driver to be a provider of a public, documented API, so that anyone could write a driver for it for any OS, instead of it being a consumer of some particular OS driver API. This would completely eliminate the need to use any GPL'd code in the proprietary driver binary.
Such an API could (and in many cases should) conceal proprietary aspects of the associated hardware, and in so doing perhaps remain stable for more than one generation of the hardware. Also, such an API could (but in most cases should not) have hidden functionality (e.g. "reserved" arguments to functions) that could be transparently used by proprietary application code (assuming the driver for a particular OS passes the arguments through unchanged).