![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
elfsThere's an article today from the manager of IT infrastructure at Princeton University dissing free software and calling it the product of, and I quote, "kids too young to work at Redmond." Go find it off Slashdot.
I do hope he's kidding.
Do you know how to make a car? The principles by which a car operates-- the internal combustion engine, with its timing system for different pistons, the gearbox, the fuel injector, the valves, the fuel pump, the transmission, the exhaust system-- are all knowledge that can be found in any library anywhere. "How a car works" is no secret. There are no patents to circumvent or avoid; the basic principles of automotive manufacture have been around for decades.
If you don't know how to make a car, you can find out. The knowledge is freely available. It's basic commodity knowledge.
Do you know how to make an operating system? The principles by which an operating system works-- the timing issues, memory organization, virtualization, process isolation, hardware interaction, graphics rendering layers, window management-- are all knowledge that can be found in any library anywhere. "How a computer works" is no secret. At a fundamental level, there are no patents to circumvent or avoid; the basic principles of software implementation have been around for decades.
If you don't know how to write an operating system, a shell, a graphics layer, a window manager, a toolkit, and applications, you can find out. The knowledge is freely available. It's basic commodity knowledge.
The difference between making a car and making an operating system is that the former has capital costs involved in making copies: you need raw materials to make copies of your car. The raw materials needed to make copies of computer programs, however, are already in the possession of people who may want that copy-- an internet connection and some free disk space.
If you make an improvement on your car, it's hard to transfer that improvement to someone else. It takes physical labor to improve your car. Not so with an operating system-- once you've made an improvement, everyone else can have that improvement without the need for capital investment. Done right, the time investment isn't that great either.
The article says, "We may have to give up project planning, quality control, coding standards, accountability, version control, and support, but it's FREE." No, the code is commoditized, meaning it's free-as-in-speech. It's based on the same knowledge principles that go into automobile manufacturing, or shirtmaking, or any of the thousands of other skills that don't have special protections.
Do you know the coding standards used at Microsoft, or Sun, or IBM? Do you know the quality control that goes on there? Do you understand the accountability of these places? If not, why should you trust them?
You can know these things with respect to open source software. It's not a secret and if there are "office politics" going on, at least the mailing lists are publicly visible, with all of the ugly rifts (X vs. XFree, FreeBSD vs. NetBSD vs. OpenBSD, etc.) well-publicized when they occur.
As for deployment, of course that's expensive. Good service people in IT are expensive. But they should evaluate each piece of software-- OS or office suite-- based on what it does and its immediate reliability, not on the promises of a company that, "Oh, yeah, we did product testing and we have coding standards."
One of the most famous quotes in Open Source history is, "Would you buy a car with the hood welded shut?" Because that's what secretive software really is-- commodity knowledge deliberately obfuscated. And these days, it is obfuscated not to protect a company's assets, but a company's reputation. Because if we really knew how ugly it was in there, we might just go somewhere else.
I do hope he's kidding.
Do you know how to make a car? The principles by which a car operates-- the internal combustion engine, with its timing system for different pistons, the gearbox, the fuel injector, the valves, the fuel pump, the transmission, the exhaust system-- are all knowledge that can be found in any library anywhere. "How a car works" is no secret. There are no patents to circumvent or avoid; the basic principles of automotive manufacture have been around for decades.
If you don't know how to make a car, you can find out. The knowledge is freely available. It's basic commodity knowledge.
Do you know how to make an operating system? The principles by which an operating system works-- the timing issues, memory organization, virtualization, process isolation, hardware interaction, graphics rendering layers, window management-- are all knowledge that can be found in any library anywhere. "How a computer works" is no secret. At a fundamental level, there are no patents to circumvent or avoid; the basic principles of software implementation have been around for decades.
If you don't know how to write an operating system, a shell, a graphics layer, a window manager, a toolkit, and applications, you can find out. The knowledge is freely available. It's basic commodity knowledge.
The difference between making a car and making an operating system is that the former has capital costs involved in making copies: you need raw materials to make copies of your car. The raw materials needed to make copies of computer programs, however, are already in the possession of people who may want that copy-- an internet connection and some free disk space.
If you make an improvement on your car, it's hard to transfer that improvement to someone else. It takes physical labor to improve your car. Not so with an operating system-- once you've made an improvement, everyone else can have that improvement without the need for capital investment. Done right, the time investment isn't that great either.
The article says, "We may have to give up project planning, quality control, coding standards, accountability, version control, and support, but it's FREE." No, the code is commoditized, meaning it's free-as-in-speech. It's based on the same knowledge principles that go into automobile manufacturing, or shirtmaking, or any of the thousands of other skills that don't have special protections.
Do you know the coding standards used at Microsoft, or Sun, or IBM? Do you know the quality control that goes on there? Do you understand the accountability of these places? If not, why should you trust them?
You can know these things with respect to open source software. It's not a secret and if there are "office politics" going on, at least the mailing lists are publicly visible, with all of the ugly rifts (X vs. XFree, FreeBSD vs. NetBSD vs. OpenBSD, etc.) well-publicized when they occur.
As for deployment, of course that's expensive. Good service people in IT are expensive. But they should evaluate each piece of software-- OS or office suite-- based on what it does and its immediate reliability, not on the promises of a company that, "Oh, yeah, we did product testing and we have coding standards."
One of the most famous quotes in Open Source history is, "Would you buy a car with the hood welded shut?" Because that's what secretive software really is-- commodity knowledge deliberately obfuscated. And these days, it is obfuscated not to protect a company's assets, but a company's reputation. Because if we really knew how ugly it was in there, we might just go somewhere else.
