I consulted Wikipedia earlier in this discussion to confirm that my understanding was mainstream and it was (although I don't take Wikipedia as gospel). You, on the other hand, have a unique definition of lock-in that nobody could expect to be using until you finally explained it.
Overall, I found that your post makes a lot of unproven assertions that are popular in certain circles (e.g. Java or web apps are the solution to vendor lock-in and host of other ills). Yes, there are many ways to make multiple platform applications (although none of them are really WORA) even without Java or a browser.
The key question is whether this idealistic goal has any real business value. As long as you choose a non-niche platform, the vast majority of in-house applications have no need to run on other platforms. In addition, if it's a non-command-line app, the user experience will meet or exceed what can be achieved with Java or browser-based apps. Java because it has to compromise to achieve multi-platform functionality and browser-based apps because in general, elements such as the back button aren't appropriate.
I think rewriting working applications merely to try undo vendor lock-in is a bad business decision in most cases.
As usual, there's isn't a one-size-fits-all approach that gives the best solution. User Java apps when appropriate, use browser apps when they are appropriate and something else otherwise.
Getting back to the orginal point, I think given a conventional definition of lock-in, Unix apps running on OS X isn't relevent. I don't think, however, the vendor lock-in matters that much. The only issue I have is when a different set of rules are used for different platforms. Sometimes excuses are made for Apple that wouldn't fly if we were taking about MS.
When developing software, it's the speed of thinking that is usually the limiting factor, not the speed of typing. Quality code can't be written contiguously at 100 WPM.
"Note that I am not discussing the specific application of EULAs that don't appear until after you've purchased the product. That's a whole different issue in and of itself (give me the money, ok, *now* read the contract!). But I fail to understand the furor behind software licensing in general."
You made some good points. I think in the case of EULAs, one might be surprised the first time, but after some experience most people realize that there's going to be one and have the option of not buying the software. I suspect that even after opening the box, a retailer will let you return it if the seal on the CD case hasn't been broken, thus allowing you to make an informed decision before commiting yourself to an irrevocable agreement. This is shakier than having the opportunity to read the EULA before a purchase, but not as unreasonable as some wish to believe.
"Both are mostly coded by commercially funded developers."
"Both are mostly" doesn't qualify as exactly the same.
"The majority of the current Linux kernel was not coded by Linus but by others and you might notice Linus does receive funding from several commercial entities."
A slippery statement. First of all the issue isn't Linus vs. others but non-commercial vs. commercial. Unless a very high percentage of kernel code has been discarded or the kernel has grown significantly, it seems unlikely that commercial development created the majority of it. Where's your proof?
Beyond the "lines of code issue" what percentage of the fundamental design of the kernel was performed before the commercial entities were involved? That is just as relevant.
"I think he's trying to imply that since OS X came out, Mac users have started to use pine and lynx and emacs instead of the usual Mac programs or something."
Perhaps, but I just think he made a poor argument and doesn't want to admit it was incorrect.
The fact is that not all agreements are technically contracts and agreements can be binding without any signature required. Unlike your silly false analogy, most people are aware of EULAs before they buy and have the simple remedy of not purchasing a license if they don't like it. As I said before, someday a court may agree with your position but it hasn't happened yet.
"They have no business whatsoever to control what one does with their own copy."
Perhaps someday EULA's will be ruled illegal by the courts. In the meantime, they are have as much legal validity as any other agreement. Copyright isn't the only law in play.
It could be relevent in a general way, but not to the subject of lock-in as it applies to the Mac. Lock-in is about being unable to run an application designed for the platform in question on another platform. The ability to run UNIX applications on the MAC, for example, argues against UNIX lock-in, but not OS X lock-in.
"No one claimed that OSX specific apps could be run elsewhere"
Not explicitly, but..
"Given the Apple emphasis on support for open standards (such as a standards-compliant web browser and email client) and the UNIX base of Mac OS X, I'd say Apple users are relatively much less locked in than Windows users."
The fact that OS X is based on Unix would be relevent to lock-in only if OS X apps could run on Unix. Thus my comment.
"Who cares whether someone is calling the kernel Linux or calling the kernel and userspace Linux when the exact same situation exists for both?"
So what situation is exactly the same for both kernel and userspace? Certainly not the percentage of design and implementation effort done by commercial companies for them. Or do you believe that Linus's contribution to the kernel was insignificant before he started being paid?
"If you could wink and ignore the chicken and egg problem, couldn't they fund the Free Software replacement with a portion of those fees?"
If part of the problem is ignored, just about any solution will suffice. There's all kinds of possible cooperative efforts between companies that might save them money in the long run. Why doesn't this happen more? Because companies usually are focused on their core business and becoming involved in other activities that are not related to the core can be a major distraction. Unless the savings are large compared to the company's overall business expenses, it usually isn't worth it.
My comment was relevent because you claimed that Linux was primarily developed by commerical companies and you sited userspace applications as part of your evidence. Given that the definition of what constitutes "Linux" is very fluid on Slashdot, I was trying to determine what definition you were using and the implications for that choice. Sorry if defining your terms bothers you.
"The vast majority of both the Linux kernel and the userspace applications have been paid for by commercial companies"
So are we taking the position today that Linux development includes userspace applications and thus Linux's security and stability includes all of those applications, or are we taking the position that Linux is just a kernel and some GNU libraries? The story around here changes so much, it's hard to keep track.
"Most people don't need 100% of the features in an application like AutoCad and it's often possible to bootstrap other applications."
Yes I'm sure there's a lot of non-architects who don't need the power of an application like AutoCad. For them there's already a number of $20-$50 packages that will do the trick, no additional development is required.
"Don't you think that The American Institute of Architects (for instance) could fund the development of a Free CAD application to suit their members needs for less than the members pay in licensing currently?"
And where exactly do you think the money going to do that is going to come from? Membership in AIA is about $210 a year already.
"This is in no way inherent in the open source model. Open source does not even mean developed in house."
I was responding to this:
"Collaborate with competitors in the same field for the common product they all need, then compete in pursuit of their market."
It might not be inherent in the open source model, but it was I was responding to. In any case, I don't think that many open source projects are going to change priorities in response to outside companies' needs unless the contribution is very high.
"Linux. Who develops it? Lots of commercial companies and it saves them (including my company) a whole lot of money. The open source business model is not academic, it is a real world reality and has been for decades"
Linux of course, is an atypical case, but the core development wasn't done by commercial companies anyway (although they've done a good job of branding their own distros to profit from unpayed developers).
"Hey, if we can impeach Clinton for lying about a blowjob.. where getting the blowjob wasn't illegal, but lying about it was"
Actually Paula Jone's attorneys were very careful not ask Clinton directly about specific intimate acts (e.g. blowjobs) because he'd have felt compelled to answer yes. Instead they asked vague questions so that he had enough wiggle room to answer no, but could still be accused of lying later.
"Instead of paying money to buy software, a company can instead choose to pay less money to modify an open source project to meet their needs and leverage the contributions other companies have made modifying the same project to their needs. It's game theory in action. Five companies all pay a little to modify an open source project instead of all five paying a lot for some big box software solution. Collaborate with competitors in the same field for the common product they all need, then compete in pursuit of their market. Game theory. "
I think you've rather "cooked the books" a bit here. It's not at all clear that modifying an OS project is going to cost less than buying one. In the case of complex applications like AutoCad, it would take considerable effort to bring open source versions to the same feature level. A company would probably have to hire additional employees (this is not a job for a typical IT type) with all the costs associated with it. There is also the issue of compatibility: you will be at a competitive disadvantage if you use tools that other parts of your industry don't use unless those tools provide unique value. Even if in those cases where it would appear to be in the long run, companies can't always choose the long term view.
The collaborative model also carries added costs. There's the cost involved in managing the multiple-company development (e.g. Who's in charge?). There's also the added cost associated with the analysis required to determine the line between collaboration and competition as well as the potentially large cost of coming to the wrong conclusion.
When you look at this issue from a real-world perspective things become more complicated than an academic view can appreciate.
Obviously because the clone makers would have to create a clean-room implementation of the OS (as they did for the BIOS) which would have taken more time and money. In addition since IBM would have full control of the hardware and the OS it would have been very easy to introduce incompatibilities without any OEM customers to worry about. Remember the Micro Channel architecture? IBM was quite willing to play proprietary games in those days (if not today).
"IBM pushed MS VERY hard on OS/2, and pushed for it to have a gui."
They may have pushed MS on OS/2, but they didn't push OS/2 in the marketplace. IBM spent far more money pushing the PCjr with the chiclet keyboard than they did OS/2. OS/2's GUI wasn't a real selling point either. It was its support for programs that needed to use large arrays without having to use ugly DOS-style memory models that was it's main advantage over MS's OS's (at least until NT came along).
Slashdot Mirror
I consulted Wikipedia earlier in this discussion to confirm that my understanding was mainstream and it was (although I don't take Wikipedia as gospel). You, on the other hand, have a unique definition of lock-in that nobody could expect to be using until you finally explained it.
Overall, I found that your post makes a lot of unproven assertions that are popular in certain circles (e.g. Java or web apps are the solution to vendor lock-in and host of other ills). Yes, there are many ways to make multiple platform applications (although none of them are really WORA) even without Java or a browser.
The key question is whether this idealistic goal has any real business value. As long as you choose a non-niche platform, the vast majority of in-house applications have no need to run on other platforms. In addition, if it's a non-command-line app, the user experience will meet or exceed what can be achieved with Java or browser-based apps. Java because it has to compromise to achieve multi-platform functionality and browser-based apps because in general, elements such as the back button aren't appropriate.
I think rewriting working applications merely to try undo vendor lock-in is a bad business decision in most cases.
As usual, there's isn't a one-size-fits-all approach that gives the best solution. User Java apps when appropriate, use browser apps when they are appropriate and something else otherwise.
Getting back to the orginal point, I think given a conventional definition of lock-in, Unix apps running on OS X isn't relevent. I don't think, however, the vendor lock-in matters that much. The only issue I have is when a different set of rules are used for different platforms. Sometimes excuses are made for Apple that wouldn't fly if we were taking about MS.
When developing software, it's the speed of thinking that is usually the limiting factor, not the speed of typing. Quality code can't be written contiguously at 100 WPM.
What's cool about what you do is that it's probably easier on your wrists than touch-typing.
"Also, the Drovak keyboard is biased against left-handers: "The right hand should do more of the typing, because most people are right-handed.""
True, but QWERTY was biased against right-handers. The DVORAK is faster either way.
"Note that I am not discussing the specific application of EULAs that don't appear until after you've purchased the product. That's a whole different issue in and of itself (give me the money, ok, *now* read the contract!). But I fail to understand the furor behind software licensing in general."
You made some good points. I think in the case of EULAs, one might be surprised the first time, but after some experience most people realize that there's going to be one and have the option of not buying the software. I suspect that even after opening the box, a retailer will let you return it if the seal on the CD case hasn't been broken, thus allowing you to make an informed decision before commiting yourself to an irrevocable agreement. This is shakier than having the opportunity to read the EULA before a purchase, but not as unreasonable as some wish to believe.
"Both are mostly coded by commercially funded developers."
"Both are mostly" doesn't qualify as exactly the same.
"The majority of the current Linux kernel was not coded by Linus but by others and you might notice Linus does receive funding from several commercial entities."
A slippery statement. First of all the issue isn't Linus vs. others but non-commercial vs. commercial. Unless a very high percentage of kernel code has been discarded or the kernel has grown significantly, it seems unlikely that commercial development created the majority of it. Where's your proof?
Beyond the "lines of code issue" what percentage of the fundamental design of the kernel was performed before the commercial entities were involved? That is just as relevant.
"I think he's trying to imply that since OS X came out, Mac users have started to use pine and lynx and emacs instead of the usual Mac programs or something."
Perhaps, but I just think he made a poor argument and doesn't want to admit it was incorrect.
Yes, it would be quite amusing if you tried to defend violating a EULA in court and started talking about building codes.
The fact is that not all agreements are technically contracts and agreements can be binding without any signature required. Unlike your silly false analogy, most people are aware of EULAs before they buy and have the simple remedy of not purchasing a license if they don't like it. As I said before, someday a court may agree with your position but it hasn't happened yet.
"They have no business whatsoever to control what one does with their own copy."
Perhaps someday EULA's will be ruled illegal by the courts. In the meantime, they are have as much legal validity as any other agreement. Copyright isn't the only law in play.
It could be relevent in a general way, but not to the subject of lock-in as it applies to the Mac. Lock-in is about being unable to run an application designed for the platform in question on another platform. The ability to run UNIX applications on the MAC, for example, argues against UNIX lock-in, but not OS X lock-in.
"No one claimed that OSX specific apps could be run elsewhere"
..
Not explicitly, but
"Given the Apple emphasis on support for open standards (such as a standards-compliant web browser and email client) and the UNIX base of Mac OS X, I'd say Apple users are relatively much less locked in than Windows users."
The fact that OS X is based on Unix would be relevent to lock-in only if OS X apps could run on Unix. Thus my comment.
I don't see how the Unix base has anything to do with it. Which Unix systems can run typical OS X apps?
this has already been attempted and it failed because no scheme can guarantee that a program will function identically on all platforms.
"Who cares whether someone is calling the kernel Linux or calling the kernel and userspace Linux when the exact same situation exists for both?"
So what situation is exactly the same for both kernel and userspace? Certainly not the percentage of design and implementation effort done by commercial companies for them. Or do you believe that Linus's contribution to the kernel was insignificant before he started being paid?
"If you could wink and ignore the chicken and egg problem, couldn't they fund the Free Software replacement with a portion of those fees?"
If part of the problem is ignored, just about any solution will suffice. There's all kinds of possible cooperative efforts between companies that might save them money in the long run. Why doesn't this happen more? Because companies usually are focused on their core business and becoming involved in other activities that are not related to the core can be a major distraction. Unless the savings are large compared to the company's overall business expenses, it usually isn't worth it.
My comment was relevent because you claimed that Linux was primarily developed by commerical companies and you sited userspace applications as part of your evidence. Given that the definition of what constitutes "Linux" is very fluid on Slashdot, I was trying to determine what definition you were using and the implications for that choice. Sorry if defining your terms bothers you.
"The vast majority of both the Linux kernel and the userspace applications have been paid for by commercial companies"
So are we taking the position today that Linux development includes userspace applications and thus Linux's security and stability includes all of those applications, or are we taking the position that Linux is just a kernel and some GNU libraries? The story around here changes so much, it's hard to keep track.
"Most people don't need 100% of the features in an application like AutoCad and it's often possible to bootstrap other applications."
Yes I'm sure there's a lot of non-architects who don't need the power of an application like AutoCad. For them there's already a number of $20-$50 packages that will do the trick, no additional development is required.
"Don't you think that The American Institute of Architects (for instance) could fund the development of a Free CAD application to suit their members needs for less than the members pay in licensing currently?"
And where exactly do you think the money going to do that is going to come from? Membership in AIA is about $210 a year already.
"This is in no way inherent in the open source model. Open source does not even mean developed in house."
I was responding to this:
"Collaborate with competitors in the same field for the common product they all need, then compete in pursuit of their market."
It might not be inherent in the open source model, but it was I was responding to. In any case, I don't think that many open source projects are going to change priorities in response to outside companies' needs unless the contribution is very high.
"Linux. Who develops it? Lots of commercial companies and it saves them (including my company) a whole lot of money. The open source business model is not academic, it is a real world reality and has been for decades"
Linux of course, is an atypical case, but the core development wasn't done by commercial companies anyway (although they've done a good job of branding their own distros to profit from unpayed developers).
"Hey, if we can impeach Clinton for lying about a blowjob.. where getting the blowjob wasn't illegal, but lying about it was"
Actually Paula Jone's attorneys were very careful not ask Clinton directly about specific intimate acts (e.g. blowjobs) because he'd have felt compelled to answer yes. Instead they asked vague questions so that he had enough wiggle room to answer no, but could still be accused of lying later.
Clinton did this as he came into office. Nobody would have a problem if Bush had done it under the same circumstances.
"Instead of paying money to buy software, a company can instead choose to pay less money to modify an open source project to meet their needs and leverage the contributions other companies have made modifying the same project to their needs. It's game theory in action. Five companies all pay a little to modify an open source project instead of all five paying a lot for some big box software solution. Collaborate with competitors in the same field for the common product they all need, then compete in pursuit of their market. Game theory. "
I think you've rather "cooked the books" a bit here. It's not at all clear that modifying an OS project is going to cost less than buying one. In the case of complex applications like AutoCad, it would take considerable effort to bring open source versions to the same feature level. A company would probably have to hire additional employees (this is not a job for a typical IT type) with all the costs associated with it. There is also the issue of compatibility: you will be at a competitive disadvantage if you use tools that other parts of your industry don't use unless those tools provide unique value. Even if in those cases where it would appear to be in the long run, companies can't always choose the long term view.
The collaborative model also carries added costs. There's the cost involved in managing the multiple-company development (e.g. Who's in charge?). There's also the added cost associated with the analysis required to determine the line between collaboration and competition as well as the potentially large cost of coming to the wrong conclusion.
When you look at this issue from a real-world perspective things become more complicated than an academic view can appreciate.
Obviously because the clone makers would have to create a clean-room implementation of the OS (as they did for the BIOS) which would have taken more time and money. In addition since IBM would have full control of the hardware and the OS it would have been very easy to introduce incompatibilities without any OEM customers to worry about. Remember the Micro Channel architecture? IBM was quite willing to play proprietary games in those days (if not today).
"IBM pushed MS VERY hard on OS/2, and pushed for it to have a gui."
They may have pushed MS on OS/2, but they didn't push OS/2 in the marketplace. IBM spent far more money pushing the PCjr with the chiclet keyboard than they did OS/2. OS/2's GUI wasn't a real selling point either. It was its support for programs that needed to use large arrays without having to use ugly DOS-style memory models that was it's main advantage over MS's OS's (at least until NT came along).