Developers As Pawns and One-Night Stands 268
jcatcw writes "At the Comes vs. Microsoft antitrust case, last Friday's testimony included evidence that James Plamondon, a Microsoft technical evangelist, in a 1996 speech referred to independent software developers as 'pawns' and compared wooing them to trying to win over a one-night stand. Last week's proceedings also included testimony by Ronald Alepin, a former CTO at Fujitsu Software Corp. and currently an adviser to the law firm Morrison Foerster LLP. He said that Lotus 1-2-3 was killed, in part, by Microsoft encouraging Lotus's programmers to use the Windows API even though Microsoft's own developers found it too complicated to use." The plaintiffs have created a site that includes transcripts of testimony presented in the case.
Stupid-ass Question (Score:4, Insightful)
Re:What's The Big Deal (Score:5, Insightful)
This is Microsoft employees saying their customers, the ones they're supposed to be developing good API's and such for, are pawns and they should never be catered to.
Re:It's just the name of the game (Score:2, Insightful)
Re:Woo (Score:3, Insightful)
Re: Removes it??? (Score:2, Insightful)
Re:Stupid-ass Question (Score:1, Insightful)
No, they can't - not while they are monopolists. That's they way the anti trust laws work.
Re:And this is relivant because Anti-competitive. (Score:5, Insightful)
Re:News flash - sky still blue! (Score:2, Insightful)
I have survived several RIFs in some large banks as a contractor, while FTEs I sat and worked with were let go.
Contracting is a much more honest relationship between employer and employee. I don't work, they don't pay. They don't owe me anything, I don't expect anything from them. I don't put up with the corporate bullshit, they don't expect me to. When I work overtime, I get paid. I don't 'request' time off, I inform that I won't be in. I don't have to fit in to any corporate team bonding excercise, although on the occasions I do attend, which usually involve lots of beer, I am heartily welcome.
And I take home about 50% more than similarly employed FTEs in the workforce.
Re:Woo (Score:5, Insightful)
There is no reason that someone else could not make controls that fade in with graphics and color menus. No secret Windows APIs are or were required to do this, even at that time. Windows has always allowed applications to draw whatever they want in their windows, and that includes transparency and fading. The win32s extensions [wikipedia.org] for Windows 3.11 even offered support for non-rectangular windows. Even easier, Microsoft licensed their Office controls to applications developers who wanted to do it. There are no special undocumented API calls required to do this stuff.
Re:Undocumented APIs (Score:3, Insightful)
Re:Undocumented APIs (Score:3, Insightful)
That said, I think the whole GPL-only symbols thing is stupid, myself -- it means that Free-but-non-GPL projects like OpenAFS get hamstrung.
Re:Undocumented APIs (Score:3, Insightful)
BSD?
Re:Undocumented APIs (Score:5, Insightful)
Clearly, you want to have a proprietary driver. Thus, you want to do something that the developers have ACTIVELY and CLEARLY stated that they are working against, and give no quarter for. You obviously don't like that, and that's your right. But you didn't write their code, nor pay for it, so they are not responsible for your desires... and that is their right.
This is very different from the Windows situation. Microsoft has kept some APIs quiet, and even the very existance of some APIs. In contrast, this Linux kernel policy has been clear for over a decade. You may not like it, but you have no right to complain; this policy was certainly there before you decided to write a line of code. As long as an organization makes clear what the rules are, then you try to work against them at your peril.
Yes, a stable internal API of the kernel would be a possibility. Windows, for example, has one. But most Windows crashes are from BAD DRIVERS; the drivers cannot be fixed, and the Windows interface can't be fixed either. That's not good evidence that this would be a GOOD thing for users. The reliability of Linux is actually pretty good evidence that their process actually works better for end-users.
Unbelieveable (Score:2, Insightful)
Funny that there are endless discussions about the poor technical quality of Microsoft's products, and at the same time rants that Microsoft is gaining an unfair advantage via technical means. Either the technology is good or it's not. If this case is valid, then we must also acknowledge that Microsoft's technology is king too.
Closed Linux drivers are distributed all over (Score:1, Insightful)
Using a GPL "Bite me, RMS" module to re-export GPL symbols with "EXPORT_SYMBOL" instead of "EXPORT_SYMBOL_GPL" is perfectly legal. GPLv2 doesn't say "You can't use EXPORT_SYMBOL in GPL kernel modules, you must use EXPORT_SYMBOL_GPL." And IIRC Linus himself has stated that GPLv2 will remain the kernel license.
So "EXPORT_SYMBOL_GPL" is completely useless. It doesn't prevent closed-source drivers from accessing GPL symbols, because those proprietary drivers can access those symbols using another module that is GPL. And that second module is trivial. Who cares if it's GPL'd and distributed? It doesn't do anything other than export symbols that everyone who can understand source code already knows is there anyway.
Re:Woo (Score:3, Insightful)
The functions on that site are indeed largely undocumented (many of the functions are officially documented [microsoft.com] as part of the DDK, but only for use in kernel mode). The functions are considered private to the OS. No one is accusing Office or other Microsoft non-OS products from using those functions. They are only used to implement the Win32 API and some system services. I, too wish that they would document those since they are considerably cleaner and more stable interfaces than the Win32 equivalents, but please don't confuse private parts of the OS with special functions for MS applications. It'd be very infeasible for them to remove any of those functions; they're used heavily inside the OS to get things done. Never has a working function in the native API been removed or seriously changed. It'd be like removing the mmap() syscall from the Linux kernel in response to the mmap() vuln they had a while ago.
Re:Undocumented APIs (Score:3, Insightful)
But it wouldn't be proprietary if you gave it to them...
Well, there isn't much point if they're going to keep it to themselves. How many hobbyists need to hang onto the code, and wouldn't donate it back to the kernel team?
But only the closed-source vendors would be able to maintain it. Suppose I have a TNT2 card - do you think that Nvidia is going to release a driver for it when linux 2.8 comes out?
The idea is to get rid of the closed-source easy-out - which should result in more code being opened. Sure, some code just won't get used at all, but that puts vendors who refuse to open their code at a disadvantage, at least among linux users. And why should Nvidia profit by selling cards to linux users when they don't release their code? The drivers wouldn't work without the kernel, and the kernel was made GPL to force redistributers to release their sources. Now, the kernel won't go GPLv3 anytime soon, but other software will, and future GPL versions will only tighten some of the closed-source loopholes that currently exist.
It has worked pretty well so far. And if somebody wants to make their own middle-layer they can, just don't expect the kernel team to help you out.