in reply to Compelling arguments urgently required
Well, there's no compelling reason, for the strict definition of 'compulsion'. The whole point of open source software is that you can ride for free if you want to. There are no gates you can only pass through if you grease the appropriate palms, and no rights you can buy above and beyond those given away for free.
So it comes down to a question of philosophy -- of ethics, in the sense of 'ethos': the character and values of an individual or group. Within that range of arguments, the one with the most obvious payback is enlightened self-interest: helping someone today so they can help you tomorrow.
Everyone can ride in Perl's wagon for free, but the wagon won't move unless someone is willing to push.
If everyone waits for someone else to get out and push, the wagon isn't going to move.
Of course, the wagon does move, and continues to move, due to the generosity of people like Larry Wall. Larry will keep pushing the Perl wagon whether anyone else helps or not, because it's work he finds interesting. And since Larry is a flat-out admirable human being, he'll let anyone else ride in his wagon, because he's going that way anyhow.
Thing is, Larry can only push the wagon when he's not busy doing other things -- things like earning enough money to keep body and soul together. And while it may be heresy to say things like this, Larry isn't The Best Person to solve every problem in the world. There are other people who can push some parts of the Perl wagon faster than Larry can, and those people also want to keep body and soul together.
An ad-hoc community of people scratching their own personal itches can crank out a whole lot of code, but that code will be nebulous and undirected. There's no guarantee of quality or coherence, and the work is likely to stall at a point where what exists is 'good enough for now'. As much as we geeks traditionally hate managers, honesty forces us to admit that it takes more than sheer code volume to keep a project directed and coherent.
A scratch-my-own-itch, good-enough-for-now environment wastes a lot of energy because it forces people to choose between reinventing the wheel and using a 245-pound wheel composed of equal parts tread, bald spots, patches, studs, bent-over nails, and chains, with cleated bulldozer treads as an optional extra. Mediocre or just plain bad solutions achieve wide adoption because they're better than nothing, and the people who use them need something that works now. Then you end up with a de facto standard of badness that can only be blasted out with dynamite, because nobody wants to give up bug-for-bug compatability with the existing bad standard.
Sure, everyone wants to use tools that were designed thoughtfully, implemented carefully, and crash-tested thoroughly -- but that takes a lot of time and work, and a scratch-my-own-itch environment doesn't promote that kind of development. For tools like that, it really helps to get a bunch of talented people together, and give them the freedom to concentrate.
That means taking the distractions out of their way, including the requirement to keep body and soul together, and the nagging question of whether life will be worth going back to once the work has been done.
In short, you have to make people comfortable.
That sounds kind of huggy-feely, but when you get right down to it, programming is entirely a mental game. All the hard work involves thinking, and people don't think any faster or better when they're tense, worried, or under pressure.
So to reduce the whole thing to enlightened self-interest, your company wants its programmers to be productive. It wants solutions that work, it wants them as quickly as possible, and it doesn't want to get mired in a tarpit of kludged-together code that was the best anyone could be expected to do under the circumstances.
In short, your company will benefit from having its Perl coders use better tools.
And since there's no organization whose survival depends on getting better tools to market now, all you can do is contribute to an organization that wants to make a bunch of really talented people comfortable enough to develop good tools.
Additional benefits include:
- good PR
- potential tax write-offs
- credibility with internal programming staff (when was the last time you saw a company willing to do jack-shit about giving its programmers better tools?)
- better appeal to potential employees (wouldn't you send a resume to company known to do something good for its programmers?)
- It gives managers a can of whupass to open on any programmer who tries to fob off substandard code.
- It makes your company known to the top-flight developers in the field. That can be handy if your company decides it's it's willing to pay to have one of its own itches scratched.
Feel free to quote, copy, alter, fold, spindle, or mutilate this text as your need demands.