Slashdot Mirror
Feature: On Being Proprietary
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.
CompetitionThe 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.
How about forwarding this to some "mainstream" news organizations? They're the ones that really need to disseminate this.
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.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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."
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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.
Bruce
Bruce Perens.
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
Bruce Perens.
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.
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...
------------------
You may like my a cappella music
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.
.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
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
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
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.
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.
Let me start by saying this article has quite a bit of capitalistic merit. My company (IBM) should certainly pay more attention to this.
:). But everyone needs to consider these things when you start ranting "Give us all your source or we'll say bad things about you."
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
The opinions I post here have nothing to do with my employer.
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'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.
Steven Rostedt
-- Nevermind
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
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.
--
Disinfect the GNU General Public Virus!
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.
--
Disinfect the GNU General Public Virus!
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.
I recommend to you Amusing Ourselves To Death, by Neil Postman.
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?
The debate rages (on and on). Without paid-for software, computing would not be as widespread - many people wouldn't be here.
...Student, Artist, Techie - Geek *
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
*...Slacker, Artist, Techie - Geek *
Remember: Nothing is Cool.
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?
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.