[linux-audio-user] Real-time kernel

[Ken Restivo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jan 15, 2007 at 11:09:27AM +0000, tim hall wrote:
> On Saturday 23 December 2006 06:06, Chuckk Hubbard was like:
> > I don't follow that last part. ?I agree, SoundBlaster is embarrassing,
> > but they have the supply for a demand. ?Should hardware be free too?
> > Should everything be free?
> 
> The relevant specifications should be freely available to make it possible to 
> build decent 3rd party drivers. It would also be quite cool if manufacturers 
> worked to some kind of agreed standard. New hardware will always have some 
> kind of material value and it is understandable that manufacturers might be 
> reluctant to reveal all the details of a piece of equipment's inner workings. 
> I think it would be foolish to insist that hardware be 'free'. All we need to 
> know from a software point of view,  is how to communicate with the device. 
> Surely releasing this information will only serve to make the device useable 
> by more people? I think what we should be pushing for is free availability of 
> the relevant specs. There is probably better terminology for this.

Well, it's been over 10 years now since I was a product manager for a computer (networking) hardware company, but I reckon that the main issues would be the following:

	1) Embarassment and humiliation. Usually the hardware has hairy, nasty bugs, and the firmware/software work around those. Thus, the customer doesn't get to see the bugs. In my day, this was a somewhat natural artifact of the hardware and chip design process: board turns took a long time, chip turns took a *really* long time, and if you're trying to beat a competitor to market then you just shove the thing out the door and make the software/firmware engineers work around it, because arguably they can do so faster than it would take to rev a board or chip, bring it up, test it, work the bugs out of any perturbations in the manufacturing process and manufacturing QA process, etc. Manufacturers don't want to expose all the dirty laundry that results from this bug-band-aid'ing, and exposing driver details would do that. I mean, have a look at the hda-intel chip. Damn.

	2) Customer support and service. Customers expect support for things, and it isn't always effective to just stonewall them and say "we don't support that", when you kind of do, because you at least released some part of it. Releasing drivers, API's, specs and then refusing to devote (expensive) engineer-hours to support it, is a "modified limited hang-out", to use Watergate terminology. Sometimes it works, at least for a while. Internal politics have a lot to do with why manufacturers don't do this: marketing or engineering may be fine with it, but customer service or QA or the product manager may balk, seeing it as a "slippery slope" towards eventually fully supporting it, and the costs/hassles associated therewith.

	3) Sometimes companies are paranoid about clones. But that rationale most often appeared under further investigation to be a cover for the above two issues. If it is a really innovative and/or high-quality product, then it'll be hard for anyone to duplicate the functionality, performance, or quality. I found a high correlation between shitty products and reticence to provide technical details. YMMV. I'm biased as a free software type, so I'm pretty dismissive of "intellectual property" in general.

So, that's pretty much why you can usually get these manufacturers to "open the kimono" (as we used to say) only under an NDA. 

Again, the only answer I know of to both the above concerns, is to simply provide a market.  If customers request/demand/expect it, then manufacturers do it, because it pays off, or because it is market suicide *not* to do it.

I don't know if I can consider the Linksys WRT54GL a success in this area, but it might be. Enough customers were using the WRT54G as a Linux hacking platform, that it made financial sense for Cisco to keep a Linux version around as an ongoing supported product even after transitioning the rest of their products over to a proprietary embedded OS. 

Gah, "transitioning"??? I just used way too many corporate buzzwords in the above post. Bad flashbacks. I feel dirty. OK, I have to go take a shower now.

- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFq+K9e8HF+6xeOIcRAhEKAKDHmy89wZEXqW3/1c2y7HxKtPIWrACePJy1
ZRMwHEoPgt1azgUpRqqH52A=
=yu8j
-----END PGP SIGNATURE-----