« Moose Type Constraints | Main | Moose is NOT a source filter »

01/13/2009

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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.

The comments to this entry are closed.