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?"

Comments

Broadcom fun

[DaHat]

Broadcom is also a big fan of not releasing much in the way of specs, even to its customers. My company has used some of their demodulator chips for years and had to beg to get some detailed specs on how to interacts with a chip in ways that it was not explicitly advertised as capable of doing (even though they admitted it was fully capable of what we wanted it to do for us)... later, when that chip became obsolete, they released a drop in replacement for it... a drop in replacement provided you were using the advertised features, things we were using, but plenty more things too suddenly went into limbo. The documentation on the new chip is ~ 1/4th the size of that of the original, so quite often we go back and forth between them, trying things that worked in the old one, hoping they still work in the new one.

Oh yes, demodulators are hella fun!

Re:Broadcom fun

[Anonymous Coward]

For my job I support a number of processors made by various vendors. Whenever somebody asks me a question about a Broadcom CPU I don't have docs for already I'm forced to answer: "I don't know, and there's no easy way to look at the docs to find the answer." (The Broadcom process to get docs is they fax you and NDA, which you sign and fax back. Then you get a .pdf with on each page stamped "Confidential for XYZ" and it's got a password to boot.) I love http://www.mips.com/ for its excellent and readily available documentation.

Re:Because it would cost them money

[ad0gg]

Very few hardware companies hold the IP rights for the technologies they implement. NDAs prevent many companies from disclosing specs to their hardware.

Re:It goes something like this:

[AnObfuscator]

Yes. I think so because microsoft DOES threaten hardware companies. It's been proven, in court, that microsoft does this sort of thing.
http://en.wikipedia.org/wiki/Microsoft#Monopoly_an d_legal_issues

In short, thinking that MS doesn't use its monopoly to intimidate PC & PC hardware makers is like believeing the world is still flat.

Re:i dunno, worked great for IBM

[linguae]

IBM didn't release the specs to the IBM PC. Compaq reversed engineered the BIOS of the IBM PC, and the rest of the PC (the Intel 8086, floppy drives, video cards, etc.) can be bought off the shelf. IBM tried to stop the clones with the IBM PS/2, but by then it was too late. Compaq and the rest of the PC industry already because successful making "IBM-compatable" personal computers (even though some parts of the PS/2, such as their mouse/keyboard ports, did trickle down to the PC platform a few years later).

Re:Actually

[bani]

What. The. Fuck?

We recently went over this in my computer organization class.

You need to leave whatever school you're going to.

Immediately.

Seriously. It's obviously a complete waste of money. Do it now before your head gets any more messed up.

Intel is reluctant to release their ISA documentation

Nooooo they aren't.

Without releasing ISA documentation, people can't program your fucking CPU. Yeah, I'm sure that's exactly what Intel wants -- nobody to code for it. Great business plan. Where do I sign up?

Interesting? Jesus christ on a cracker, the mods are fucked up today.

Re:Reverse Engineering

[John Hasler]

> Far as I can tell though, most ICs are pretty
> standard and available.

Million gate FPGAs stuffed full of the manufacturer's "IP" (plus some licensed stuff such as dsp cores) are not "standard and available".

Bad assumption

[alexo]

> ... 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.

As a former ATI employee (working on HydraVision some 3-4 years ago)
I can tell you that ATI's drivers are written in-house.

Re:Time is money to make NDA'd docs publishable

[ComputerSlicer23]

In a lot of ways, yes it is a very small number. First off, I'm not sure which documentation you are discussing from NetCraft. A link would be useful, but I'm too lazy to dig one up. The two stats to remember, are that something like 80% of the domains out there in the world run non-Windows OS's (read people who probably need access to the documentation). I want to say, only 30% of the IP's (possibly physical machines) out there, run non-Window's OS's. So in the end, even on the Internet, Windows is fairly dominate in terms of "numbers of machines". Which is a crying shame in my opinion, but oh well (most hosting companies, use non-Windows machines for deployment).

Now, the number of machines on the acting as servers on the Internet is dwarfed by the number of machines not acting as servers on the Internet. Not a contest. Not even close to a contest. Finally, most hardware vendor's that produce high end hardware do get it. Look at the number of SCSI devices that have documentation or drivers. Not the crappy low end ones, but the really good stuff. Sorry, the crappy low end adaptec IDE RAID cards aren't ever going into a high end server. Most internet servers don't really need a good 3D card from Nvidia or ATI. Look at the e1000? Yep, got a lot of those sold, and some really good documentation available to the public. Now look at the wireless chipsets, never going in a server. Not going to get public release based off domination in the "NetCraft" stats. 90% of all wireless cards will never ever be put in a machine that is counted by "NetCraft". They will be put in machines that say, 90-95% of all shipping computers have a Microsoft OS on them.

So depending on the product, yes, the NetCraft numbers are insigificant, both in terms of percentage and raw numbers.

For other products, the NetCraft numbers make a lot of sense. Look at the number of Open Source drivers for high end SAN cards. Look at the number of Gigabit cards that have open source drivers. Look at the number of highend RAID cards that have open documentation.

The other thing they are confusing is "won't release specs", versus won't allow re-distribution of the firmware. For a lot of wireless cards, it's that they can't re-distribute the firmware which is necessary for the hardware to work, not that they don't have the specs for the actual hardware. (I believe a number of OpenBSD's issues with Wireless Intel chipsets are this issue). The other issue with Wireless is that releasing the specs could invite FCC issues. I'm not sure of how much teeth those could have, but it sounds like a legitimate concern. If the FCC could say, well people are using your part with your documentation to drive it out of complaince, your wireless cards can no longer be sold. That'd be a real problem for Intel or Cisco.

Finally, releasing the specs, would allow a competitor to say they clean room, backward engineered without having to do the documentation. It's really expensive to do that testing and documentation. So they could sell a competing product at a much lower price. It's much easier to match an existing specification, that it is to write a good known working specification. It is valuable IP. Personally, I think it's wonderful when they release it. For a lot of hardware they do. Especially for the really high end hardware that needs high reliability.

Kirby

Re:Because it would cost them money

[AngryElmo]

Well, seeing as I operarate a budget of a couple of million and I use exactly that methodology (What function to perform, what are the supported OS's, is it one that we have skills with and which hardware vendors provide certified drivers), I would think that a few vendors would be interested. And keep in mind that I work for an SME and this is just one company in a sea of thousands...

Re:i dunno, worked great for IBM

[Detritus]

Informative, my ^&*(.

My IBM PC came with a technical reference manual that included a complete set of schematics and a listing of the BIOS. The only thing that it didn't include was a listing for the ROM BASIC.

Re:Because it would cost them money

[SurfsUp]

Strawman!
Oh... Sorry. I got a little excited there. Eveyone else on Slashdot misuses that word. I didn't want to be left out.

You are close. He actually made an "argument by analogy", yet another common form of logical fallacy.

Re:Time is money to make NDA'd docs publishable

[Anonymous Coward]

Have you seen any internal specifications? I'm guessing you haven't. They are quite often littered with references to other project codenames. There are references to design and verification methodologies. There are references to third-party requirement/IP. They would be a treasure trove for any competitor to pick through. Don't you think that knowing codenames of related projects that use "this piece" or "that piece" of a reusable design wouldn't help a social engineer to find more information? Don't you think being able to piece through design/verification methodology would undermine a company's ability to be first to market because they have better processes in place than the competitors? Don't you think those third-party partners/vendors would be a bit peeved if their information was leaked?

I work for a company involved with designing RAID-on-chip solutions, so I speak from experience. We constantly have discussions with our customers regarding what features they want/need implemented to maintain an advantage over their competitors. The features are implemented, only the one customer knows about them, but they are still a part of the internal specifications for the part. Internal specification are in no way, shape, form or fashion designed or written for general public consumption. Believing that they are or that they should be is naive. Trying to deliver a "clean" spec for general consumption would involve more than one company's lawyers.

Re:Time is money to make NDA'd docs publishable

[ComputerSlicer23]

Not really, trust me, as some one who writes software, it's much easier to build something that fits a working model, then it is to build a working model and write software for it.

I've dealt with hardware guys, building drop in replacements is much easier then building an original working model in a lot of ways. While in constrains the design, it also creates a definitive goal. There is no argument about "should it do X or Y". Just look at the specs. They'll tell you exactly how it should behave.

Try and think of it as "Test Oriented Development". You now have the tests to develop something. If you want to know if it is correct, you run the test. The result of the test is spelled out in the documentation. Ask anyone who has done lots of development, about unit testing and how wonderful it is to have. Design specifications are very close to unit testing. Especially if you have a working driver from the company.

Besides all that, just ask Pepsi how valuable Coca-Cola classic's secret recipe is. In the end, no one has been able to reproduce the damn thing despite ~130 years of trying, and literally billions of dollars in incentive. While a lot of Coca-Cola is branding, don't underestimate that they got big based on their taste. I've tried a lot of other soda's. Most of them are horrific.

Kirby

Via does release their specs

[Animats]

Go to ViaArena. Click on "Open Source", and go from there. Source for drivers for their Ethernet and graphics chips is provided.

It's multiple issues, really

[Anonymous Coward]

Background: I used to write device drivers for a now-defunct *BSD operating system. It took quite a while to get the right contacts with the companies (many of which have been mentioned in these threads already), but you have to understand what drives these companies:

• A windows driver provides at least 80% (probably closer to 95%) of the sales. There isn't much money on the remaining 5%, so efforts to make that work are also minimal (and usually based on personal championship. For those I've worked with during that time, _thank you_).
• Docs frequently aren't cleaned-up - there's no need. One manufacturer used to build network cards that had two methods of driving them. The Internal doc I got mentioned both, but had a sticky yellow note on it (from my hardware/doc contact) saying only to use DMA - PIO mode would be obsoleted. The Linux croud built a 'driver' using the obsolete PIO mode, and all hell broke loose when the PIO mode was removed to save silicon real estate. This resulted in a lot of bad press.
• Docs sometimes also list future, not-yet available features on successor chips. In several cases, I had the docs and early silicon and wrote code for a not-yet-released new card. I then had to wait for customers to start complaining that things don't work, find out that the new card had been released, and then release the updated driver I wrote earlier - I could not do so earlier as it would give away news about new hardware releases!
• Manufacturers don't like to be bad-mouthed. Let's face it, all hardware has bugs. Part of the aim of the driver is to make the hardware work. Page-size docs explaining hardware bugs (that easily can, and should be worked around by the driver) only cause customer confusion. The "us" that represent the 5% of the market simply don't warrant that kind of effort.
• By not releasing the specs, other manufacturers can't make hardware that uses the same API. That's a hardware lock-in, if you use the hardware and build a driver, then you need to make a new driver if the hardware changes
• Open source, unfortunately, has a mixed history of code quality and the ability to follow-up. When you create a partnership with a manufacturer, then all problems the customers may have are _yours_ and should not leak back to the manufacturer. Be the quiet 5% - if you're noisy they you're too much effort.

So there's many reasons. So it goes.

Geert Jan de Groot
former developer of a now-defunct commercial *BSD operating system