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."
need... link... to.. *twitch*.. click.
HELP!
I have never made a migration on a scale like this, so I have no horror stories.. but I would like to commend you and all peoples making the move to open source where possible.
** "It's not my job to stand between the people talking to me, and the ones listening to me." -- Pego the Jerk
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.
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).
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.
And this can a bad thing? I can't imagine it drawing bad PR.
Life is not for the lazy.
It's great you're doing this. Make sure that people (i.e. potential customers) hear about it. Given a choice between two comparable products, if I know one of them supports the free software community, I'll choose them. I know I'm not alone. You're not only going to benefit (eventually, don't expect instant gratification) from code feedback, your sales will tick up, assuming you market yourselves well. Try to measure it, and then show the evidence to your company's other divisions.
You might be using it, but it makes you look stupid if you want to be taken serious in the linux world.
The same with your second point. While just dumping crap on the doorstep might make you a few friends you won't get the same kind of welcome as when you release nice clean code and play along with the other kids.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
As an observor on the sidelines, here's a few points that sometimes cause issues.
- Expect a rough transition.
Releasing your app to the community is like hiring a bunch of new developers but not giving them any management. If they like what you have, they will work with it; if they don't, they might re-implement things or openly disagree with your existing design. Get as much relevant information online as possible so others can make informed design decisions.
- Provide direction, but be flexible.
One benefit of OSS is that others can suggest fixes that may directly contradict your current view of the problem. By carefully accepting some of these changes, your software will become better.
- Don't expect the OSS community to do all the work.
Several major bloopers have come from companies saying, "fine; we're open-sourcing it; let them do the work". This is the road to stagnation. The community will support things that are useful to them; don't assume that your alpha-OSS release will generate immediate support. A small OSS community is excellent for porting existing software to new systems; they are generally slow for actual development work.
- Keep providing support.
During the initial transition, you will probably have more work than normal as people flock to your project asking questions. Then only those who like what they see will stay. At a minimum, your company should host an email list and an anonymous CVS or Subversion server.
- Advertise the transition to your users.
Make sure your customers understand that they can now customize things in-house. Make OSS a "value-added" feature. Encourage them to return their improvements back to the community.
- Make a good testing framework available.
Most of your end-users will only have access to the hardware they actually use. Your current Q/A process probably tests against a range of hardware. As such, you own a range of test machines. Network these to a test framework that can validate community changes as they are submitted. Maintain a "stable", in-house tested branch and an "unstable", bleeding-edge branch.
http://www.intel.com/software/products/opensource/
http://www.intel.com/cd/ids/developer/asmo-na/eng/ 52779.htm
And of course, stating one point always means denying that point in the comparison, right? It's never possible that both sides being compared have the same flaw, but it's worth mentioning only in the side being considered, right? Comparisons are always 100% competitive - one side is always right, the other is always wrong.
--
make install -not war
1) As others noted, do a full code audit and make sure there's no proprietary code in there at all. When in doubt, take it out. You don't want a lawsuit on your hands. Make sure you have the rights to distribute all of your source.
2) Clean up your code. If the comments are incomplete, complete them, if there's something that's obfuscated for no good reason, unobfuscate it, etc. Remember that for it to be useful someone who's never seen it, and doesn't know how your stuff works. While doing that clean up any bad language in the comments and code.
3) Make sure your code builds completely to a final useful state on standard compilers (GCC on Linux, VisualStudio on Windows). If there's any special options that need to be set, document them. Don't release something that won't compile without tweaking, it should be ready to go.
4) Don't neglect binary versions. Keep them at least as current as the source versions, if not more so. Many (most?) people don't like fucking around with compiling their own stuff. It takes time, and the compiler is scary to non-programmers. Have an easy to install binary version as you did before. Goes double for Windows.
5) Do it for the right reasons, that being to get feedback from the world at large and to help out. Don't do it expecting the OSS community to pick up your slack and develop your drivers for you. You might get lucky and find that some extremely talented individuals do just that, but more than likely if you open them up and ignore them, they'll become crap.
6) If you take community contributed drivers that you have nothing to do with (like ports to an unsupported OS), make sure you make it clear on your site that they are different. Have a clear demarcation between drivers you created and supported (with or without community help) and drivers someone else did, but you didn't make and can't support.
In general I think it can work to your advantage, but only if you treat the OSS community as an additonal asset, not as your core development. Maintain the same team you have now, same standards for testing and quality (I'm assuming they are good here) and so on. Take any useful contributions the OSS community provides, but don't rely on them to start doing your job for you.
"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."
d ev/200 4-July/005203.html
:)
:)
I wouldn't be surprised if this is one of Gerry's motivations for switching to open-source. Do a bit of Google searching, examples are:
http://lists.digium.com/pipermail/asterisk-
Gerry works for Intel/Dialogic.
As another poster who figured out who you work for said, you might want to get in touch with people in your parent company familiar with open source, such as the eepro maintainer. They'll probably give you better answers than Slashdot. Although they won't give you as much free publicity as Slashdot.
retrorocket.o not found, launch anyway?
I can think of two things to look at with respect to comments.:
First of all, you would like your comments to be meaningful, understandable and accurate. (I'm sure I could find you some juicy counter-examples in my own code).
The second thing (which, I think the grandfather post referred to) is: You might want to edit out comments like
- "I was going to shoot George Bush but this seems even more insane",
- "This is the worst IP violation I've ever committed", or
- or "This code stinks worse than our hardware."
You know -- stuff that just might embarrass your PR group if it got published on slashdot. There probably isn't a whole lot of stuff like that, but you should hire a couple of young code monkeys to go a quick read thru your code, and flag anything even vaguely questionable for your more senior programmers to vette.Murphy's law says that you won't necessarily catch everything that might be embarrassing, but if only one or two nasty examples make it past the review, you can always blame it on too much coffee. If there's lots of stuff that you find on a quick audit, then you might want to delay the public release for a couple more months while you go over the code with a fine toothed comb.
If you can find some code monkeys with OpenBSD style auditing experience, then you could possibly add in cleaning up the actual code to the benefits of such an audit. This code is going to represent your company (unless you release it anonymously), so it'd be good to release the best code your resources allow you to generate.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Just as IBM is being asked to pull out 30 years worth of source code for SCO, your company might be asked to do the same by some company abusing the legal system. If your whole source evolution may be viewable, that suggests that only a ground-up rewrite can hide some of your nastier ethical and social improprieties. The best option in this situation is making it open-source from the start (even basing on open source code) and black box testing against your old code. Making it open will do a lot to keep it clean and test it hard.
True, your company may have signed all sorts of legal entanglements with your old source, but you'll probably have to rebuild it all from scratch anyway in eighteen months or whenever Longhorn is finally unleashed. Starting over is inevitable; get a jump on things and start that re-construction effort from scratch now with an open source driver. Whatever changes you have to make for Longhorn, you'll be starting from a trunk of source that's stable in execution and legality.
That's just fine. But if they want control over everything, they need to be responsive by getting things done and have useful information on the school website.
As a blatant example, it's a disgrace to the school to have sports and music schedules that are 3 years old attached to "upcoming events" on the main page. Equally lame was that PR would not allow departments to post lists of classes being offered.
But I think the most absurd was that PR would not even allow the School of Business, which has professors being entrusted with teaching things like marketing and branding, to have input about what was on the website for the School of Business.
It's really sad because while the website is pretty, it's really devoid of useful information. If I were a prospective student I would quickly dropped the school from consideration just based on how lame the website was. In my case, I worked at the school (systems administrator) and got a nice discount.
It was frustrating telling professors and department heads, "Sure, you COULD have your course schedules put online, as well as a staff directory. In a technical sense, it's quite simple to do, really. But you'll have to get it past PR first."
Going back to responsiveness, I was assisting a professor with creating documents for a series of seminars he was contracted by the state to do through the university. We created brochures for the seminars, giving descriptions, agenda, etc. Because it was done through the U, PR demanded final approval on the things. I would agree with that in general. But, even with persistent hounding, they did not bother to take a look at them until after the seminars had already passed. How were we supposed to get the word out, and people registered (and paying) for the seminars if we can't send brochures?
So, maybe I'm tainted by my bad experience with PR where I worked for several years. But my general feeling is that PR folks are arrogant asses who don't give a shit about what other people are trying to accomplish and who feel that as long as it looks pretty, there's no need to have current or useful information available for people.
That's not good branding. It's just being an ass.