Nearly all the large successful free software (and many non-free) projects makes extensive use of plug-in architectures. From EMACS to Firefox (XPCOM and others), WordPress, Apache, Linux, Perl (CPAN), PHP (PECL).

From this we conclude that they are an important and useful model for software development.

As a security person, and previously as a system admin, nearly all my pain comes from bad modules, modules which don’t work because they are too old, modules that don’t work because they are for newer versions only, and keeping modules up to date. Modules or Applications that embed third party dependencies, but don’t maintain them (some even go so far as to bundle specially maintained versions of ancient Java runtime environments from Oracle).

The number one issue for me is modules that don’t use the OS update mechanism (think Perl modules & WordPress Plug-ins).

Thus in many cases you probably should use modules in your software project, you probably also want consider bundling some or all the modules the user is likely to commonly want as standard (so the OS vendors bundle them too), you probably then need a mechanism to disable the ones it turns out they don’t need (think a2dismod). You then also need to think carefully how you will deliver (securely), and update (timely), modules than don’t qualify for inclusion for everyone, or which arrive after release. How developers will test modules to establish which versions they will work with (rather than the inevitable “what I’m running and newer (till you find it breaks)” approach).

Then make sure you document all the relevant APIs clearly, and maintain this documentation (with examples).

If it sounds like a lot of work, it is, but if you don’t do it, you are pushing some or all this work off onto your users, who will (collectively) repeat it for each installed instance, for each module (or release of each module), and if they don’t your software will get a bad reputation for security, reliability or maintainability.

Indeed I think this is one of the things that held back Perl adoption, is non-Perl experts typically have no idea how to deliver a Perl application and all the required (Perl) dependencies on their platform of choice except by using CPAN (and you really don’t want to be there due to dependency hell), or if the linux distro vendor happens to package the software and all the dependencies (Probably only Debian even bothers to try for more than a handful of Perl applications). It is  easy to do this, but you need to know a fair bit about Perl before you discover the methods that make it so. Most deliver with Perl modules they needs bundled, which is the only way with Perl apps not packaged with the OS, if you go this way remember to release new versions every time a dependency has a security update.

Thus I think the answer is to use a plug-in architecture for writing the software, for all the benefits it brings, but mostly hide this from the end-user as much as possible. This is typically how Apache is delivered, and causes very little pain for system admins relative to its utility, and the high risk environment (due to nearly everything being exposed to untrusted data from the Internet).

If you can make it easy to distribute plug-ins as packages, for the various OS vendors to distribute, you’ll save yourself a lot of grief, win friends and maybe even influence people.