Chris, I think you might have played with Northeastern University's band once a couple years ago. You borrowed a saxophone, and we never got it back. We tried to call you, your friends, your place of work, your parents; in short, everyone we could find who had a connection with you. And yet, we never got a hold of you *or* the sax, and it was an expensive one.
What happened to that instrument, and was this a precursor to your later warez activities???
(Note: If this is the wrong Chris, my sincere apologies for accusing you of something you didn't do!)
I actually ran into this at work yesterday. A Java developer was using Apache to prepare a demo for a client. He ran into an issue with Apache, and we had some trouble figuring out the solutions. Although we did figure it out, for a few minutes it seemed like there wasn't an answer. His first action? "Well, let's get on the phone with the Apache people!" When I quietly informed him that there wasn't a specific "Apache people" to get on the phone with, he was utterly confused. Next he wanted the distributer... and completely didn't understand the concept of Apache being free, open source, and open developed.
It does pose an interesting problem. Although in my experience it's been easier to find a solution for an open-source software, companies are very used to purchasing contracts. As more and more IT professionals get on the "open-source bandwagon" companies are having to readjust their policies and thought processes towards supporting and understanding the software that they use, rather than the Commercial-Off-The-Shelf approach.
So when "real money" is at stake, like it was here, how do you explain to the management the benefits of free, available code? Does it actually save money in the end? After all, to a company man-hours are the most expensive portion; investing time in a developer to learn and rewrite the code giving him a problem is, to them, far more expensive than buying a software contract from the local support company. Unfortunately, they frequently don't understand the difficulty of working with a closed source base and trying to add functionality to a product it wasn't designed to handle.
Slashdot Mirror
This is slightly OT, but what the heck...
Chris, I think you might have played with Northeastern University's band once a couple years ago. You borrowed a saxophone, and we never got it back. We tried to call you, your friends, your place of work, your parents; in short, everyone we could find who had a connection with you. And yet, we never got a hold of you *or* the sax, and it was an expensive one.
What happened to that instrument, and was this a precursor to your later warez activities???
(Note: If this is the wrong Chris, my sincere apologies for accusing you of something you didn't do!)
I actually ran into this at work yesterday. A Java developer was using Apache to prepare a demo for a client. He ran into an issue with Apache, and we had some trouble figuring out the solutions. Although we did figure it out, for a few minutes it seemed like there wasn't an answer. His first action? "Well, let's get on the phone with the Apache people!" When I quietly informed him that there wasn't a specific "Apache people" to get on the phone with, he was utterly confused. Next he wanted the distributer... and completely didn't understand the concept of Apache being free, open source, and open developed.
It does pose an interesting problem. Although in my experience it's been easier to find a solution for an open-source software, companies are very used to purchasing contracts. As more and more IT professionals get on the "open-source bandwagon" companies are having to readjust their policies and thought processes towards supporting and understanding the software that they use, rather than the Commercial-Off-The-Shelf approach.
So when "real money" is at stake, like it was here, how do you explain to the management the benefits of free, available code? Does it actually save money in the end? After all, to a company man-hours are the most expensive portion; investing time in a developer to learn and rewrite the code giving him a problem is, to them, far more expensive than buying a software contract from the local support company. Unfortunately, they frequently don't understand the difficulty of working with a closed source base and trying to add functionality to a product it wasn't designed to handle.