Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Technology

Feature: On Being Proprietary 139

Posted by CmdrTaco from the stuff-to-read dept.
Russell Nelson has submitted a feature called "On Being Proprietary" which tries to explain why proprietary is bad, and vendors should really think about open specifications. Read on.

Introduction

Are you a hardware vendor who includes a proprietary Windows driver with your product? If so, I intend to convince you that documenting your hardware, and providing OSI Certified(tm) open source drivers, generates enough value to overcome the risk that your intellectual property will be stolen.

You're in business to make money. You engage in activities that advance you towards that goal, and refrain from activities that don't. Therefore, the only sensible reason for holding information (drivers, and hardware documentation) proprietary is to protect your business from activities which would reduce its profit.

One reason is simply because you can -- because property rights exist. Another is because it is traditional and expected. Another reason is because someone told you to -- perhaps an investor or other trusted party. But these reasons aren't rational unless they advance the goal of making money.

Competition

The big fear of any company is competition. Every good capitalist wants a monopoly on their own products. Any hook that keeps out the competition has been used, and holding information proprietary is one of them. However, there is no such thing as a free lunch, and keeping information proprietary has its cost.

One of these costs might be that your competition has started using Open Source. There's a cartel-like effect when all the manufacturers keep all information about their hardware proprietary. No customer gets a benefit from choosing Open Source because that's not one of the choices. But as soon as one vendor breaks rank, that gives them a new product differentiator over the competition.

Value proposition

Another cost is not telling people how to use your product in the manner *they* wish. You are requiring them to abandon their chosen method of using your product, and pick up your method. This has a learning curve associated with it, so they will not buy your product as quickly as they might. It may make their use less efficient, so that they cannot afford to buy as much of your product. It may drive them to your competition, who might also be holding information proprietary, but whose approved method is more in line with the customer's chosen method.

Many companies are proud of their engineering, and rightfully so. It is a mistake, however, to presume that you know the customer's business as well as that customer. Some customers may have innovative and profitable uses of your hardware that you haven't anticipated. If you hold information about the product proprietary, you will never know about these customers, because they will simply not exist. Yes, you can use a nondisclosure, but there are costs and risks to using them. If you execute a nondisclosure with everyone, then what are you not disclosing if everyone can find out about it? In the world of science, many discoveries have been casual accidents. Nondisclosures get in the way of those accidents.

Other times a customer needs to make your product work in their environment, and alas, your engineering has a flaw. The less you tell that customer about your product, the less likely they are to be able to fix the flaw for you. Many, many times I have had packet driver bugs fixed, not just by amateur hackers, but by paying customers. The value of even a single fixed problem is inestimable. It is extremely difficult to decide which customers are able to fix bugs.The only way to solve that problem is to enter into nondisclosure agreements with all comers. And you'd be surprised by who fixes some problems. Someone in MIS at (a national automotive repair chain) whom I had never heard from before, sent me a bug fix for the token ring packet driver which allowed it to run under Netware as well as TCP/IP.

Scant protection

So far, I have assumed that not voluntarily disclosing information actually succeeds in keeping customers (aka potential competitors) from learning anything they need to know about your product. This is not the case. I can assure you that "no reverse engineering" shrink-wrap license terms are universally ignored by everyone concerned. The first thing an engineer does is whip out the reverse compiler to see how the code operates. This is not hearsay. When I was consulting for (a silicon valley fabless design shop), I actually saw a reverse-compiled listing of the 3C509 driver less than a week after 3Com started distributing it, with notes as to how the product worked. I produced my own source of MS-DOS which could be modified and assembled. I know someone else who did the same thing. Customers have been known to reverse-engineer products also, but they usually have less economic incentive. For a while, Diamond held back their variable VGA clock interface as proprietary. The information itself was widely available anyway. Connectix didn't want to release programming information for their Quickcam, but users reverse-engineered it. Eventually they released programming information after the horses had left the barn.

Trading off

The benefits, then, of protecting intellectual property through trade secrets are slim compared to the costs. A company that wishes to compete with you must make substantial investments in mechanical and electrical engineering, plastic molds, certification, prototyping, production, sales, and marketing. Another few thousand spent on the due diligence of reverse-engineering the competitor's products is lost in the noise.

There are some costs involved in releasing documentation and driver source. The documentation has to be good enough that people can actually use it. You have to develop a policy on answering questions about the documentation (charging a fee is not unreasonable). The driver source may not be in a state that you want to expose to the public. It might be poorly written. It might have profanity, or might have derogatory comments about the competition.

In summary

There is no track record which associates proprietary documentation and drivers with causing greater success in the marketplace. 3Com gives away information on how to program their network adapters. So does SMC. So does Intel. If proprietary documentation was truly a help, then how to explain these company's success? Hardware manufacturers, please document your hardware, and put that documentation up on your web site. Please use an OSI Certified(tm) open source license on your drivers, and put them up on your web site.
This discussion has been archived. No new comments can be posted.

Feature:On Being Proprietary More

Feature:On Being Proprietary

Comments Filter:

  • Calculation error (Score:1)

    by Anonymous Coward
    He said _DEBUGGED_ lines of code. At last count, there were only 314 bug-free lines of code in windows, so we could kick out the equivalent by about 9:30 tonite ;)
  • > The super-simple way out of this dilema is to
    > make a big fuss that "Absolutely no support
    > will be provided for these drivers".

    Tried that, it doesn't work. You still spend a lot of time saying "sorry we don't support that" over and over again. If you have 5 people who want help you'll have to say it 50 times because they call back hoping they'll talk to someone else who will help, or you'll change your mind. You also get a bunch of upset people complaining about how unhelpful you are.

    > Setup an email alias, and then filter all
    > incoming emails to that specific address and
    > limit them to your design group or company.

    Too easy to filter our important e-mail with the bad. Just another way to waste more of your sysadmin and engineer's time.

    > Just because you release a product does not
    > mean you must support it.

    Your company's image, not to mention your self respect, is strongly based on how well you support what you produce. Every time one of our marketing poeple says they want to release an "unsupported beta" of somthing I'm working on I know my timeline just went out the window. When it comes down to it, every thing that goes out the door must be supported to some extent. If the customer convinced marketing to send them the beta, they can convince them we need to support it.

    > If you are concerned that someone will damage
    > the hardware after modifying your software, and
    > then deny it (blaming your software, but not
    > mentioning his modifications) then all you have
    > to do is include an MD5 checksum and compare
    > this!!! Simple!!!

    Not so simple. The customer will say they didn't change anything significant. This has happend on products we have provided the source to the drivers. You can call them liars, not a good choice even if it is true, or spend the time looking through their modified source to find out what they changed.

    One important note is that really good technical support people are hard to find. A skilled, technical person who can stand to be lied to and insulted by customers, treated like the plague but engineers who don't want to "waste the time" answering their questions, and handle the stress of being blamed for every return by every idiot that couldn't figure out how to remove the shrink wrap from the packaging is a rare commodity. If you can't justify developing a driver for that platform in house. You may not be able to justify the increased strain on your support team.

  • It does (Score:1)

    by Erich ( 151 )
    Look at the (new) postfix license.

    Postfix, by the way, is a fantastic piece of software. End sendmail, use postfix. It's probably a drop-in replacement for you.

  • I don't mind constructive criticism. However, the problem comes when someone gets irrationally flamed for having an unpopular position and/or outright attacked. That propagates a common misconception (that SlashDot readers are a bunch of immature jerks).

  • How about forwarding this to some "mainstream" news organizations? They're the ones that really need to disseminate this.

  • I somewhat agree with you on that, what should be going on is that the author should take all the input from all the comments that follow his article and use them to improve it, before being passed onto 'real' media. Open source essay anyone? ;]
  • Posted by Nick Carraway:

    I'll agree with your comments about the essay's structure, but would-be English teachers should spell-check their stones before casting them. Here are a few doozies that I uncovered in your reply:

    * ancillary, not "ancillery"
    * demonstrable, not "demonstratable"
    * reinforce, not "re-enforce"

    There were a couple of other spelling mistakes, but I picked the ones that were obviously not typos. Your sentence structure often seems forced as well, but I'm sure your freshman comp teacher will help you with that this Fall. Best of luck at community college!
  • The possibility of damaging hardware while programming it can be mostly eliminated with decent documentation, and the rest of the cases can be handled by including a disclaimer.

    This is simply not true. A vendor can't claim no warranty, and customers are going to claim they used them with the vendor code, not hacked, warranty-violating drivers. If Joe random programmer releases a new driver that gets 5% better performance but fries cards on a random basis, and a bunch of people download and use it, the vendor is going to get returns from those people. Since it's nigh-impossible to prove that it's the driver's fault, the vendor will end up having to replace those cards at their expense.
  • Or as Dr. Fred "Mythical Man-Month" Brooks said to us about presentations:
    "Tell 'em what you're going to tell 'em, tell 'em, and then tell 'em what you done told 'em."
  • He's referring to the certification of the license under which the drivers are released, not the drivers themselves.
  • I'll start by assuming that the 35M LOC used in Windows has the same proportion of unneeded lines to lines absolutely required as Linux (i.e. I've written code that does in 2k lines more than what someone else did in 13k lines, these are not comprable based purely on LOC). The Linux kernel source is 1909546 lines (including documentation), XFree86 3.3.3.1 on the other hand, which you don't have statistics for, is 6874758 then you add in Mozilla M6 which is 41483 and just for fun we'll throw in Gnome which weighs in at around 2230149 LOC. Now we add a 505543 for glibc 2.0.6 and an extra million or so for all the shell utilities and random X programs.

    Now we're showing more than 10 times the size of the kernel and probably a great deal larger in number of LOC debugged per unit time by nature of the fact that application code is easier to debug than kernel code and we still haven't figured in initial development or upgrades, only continuing support. The real comparison would be between the Service Packs to the NT kernel only and 1 LOC per 2 minutes, but not really because the NT kernel contains things like video card drivers and web server bindings that aren't in the Linux kernel. Also it wasn't specified if this was purely submitted lines of code or if it included fixes by the developers as well. If it's only submissions then you can count 0 for NT, otherwise I'd still bet on Linux versus SPs to the NT kernel, even with all the junk that's in the NT kernel.

  • While being modest on /. may be a good thing, it doesn't help the targetted desicion makers know why he should bother to read the article. So, assiming that it is going to be published somewhere else (closer to the target audience), RN should give his (quite impressive) credentials.
  • Nice counter argument, dude.
  • I agree wholhartedly

    Here's to hoping that Creative, 3dFx, and Matrox read this and become enlighted.

  • The Linux Kernel is gaining one debugged line of code every two minutes. This information from Alan Cox, the #2 kernel developer.

    Bruce

  • Windows 2000 ~= 35000000 LOC

    No, there are not 35000000 LOC in the Windows kernel, or if there are it's much worse than I thought. You're confusing the entire distribution with the kernel. Debian has about tripled in size in the past three years (source included), but I don't have a line count. Someone with more time on their hands could generate that.

    Bruce

  • One comment for the author: You have some credentials, but you make the reader infer them, and even that's hard until you talk about your own experience three quarters of the way down. How about front-loading your credentials on this, so that some corporate type knows who you are and why your opinion might be well-informed?

    Just a suggestion.
  • The possibility of damaging hardware while programming it can be mostly eliminated with decent documentation, and the rest of the cases can be handled by including a disclaimer. The process of writing a driver isn't all that much trial and error, unless you don't have good documents, or if you're trying to venture outside of what the board is designed to do. I've blown up a few boards while writing drivers for them, but the majority of those were due to incomplete information about the hardware (the rest were coding errors and pushing the limits of the board).

    As far as customer support goes, yes, there are those who will abuse it, especially if there is individual contact information handy in the distribution.

    But this merely highlights a problem that is becoming even more endemic to the industry, that of poor support across the board. Customer support is often treated as an afterthought, and is usually staffed with neophytes or other poorly trained personnel. Admittedly, it is hard to deal with the clueless among the user community, as well, but a lot can be done with a good support service.

    Even for a purely proprietary product, a support infrastructure is required, and they will have to deal with bug reports (accurate or otherwise), installation problems, driver conflicts, etc., anyway. One advantage of open source support for hardware would be that you would still provide a standard support model, in addition to being able to provide a single point of contact for bug fixes, etc., from the user community. This has the advantage of providing the service dept with more information than they might otherwise have, allowing them to provide even better support. There would be a need for more technically knowledgeable support personnel, but IMHO, these are needed anyway.

    Sadly, there is no way to completely circumvent the clueless user, and as a result, someone in a service dept, or even the designer, will end up dealing with it. But a great deal can be ameliorated with good documentation for the specifics of the hardware and the software, and by providing a single point of contact (to a GOOD service department) for support issues.

  • Some people commenting this article don't see that Russel is talking about drivers, not about proprietary software in general.

    Only few (but loud) radicals complain that closed source applications exist. So what. You don't have to use them. You can always write an alternative open source application if you have the time.

    But proprietery drivers are a different problem. You cannot use a device without drivers and if the reseller doesn't support your favourite OS, bang. Without hardware specs or - even better - example source code, writing a driver for some extravagant device is extremly painful and sometimes even impossible. You can try to re-engineer, but go ahead and try - it ain't fun.

    But now to my subject. I have read in an article that most graphics card manufacturers keep their drivers closed source because they are afraid of lawsuits.

    Thanks to strange laws, virtually every modern graphics algorithm is patented by someone out there. They are afraid that some competitor finds out that their driver uses such an algorithm or method...
  • I wonder how much of windows code doesn't really need to be there.

    I have worked with a proprietary software product which came in source code, and I have added features to certain parts of it, but instead of modifying their spaghetti code I just wrote the file over--the right way. I have written c programs with the same functionality as the canned one with some added features in half the lines of code. One of the programs was a single file with over 16,000 lines! And all it did was print a friggin' one page bill! I wonder if windows has anything like this in it.

    Jason
  • The GPL is not legislation, it's a license agreement. A voluntary agreement is by definition not coercive.
  • Heh. At CMU, 'rtfm' is a command which,
    roughly, is to 'man' as 'less' is to 'more'.

    ---Jason
  • Open source enthusiasts need to put numbers behind their claims. I'd like to see a list of say KLOC's per second of patches generated by open source. Or maybe a user happiness quotient. These essays are good and all, but how can we make decisions without dubious statistics gathered by unspecified methods?
  • 1 LOC per 2 minutes = 720 LOC/day.
    Windows 2000 ~= 35000000 LOC
    Unless I hit the keys on my calculator wrong, this means that it would take the Linux hackers ~133 years to write W2K. Wonder how that compares to MS? (insert your own W2K shipping delay joke here) No wonder the free software community is opposed to bloat.
    --Shoeboy
  • If you read the original post, I asked for meaningless statistics of dubious origin. (or something like that) I was operating on 3 hours sleep and feeling cranky - my original intent was to gripe about both the constant, completely unsupported 'open source works better' assertions, and the amazing prevalence of lousy numbers on the web. I didn't do it coherently though, sorry. Fortunately my request was granted, and I got lots of meaningless statistics of dubious origin. I'm pretty sure that Alan isn't a dubious source for linux development info, but I am pretty sure all of the statistics in the thread lack meaning - more so, since we have no idea how they were gathered (except my 35MLOC number, and that was a wild guess. Other guesses I've seen about the web number it from 12MLOC to 65MLOC) and precious little decent analysis of what they mean.
    --Shoeboy
  • If debugged lines of code were nose rings, in 33years and 4 months, the linux hackers could decorate a nostril on every Algerian woman between the ages of 15 and 65. (based on July 1998 estimate.) Furthermore, if the linux hackers recieved $100 per debugged LOC, in 4581 years they would be able to make 120.4 billion purchases at the dollar store.

    Oh yeah, and you should start by assuming that the 35M LOC in windows is a best guess.
    You should follow it up by assuming that Alan's .5LOC/min number cannot possibly indicate either further kernel development rates, or the rate of accelaration in development rates over time - there's no way to measure this without a time machine. It would also be worth noting that MS code is in a large part wizard generated, and may not be strictly neccessary. While were at it, we can note that
    #include "stdio.h"
    #include "tchar.h"
    #include "windows.h"
    #define HELLO_MSG "Hello World.\n"
    void main(void);
    void main() {
    _tprintf(_T(HELLO_MSG));
    }

    is equivalent to:

    #include "stdio.h"
    void main(void) { printf("Hello World.\n");}

    even though 1 has many more LOC. In conclusion, 75% of all statistics are meaningless.
    --Shoeboy
  • Ok, I keep seeing posts claiming that MS is paying people to post on /. If this is true, it totally redeems them in my view. In fact, I can't think of a better job. Free soda and /. Where do I apply? Do you get bonuses for "First Posts?" The one downside would be the performance reviews - "Well shoeboy, I'd like to give you a raise, but you keep getting moderated down for being off topic."
    --Shoeboy
  • Is it me, or is 'lose' the single most misspelled word on Slashdot(or on the net)? I swear if I see one more person loose the word 'loose' on everybody when he/she means 'lose' I'll lose it. And then I'll surely wish I could loose a big ferocious dog on the loser (and looser).

    chris :)
  • Making specs public is an easy way to gain wide support quickly. On the other hand reverse engenearing hardware is very easy.

    As wide support is easyer to hold on to once you have it than a monopoly on the specs it's logical to offer the specs.

    In the past chip makers would liccens compeating chip makers to make there chips. This way companys can use there chips with out fear of the chip maker taking the down if the chip maker gose out of busness.

    When you bet your busness on one company that company owns you. Even if Microsoft isn't going out of busness any time soon if you write software exclusivly for Windows your running the risk that Microsoft won't one day change Windows so your product dosn't work. Microsoft dosn't have to have an agenda they can do it as an honnest mistake.

    By providing the specs drivers for Linux, BeOS and any other operating system that wants to use your product should be comming around the corner. Your market share increases and Microsoft dosn't own you. It's still wise to keep your Windows drivers up to date however.
  • You want to provide a URL to reference this so-called FSF software tax reference? IDTS.

    Nothing wrong with giving somebody money in exchange for getting something from them. In fact, there's this whole capitalism thing that relies on it. Only difference is, if you buy, say, a software package w/ manual from the FSF or another free software company, you get three things:
    1. a product that you could have gotten for free over the Internet
    2. a manual that costs some money to print
    3. programmers who are now getting paid to write software for you (and a lot of other people, too!)
  • However.. there are a lot of talented hackers out there who would be more than happy to come up with a better/faster driver given some source code or at least specifications. For consumer items, I'd wager it's better for the company to skip internal development for new platform support/etc. Instead, make the source code free [speech] and give away a couple of their {video cards|sound cards|scanners|etc} to hackers who are willing to develop free drivers because they want experience, fame, or just free [beer] stuff. This potentially costs the company, and hence the consumer, much less.

    I am a paid programmer who likes to make money for what I do, but a few college hackers writing drivers in exchange for free hardware isn't going to put me out of a job. ;)
  • Okay. Now let me put this in perspective with the ACTUAL quote:

    --------- RMS said:
    In the GNU Manifesto, published in 1983 and 1985, I proposed a tax on computer supplies and equipment as one possible way to fund free software development.

    At the moment, it seems to me that we do not need to use any special taxes--it seems that the job will get done without them.
    ----------

  • You do not speak for me, or the large group of folks who believe the GPV is anything but "free". I do not stand for coercively making software freely available.

    Oh, this is to tired and overused...

    Let me put it simply: There is no such thing as 'absolute freedom'. have you considered the fact, for example, that my 'freedom to pursue happiness' confliucts with someone else's freedom of the same kind, if their pursuit of happiness involves punching me out?..

    Freedom necessarily comes with SOME restrictions, one way or another, there is no way out of it. Just as you cannot have absolute ethical relativism, you cannot have absolute freedom -- it conflicts with itself. The best you can do is pick which restrictions you wish to use.

    Do you want to guarantee that others do NOT have freedom to infringe upon my freedom? If so, you agree with the typical interpretation of 'freedom' by the modern societies (on the society level, that is) -- just as you lack the freedom to pursue your happiness by, say, robbing me and thus depriving me of my chances to pursue happiness. This is the GPL way.

    Do you prefer to impose NO restrictions? then you leave the door open for others do deprive me of freedom by pursuit of their version thereof; this is the BSD way.

    Both ways are free, in a different manner. So say that GPL is 'less free' than BSD is like saying that minimalistic libertarian government is 'less free' than anarchy. The latter seems to afford people more freedom -- by including freedom to deprive others of it; it is not at all clear that one is actually more 'free' than the other.

    So, man, drop the political shit and get that anti-GNU chip of your shoulder. We are not the enemy.

    --

  • Your life will be consumed with inane and demoralizing questions like "how to I run make?"

    I've faced these sorts of questions, and I don't mean to minimize the problem. However, there is a solution: learn to be unhelpful. Learn the words ``I can help you with questions about X, but I'm afraid I can't help you with that question. Please ask somebody else. Sorry.'' Most of the time, they'll go ask somebody else, and they won't even think bad thoughts about you.

    They don't have to support 10 thousand different compilers, repeatedly tell people not to use -O99 when they compile, or explain to people that you need version x.y of the foo library.

    The way to handle these sorts of questions is through a FAQ. Then reply to people saying ``please see the FAQ at ....''

    In other words, these problems can be solved, once you stop trying to solve problems merely because you know how to solve them. Never forget that your time is your own. By all means give it to other people when you can, but don't ignore the cost to yourself.

  • Why do you have to equate nihilistic anarchy with liberty? Since you mentioned libertarianism, it's basic tenet is that one cannot deprive another of their liberty (non-initiation of force). By punching me in the nose, you have violated my fundamental rights. By disallowing force/coercion/violence, you have not diminished anyone's liberty. Nihilism is a much different thing than liberty.

    Minimalistic libertarian government is of course less free than anarchy, and if human beings were angels, then anarchy would work. But BSD licenses have nothing whatsoever to do with anarchy! Neither does the GPL have anything whatsoever to do with liberty! These are licenses that grant permissions, not political rights.

    You lose no freedom at all by using a BSD license. If microsoft comes along and "borrows" your code, it's still there! You have lost nothing, nada, zippo. You may be pissed because they aren't as altruistic as you are, but so what? The BSD says "I'm sharing my code with the world". The GPL says "I'm only sharing my code with those who share their code with me".

    The problem with the GPL is it's "viral" nature. If I am coding with a GPL package, I must make sure that everything else I code with is GPL. If I am coding with a BSD package, I can code with everything else that is not GPL. Talk all you want about "free speech", but the BSD talks about "freedom of assembly"! Free speech means nothing if it is illegal for some people to speak.
  • The scientific community is hardly the utopia you describe. Fierce competition exists to acquire the limited grants available. Governments are lobbied for additional funding on glorious project Alpha, and if there isn't enough tax dollars to go around, then just take it away from that frivolous project Beta. And those few institutions that get away from the competitive infighting degenerate into mutual admiration societies.

    I'm not criticizing the scientific community, just trying to point out that they're no different than any other community.
  • I don't think he accused RMS of that. However, you can't deny that many of Richard's followers have said nearly the same thing, just not in quite so violent of verbage.

    Calling the GPL the "GPV" is just a mild form of satire. It pokes fun at exclusivity clauses in a "free license. Lighten up! Have you never mischaracterized MS as M$? Have you never called Windows as Windoze? Honestly now!

    Apparently it's okay for RMS and his disciples to mistype the users of proprietary software as "slaves".
  • "I'm willing to accept this level of tyranny for the time being."

    I seem to recall Lenin saying something very similar. If you consider free software to be liberty, then think on this "Those who would sacrifice a little freedom for some security deserve neither." What is this "time being" stuff?

    "Why do you use GPLed code?" Because this is not a liberty issue. Whether I use GPL or BSD or Proprietary is no different than if I use IBM's, Sun's or HP's hardware. But if my use of the software necessitates that I modify or distribute it, then I don't use GPL. Not because I think it's inferior or immoral or not free enough, but because I wish others to share my code. The GPL severly restricts the manner in which my code can be shared.

    Free software is not free speech!
  • Okay, I understand this and agree with you, the software value-add of a good driver is A Good Thing for a hardware company.

    However, I think that a more important thing, which the feature mentions but to which you didn't reply, is the hardware specs. The hardware specs allow anyone to write the type of driver you're talking about --- to complete with you, but not steal your stuff because they're writing their own algorithms.

    Creating hardware without publishing the specs dooms your hardware to be used only by those with the supported platform. By publishing the specs, those on unsupported platforms who want to use it can write drivers, and, very possibly, when the user base for the unsupported platform grows large enough on the renegade driver, there just may be enough of a market to justify the release (for sale by you, the vendor) of a souped-up driver using your super-secret patented software algorithms. If this software is Good, people will buy it.

    Everyone wins. Only the "all-software-must-be-completely-open" people are unhappy, but they would be unhappy anyway.

    To run the point into the ground, if you're going to make hardware, you should tell people how to use it. Period.
  • Except that 1 line of 2000 code != 1 line of Linux code. Linux code here only means kernel code, while 2000 code includes the GUI etc, meaning 80% of that doesn't count. Add to that the fact that one line of kernel code is worth more in terms of stability and design and the equation goes totally haywire.
    I wonder how many centuries the NT programmers would need to build Linux ..

    Floris
    -
  • One comment for the author: You have some credentials, but you make the reader infer them, and even that's hard until you talk about your own experience three quarters of the way down. How about front-loading your credentials on this, so that some corporate type knows who you are and why your opinion might be well-informed?

    And if he put that in there somebody else would be reaming him for 'bragging about where he used to work' or something stupid, like Jon Katz always got when he would just mention Wired or whatever.

  • Do these hold up in court? Does this mean Chrysler could sell me a car, and stick in the agreement (and who knows if they've already done it) that I can't take the thing apart to see how it works? Has anyone ever actually taken one of these clauses to court?

    I know that the difference here becomes hardware v. software, and that my reverse engineering my jeep doesn't reduce the value of chrysler's property, whereas with software it just might. But then, these drivers are more often than not free, anyway, right? Wouldn't an Open Source model actually reduce driver development costs for people like Diamond if they required modifications to be submitted back to them for testing and release for the good of all?
  • Boy I love FSF double speak... its free software, but we want you to pay a tax on it. They are worse than MS in their own way.
  • He doesn't threaten - just points out that the paying customers are struggling to be able to use the hardware to best suit their needs, while the competition has the tools and resources to reverse-engineer in minimal time.

    In a product development cycle, that reverse-engineering time is irrelevant when set against tooling, purchasing, and marketing.

    So, just as with dead-end copy-protection schemes, secret designs offer no barrier to the competition while disadvantaging the paying customer.

  • You mean he's modest ?
    Seems good to me ..

  • What makes you think that the openness of the drivers has anything to do with it? It seems to me that if you are looking to clone the hardware then you'll find just about everything you need by simply looking at the hardware. It's possible that Creative has patents on key parts of the sblive that make it difficult to legally clone.
  • I didn't think businesses had morals...

    Don't feed the trolls :8]

    ~Tim
    --
  • This article makes some interesting points, but does not present enough arguments for Open Source. The author tries to compare the scientific world to that of hardware vendors by stating: "In the world of science, many discoveries have been casual accidents". I dont' find this to be a convincing reason to open up drivers and hardware specs.

    Most hardware is designed for a specific purpose and most users are happy with that purpose. That's why they bought the device. If they can find another use for it, great. But, that doesn't mean that everyone wants to do that with it.

    Open Source drivers are be great, but are not necessary for making money. Companies have done fine without them and will continue to do so.
  • Matrox is already enlightened! You can download the specs for the G400 which hasn't even been released yet from their webpage after a free registration! Some guys have hacked a G200 3d driver (which runs quake2 at 8-10fps on the g200, and 20%-80% faster on the G400 aparently...) already (the guy was from VA and had a pre-released demo or something).

    Matrox is already enlightened... no code, but the specs of programming a device driver is there. Not to mention that Xfree 3.3.4 which is being released soon will support the G400 and you can't even buy the G400 yet! Well, within a week you'll be able to, but the Matrox website says "preorder the G400..."

    -ryan
  • I agree with the above post. You should most definitely establish yourself as a expert, especially on /. where a good number of very confident poster are college students.

    For such a short article a simple sentence or two could do the trick. "We faced this issue during the 20+ years I was working in xxx industry" or some such. Modesty works, but make sure we know that you are being modest and not just some 2-bit hack.

  • Those old-fogie executives will wake up when they see sales figures. I don't see any fully open source drivers happening until some daring young company is able to do it AND MAKE MONEY AT IT. I think it will work because any company that does it at this point will be /.'ed at the retail level. And I believe that brand loyalty is huge in the Open Source realm, if you will (flame whats?). But who's going to take that first step?
  • Let me start by saying this article has quite a bit of capitalistic merit. My company (IBM) should certainly pay more attention to this.

    HOWEVER, I feel I must post a "caution" (for lack of a better term) about this feature, which has evolved through years of Finding-Out-the-Hard-Way.

    There are two problems that this article does not address. By releasing a driver for a piece of your hardware in Open Source form, you open up a big can of worms in two areas: customer support and hardware damage.

    I will speak on the second topic first because it's probably less obvious. I have worked in houses which design some pretty complex devices. These devices typically make network cards look like a child's plaything. With this hardware, it is often possible to apply certain register settings that will destroy the boards, aside from the possibility to hang your machine. Please note that this possibility is more common than you might expect. Also note that these kinds of boards are now becoming more common, and are more likely to make their way into the Open Source/Free Sofware/etc. community.

    Given the trial-and-error nature of Open Source debugging, there would exist a significant possibility users would start frying their boards after tinkering with it. They would then direct all their anger toward the manufacturer, and the end result is obviously not good for either party. In this case, keeping the drivers closed protects the consumers from damaging their products and contains the damage to those few unlucky prototypes in the lab.

    One other major concern for businesses is the cost of customer support. When drivers become Open Source, any Joe User now feels he has the right to call the design engineer and speak his mind at all hours of the day. Nevermind that Joe doesn't have the number; he'll find out if it kills him. Since Joe can't get his poorly formed hack to work, he has no compunction about calling Mr. Design person at 4 am to bitch about how bad Mr. Design's hardware is.

    I am not making this stuff up. It happens every day to design engineers, who end up spending their entire working lives answering tech support questions to people that really aren't qualified to hear them. There is no way to move on to new designs when your email address is at the top of a Linux driver header file. Your life will be consumed with inane and demoralizing questions like "how to I run make?".

    Engineers are blissfully shielded from all this when it's done in house, which keeps them happier and more good products rolling out the door. They don't have to support 10 thousand different compilers, repeatedly tell people not to use -O99 when they compile, or explain to people that you need version x.y of the foo library.

    Granted, this is NOT an argument against Open Source support for hardware -- I sincerely hope that effort continues to succeed as well as it has been of late, because I plan on running Linux forever :). But everyone needs to consider these things when you start ranting "Give us all your source or we'll say bad things about you."
  • He first states that companies should open up their source because there is a larger market -- then threatens that even if they don't, we will reverse engineer your product anyway -- so just give us the goods now.

    So you're confused by the author's presentation of more than one reason to do something. What's the problem?

    He also touches upon, but fails to strike down the idea that if everyone has your product specifications, then the competition can clone your cycle even faster.

    This is false. He quotes some frighteningly short times for the reverse engineering of some products -- go back to the article and to a search on 3C509 to refresh your memory.

    --

  • I'm trying to figure out if I like or I hate what you say. On one hand, you take the all too bitter "education" point of view that an evil high school teacher (Kimmery) of mine did. On the other hand, you write with the classy style that I find in Salon Magazine.

    But we're engineer types. We focus on the meat and not so much the trimmings. It made sense even before reading your re-write. Actually, it made a little more sense. It didn't use "ancillery" and "postulation" or "expository".

    But you are quite correct... it could use some touch-ups.
  • I'd just be happy to see hardware manufacturers manufacture a standard board for once. Companies like Packard Bell, HP and Compaq manufacture these shitty boards that have proprietary plug-in cards. My gf had a Compaq system that had a proprietary freaking modem. Talk about re-inventing the wheel. Friend of mine had a HP that used a riser for expansion cards - and his case was BIGGER then my standard-board case. Total crapola. I'll be happy when they make these cases easy to open, easy to get into, and easy to upgrade.
  • I think the author meant that the source should be distributed under an OSI-certified license (such as GPL, LGPL, Artistic, BSD).
  • Thanks for all the comments. Lots of people had good contributions. The revised version of this essay will have a link from my web page (URL above).
    -russ
    p.s. yes, I'm preaching to the converted. You're supposed to take this essay and wave it in the faces of people who aren't converted yet.
  • I guess I don't write very well -- my whole point is that no assets are at risk. You still own your patents and copyrights. Your enemy already owns your trade secrets, so why not give them to your friends as well?
    -russ
  • Nobody is going to bother to clone your product unless it's clearly the market leader. If it's the market leader, why do you care if someone tries to copy your product? By the time they can, you've out-innovated them. The only time you've got something at risk is when you've got a cash cow that you have no follow-on product for. If that's the case, you've got other problems than just cloners.
    -russ
  • I think I've already addressed your point. You're saying that the company's friends have trouble reverse-engineering. I agree, and further assert based on personal experience that the company's enemies have good reason to do the reverse-engineering and keep it a secret. I've done reverse-engineering when I had lots of free time (student). I made a compilable source of MS-DOS 1.0, COMMAND.COM, and DEBUG.COM. It's just not that hard. And I had to write my own disassembly tools -- you can just go buy them now.

    Yes, writing an Ethernet driver isn't that hard, now that documentation is available for them, and now that there's a body of free software to work off of. Go and grep for Crynwr or Nelson in /usr/src/linux/drivers/net/*.[ch] . This is not to diminish Don Becker's work, but merely to point out that his work builds on mine (and others, including the Jay Maynard who is posting here).
    -russ
  • I'm not saying that Open Source drivers are necessary for making money. I'm saying that proprietary information doesn't help you make money. Therefore, you may as well give away information about your hardware, since it might help.
    -russ
  • The manufacturer has control over the new market by virtue of selling the hardware which it's based on. More control doesn't help grow that market, and can only hurt it.
    -russ
  • Who's talking about bootlegged drivers? I'm not asking companies to make *their* driver code public. I'm just asking for enough programming information so that we can write our own drivers.
    -russ
  • On the subject of hardware damage, you've got a lot more to fear from random windows crashes than hacker probing. At least with hacker probing you can say "You play, you break, you lose."

    On the subject of customer support and inappropriate questions, a developer just has to be disciplined. The 'D' key is your friend. Tech support has to be able to say "We didn't write that driver; we don't support it either."
    -russ
  • Right. Ask the right party for the dox. These days it's usually the chip maker.

    Not to dismiss your experience, but in my experience, Ethernet controller documentation is usually complete and accurate enough to write a working driver. Maybe that's because they've had to supply such for many years because no one manufacturer controlled the market.
    -russ
  • Could you point out just one of them?
    -russ
  • Well, of course this audience is converted. You're supposed to use it as a tool to wallop the infidels.

    And of course, I disagree that it's the same argument, otherwise I wouldn't have bothered to write it. For example, tCatB says that peer review produces reliable code. I say that holding back information about your hardware doesn't lead to more success in the marketplace.

    Do you think I'm wrong?
    -russ

  • Although you have a good point, you would be amazed at who reads this.

  • I'm sorry, but yes "They are trying to make money". You think business wants to make just free software. I'm all for RMS and his views but I believe mainly that libraries and OS should be under LGPL because other tools use them and should have full benefit of them. But all I care about a user-end app is that it is Open Source. Even as a developer, I like to see how something works, but I don't just want to have it for free (as in beer not speech).

    Let Open Source get into the business market. Then worry about Free Software. No proprietary business I know wants to go Free yet. Let them benefit from Open Source then test the waters of FSF.
  • What this guy is pointing out is the need to share your work in order to make it better. What's happening here is sort of what happens in the scientific community. Science people are expected to release papers when some experiment makes a breakthrough, so other scientists can replicate the experience. But when there's money involved, nobody shares anything.
    Computing and programming is a science like anything else. And if we want to *really* make breakthroughs (AIs, sentient software, etc.) we should start to behave more like a community and not like a bunch of capitalists.

    My $0.02, from Argentina.


    Mondongo
  • Oooh I think we need to sit down and think about this one don't we.

    1 - Alan's statistics are for lines of debugged code - I.e. code which has been checked and fixed. Not total lines of code.

    It's easy to write lines of code but to write lines of code that are debugged is a hard job - why do you think windows 93 never shipped.

    2 - The Linux kernal is the core of the Operating system. to create functionality you have to add in Apache, X Windows, FTP Server, User programs, Multimedia extensions, setup routines, easter egs, network utilities, network daemons blah blah blah.

    I think you'll find that if you strip the kernel from Linux and you string the excess tat from NT you have a much closer comparison to make.
  • I have one of those HP "riser for expansion card" PCs! The only solution is to design my own case...being able to get in (and get testprobes in) is essential.
  • So as long as I don't install it I can reverse engineer it? Could this be true? (hehehe) Would they believe me if I told them I thought it was true??? (hehehe hehehe hehehe)-*deviously chuckles*
  • Serious question:
    What if I monitor the change of states, as you refered to ("clean room") and I ALSO decompile for the purpose of easing the documenting of said changes? If the new product is written from scratch? That is, if the only use of the decompile is to further the understanding of the flow of the change of states?>br>
    Would it be ok if one person did the above, to create a flowchart? Then another used the flowchart to code a new algorith without ever looking at the decompiled code?

    Does it matter if one uses a one-to-one mapping of the input/outputs rather than augmenting this with decompiled source code? (Again, assuming that no code is stollen for the new implementation?)
  • But there is no correlation between spelling ability and intelligence! As an atrocious speller who scored college level reading comprehension in the 4th grade I am an example. I also do math.
    The ability to percieve,
    the ability to analyse/synthesize,
    the ability to arrange thoughts coherently,
    the ability to express said thoughts in a given medium, with due consideration to the audiance (to avoid an impedence mismatch)
    and oh yeah, right, the ability to spell.
    Quess one needs to empahsis what what can do? (Thats last ones supposed to be a joke, son).
  • So if 75% of all statistics are meaningless, why'd you ask for them in the first place?
  • This is just another dumb peice of propaganda from the non-free software crowd.

    You must not know who Russ Nelson is. He's the guy responsible for the existence of the overwhelming majority of the freely available driver code for Ethernet cards out there. He was releasing driver source code long before it was fashionable.


    You keep posting things that directly or indirectly assault everything we stand for. What a bunch a turncoats! OSI does not have you're best interests at heart.

    To borrow a famous punch line, "What's this 'we' shit, white man?" You do not speak for me, or the large group of folks who believe the GPV is anything but "free". I do not stand for coercively making software freely available.


    They are a tool of business, created by Tim Oreilly and his flunky, Eric Raymond. There are trying to make money, not free software.

    Your point is?

    Let me put this another way: I'd like to see you walk up to the checkout counter at your local grocery store and pay the bill with a freshly updated copy of GNU EMACS. Like it or not, money is the only widely accepted medium of exchange, and making money is necessary to survive...that is, unless you enjoy living on the street.
    --

  • Do you prefer to impose NO restrictions? then you leave the door open for others do deprive me of freedom by pursuit of their version thereof; this is the BSD way.

    I'm STILL missing something. How, exactly, has the BSD code become less free even though others have adopted it and made it part of their proprietary, non-free (by either definition) code? What, exactly, IS the NetBSD source tree I'm tracking (for three different platforms)?

    I contend that the BSD code is MORE truly free than GPV-infected code because I can do with it whatever I wish. Doing so in no way affects your freedom to do with it whatever YOU wish.


    So, man, drop the political shit and get that anti-GNU chip of your shoulder. We are not the enemy.

    You (collectively) are the enemy, at least for one of my main objectives: seeing freely available software gain acceptance in the real world. I'd much rather work ith Linux and BSD for a living than, say, Windows 2000. RMS' repeated posturing that his way is The One and Only Pure Path to Freedom and Enlightenment and that ESR and the OSI are heretics to be burned at the stake at the first opportunity do nothing to advance that cause at all. Writings such as Russ Nelson's and ESR's do quite a bit to advance that cause.
    --

  • Jay, you Ignorant Splut[...]

    (shaking off the effects of a trip down memory lane) Shame you posted that as an AC...it's been a long time since anyone has called me that, and I'd like to have known who was still around that remembered it...


    this is just like saying that a company's Intellectual Property Agreement is coercive. Of course it isn't. You don't have to work for them.

    That's not your only choice, though. It happens that I've had this discussion in the recent past, in a setting where it mattered, and such agreements are generally negotiable in a manner satisfactory to both sides. Neither deed restrictions nor the GPV are.
    --

  • Depends on how you define "intelligence"; it's said, around the Johnson Space Center, that you can't make anything astronaut-proof because astronauts are so darned ingenious...
    --
  • if you read RMS's article on /. from a couple of weeks ago, you will notice that he in no way attempts to call ESR and the OSI "heretics to be burned at the stake at the first opportunity".

    You're right to call me on this; I overstated the case a bit for humor. RMS's rhetoric is seldom this flammable. The members of The Church of the Holy GNU, OTOH...


    you should not insult GPL by mistyping its proper name.

    This one falls in the category of calling a spade a fscking shovel. The GPV is exactly that: a legal virus that contaminates all it touches. Insulting it is exactly what I have in mind. My hope is that this debate does not die away, and that people realize that there are alternatives to the GPV for truly free software.

    I realize that this will make me, in the eyes of a nontrivial portion of the community, an Evil Bad Guy Who's Out to Make Money, and thus a Danger to the Movement. I'm willing to accept that, because it also makes me more palatable to the folks who make real world decisions, and right now I care more about getting freely available software adopted in the real world than whether RMS' utopia ever comes to pass.
    --

  • The GPL is the only thing that sets us free.

    This is the entire bone of contention between the followers of The Church of the Holy GNU and those of us who believe that calling something free does not necessarily make it so. It may set us free from one evil, but I contend it binds us to another: RMS' software communist utopia. I do not accept that evil either.


    It's not coercion to make someone do the moral thing by law.

    The objection here is the same as the objection to legislating morality in other areas: Whose morality? There are some moral values, like "killing without cause is wrong", that are noncontroversial; legislating those is not a Bad Thing. OTOH, legislating your morality is no better than legislating the entire Christian fundamentalist agenda would be.
    --

  • Re:More Open Source (tm) Propaganda! (Score:3)

    by Jay Maynard ( 54798 ) on Thursday July 08, 1999 @05:49AM (#1813341) Homepage
    A voluntary agreement is by definition not coercive.

    Would you call a deed restriction you must agree to before purchasing a house voluntary? Many folks do, arguing that you always have the choice not to buy the house. I believe that it, like the GPV, is what's known as a "contract of adhesion": an agreement that is not negotiable, and therefore not a true "meeting of the minds", but rather a take-it-or-leave-it proposition that's attached to something else.

    (Those who claim that shrinkwrap software licenses fall in this category will get no argument from me, either.)

    The GPV coerces me to join RMS' utopia if I wish to partake of the benefits of his "free" code. I do not think that's either freedom, or acceptable.
    --
  • you will soon loose all the free software developers
    But that which was free first, can never be loosed!
    And that which was loosed, well 'twas never quite free.
    With meaning so muddled as you have produced,
    I wonder what else you can't manage to see.
  • It has been my observation that not only do the overwhelming majority of Internet posters in both this forum and nearly every other one you are apt to come across find themselves miserably incapable of spelling even the most common of words with the accuracy expected of your average fifth grader, they are also hard put to compose a sentence that uses words with anything longer than two or perhaps three syllables and nine or ten characters, whichever comes first. But this already sordid state of affairs does not begin to reveal the deplorable state of their linguistic destitution. Few and far between are those writers today whose video-game-addled attention spans permit them to compose or even to assimilate sentences containing more than one independent clause, let alone to weave together several varied devices into one larger, coherent construct. Although it is almost embarrassingly easy to notice and decry their pathetically clumsy stabs at rigorous orthography, that particular failing is but a venial sin that pales in comparison before the far more perilous problem so clearly indicated by their complete ineptitude when it comes time to logically develop and carefully enunciate a thought of any depth or complexity--in a sense, to think with deep breaths and to set these thoughts down in well-formed writing.

    I recommend to you Amusing Ourselves To Death, by Neil Postman.

  • What the heck are you talking about? He is not talking about releasing any for-profit software for free, he is talking about releasing already free(beer) software as open(free speech) software.
    I don't know of any company who makes money on their drivers, their drivers are just a way of selling the hardware, and as such it makes sense to have the drivers avalible to the largest number of people possible for the lowest cost possible.
  • All very good points.
    Commenting, and documenting the different registers by descibing what they do, what the limits are, and what the consiquences are when they are set to certain values would be much more helpful in preventing the destruction of cards than leaving it closed and proprietary. If the product is valued by a group that isn't supported, and if that group has the ability, the chances are very good that the product will be reverse engineered. This increases the chances of destroying the card because there better chances of changing one of those variables to a value that in inappropriate.

    As for the average joe calling engineers. There is no good way to prevent that unfortunately. Perhaps in order to gain access to the code one would need to register themselves with the company as requesting it. To keep the code from getting into the wrong hands, so to speak, place some sort of identifing tag in it, so that derivations can be traced back to a specific person. That way when complains of broken code are sent in they can be directed to the person who owns the identifing tag. Not perfect, but it makes it harder for Joe to get his hands on code and from hunting down the engineer who made the original code.
  • Just a short comment... if you read RMS's article on /. from a couple of weeks ago, you will notice that he in no way attempts to call ESR and the OSI "heretics to be burned at the stake at the first opportunity". On the contrary, his comments are polite and constructive. You are free to believe in the BSD license more than in the GPL one, however, you should not insult GPL by mistyping its proper name. In so doing, you fall into the same trap that Mr. Metcalfe and others have fallen, and do not benefit any part of the Free Software movement.

    Take care,


    Wolfheart
  • "You're right to call me on this; I overstated the case a bit for humor. RMS's rhetoric is seldom this flammable. The members of The Church of the Holy GNU, OTOH..."

    Judging a person by its followers is just as debatable, IMHO, as judging a religion by the members of its church. What I am trying to say is that a person cannot be held responsible for the way other people act. Of course, I cannot be certain of what Richard Stallman himself means, I can only give you my own interpretation...

    "The GPV is exactly that: a legal virus that contaminates all it touches. Insulting it is exactly what I have in mind. My hope is that this debate does not die away, and that people realize that there are alternatives to the GPV for truly free software."

    The GPL is attempting to set a group of rules for the distribution of free software. It does not, afaik, limit you from redistributing your software later on under a different license (correct me if I am wrong though). I am not saying it is the one and only _true_ way, but it is definitely better suited at preserving a certain set of rights (those of the program itself).

    As you said, the GPL is less about convincing businesses to create/use free software, and more about a way of life. Both your efforts (as a non-follower of GPL) and ours are useful, and will contribute to the ultimate goal - a better society, be that through freedom (as Richard Stallman envisions it) or through better software (as you seem to envision it).

    Take care,

    Wolfheart
  • how to use rtfm anybody? (overheard on Dalnet #linux)

    some guy on freebsd-hackers started a thread about a new utility called "rtfm." Guess what it does :-)
  • The analogy does not quite work. When you buy software, you are actually buying the liscense to use it, not the code itself. It is still owned by the company. You know that annoying little user liscense you click through every time, well that is a legal binding that you _agree_ not to do that in exchange for the right to use the software. It is the consumer who agrees not to reverse engineer.
  • The author probably submitted this here in order to gauge /.'ers responses to it. The Slashdot forum is probably the best one around for getting not only criticism, but also emotional feedback. I'm guessing the reason I'm hooked to this site is because I enjoy seeing how my feelings mesh with those of others', whether agreeable or not.

    I hope that many more folks are inspired to put their arguments into cohesive articles, and then submit themselves to our relentless commentary. I further hope that those folks gain enough quality feedback to polish the rough ends (where necessary) and place their views where the powers of change can be most effective. Keep up the good work, Russ!
  • Nice piece.

    You overlooked what I think is the biggest reason companies have problems donating code to open source: legal reasons. I.e. the company licensed code or technology from several sources to make their product, and they do not own redistribution rights to that code.

    I know for a fact this is a big problem at software vendors like SGI, IBM, etc. who must pay the cost of untangling dependencies of software they'd like to open-source from SVRx/BSD/OSF/other code they don't have redistribution rights to.

    I suspect its also a lesser but still present issue at hardware vendors who have licensed pieces of technology from others (e.g. a 3D chip maker who has licensed S3's VGA boot code or 2D core, for example. They can't give away S3's software interface code or documentation.)

    Solving this problem would definitely help the Linux community. Creative suggestions anyone?
  • I know, I know - I agree that manufacturers should let us have their drivers. Ultimately, an improved driver means that the hardware runs better/faster - which can only be a good thing.

    I was generalisng though, and stick by my comments on software.

    Mong.

    * Paul Madley ...Student, Artist, Techie - Geek *
  • The debate rages (on and on). Without paid-for software, computing would not be as widespread - many people wouldn't be here.

    Can people not see, that in order to undertake big project, you need teams, facilities, _budgets_. Sure, release the source - let people make improvements (I agree, to an extent, with the Netscape stance). If people are gonna invest their time, effort and money into something which people want, why not charge a little - not M$ amounts, but enough to allow them to code the next version. Am I making sense?

    There's no such thing as a Free Lunch. With isolated, individuals/organisations developing products, you'll get different standards and differing quality. Wanna go back to the dark old days? I don't.

    Mong.

    * Paul Madley ...Student, Artist, Techie - Geek *
  • Are you having a serious case of ignorance today? Because the author never said that companies were releasing drivers all the time, he said they should. You also infer that you haven't done any driver coding yourself -- that's a serious loss of credibility in this game considering your comments.
  • He first states that companies should open up their source because there is a larger market -- then threatens that even if they don't, we will reverse engineer your product anyway -- so just give us the goods now.

    He also touches upon, but fails to strike down the idea that if everyone has your product specifications, then the competition can clone your cycle even faster.

    He makes one good point though. It is that once your device drivers are released in open source, you can expect the community to release bug fixes themselves.

    I think the basic question is:

    Is the Open Source market large enough for us to even worry about lost customers -- while still worrying about competition cloning our products?
  • Oh? I'd like to see what creative has to say about that. They still haven't released open source drivers for their sblive.

    It's been a while now too -- and we haven't seen any company come out with a very similar product (would likely be diamond).

    One example I can give you though is with the Tivo digital VCR thing. I know of a company who has taken looked over their open source drivers and linux distro and included some 'ideas' in their windows computer version of the product -- all made possible by open source :). Lets see, a couple months reverse engineering or 5 minutes reading source code.. I wonder.
  • The point, however, is that, beyond ethernet cards and a few graphics cards, you arent going to see fast reverse engineering.

    Just ask the people trying to reverse engineer the creative drx2. Linux doesn't have many drivers for multimedia products -- and probably never will until there is an actual market for such a thing.

    Also, an ethernet card is an ethernet card. No one really gives a ##$# either way. I'm also willing to bet that creating drivers for that type of hardware as such is easy relative to other products. This is probably why drivers have been released for almost every ethernet card there is (not to mention that many use or are derived from the exact same chipsets).

    An example of when a company has finally been co-operative and released specs is ATI. They've released specs 6 months ago and the initiative for drivers for their tv product has been moving incredibly slow. May I also mention DVD? How about some types of high end raid? How long has it taken to create drivers for miro cards? Let alone software to even use these specialty products.

    Wether it be the amount of time it takes or the fact that no one is willing to put out the effort just yet; The simple fact is that companies are going to try and protect their investment for as long as possible. I think the author is trying to spur some investment in the movement on their part -- since this is often a weekend project for much of the contributing community. Bigger projects just can't be done, and won't be done unless hardware companies release specs and documentation to aid in the development of software and drivers for their products. If the market grows exponentially in the next couple of years, then maybe -- but not now. Not when they have other interests to protect.
  • As a commercial device driver writer, I can tell
    you exactly why HW Mfgr's don't publish source code, it's called "value add".

    These days, most HW boards are centered around a particular chip. In network boards, it's an ethernet chip, in graphics boards, it's the accelerator, in sound cards, it's the DSP.
    In every market segment, there are generally only
    one or two market leaders for a particular chip niche. Competition between companies using the same hw design is fierce.


    All silicon vendors
    publish "reference designs" which are unoptimized
    (and generally buggy) versions of code that works with the chip in known design settings.

    In todays world of short design cycles, most HW board designers don't stray too much from the reference design. They don't have the time.

    In order for a HW board vendor to distinguish
    themselves from the reference design, they have to
    value add. This generally means figuring out how to make the chip run faster or better using software.

    If I, as a HW board vendor publish my value add,
    I'm allowing those Taiwanese companies that just
    manufacture the chip reference design to kill me.

    It is a non-trivial exercise to extract value add from a chip. This represents real investments. These "value adds" are not something that casual open source hackers are going to figure out.

    I'll give you 2 personal experiences (with names left out because they were clients)..

    I wrote drivers for a CODEC chip. There were
    3 other companies using the same chip. In the
    process of development, we discovered by accident
    a non-intutive 7!! lines of code that would cause
    the chip to encode at 15 frames/sec. The best that the reference design and other users could manage was 10. None of the other companies (nor even the chip mfg) ever discovered this and my client derived a great deal of money from the ability to show better video.

    Another example was an S3 chip customer who was
    able to blow away other vendors in benchmarks using the same chip by using some interesting hacks to the chip.

    If you want to apply pressure someplace, don't talk to the HW board guys, talk to the semiconductor vendors and ask them to publish the source code to their reference designs.


Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close