This whole thread brings up several points that management needs to examine before accepting/rejecting a module:
- Does the management and/or engineer suffer from NIH (Not Invented Here) syndrome. This is a very real, and sometimes fatal, affliction where the perons involved will not accept a module/component/device/etc merely because it was not invented by their company/department/team. I saw this a fair amount at IBM, and I've heard that Motorola is notorious for it. This is often a matter of pride, sometimes a matter of distrust (which is a variant on pride), and occasionally a legal matter. Accepting a component not developed by your people/department/company can lead to support availability issues, etc, that may play a factor.
- Are there practical ramifications to not accepting a module? It may indeed make *your* life easier, but what are the licensing requirements? Will it place your company in an undesirable position? If it's an Open Source module, and you are not a Open Source embracing company, this places you in violation. Developing your own component (and let's use this to cover just about anything we need, large or small, software or hardware) keeps your proprietary knowledge just that. Information may want to be free, but the shareholders don't always see it that way.
- What are the long term support issues in the module? If you have a problem, will your people be able to figure it out? If it's a closed source component, and the company goes out of business, will you be seriously up a creek? (Obviously, the Open Sourcers will start going nuts right about here, but I'm taking this just a little past the Perl module discussion). Do you have rights to the source, if said company goes out of business?
- What's the reliability of the component in question. We (Perl developers) have this tendency to trust CPAN modules. "Oh, they've been out there, they're debugged". Well, that's just utter nonsense. Some of those modules have only been out there since yesterday, some are so little used as to have no history, there are seemingly endless updates for others. Yet, we trust them. Now, if you've got the source, sure, you can fix them if you find the bug. If you're smart enough, anyway. How many of you think you could really fix something in Parse::RecDescent? What's the security, for certain modules? Do you *really* want to trust an enterprise financial package's core security functionality to a module with no history? (And you Open Source nuts, calm down. Just having the source doesn't mean you can see/find/fix/understand any/all the security holes. Security holes can be more than just an 'if' statement looking for a checking account number. Sometimes it's a race condition, or other trickier, less obvious beast.
While I readily agree that some of these examples are slightly outlandish, they are very very real. They represent concerns that *real* companies (that know what they heck they're doing) have. Open Source obviates a few of these, but doesn't necessarily fix the legal issues.
It's for reasons like these that companies would rather pay you 8 times what it's worth for you to write it. At that point, the company owns it. Assuming you're a half decent programmer, and you're programming for what you're paid, and not for job security, the company now owns that technology, free and clear (you weren't stealing that idea, were you?). Free and clear doesn't just mean licensing issues, either. It means they own the technology, which adds value to the company. A company that is built on a product that they don't own all the components of, or don't understand the technology of, is pretty worthless (unless you've got a management team that are consumate scam artists. Been there, seen that).
Anyways, I hope this has provided some enlightenment as to why companies can't always go to 'Free Wheel Depot'. Free is not always Free, nor always Best. And Dog help anyone who gets me started why companies shouldn't hire consultants most of the time... (Even though I am one! I love to consult, I hate consultants!)
--Chris
e-mail jcwren