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

Comments

Know your code

[prestwich]

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.

Re:Know your code

[bebing]

Or things like...

//WARNING! We do not know what the following code does!
//But do NOT remove that extra semi-colon whatever you do

or...

//TODO: Change from inefficient inept implementation to sane one

Open source is more than Linux

[Anne Thwacks]

Remember, once the source is in the open, people can port your stuff to *BSD and WindRiver, VXworks, etc.

This may be really useful for sales, but it may also lead to a serious amount of bug finding!

Are you really sure you want your device drivers debugged?

Make it completely open...

[tony3w]

Release Everything
Make sure that you release all documentation and tools (preferably with source) for the hardware and the drivers. The last thing a "free" developer wants to do is re-invent all of the wheels that your company created.

Provide Good Documentation
If you provide well organized and complete documentation to a quality product, developers will most likely flock to it.

Support the Developers
You will want to have staff on hand to answer questions about the technical details of the product. Create a forum that is monitored by the engineers who designed and create code for the product. Make sure that questions are answered thoroughly and quickly.

Don't jump into this.

[Anonymous Coward]

Sort through the code. Take out everything you do not want shown.. comments and the like.

Sweep through the code to make it/make sure it is readable. This will attract more developers to your project.

Open a project. Still release the binary drivers, just let people get into the code and start making the fixes for the bugs they find. Once it's sufficiently linux-ized by members of the linux community, switch them to your main drivers instead of your binary drivers.

Your binary drivers work right now (I assume), so leave them as your defaults, until the open source community can go in, change, break, fix and test out your open source drivers with you.

And thanks for your future contributions to the comunity. Please post a follow up when they do go open source. This will generate more interest in your products, and I, and many other admins who are part the decision making process of picking hardware for their companies, will definately give your products another look if they have open source, stable drivers (Like 3Ware....they rock. Because of thier long time commitment to linux, they are the only hardware raid cards I buy for my linux servers).

Why aren't more hardware concerns doing this?

[thrashbluegrass]

Although I understand that NDAs can be involved, it often amazes me that hardware manufacturers keep to closed driver implementations.

While it's true that windows and linux are the biggest games in town, offering potential customers who run other OSes a way to use your hardware seems like a no-brainer: larger potential customer base -> more customers -> more profits.

It often seems like pulling teeth; take a look at the recent (and ongoing) attempt OpenBSD is making to get more documentation and relaxed licenses for hardware. Being able to point to $1 million of hardware already running under an OS and getting little or no response from a vendor for better support -> larger customer base -> greater profits? WTF is wrong with the PHBs?

And now, back to the topic:

Document, document, document. Although I don't have any directly relevant experience, I've occasionally taken over 5000+ lines of code with abysmal documentation; on one occasion, it became so painful I rewrote major portions because it ended up taking less time than having to figure out what was going on.

Work with the community

[hellgate]

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.

Re:2 space tab indents?

[rohanl]

The problem with using tabs is that although they work fine for indenting code, they do not work well for continuation lines.

Consider the following simple example, coded with spaces and 2 character indent.

public class Foo {
void methodName(int arg1, int arg2,
int arg3, int arg4) {
return;
}
}

Now suppose, I had used tabs instead. With 2 character tabs, it would look the same.

But, someone else who prefers 4 character tabs, opens the source in their editor, and gets:

public class Foo {
void methodName(int arg1, int arg2,
int arg3, int arg4) {
return;
}
}

If you're going to standardise on using tabs for indentation, you need to distinguish between indentation and alignment and use tabs for indentation and spaces for alignment

So in my exmaple, you would need to write:

public class Foo {
<tab>void methodName(int arg1, int arg2,
<tab>________________int arg3, int arg4) {
<tab><tab>return;
<tab>}
}

It's hard enough sometimes to get programmers to follow coding standards where the difference is visible to them, but trying to enforce a mixture of tabs and spaces like this when the editor does not make it easy to differentiate between them is almost impossible.

It's much easier to just standardise on spaces everywhere.