This is a question some folks have asked me, and I feel compelled to explain why I added a plugin system to Nitrogen 2.2.0. Ultimately, yes, most of what the plugin system does can be done with some shell scripts and rebar pre- or post-hooks. And, honestly, this is sort of how the plugin system works.
But, while what Nitrogen is doing with plugins isn't exactly earthshatteringly complex, the plugin system serves three core purposes: Simplification, Standardization, and Environmentalism.
It simplifies the inclusion of custom elements without having to screw around with manually referencing .hrl files and manually copying dependent static resources. Adding a Nitrogen plugin to your app is generally as simple as adding it as a rebar dependency, and letting the Makefile bring in the .hrl and copy any static resoures.
For example, in my own projects, for the longest time, I've been copying some of the same elements from one project to another, knowing that some of them wouldn't make sense to include into mainline Nitrogen (some because they aren't general purpose enough, and others because they are still very beta). With those elements, the overhead of updating the .hrl files in scattered projects, copying static resources, and of course copying the .erl files proved to be enough of a pain to need to make the process more streamlined. As a result, I've already open-sourced some of those elements and have several more I'm working on.
Plugins standardize the expected format of custom Nitrogen elements so that users using a plugin won't have to guess as to how to include those elements and resources into their projects. Plugins follow a defined standard, and are therefore fully "plug-and-play."
Further, users who might be using an "atypical" Nitrogen configuration (say using Nitrogen embedded into another application), the Plugin system can be configured to ensure that your plugin resources go into the right place.
Since Erlang has a single global namespace, with the use of plugins, we're not polluting the global namespace with a bunch of rarely-used elements in mainline nitrogen_core. While some plugins might be worth eventually absorbing into mainline nitrogen_core, the plugin system will ultimately allow users to create their own elements and include them in a simple manner without having to fork nitrogen_core to make their changes - which is rather prohibitive: no one wants to maintain a fork just to have a few small changes. At the same time, this allows other users to easily use their elements, to effectively hone and improve the elements on an individual basis. This, to me, seems like an easier to deal with process.
By comparison, the nitrogen-elements repository (a loose collection of mostly unrelated Nitrogen elements), which has a bit of an irregular history: Unmaintained for years, then having it heroically picked up and impressively updated by Roman Shestakov, but now having not seen any activity in it for half a year, except for another fork. The problem here is that all these elements are tied together in a single repository, and once again forks are beginning to abound without being merged into mainline.
Having a single repository for one or a few related elements is, to me, a vastly superior approach to this. It remains distributed by nature, but we don't end up with a pile of forks each running a slightly different version of the same elements.
As a result, the "fork pollution" is kept to a minimum, and it's clear which versions of which elements are the "best" versions. While at the same time, we're keeping the global namespace unpolluted. It's a two-pronged approach to fighting pollution in a Nitrogen and Erlang system.
So here is where I say: GO MAKE SOME NITROGEN PLUGINS!
If you have some elements you use in various projects, creating a plugin is trivial, and simply add your plugin to the Github Wiki Page for Plugins.