The Perlegorical Imperative and the Will to Contribute

Caleb Cushing has suggested multiple times that developers of free software should consider support an obligation and make support a priority.

I can agree with that as a categorical imperative, but I can't agree that releasing free software induces a requirement to do so. For example, any distribution you upload to the CPAN should contain a comprehensive test suite which suffers no false negatives and offers no false positives. Yet not all CPAN distributions do so. CPAN itself requires no test suite, and plenty of useful CPAN distributions lack comprehensive test suites, and few CPAN distributions have neve suffered from false negatives.

Certainly the utility of CPAN would increase if our test suites trended toward perfection, but requiring perfection would likely suppress the utility of the CPAN in the long term.

Ever since I gave up the dull periods between crises of system administration for what has become my career (and a mortgage and family obligations and hobbies which do not require me to sit in front of my computer all night long), I have had to prioritize how I spend my time. Sometimes I add new features. Sometimes I apply patches. Sometimes I revise documentation.

Yet the fact that I wrote a long-dead templating system in 1998 or my own test framework in 2000 or even Test::Builder in 2002 in no way obligates me to neglect mowing my lawn in favor of adding a feature anyone requests in 2010.

You can tell. Read the disclaimer of warranty in the license. I hope my code is useful for you, and I intend it to be useful, but I can neither promise its utility nor its suitability for your purposes.

In return for the risk you take on using software written and maintained by someone as capricious and unpredictable in schedule and interest as myself, you get its complete source code, you get (in many cases) read access to the repository where I develop the work, access to the bug tracker and mailing list and forums where I discuss the work, and you get the right to fork and maintain it yourself.

In my mind, that's a fantastic trade to make. The Perl community has survived deaths, job losses, family crises, births, flamewars, resignations, forks, other languages, trolls, test failures, catastrophic installation failures, and even ExtUtils::MakeMaker.

Community-driven software means we don't have to suffer the whims of profitability or market changes or personnel changes or trade secrets or market segmentation or duplication or competition. It means that we, collectively, have the power to make our lives easier with software. Sometimes that means changing how we develop software. Sometimes that means changing how we support software. In this case, I believe in means changing our will: no longer should we act as if software is a resource produced by someone else and we are mere consumers. We should act as if we are equals in producing software—because we are.