Slashdot Mirror
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."
So the really important thing is to really look through your code first - you need to:
1) Check it is all really your code - you didn't buy any in 5 years ago? If you have a source code control system then actually being able to trace your code is great.
2) Read the comments - ok, so lots of closed source contains rather dodgy comments that you might not want to be public.
3) Check that releasing it wouldn't be revealing any information you got under NDA from any of your suppliers/partners.
Include reasonable amount of documentation, like a README and an INSTALL file. Keep both short.
Try to use autoconf scripts, since that may help in the long run when people tries to build it on all kinds of strange platforms. Be clear of which platforms that are supported, and which are not. Be also clear of platforms known not to work.
Set up a bug report tool. Bugzilla is a well-known tool. Bugs will be reported, and you may also get fix feedbacks that way.
A clear versioning strategy is also necessary. Avoid a multitude of branches if possible. The preferred way is to have a public read-only CVS archive. (you can use cvsup to create a mirror of the real archive in case you have a security breach on the public server.)
Have a reasonable licensing for your software, it will pay off in the end. You may want to take a look at MySQL. Try to be flexible and not too complicated.
This seems to be what I could come up with on a short notice.
And GOOD LUCK!
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
OpenBSD is striving to open up all drivers, and refuses to allow binary modules. Currently, they are targeting Adaptec, trying to get the management interface opened up. We don't want them to write code for us, or to support it, we just want docs, so *we* can write the code, and support it.
1 8231311&mode=expanded
http://undeadly.org/cgi?action=article&sid=200503
Because hardware has a bad tendancy to hang around long after the vendors lose interest in it?
By making the drivers open source & letting the OS supplier recompile them for new releases they lessen the future load on their support desk from people complaining that their Linux 2.8 binary drivers won't work in Linux 4.2
I am the maintainer of a driver in mainline Linux. An competing driver is offered by the actual hardware vendor (also Open Source). While working with their engineers has been quite pleasant, we have never been able to agree to work on the same driver.
So the people who know the hardware best are paid to work on a driver that few people use. Meanwhile, the driver in mainline keeps up with the frequent changes of in-kernel APIs but lacks the resources to make use of all the features the hardware offers.
A few companies (e.g. Intel with their eepro) seem to get it right: Have someone work with the community to write and maintain a driver in mainline. You are still largely in control as long as you are competent, and you are pushing the code people actually use.