Linked by Thom Holwerda on Mon 5th Oct 2009 17:50 UTC
Software licensing. As home users, it's already an incomprehensible mess of legalese that nobody cares one bit about. However - we home users have it easy. The situation for business users and people managing IT departments is even worse (proprietary software, mostly, of course). Microsoft is a major culprit in this regard, and while the company acknowledges that the situation is messy, they claim they can't really do anything about it.
Permalink for comment 387850
To read all comments associated with this story, please click here.
Obviously, you've missed my point. It's not usually the data that causes problems; it is the code behind that data. Unless we are to assume that you work for a company that doesn't actually do anything with the data it produces.
If my company wanted to switch from MS Office to Openoffice, for example, probably the biggest pain in the ass would be having to rewrite all those Excel macros and such. And even if you were using OpenOffice and ODF, when you wanted to switch from that to something else in 10-20 years, I don't see how you're going to be free from this hassle, unless you get lucky and whatever you switch to just happens to support Openoffice macros. Hell, I can hire interns to go through documents and make sure italics are in the right places, but what about that Excel spreadsheet that has a macro which hits an Oracle database and prints out graphs/charts based on the data that is returned?
If you've got a standards-compliant website and you use PHP on the back-end, if you wanted to change from PHP to another language, it's still going to suck, even if you don't have to change the formatting. Sure, it'll be cheaper if you don't have to reformat any of the data, but it's not like, "Oh, we're using open standards, so we can flip this switch and overnight we'll be on a new platform/office suite/whatever.'
I guess my point is that once you get settled on a particular infrastructure, it's difficult to move away from it, so there are risks involved no matter which way you go. When moving to something from something else, there's almost always going to be some pain involved, whether you're stuff is tied to a particular vendor or not. Rarely (if ever) will it be as cut and dry as you make it sound.
Member since:
2005-11-13
Obviously, you've missed my point. It's not usually the data that causes problems; it is the code behind that data. Unless we are to assume that you work for a company that doesn't actually do anything with the data it produces.
If my company wanted to switch from MS Office to Openoffice, for example, probably the biggest pain in the ass would be having to rewrite all those Excel macros and such. And even if you were using OpenOffice and ODF, when you wanted to switch from that to something else in 10-20 years, I don't see how you're going to be free from this hassle, unless you get lucky and whatever you switch to just happens to support Openoffice macros. Hell, I can hire interns to go through documents and make sure italics are in the right places, but what about that Excel spreadsheet that has a macro which hits an Oracle database and prints out graphs/charts based on the data that is returned?
If you've got a standards-compliant website and you use PHP on the back-end, if you wanted to change from PHP to another language, it's still going to suck, even if you don't have to change the formatting. Sure, it'll be cheaper if you don't have to reformat any of the data, but it's not like, "Oh, we're using open standards, so we can flip this switch and overnight we'll be on a new platform/office suite/whatever.'
I guess my point is that once you get settled on a particular infrastructure, it's difficult to move away from it, so there are risks involved no matter which way you go. When moving to something from something else, there's almost always going to be some pain involved, whether you're stuff is tied to a particular vendor or not. Rarely (if ever) will it be as cut and dry as you make it sound.
Edited 2009-10-06 03:20 UTC