Perl Templating Ecosystems

The old saying goes every Perl programmer designs at least one templating language.  The present author is no exception, having authored a system roughly based on some bits of XSLT I liked.  Eventually you find your way toward one of the more popular existing system, such as Mason (more than just templating, I know), HTML::Template or Template::Toolkit.

After what seemed like years of stagnation, it appears once again that people are growing tired with the available options.  Most of the big three have received what seems to be only minor updates in the 21st century.  On the one hand you could say this means they are complete.  My gut feeling here is that they are not growing due to people not really being able to meaningfully contribute to the projects.  Either the principal author has not gone to pains to encourage this (by prolonged absences or general approachability) or the underlying source code is too idiosyncratic for people to be able to figure out how to join in.

I've noticed this problem in other, core Perl modules. How many very important projects have just one author?  Part of this is due to the highly individualistic and 'do it yourself' attitude of the Perl community.  Are there other reasons?  I'd like to hear your thoughts, particularly if you are someone that maintains a Templating systems on CPAN or someone that contributes or tried to contribute to one. 

Comments

[liberal provocateur]

Actually, in core modules it's the opposite problem, once a module has become core the author has much less flexibility and consistency is more valued.The same thing applies to any package that has a singnificant and mature userbase - if a library is primarily used in new development then radical change is less of an issue - if a library is depended on my a gazillion production sites who are only interested in bugfixes and stability then any significant change is a very big issue.I think that usually it means that a project is not so much complete but has mined a API lode and has diminishing returns on any change made.Maybe I'm biased because I have several projects that I'm sole author of, but they're in version control and I actually respond to requests and suggestions - take a look at the CREDITS and changelog of Autodia to see how much difference users can make on a very occasionally updated project.

[John Napiorkowski]

For me, that's a good reason why Perl core should be nearly empty, since core stuff ends up have to maintain bug to bug compatibility.I guess you also have the size of you problem domain at work. For example, if your module is about implementing a spec, like a DOM parser, then your work is basically done when the spec is done.It's not always bad to have single author projects and certain task play better to one cook then to many. I'm just wondering if some of these important projects are not being held to one author because that's the natural and easiest solution, but that they are being artificially held back by something fundamental in the community or *gasp* the language itself.

[liberal provocateur]

Nothing in the language prevents multiple developers as far as I can tell, in fact stuff like POD and the culture of testing and koala tea postively encourages it.I thinks it's more to do with Perl being a mature language and many of the critical and core modules have met most or all of their initial goals, and the technical or social benefits of large changes don't pay off - it's much easier to just report bugs or send patches to a single developer, and when you have a fairly stable project with small churn, more than one developer doesn't really help much.Like I said, look at Autodia, it's not a critical project but it is mature (7 years old), and widely used and distributed, I have a steady trickle of patches and suggestions but very few or no radical suggestions, and most radical changes would be better suited to a new or forked project.In fact that happened in a pretty healthy (technically, but unfortunately not socially, due to clumsy geek bull-in-a-china-shop interpretation of meritocracy in a couple of people) way with the DBIx::Class project forming because C::DBI was mature and widely used and no longer really appropriate for radical changes.