Re^3: Why non-core CPAN modules can't be used in large corporate environments.

Every non-trivial technical package has this problem. Also, if the "non-developers" are making all the decisions without developer input, I guess I'd have to ask "why?". Who better to assess the situation than the guy that has to deal with it? Also, how much money are you spending re-inventing wheels?

thor

The only easy day was yesterday

Comment on Re^3: Why non-core CPAN modules can't be used in large corporate environments.

Replies are listed 'Best First'.
Re^4: Why non-core CPAN modules can't be used in large corporate environments. by Moron (Curate) on Dec 06, 2005 at 15:18 UTC
The minute an issue goes multi-functional it enters a political arena. The developer may theoretically be able to give input to such an arena, but usually they lack the verbal skills to make an impact at that level. If your experience is otherwise consider yourself lucky. To address your last point, a non-module solution is not necessarily a re-invention of the wheel; indeed instead of backporting there is yet a third option: just copy the parts or even ideas you need from the module rather than treating its use as an all-or-nothing proposition and suddenly the developer is king again - I used that method to sneak Devel::Trace into a Q/A environment. -M Free your mind	[reply]
Re^5: Why non-core CPAN modules can't be used in large corporate environments. by tirwhan (Abbot) on Dec 06, 2005 at 16:54 UTC
just copy the parts or even ideas you need from the module...I used that method to sneak Devel::Trace into And I take it you've discussed licensing with MJD and put the correct copyright attribution into your corporate code? Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.