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.
