I've been reading The Hacker Ethic by Pekka Himanen lately. It's an excellent treatise on what makes hackers tick, but it's also been provoking some thoughts besides beer and polygons in my poor tormented little head.

Himanen, ESR, and probably most everyone else these days broadly categorizes development strategies into Cathedral and Bazaar. According to Himanen (broadly), the Cathedral is characterized like so:

• Controlled by one person, or a small group
• Significant advance planning
• Closed development, users only see "finished" work

and the Bazaar:

• Everyone involved contributes ideas and viewpoints
• People try different approaches on the fly, staying with the one that works the best
• Code is released early and often

This dichotomy (like most of 'em) strikes me as too simplistic. There is at the least a third category midway between the two (and at most, and most likely to my mind, a continuum passing through both points), and this middle ground, I think, is where most Perl modules end up. (See, this post is on topic after all!) I don't have a snappy name or clever metaphor for this bit, so I'll settle for describing it:

• One person or a small group writes the code, with the community providing feedback and occasional patches
• The project is planned out in advance, but is responsive to (frequent) user feedback
• Code is frequently released (on CPAN) for feedback

I think that Perl is very well suited to this style of development. It's easy to write featureful, powerful code in Perl, which means that one or two people can fairly easily grasp a significant project. Perl also has a large, dedicated, and vocal user base, which means that hackers can (and will) get plenty of feedback from users and observers. Also, Perl lends itself to small and medium-sized projects, which (I think) are where this style shines.

For the record, I haven't finished reading The Hacker Ethic, nor have I read CatB particularly carefully.

--
:wq