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