Slashdot Mirror
Why Don't Companies Release Specs?
Mhrmnhrm asks: "With the recent activism by the OpenBSD crew focusing on release of documentation from the likes of Adaptec, Intel, and others, I'm left to wonder: why do companies insist on believing that by denying access to the specs, they somehow gain an advantage? It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?"
Because it would cost them money to (1) write coherent and complete documentation and (2) review that documentation to make it safe and legal for public consumption. Why would they spend all the extra time and money to do that when it doesn't bring them any more profit?
Companies exist to make money, not to be good samaritans.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
... the more common problem is that the hardware people paid to have their drivers and stuff written for them and that a great deal of their product's functionality is, in fact, within the driver rather than within the device or firmware. These drivers are then restricted by the agreement between the driver-writing entity and the hardware maker... or so they claim. ATI apparantly has this difficulty which is why we can't get really good drivers for Linux just yet.
It's because of fear of lawsuits, not a desire to hide their chip interfaces. There are just as many bad hardware patents as bad software ones. By controlling spec release with an NDA they stop the law firms from searching for violations of these bogus patents.
The damage from keeping hardware specs out of open source hands is tiny compared to getting a $400M judgement for patent violation.
Trade secret laws prevent law firms from forcing spec releases without pretty good proof of a patent violation.
I have often wondered about this myself, back in the day of the Apple IIs and TRS-80s there were almost always hardware specs available because that was what you used to program your application with. There were no drivers or OS abstraction layers, there wasn't enough memory or speed to do that so your program just talked directly to the hardware.
The first time I realized there was a problem was back in the 90s when my brother was trying to load up Linux on one of his machines and complaining that his video card wasn't supported because the people who made it (Diamond Multimedia?) wouldn't release any specs and people were having to reverse engineer how it worked. That seemed crazy to me. Back then it wasn't just a Windows world either, OS/2 was still around and DOS apps were huge. It boggled my mind that anyone would hold back information like that because releasing programming specs would encourage third party application development that made use of their hardware and ultimately boost their sales!
Sadly these days no one seems to care as long as the vendor has a Microsoft Windows XP(TM) driver available, even if the driver is half-assed and crashes some times.
Does anyone seriously doubt that they DO?
Andy Grove (ex CEO of INTEL) described how MS prevented INTEL from including certain features in H/W. Andy's reaction was life is too short to spend it fighting MS. This was INTEL not some much smaller niche player.
...there are no specs.
Often products are created & sold based on some back-of-a-napkin drawing that a manager handed to development. I've been fortunate in my career -- I've been lucky to get them on notebook paper. It's much nicer than trying to figure out what was drawn through the martini condensation stains...
Chip H.
Thing is, we're not asking for source code to the win32 driver or firmware source code or roms or verilog source for the chips.
We're just asking which pci registers to poke to get the chip to go "bleep".
So the 'source code' argument is totally out the window, irrelevant.
I was about to mod you insightful, but then I realized what the grandparent was probably talking about... the microcode. The microcode is a lot more important for recreating details. Pentium processors have a limited ability to fix silicon bugs in software. The microcode is in volatile memory, so it must be loaded on every boot by either the OS or the BIOS. It's top-secret, but access to this lower-level info might let you write a custom instruction (or not, I don't know how much the mechanism can change the operation)
An example microcode fix is for "High Temperature and Low Supply Voltage Operation May Result in Incorrect Processor Operation"
HIV Crosses Species Barrier... into Muppets
Bill: That's nice. You know, it'd be a real shame if your driver couldn't be WHQL certified, and users had to see a warning box when they ran with your card. Or worse, if there were mysterious blue screens . . .
"It'd be a real shame when our engineers show a disassembly of your driver verification software before the last windows update and after causing our drivers to break, especially in light of this conversation. There's a few judges who might see things our way."
Claims of conspiracy are just intellectual laziness. I suspect yours was a joke, but I think many people actually believe it.
Now to make my own point: I know companies have IP arrangements that prevent them from opening drivers. Wouldn't it be nice if they disclosed this fact, or gave some kind of reasonable explanation to developers other than patting them on the head and saying "no specs today, go have some cookies". I'd just like to see the FAQ of "Why isn't the driver open source" answered truthfully and reasonably completely.
I'd also like a pony.
I am no longer wasting my time with slashdot
R&D Costs for driver development can't be recouped
When BusLogic came out with their AHA1540/AQHA1542 compatible SCSI controllers, they did several things:
(1) They leveraged Adaptec's R&D effort on driver development so that they didn't have to spend their own money developing drivers.
(2) They avoid the effort of convincing Microsoft to ship with the drivers as part of Windows; never underestimate the barrier to entry a separate driver disk represents: for NT 3.51, you had to install the driver disk twice during the installation process, and a third time post-install to use a third party disk controller, and it was not well documented where or when NT 3.51 would reference the disk, not find it, and simply crash (you "just had to know").
(3) By making the card's interface compatible with an existing card, they avoided all the R&D necessary to get from a concept to a working interface.
So basically, BusLogic got a free ride on Adaptec's dime in a number of areas, and Adaptec was left holding the bag, having to charge a higher amount to recoup their R&D investment, leaving BusLogic to undercut their prices and steal their market.
That's not to say that I totally agree with Adaptec, or that bad designs which can't be safely exposed without risking physical damage to the devices (Diamond Multimedia video cards[*]) or legal repercussions (Oscillator/PLL tuned WiFi cards that don't have hard-wired frequency bands) don't exist, but I can certainly understand the position of companies who don't want to sacrifice hard-earned product lead-times, OS vendor relationships, or actual R&D results on the altar of public domain.
[*] Diamond, in particular, pisses me off, since any halfway decent software engineer could have separated the model and view from the controller, and made their cards both Open Source friendly and non-x86 architecture friendly, and the EE who wrote the firmware didn't.
-- Terry
I used to work in the DOCSIS cable modem industry, so I'm reasonably familiar with the Broadcom 335x/334x CPU family. The best I ever saw was the datasheet for the 3416 chip (tuner chip).
For those of you who aren't aware, or don't remember, Broadcom was slapped with a lawsuit by Microtune, alleging patent violations http://news.com.com/2100-1006_3-5064586.html, (one of many articles available on this subject).
So, I was tasked with providing software support for the 3416 tuner chip (the replacement for the 3415 "problem" chip) in our cable modem product, as the 3415 couldn't legally be sold in the U.S. anymore. Well, I figured it would be easy, since the datasheets for the two chips were exactly the same, except that "3415" was changed to "3416". (And, I mean exactly the same, to the word - it was only a 15 page datasheet, so I compared them).
Nope, good old Broadcom documentation does it again... I managed to study the source code for one of the newer cable modem CPUs and find the changes between the chips. The real stupid thing though: Even though there's a version register (which tells which version the chip is), they didn't update it to indicate a 3415/3416, even though they had the bits available. So, 3416 chips would show up as 3415 chips if you try to read the version number (that made things difficult).
Incidentally, Broadcom does make Linux drivers for most of it's newer hardware, they're just meant for their customers (the OEMs making the hardware, not the end-users). The general rule with Broadcom is, if you pay them a lot of money, you get excellent support. (At the previous company I worked for, I had an engineer that would get back to me within 24 hours on any issue related to the product, because we bought so many cable modem chips. When I currently work, they won't even give us the time of day, we just don't purchase enough.)
I feel your pain, I really do.
-- Joe
It's very simple: back in the old days, when there was no monopoly, many chip manufacturers gave away thick, printed databooks. It was expensive for them, but they needed developers to use their products.
Now, however, there is a monopoly. You don't need to attract developers. The only concern is to have a driver for Windows, and having that driver included with the Windows install disk, so that your device, be it a soundcard, graphics card, or whatever, is "easier" to use. I wonder if there is a "dark hand" behind it...
Some years ago I sent a proposal to the European Comission: banning the sale in Europe of peripherals for which there is no public interface information available. It should not hurt the manufacturers, as the information can be made freely available in Internet (it's cheaper than shipping huge printed manuals), but it would have a side effect: the driver advantage for Window could disappear.