Feature: On Being Proprietary 139
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.
Calculation error (Score:1)
Re:On the sticky subject of proprietary products.. (Score:1)
> 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)
Postfix, by the way, is a fantastic piece of software. End sendmail, use postfix. It's probably a drop-in replacement for you.
Re:Preaching... (slightly off-topic?) (Score:1)
Preaching to the converted... (Score:2)
Re:Typical /. Fluff (Score:1)
A spelling lesson for Conan the Grammarian... (Score:1)
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!
Re:Good points, but ... (Score:2)
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.
Re:Focus on the structure (Score:2)
"Tell 'em what you're going to tell 'em, tell 'em, and then tell 'em what you done told 'em."
Re:He doesn't seem clear to me. (Score:1)
Bad Statistics. (Score:1)
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.
Re:one comment for the author (Score:2)
Re:swiss cheese (Score:1)
Good Points! (Score:1)
Here's to hoping that Creative, 3dFx, and Matrox read this and become enlighted.
Re:What we need are statistics. (Score:2)
Bruce
Re:What we need are statistics. I did Math (Score:2)
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 (Score:2)
Just a suggestion.
Good points, but ... (Score:1)
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.
Reasons for proprietary drivers (Score:2)
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...
How about bloated code too? (Score:1)
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
Re:More Open Source (tm) Propaganda! (Score:1)
Re:Preaching to the converted... (Score:1)
roughly, is to 'man' as 'less' is to 'more'.
---Jason
What we need are statistics. (Score:1)
Re:What we need are statistics. I did Math (Score:1)
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
Re:Really Really Bad Statistics. (Score:1)
--Shoeboy
Re:Really Really Bad Statistics. (Score:2)
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
#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
Re:This guy is almost surely an MS-paid agitator. (Score:3)
--Shoeboy
you've lost me with your loose talk (Score:1)
chris
A little more on this (Score:1)
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.
Re:More Open Source (tm) Propaganda! (Score:1)
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!)
Re:On Why HW Card Mfg's don't publish source code (Score:1)
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.
Re:More Open Source (tm) Propaganda! (Score:1)
--------- 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.
----------
Re:More Open Source (tm) Propaganda! (Score:1)
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.
--
Re:On the sticky subject of proprietary products.. (Score:2)
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.
Re:More GPV (tm) Propaganda! (Score:1)
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.
Re:Methinks you have it wrong... (Score:1)
I'm not criticizing the scientific community, just trying to point out that they're no different than any other community.
Re:More Open Source (tm) Propaganda! (Score:1)
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".
Re:More Open Source (tm) Propaganda! (Score:1)
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!
publish HW specs, not driver code (Score:1)
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.
Re:What we need are statistics. I did Math (Score:1)
I wonder how many centuries the NT programmers would need to build Linux
Floris
-
Re:one comment for the author (Score:1)
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.
Legal soundness of Reverse Engineering Clauses (Score:1)
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?
Re:More Open Source (tm) Propaganda! (Score:1)
Re:He doesn't seem clear to me. (Score:1)
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.
Re:one comment for the author (Score:1)
Seems good to me
Re:He doesn't seem clear to me. (Score:1)
Re:More Open Source (tm) Propaganda! (Score:1)
Don't feed the trolls
~Tim
--
Arguments Not Strong Enough (Score:2)
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.
Re:Good Points! (Score:1)
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
Establish expertise (Score:1)
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.
Re:Excellent! Lets send this essay around!! (Score:1)
On the sticky subject of proprietary products.... (Score:2)
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
What exactly is the problem? (Score:1)
So you're confused by the author's presentation of more than one reason to do something. What's the problem?
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.
--
Salon Magazine gives tip to Slashdot contributor! (Score:2)
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.
How about just no proprietary? (Score:1)
Re:He doesn't seem clear to me. (Score:1)
Thanks for all the comments (Score:1)
-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.
Re:Preaching to the converted... (Score:1)
-russ
Re:He doesn't seem clear to me. (Score:1)
-russ
Re:What exactly is the problem? (Score:1)
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
-russ
Re:Arguments Not Strong Enough (Score:1)
-russ
Re:Arguments Not Strong Enough (Score:1)
-russ
Re:Yes--They Do (Score:1)
-russ
Re:On the sticky subject of proprietary products.. (Score:1)
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
Re:publish HW specs, not driver code (Score:1)
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
Re:swiss cheese (Score:1)
-russ
Re:Typical /. Fluff (Score:1)
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
Re:Preaching to the converted... (Score:1)
Although you have a good point, you would be amazed at who reads this.
Re:More Open Source (tm) Propaganda! (Score:2)
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.
Like the good ol' scientists (Score:2)
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
I did Math - I marked it 2/10 see me. (Score:1)
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.
Re:How about just no proprietary? (Score:1)
Re:Legal soundness of Reverse Engineering Clauses (Score:1)
Re:Yes--They Do (Score:1)
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?)
Re:you've lost me with your loose talk (Score:1)
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).
Re:Really Really Bad Statistics. (Score:1)
Re:More Open Source (tm) Propaganda! (Score:1)
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.
--
Re:More Open Source (tm) Propaganda! (Score:1)
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.
--
Re:More Open Source (tm) Propaganda! (Score:1)
(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.
--
Re:On the sticky subject of proprietary products.. (Score:1)
--
Re:More Open Source (tm) Propaganda! (Score:1)
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.
--
Re:More Open Source (tm) Propaganda! (Score:2)
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)
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.
--
Re:More Open Source (tm) Propaganda! (Score:2)
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.
Re:you've lost me with your loose talk (Score:2)
I recommend to you Amusing Ourselves To Death, by Neil Postman.
Re:More Open Source (tm) Propaganda! (Score:1)
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.
Re:On the sticky subject of proprietary products.. (Score:1)
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.
Re:More Open Source (tm) Propaganda! (Score:1)
Take care,
Wolfheart
Re:More Open Source (tm) Propaganda! (Score:1)
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
Re:Preaching to the converted... (Score:1)
some guy on freebsd-hackers started a thread about a new utility called "rtfm." Guess what it does
Re:Legal soundness of Reverse Engineering Clauses (Score:1)
Re:Preaching... (slightly off-topic?) (Score:1)
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!
One reason you didn't address: Legal issues (Score:3)
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?
Re:More Open Source (tm) Propaganda! (Score:1)
I was generalisng though, and stick by my comments on software.
Mong.
* Paul Madley
Re:More Open Source (tm) Propaganda! (Score:2)
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
Re:What exactly is the problem? (Score:1)
He doesn't seem clear to me. (Score:2)
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?
Re:He doesn't seem clear to me. (Score:2)
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
Re:What exactly is the problem? (Score:2)
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.
On Why HW Card Mfg's don't publish source code (Score:2)
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.