Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Software Hardware Linux

Moving from Binary Drivers to Open Source? 186

Posted by Cliff from the welcome-to-the-family dept.
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."
This discussion has been archived. No new comments can be posted.

Moving from Binary Drivers to Open Source? More

Moving from Binary Drivers to Open Source?

Comments Filter:
  • 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.

  • Know your code (Score:5, Informative)

    by prestwich ( 123353 ) on Saturday March 19, 2005 @04:19PM (#11986231) Homepage
    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 (Score:4, Funny)

      by Savage-Rabbit ( 308260 ) on Saturday March 19, 2005 @05:00PM (#11986498)
      ...lots of closed source contains rather dodgy comments that you might not want to be public.

      Hehe.. very true. My favorite one:
      "Sane people do things like this?"
    • If you have a source code control system...

      What do you mean, "if"?

      • You missed the implied rest:

        else
        shoot everyone who worked on the code without installing source control

        Sadly many companies do not use source control. CVS is free, and as been around for years not. (Not to mention all the newer systems that fix some of CVS's flaws) Doesn't mean anyone uses them.

    • The Linux kernel (and much other open source code) has some "interesting" comments as well.

    • One of the things that many companies are only now coming to realize is that when you get lawyers involved, you may not have the option to keep your embarassing source code private. When that subpoena arrives, you may not have the option of pulling out legally embrassing source. Taking out the cripple homosexual lawyer joke. Trying to firm up exactly which BBS that 1992 I/O polling code came from that you always intended to rewrite but never bothered since it was "free" (as in jail time) and decided to keep

  • codingstyle (Score:5, Interesting)

    by pe1rxq ( 141710 ) on Saturday March 19, 2005 @04:20PM (#11986234) Homepage Journal
    Read the codingstyle document and look at what others are putting into the kernel!
    The biggest mistake is some idiot using unusual function names, spreading his driver over atleast ten files and using 2 character indents or no indentation at all.
    Especially if your source is ported from windows (or the programmer has only windows experience) make sure you do this right.

    Jeroen
    • Along with the coding style (Documentation/CodingStyle), I'd recommend also reading Documentation/SubmittingDrivers
    • Something tells me that what these guys want to do will involve bigger issues than number of spaces to a tab. Especially given the existence of the indent program. But hopefully there won't be any huge barriers, nonetheless. To Gerry Gilmore: what you want to do is good on many levels -- good for Linux, good for society, and quite certain to be good for your company too. You have my thanks, and my best wishes with it :)

    • 2 space tab indents? (Score:3, Interesting)

      by reborn ( 224970 )
      Interesting, a study we did showed that in terms of productivity and readability 2 space tab indents was optimimum. "Why?" I hear you ask - any developer that's worked on a project of any size above "tiny" will know that large indents don't aid readibility, unless your code is very 'squished'. Which brings us onto one of the most important aspects of any project - white space.

      Let's look at the following chunks of code;

      Many would write a simple for-loop like this (using standard 8-space unexpanded tabs);

      f

      • Re:2 space tab indents? (Score:3, Interesting)

        by vivian ( 156520 )
        What about 4 space tabs? That's IMHO the best compromise between readability & vertical space use, and what I have been using for the last 12 years.

        • What about 4 space tabs? That's IMHO the best compromise between readability & vertical space use, and what I have been using for the last 12 years.

          From "Code Complete":

          Indentation has been shown to be correlated with increased programmer comprehension. The artcile "Program Indentation and Comprehensibility" reported that several studies found correlations between indentation and improved comprehension (Miaria et al. 1983). Subjects scored 20 to 30 percent higher on a test of comprehension when

      • I'd figure an experienced coder would never use l as a loop variable. Too easy to confuse with 1. (Of course, syntax highlighting helps, but still...) Also, why not use the <ecode> tags so we can read your stuff?
        for( int i=0; i<10; ++i ) {
        printf("%d\n", i);
        }
      • The point of using the tab character is it does not represent a fixed indent. If you like 2 char indents, set your tabs to 2; if you want 8, set it to 8.

        Using hard coded spaces consumes more bytes and requires reformatting to change the indent. Use of Tabs is a no-brainer, but judging from the comments here and elsewhere people still don't understand the issue.

        • Re:2 space tab indents? (Score:5, Interesting)

          by rohanl ( 152781 ) on Sunday March 20, 2005 @01:45AM (#11989074)
          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.
      • My personal view is that two-space indents encourage excessively deep nesting. It's just too easy to nest conditional structures and loops very deeply without your code looking too contorted at a glance.

        Of course, that's the viewpoint of someone who doesn't use two-space indenting ;-)

        I'll use whatever the code I'm working on uses reasonably comfortably though. I currently regularly work on code with:
        <ul>
        <li>4-spaces-indenting with a tabstop of 8</li>
        <li>4-spaces-indenting with a ta

    • Re: (Score:3, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

  • Open source is more than Linux (Score:5, Interesting)

    by Anne Thwacks ( 531696 ) on Saturday March 19, 2005 @04:20PM (#11986237)
    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?

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
    • " Remember, once the source is in the open, people can port your stuff to *BSD and WindRiver, VXworks, etc."

      It makes me wonder why more hardware manufacturers aren't asking this very question, and why anybody making new devices wouldn't open their driver code from the beginning. I mean if you make hardware, and you write software to run it on at least one platform, what is the point in making it hard for people to port the software to another platform? Isn't your profit margin in the sales of the hardwa

  • Place to Ask (Score:2, Informative)

    by norm_z ( 154015 )
    You could find more information at LKML. The archives are here, http://marc.theaimsgroup.com/?l=linux-kernel.

    Many vendors have been moving from proprietary to open source. You can join LKML at http://www.kernel.org/.

  • Avoid closed source coding conventions (Score:3, Funny)

    by JamesP ( 688957 ) on Saturday March 19, 2005 @04:26PM (#11986282)
    The worse thing i've seen in a (Windows) driver.

    for (i=0;i10;i++) {
    switch(i) {
    case 1: // stage 1 // stuff here
    case 2: // stage 2 // stuff here
    case 3: // stage 3
    }
    } // lameness filter mary had a little lab, blah, bla, 1 3 5 7 11 13 17 19 23 29 31

  • Make it completely open... (Score:5, Insightful)

    by tony3w ( 559959 ) * on Saturday March 19, 2005 @04:27PM (#11986286) Homepage
    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.

  • Code (Score:4, Funny)

    by rbreve ( 94225 ) on Saturday March 19, 2005 @04:28PM (#11986294) Journal
    be sure you dont have any SCO code in there ;)
    • Seeing as that SCO will claim anything as being their own code, this could seem rather difficult. I think the only way around this is to code your entire driver out of the typical hello world. Oh shit, SCO owns that too.
    • be sure you dont have any SCO code in there

      No, it goes like this:

      1. Be sure there is no SCO code in your drivers
      2. Be sure there is no code SCO can possibly even mistake as being theirs
      3. Prepare legal staff and funding for inevitable and relentless SCO attack
      4. Endure years of courtroom entropy
      5. Re-elect your litigation-favoring politicians/legislators
      6. goto 1

  • Don't jump into this. (Score:5, Insightful)

    by Anonymous Coward on Saturday March 19, 2005 @04:29PM (#11986298)
    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? (Score:5, Insightful)

    by thrashbluegrass ( 855748 ) on Saturday March 19, 2005 @04:33PM (#11986332)
    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.
    • Bless you for doing this. And if your tools are built on top of someone else's tools, such as hardware driver patches on top of someone else's work in the kernel source trees, pretty please eliminate silly white space differences between your code and the author's code, generate clean diffs, and apply those on top of the original source. Then publish, to ease reading of the actual diffs.

      If you require software to accompany the kernel modules such as the way PCMCIA drivers are integrated with the PCMCIA man

    • Re:Why aren't more hardware concerns doing this? (Score:5, Insightful)

      by Jetson ( 176002 ) on Saturday March 19, 2005 @05:28PM (#11986694) Homepage
      Although I understand that NDAs can be involved, it often amazes me that hardware manufacturers keep to closed driver implementations.

      In a lot of cases the hardware is pretty simple and the functionality that differentiates their product is all located in the driver. Think "WinModem". Releasing the driver as open source can take a way a competetive advantage in that case.

      • In that situation, it seems like your only competitive advantage is your cost--which is entirely a hardware issue. The drivers are almost a value-add--even if they accomplish what hardware traditionally does, they're not doing anything new or spectacular.
    • I don't think you fully understand the paranoia of manufacturers.

      Opening up their drivers would enable other software to be written for their device, but it would also open up their designs to competitors, not something they like to do.

      I don't want to name names, but for this story, the company will be known as... Widecom.

      I have spent some time working with some products from Widecom in past and have learned much about their seeming paranoia. We have a couple of proprietary datasheets on a couple of part
      • I understand THAT they're paranoid; I don't understand WHY they're paranoid.

        The whole "if we release the specs, it can be reverse engineered" is so shallow as to be laughable; if a competitor truly wanted to reverse engineer your product, they'd do so with or without your published specs, by disassembling a) the hardware, or b) the driver you provide (this all reminds me of the "hackers only know how to break windows because we release security advisories" bs that comes out of redmond from time to time). M
        • 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 thr
          • In this case, you're talking about *your* house, not about a house you built that someone else bought. If your house-builder had locked rooms in YOUR house that you weren't allowed in, wouldn't you be a little suspicious, if not a whole lot ticked off?

            I really fail to see how anyone can expect to continue to own any part of something they've sold. It's just plain silly and it's going to become very damaging to society at large before long.

  • Patience (Score:4, Informative)

    by Z00L00K ( 682162 ) on Saturday March 19, 2005 @04:34PM (#11986336) Homepage Journal
    is necessary. It may be a good idea to first check that the code you have works with the latest versions of the Linux kernels, 2.6 firsthand and possibly 2.4. If there are too much problems supporting both, go for 2.6 and try to avoid pitfalls regarding deprecated functions. (use udev instead of devfs for example)

    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!

    • Don't assume that those choices are good just because they are popular.

      The autoconf scripts are a mess. They run slow. They take up 200 to 300 kB compressed. They test for various basic POSIX features that exist already on every OS you'd ever care to support. They add several extra layers of complexity.

      Better way: good old #ifdef and such. It works.

      Bugzilla is an isolation tool. (see the recent trouble with GNOME developers ignoring bug reports) At the very least, you must enable voting. You also face

      • Mozilla is based on Netscape code that was opened up ... It took time ... for the code to get cleaned up.

        Actually, it took a short amount of time for the mozilla project developers to abandon the netscape codebase and start over on developing mozilla from scratch(though I'm not sure if no netscape code made it into the new mozilla code or not).

        It then took a fair amount of time for the project to then reimplement most of netscape and create the firefox which I'm typing into right now.

      • For an example of this approach, go look at the old software for HylaFAX. The "configure" script for that was written by hand by Sam Leffler, one of the original authors of BSD and the creator of TIFF. Now try writing that thing by hand, yourself, for every single software author. They will break things, they will write incompatible tools, and maintaining them will be nightmarish. Using autoconf is like using standard size screw holes: it's not the optimum for every job, but it's necessary to allow using

        • I hate to bring this back on topic, but the subject is device drivers for linux. There is no need for any configure script because they only need to run on the current kernel. You know in advance exactly what is there. The most you might need is a depends line in the makefile to be sure your not getting compiled when someone you need isn't. (that is don't compile your SCSI card driver if the SCSI subsystem isn't installed) Should be trivial to do this.

          • Right. And autoconf has nice structures to test for things like kernel versions, the presence of any specific libraries, GCC versions which can affect code compilation, the presence of x86 or ppc or x86_64 or ia64 hardware, etc., etc., etc.

            It even has nice structures for building one version of a kernel module that's not the one you're running at the moment, or building RPM or .deb installation packages. But hey, if you want to write magical mystery Makefiles and #ifdef statements to deduce what the perso
      • The autoconf scripts are a mess. They run slow. They take up 200 to 300 kB compressed. They test for various basic POSIX features that exist already on every OS you'd ever care to support. They add several extra layers of complexity.

        autoconf checks for whatever you tell it to check for. If you don't want to check for sys/socket.h, don't tell it to.

  • *cough* (Score:5, Informative)

    by Geekboy(Wizard) ( 87906 ) <[spambox] [at] [theapt.org]> on Saturday March 19, 2005 @04:41PM (#11986378) Homepage Journal
    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.

    http://undeadly.org/cgi?action=article&sid=2005031 8231311&mode=expanded [undeadly.org]

  • Get marketing involved (Score:4, Insightful)

    by Anonymous Coward on Saturday March 19, 2005 @04:41PM (#11986379)
    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.

  • From the bleachers (Score:4, Insightful)

    by nuntius ( 92696 ) on Saturday March 19, 2005 @04:47PM (#11986410)
    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.

  • Look for in-house advice too (Score:5, Insightful)

    by CedgeS ( 159076 ) on Saturday March 19, 2005 @04:47PM (#11986416) Homepage Journal
    You probably already know it, but here are a couple of other collections of open-source projects in your parent company. They can probably provide advice about such topics as which person in your legal departments has expertise and advice on the subject and other institution specific headaches and shortcuts.

    http://www.intel.com/software/products/opensource/ [intel.com]

    http://www.intel.com/cd/ids/developer/asmo-na/eng/ 52779.htm [intel.com]

  • Work with the community (Score:5, Informative)

    by hellgate ( 85557 ) on Saturday March 19, 2005 @04:57PM (#11986480)
    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.

  • Thigs to do (Score:5, Insightful)

    by Sycraft-fu ( 314770 ) on Saturday March 19, 2005 @05:30PM (#11986708)
    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.

  • Support Zaptel (Score:1, Redundant)

    by mamladm ( 867366 )
    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

    • Re:Support Zaptel (Score:4, Insightful)

      by Andy Dodd ( 701 ) <atd7NO@SPAMcornell.edu> on Saturday March 19, 2005 @06:33PM (#11987064) Homepage
      "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."

      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-d ev/200 4-July/005203.html

      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. :)

  • Release tokens (Score:2, Informative)

    by LP_Tux ( 845172 )
    Make sure you tag each release with a tag appropriate to its stability (prealpha, alpha, beta, stable etc.) Also you might want to do what redhat did with fedora and have a section if the team working on the drivers in an open source manner. naturally keep the binaries available for download too. And make sure it compiles on GCC and mingw. Good Luck!

  • Dear Dialogic (Score:1, Interesting)

    by Anonymous Coward
    Thank you for your interest in finally removing your head from your posterior.

    I would like to suggest the following:

    - Communicate with your application developers openly. You rob yourself of invaluable feedback when the forums you sponsor are not as free as the source.

    - Particiapte. While it's not neccessary to feed the trolls, your guidance and expertise are critical to the success of the project.

    - Take a resolute approach. An insistance on silly extra clauses added to otherwise good licenses only c

  • Other telecom vendors do a better job.... (Score:1, Interesting)

    by Anonymous Coward
    I am the CTO for a telecom company that once used hardware from this "very large supplier". Having worked with their products, I would be very surprised if the code for their drivers is not a train wreck. We struggled for over a year to get their PSTN boards to work with a generic ISDN PRI network.

    We switched from this company to a smaller vendor that shipped PSTN and VoIP boards with stable drivers. We've never had a problem since, and will never go back to the previous vendor.

    As for open source, if I am
    • For whatever my word is worth, we're doing this for several reasons: 1) Sell more stuff. I am a greedy, capitalist pig and I want to sell more stuff. I know from having participated in the Linux industry since installation was on a pile of floppies that open source drivers allow hardware companies to sell more stuff. 2) Help our software be better. As mentioned above, I know that open source leads to better software, even if you do start with a train wreck. :-) 3) Help our customers. It's only somewhat a

  • Some Linux kernel tips (Score:5, Interesting)

    by Wesley Felter ( 138342 ) <wesley@felter.org> on Saturday March 19, 2005 @07:02PM (#11987221) Homepage
    Get into the official kernel. If a driver isn't in Linus's tree, it doesn't matter, so you will be on an endless treadmill of API breakage. Once your driver is in the official kernel tree, the kernel hackers will take responsibility for most of the API refactoring.

    Know the politics. Most Linux kernel developers aren't accountable to anyone and don't negotiate. You will have to put up with whatever requirements they give you if you want your code to be part of the kernel.

    Know the effort. You will probably be asked to rewrite your drivers, possibly more than once. This will take months. If you don't do it, then open-sourcing the drivers was mostly wasted effort.

    As others mentioned, coding style is important. Also, wrappers are not allowed in the kernel, so call kernel APIs directly instead of wrapping them. The result is a totally Linux-specific driver, but the rules are the rules (see above).

  • Two-way delivery (Score:3, Interesting)

    by captaineo ( 87164 ) on Saturday March 19, 2005 @07:41PM (#11987416)
    As a developer of binary drivers you are used to having complete control over your code, and "pushing" all updates down-stream. But once your code goes in the kernel (which I highly recommend - don't let it languish outside Linus' tree), you'll have to consider how to deal with code changes coming TO you FROM the kernel developers.

    This is both a good thing and a bad thing. It's good because you'll get fixes from people testing your code on all sorts of weird platforms you've never heard of. It's bad because you can wake up one morning and discover the kernel API for your type of driver has changed overnight, and your code won't even compile until you re-write half of it (there go your plans for the weekend). A certain amount of lag is acceptable, and you can restrict support to the stable kernel series only if you want, but expect to hear a lot of whining from users who will demand that you keep up with the cutting-edge development code.
  • Check out this article [feyrer.de] for some reasons to go for BSD over GPL. Feel free to contact me via email.

    - Hubert

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close