Moving from Binary Drivers to Open Source?
GerryGilmore asks: "We are a division, specializing in telecommunications equipment, of a very large hardware manufacturer. Our equipment, DSP and PSTN boards, has been supported under Linux through a set of binary driver modules and binary libraries implementing our API set. We are in the process of migrating to a completely open source-based software infrastructure to be more in sync with the rest of the Linux industry. However, not having any real experience with moving from proprietary to an open source model, we wanted to see if the Slashdot crowd has any similar experiences to share: The Good; The Bad; The Ugly; and how best to avoid the most common pitfalls."
You may want to check out the open Zaptel interface driver suite. [Google for Zapata Telephony]
It was originally developed by Jim Dixon for his Tormenta T1 card (open source GPLed hardware BTW) but has since been used with open source telephony projects such as Asterisk.
Asterisk is an interesting example to study in respect of open versus closed telephony drivers.
Some vendors have closed driver support for Asterisk, eg. Intel/Dialogic which means their drivers can only be sold through a non-GPL Asterisk License. This however means that they rely on sales through Digium, who hold rights in Asterisk. The irony is that Digium are also a telephony interface card vendor and thus a competitor.
Voicetronix have open source driver support for Asterisk through their own GPLed drivers. Yet, the action on open source drivers is with Zaptel and so Voicetronix have to do the work on their open source drivers all by themselves and their drivers lack features that Zaptel drivers have.
Sangoma Technologies support Zaptel in addition to their own drivers. To Asterisk and other telephony packages using Zaptel, a Sangoma device is just another Zaptel device. A significant benefit for end users, open source projects and the vendor.
Zaptel is now supported on Linux (x86 and PPC) and BSD. In addition, work is under way for Zaptel on Solaris and MacOS X.
the macintosh asterisk mailing list http://www.astm
It's not "if we release the specs, it can be reverse engineered", it's "if we release the specs, it'll be much easier for it to be reverse engineered".
Simpler example: I lock all of my doors and windows when I am away, heck, I even have a security camera running in my livingroom... but that of course is not going to stop someone who wants to break into my house, which has happened. (http://www.brendangrant.com/breakin/index.html) Just because it has happened and it can happen doesn't mean I should just throw open the windows and doors.
The reason for not releasing such things, whether it be register values, pin-outs, passwords and what not is because you do not want to make it easy on those who you do not want having access to your secrets.
If you disagree, that's fine, but in doing so please, save me the time and give me your bank account #'s, passwords and a copy of your signature... not to mention all of your secrets that a determined person could probably dig up on you.
Help Brendan pay off his student loans