I wish people in the Rails (and Django) community would release modules instead of blog posts. A plugin is easy to maintain. Code that you cut-n-paste from teh intartubes is a nightmare to maintain. If you want to write literate code and make it a blog post, that's fine, but please make the actual meat available in a machine readable form (so the computer can manage updates, instead of you googling for a fix).
Also, they need some sort of solution to the monkey patching problem. Perhaps emacs-style hooks.
It's hard to call something an "enterprise solution" when it's a bunch of code cut-n-paste from blogs, mixed in with possibly-conflicting modifications to the core.
I think the issue is more with the consumers than the producers.
Instead of using the code you find on the blogs as copy and paste modules to add functionality to your software use it as an example of how to use a certain technique then implement that technique in your software.
Lego applications rarely end up being what the consumer actually wants despite having all the required functionality because general solutions are hard to map to specific requirements.
I'll second that. Further, just because a package is available as a plugin, that does not mean it is suitable and is of sufficient quality for a production application.
But at least there's some central place to submit a patch to. If you improve the module, then everyone can easily benefit simply by upgrading the module.
Part of the cause, I suspect, is that the Rails Trac (http://dev.rubyonrails.org/) has a rather strict policy. Unlike, say, Firefox's or GNOME's Bugzilla, where a feature request with a halfhearted patch can stay open for years, the Rails folks will immediately close ("WONTFIX") any feature request that doesn't also contain a working patch, documentation updates, and unit tests.
The upshot of this is that I've contributed many patches to GNOME, but none to Rails. If I come up with something useful, I'll blog about it so others can see, and then let it go. The entry barrier to get it in Rails is just too high.
I suppose I could make it a plugin, but a lot of these things seem like they should really be in Rails itself, so trying to factor them out to be a usable plugin is just a different kind of pain.
Why do features need to be in the core? Why can't you just make a gem or something available?
For Catalyst, we have the same policy. Send us some random patch with no tests or docs and there's no way it will ever see core. However, we are very successful at getting people to resubmit with docs and tests. But usually, the patch to core doesn't need to be a patch to core, it can be Some Other Module.
If you don't care enough to write tests or clean up your code, why would anyone else? If you just want to throw out a proof of concept, a blog or paste site is really the best place for it.
Let me play devil's advocate:
I wish people would turn these blog posts into modules if they also find them useful.
It doesn't seem fair that the person who took the time to a) explore this problem, b) create a solution, c) describe their solution (with code) should also have to d) create a plugin/gem.
Conceivably, the time they saved you could be devoted to creating the plugin and adding some polish.
You should really check out the Catalyst framework for Perl if you want a system that allows you to create plugins that augment and add functionality in a modular and maintainable way.
You do realize that you just linked to a module I maintain, right :)
FWIW, Catalyst plugins have a lot of problems, but they have also proven useful to people trying to extend the framework. 99% of the time, people can get a maintainable chunk of code into their application without having to monkey patch or change the core. That is a Good Thing, but we can do better :)
Catalyst 5.8 will use Moose roles for plugins, so the safety problems of mixins should go away. The next problem to solve is how to reuse cross-sections of applications (models, views, controllers, templates, etc.) in a clean manner. I'm experimenting with Bread::Board (IoC) in a new framework called Kiiteh. If Kiiteh pans out, it will be Catalyst 5.9.
I had a good chuckle posting that. I've been a Catalyst user/fan for around 2 years now and appreciate your work on it. I saw that your slides on KitiWiki used Moose. Exciting that Catalyst will be using it itself. Now I have a fun excuse to play with Moose for real. Bread::Board looks interesting as well, I hadn't seen it at all.
I dont know about rails, but for django it is not possible to standardise modules/plugins etc until 1.0 comes out and the 'best practises' are defined. This is a design decision as until 1.0 comes out there will be backward incompatible changes. So there is not alternative to 'monkey-patching'
Also, they need some sort of solution to the monkey patching problem. Perhaps emacs-style hooks.
It's hard to call something an "enterprise solution" when it's a bunch of code cut-n-paste from blogs, mixed in with possibly-conflicting modifications to the core.