The Open Source Paradigm Shift
Tim O'Reilly has written up a talk he has given about the open source paradigm shift, which he describes as fundamental and long-term changes in the technology world brought on by the widespread adoption of Free and open source software.
Totally
Really?
Tim O'Reilly is right more than he is wrong, though. IBM did choose to make the PC open. The early PCs from IBM actually came with schematics! You could easily get the source for the BIOS! (Not useful for cloning a PC since the BIOS was still under a proprietary license.) IBM made no effort to exclude anyone from making accessories for the PC, or software for it.
It's widely believed that IBM did these things because it didn't take PCs very seriously; it didn't view PCs as a threat to its other lines of business. Ironically, it was the very openness of IBM's PCs that led to them demolishing so much of IBM's old lines of business.
The Apple II came with a schematic and with code listings. It seems probable that IBM was deliberately doing things the same way the Apple guys did things, hoping to duplicate the success with a similar recipe. But an open platform with the IBM brand turned out to be a huge success, far beyond what IBM ever expected.
P.S. I have no special inside knowledge of what was going on at IBM, but there are a few things I consider interesting that may indicate what IBM was worried about.
The original PC keyboard was painful for typing; in particular it was hard to hit the right shift key. I believe this was just to help ensure that IBM's word processors (single-task computers, that did nothing but word processing) were not put out of business by the PC. Of course, after-market keyboards came out with saner key arrangements, word processing software became popular, and dedicated word-processor boxes were in fact put out of business by the PC.
The original IBM AT came with a socketed clock chip, which ran the AT at 6 MHz. But the schematic clearly showed that the system was designed to run at 8 MHz. People replaced the socketed crystal and pushed their ATs to 8 MHz, and found they ran perfectly stable. (Overclocking!) I believe this was because IBM's minicomputer group was starting to worry about PCs displacing IBM's lower-end minis. Of course, clones of the AT came out with faster and faster 286 chips.
When the 386 came out, everyone waited for IBM to release a PC with a 386. Months went by. Finally Compaq, in a bold move, made a Compaq AT clone that had a 386 instead of a 286, and the rest is history. IBM had abandoned its leadership role, and never reclaimed it. I believe that IBM's minicomputer group was seriously worried about 386-based PCs, and IBM couldn't come to the decision to launch a 386-based computer in time to be first. (IBM was the leader only as long as it was leading. When it tried to lead the customers to a place they didn't want to go -- the proprietary, locked-down PS/2 computers -- the customers didn't follow.)
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
To clarify that a bit:
Comprehensive Linux Support
Dell supports your computer to help ensure the proper hardware functionality. Computers purchased with Red Hat Linux factory installed also come with installation and configuration support from Dell and a one or three year subscription to the Red Hat Network. Red Hat Network allows administrators to efficiently manage the systems on their network. Through a simple user interface, administrators can perform patch management, updates, monitoring, and maintenance.
For workstations that are shipped with Linux, they offer support. This seems pretty reasonable. I can't imagine having to support every operating system someone tries to put on their hardware.
Programming commercial software must:
- Focus on maximizing the feature list and on marketing demands
- Protect their intellectual property by providing API's instead of file formats.
Programming Open Source means:
- Make sure that the features in the system actually work as intended.
- Exploit synergi effects with other software (interoperability, using the code, piping etc.)
- Use well defined file formats instead of APIs.
Did you know that the Microsoft Access file format is "company confidential"? Actually, the precise file format is probably not even written down anywhere in an internal document, since you don't need it - you just use the same code to read a block that you used to write it. It was never intended to be read by more than one implementation of the file format.