Slashdot Mirror
Free/Open Source Software Hardware Requirements?
Bender asks: "Most on Slashdot seem to be concerned with getting Free/Open Source software to be compatible with hardware (firmware, register sets, etc). My question is from the other side of the table: I'm in the hardware business and I'm wondering if there are any central guidelines to better guarantee compatibility with Linux/*BSD. As an example, to guarantee that our hardware runs Microsoft Windows, we have to conform to the Windows Logo Program Requirements. These requirements dictate (among other things) firmware interfaces, debug ports, and DRM. Some of these requirements, if not implemented carefully, could trigger incompatibilities with non-Microsoft operating systems. Is there a Linux/*BSD equivalent to the Microsoft requirements to allow hardware designers to build OS agnostic systems?"
My ininformed, off-the-cuff answer would be:
Complete and freely available documentation.
If your product is really wanted, people will adapt (look at how hard people try to do this with things like reverse-engineered open-source drivers). If you freely provided complete documentation on your hardware, it would make it several orders of magnitude easier for developers to write software for your hardware.
I always felt the term "Windows compatible hardware" was a big piece of bullshit. Shouldn't it be the software to conform to the hardware, and not the other way round? Hardware seems to be the lowest common denominator here.
Of course (as some posts already mentioned), this can only be achieved if the hardware in question is properly documented so that developers know how to write drivers for it, without having to resort to dirty (and sometimes illegal) tricks like reverse engineering.
Score: i, Imaginary
...then people will correct you if it's wrong. If you release open source drivers to the community and do it in a fashion which inspires feedback (mailing lists, forums, Sourceforge) and people find fault (bugs, standards compliance, bad code style) it can and likely will be fixed.
If you are prepared to put paid developers at the whim of the community then you are already on the right track to wide acceptance. You have to realize it isn't your baby anymore and if you've just released a horrible monster it will get tamed and put into other projects that have nothing to do with you.
Going open source is easy - anyone will tell you what is good and bad to do. Closed source, proprietary software tends to lean towards groupthink and suddenly a bad project is worse. There is no reason to keep discussions and ideas behind closed doors in the open source world so you can benefit from wider feedback.
In a year you'll be discussing you're release on Slashdot, and we'll be saying *BSD is dying. But that will be some of the best marketing and market research you can do, and it will all pay off.
I'm in a weird mood..
Get your Unix fortune now!