There has been some discussion recently on whether the “free” in Free Software is “free like a puppy“, or “free like a flower”. These posts, the comments on them, and the wider discussion in which they participate (on the death of NDoc), examine both why people use free software, and why people release free software.

This ties in neatly with a conversation I was having recently with Karen about her CPAN tutorial at the upcoming YAPC::Europe conference.

Karen was hoping to avoid discussing the question of “Why would I release my code to CPAN?”, and instead focus on the “how”, once someone had already made that decision. I encouraged her to add something about the flipside: “Why might I not want to release it?”

There has been surprisingly little written about uploading code to CPAN in general, so it’s not surprising that there has been even less written about not doing so. CPAN itself is largely silent about the philosophical issues, so I had a look at Sam Tregar’s “Writing Perl Modules for CPAN” book.

Right at the start of Chapter 1 Sam considers the “Why contribute” question. He states: “CPAN is more than just a repository—it’s a community.” One of the primary reasons why you might upload your code to CPAN is therefore because “you’ll come into contact with other highly talented Perl programmers.” And “just as contributing to CPAN enhances a programmer’s resumé”, a company can likewise “improve its hiring ability” by supporting CPAN, as well as “establishing a standard around [their] practices”. There’s also a nod towards idealists contributing as “a good way to save the world”, but this isn’t really explained.

There are some interesting assumptions lurking throughout the book. The first is the notion, seemingly taken as axiomatic, that by contributing to CPAN you’re choosing to become part of a community. There also seems to be the assumption that what you’re uploading is a “project” that you are planning to continue to develop, with implications about your code being good enough to release, along with comments about “competitors who might be close to a release themselves”, and that your job is to “create the next CPAN hit”, and to do this you’ll need to “keep your user community engaged”.

Lurking under all this seems to be the idea that you want your software to be widely used and popular. For authors who actually have this goal, Sam offers lots of good advice, but the book completely ignores the entire class of authors who actually aren’t seeking that. Unfortunately, many of the citizens of the Perl Community share this same blind-spot, and have a tendency to place a series of obligations upon all CPAN authors.

For those authors who see releasing their code to CPAN as part of their journey towards Perl mastery, there is much to be learned from paying careful attention to the wide range of ancillary websites and mailing lists where releases are commented upon, annotated, tested on various platforms, checked against a 19 point “kwalitee” list, and bug reports are filed etc.

For the growing numbers of authors for whom their CPAN releases are their business, not just in the “making their CV look good” way, but because they offer consulting services based around them (or are hoping to), then it becomes even more essential that the feedback from these sites is monitored and responded to quickly.

But for authors who do not share these goals, many of the benefits disappear, leaving what seems to be little more than a growing number of expectations and obligations.

One of the benefits of Free Software is in not having to start from scratch. If you need to write some code, and you can find something close to what you need, with a suitable license, you can take that and adapt it. (If you’re lucky enough to find something that does exactly what you need, then that’s more useful, but you’re actually no better off than if you found suitable free but non-Free Software, unless you want to distribute it). Unfortunately, the Perl Community doesn’t appear to place much value on this freedom. I suspect that at least some of this stems from the difficulties of running modified versions of Perl modules when there is no core way to specify that you want to use an exact version of a module (there are several workarounds available, but they don’t seem to be widely used). So when a CPAN author either rejects or ignores a patch people get more upset than might be expected when Freedom 1 is in place. If a CPAN module doesn’t install or doesn’t compile, most people seem to just write it off and go in search of something better, and never discover that it might actually be perfect for their needs if they just spent 10 minutes fixing a couple of simple problems.

To give a concrete example: back in 2001 I wanted to analyse my telephone bill. BT helpfully provided all the data in CSV format, but rather than just manipulate it in Excel, I decided to do it with Perl. I then released to CPAN the module I wrote, in the hope that if someone else ever wanted to work programmatically with their phone bill, this might help them. It wasn’t a project I was planning to continue to develop, and I certainly wasn’t wanting to build a community of users—I was just offering my work as a gift to anyone else who wanted to save a little time later.

At some stage in the following couple of years, BT changed the format of their CSV file to add some new fields. I didn’t notice, as I was no longer even using the module myself. There was however at least one other user, who noticed that the code was now broken. I wasn’t that interested in fixing the code, or even applying patches to it, not least because I wasn’t using it. As the user in question was Simon Cozens, however, and I trusted him to not do anything horrendous [insert your own joke here], I gave him “co-maintainer” status and let him fix the module and upload a new version of it himself. I suspect he’s no longer using the module himself (or certainly won’t be shortly when he moves to Japan), so if BT change their format again, the module will break again, and again I almost certainly won’t notice. And if someone reports this as a bug, I almost certainly won’t fix it. And if they’re not someone I know well enough to slap with a wet kipper if they mess things up, I probably won’t make them a co-maintainer either. And although I could probably come up with a better design so that when BT change their CSV format the module doesn’t break, I’m not really that interested in doing that either.

To many in the Perl Community these statements are pure heresy. Not only do they show that I’m too selfish, and not a good member of the community, but they spoil the type of advocacy that tells businesses how Perl is great because with CPAN you get all this wonderful code that Just Works everywhere and is well maintained by friendly, receptive, responsive authors who’ll do whatever you need without having to pay them. In other words, the “Free as in beer” approach.

Maybe CPAN would be superficially better with higher quality thresholds, and if authors were explicitly committing themselves to a life of maintenance and servitude (or at least until they could find some other sucker to take over). And maybe authors who aren’t prepared to live up to the expectations of the community should just keep the code to themselves, or just publish it on their blog, or distribute it in some other manner than helps keep CPAN pure. But I personally think CPAN is great because of all the “crap”, not despite it.

Authors who upload to CPAN are offering you a gift. You certainly don’t have to accept it, but you equally don’t have to criticise it or attack the author for not meeting your expectations of what the perfect gift should be.