Problems &solutions

While plugins can make sense in some contexts, the situation is out of control with the

There are numerous plugins which have more to do with lack of collaboration and business models than about collaborating to make awesome solutions.

There was a time when search engines would heavily promote how many pages they indexed (with the idea that more was better). And then Google came along with a better focus on relevance and the rest is history. It's not how many pages of results that counts, but finding relevant results.

Why are there 20 similar plugins to do the same thing? Really, what's the point?

End users: Don't you prefer to work with the official and solid option?
Developers: Don't you prefer that your code becomes part of the official code base?

Problems with plugins	Tiki benefits
Security vulnerabilities: Most vulnerabilities are via plugins Because they are not maintained and because main project leaders can't possibly take responsibility for vulnerabilities in thousands of plugins. Each file is a potential security vulnerability. Drupal, WordPress and Joomla! have more plugins than Tiki has files. A typical plugin can be composed of dozens or even hundreds of files. And thus, the more files there are, the greater the vulnerability to attack.	In Tiki, all features are built-in (so all those files could be attack vectors). However, if a feature is de-activated, malicious code can't run, and thus you can only be vulnerable via files used for features that are activated (just as plugins can only be attack vectors if they are installed). Because of the code integration, there are way fewer security issues to manage. And all the community can be affected so project leaders review all new code.
Poor performance Plugins may not take advantage of core tools to improve performance	Since everything is built-in, all performance features work with all features.
Abandoned plugins The reason most plugins are abandoned is because they were never needed in the first place!	If a feature is unmaintained, it is tagged as such. If it is no longer useful (for example, because of the evolution of technology), it is removed after a Long Term Support (LTS) version so end users know what to expect.
Paradox of choice (Which of five plugins should I use?) Because there are many choices, you need to pick carefully, and spend a lot of time analyzing and comparing features set vs stability vs odds that the plugin will be around in five years	Activate and use. If you fix something, you can upstream the fix and it will become part of the official version of Tiki.
Each instance has a diverging code base Because each of your projects will have different needs, you have a different permutation of plugins. If you manage a large number of sites and you are not careful, you will end up with a different code base for each site, leading to more difficult maintenance.	The Tiki code base is always the same. Only the site configuration and preferences change. Site maintenance is much easier as all your projects have an identical code base.
Upgrades are more work You need to upgrade the core, and then each plugin. In some CMSs, you can't skip versions. This is very labor intensive.	One upgrade. If you use a one-click installer, all is done in one operation. You can upgrade from any version to any subsequent version (all migration scripts are part of all versions) Techies: Minor upgrades are done with this simple command: php doc/devtools/svnup.php
Lack of collaboration (Fragmentation of effort) Human nature and business models There can be a hotshot developer who does things his/her way but doesn't want to work with others or take into account the larger needs. Access to the source code (and collaboration) can be harder. The plugin leader may not be very collaborative because the contribution of the FLOSSFree / Libre / Open Source version could be cannibalizing sales of his/her premium version. It's harder to read code than to write it. Developers too often prefer to write their own code rather than invest the time to compare, test and understand various existing plugins (to then improve code started by someone else, and who may in the end refuse their patch).	Easy, there is just one thing to learn. All community members converge their efforts on a common solution, the wiki way! In Tiki, everyone collaborates on a common code base.
Incomplete feature set A hotshot developer thought all the existing plugins sucked so (s)he built something really awesome but then got bored and moved on to something else. Freemium business model (basic plugin is FLOSSFree / Libre / Open Source but the developer actually wants you to buy the paid version with nicer features)	In Tiki, everyone collaborates on a common code base.
Support challenges and service providers' familiarity with your set of plugins What service provider can realistically offer cost-efficient support for thousands of plugins? Where can you get support when your issue is an interaction between two plugins? Each service provider will have their preferred set of plugins, so if you have 10 similar projects with 10 different service providers, you will end up with 10 different solutions.	If you have 10 Tiki projects with 10 different service providers, you may have some slight differences in how things are configured but all projects will have the same code base, and so it's easier to take charge of an existing project.
Your service provider can't commit to a long-term support plan with predictable pricing Your service provider can't predict if the particular set of plugins will still be around in a few years.	In Tiki, since there is no duplication, the worse that can happen is that a particular feature doesn't evolve much. Thus, Tiki service providers can offer support plans for five years or more.
Unresponsive plugin maintainer Maybe the person moved on, maybe the business model didn't work out, maybe the maintainer gave up because another plugin became more popular... so many different reasons, and often, we'll never have a real answer.	To be fair, in Tiki, not all features are actively developed. And bug reports can go unanswered. However, everyone in the community has full access to all the source code, and the feature can evolve. You can have commit access to fix an issue or you can hire a Tiki contributor to fix it for you.
Hard to audit for file changes When you take over a site by someone else, it's a good idea to check if any files were modified compared to the official version. Also, when doing a security audit, modified files are a symptom of a hacked site.	In Tiki, it's easy to see how much code has diverged, using the built-in tiki-admin_security.php?check_files or svn diff.
Lack of innovation and adoption of new technologies / need to maintain backwards compatibility Of course this is due to the need to support old plugins. But it's also because technology evolves and things we used to do in PHP can later be done in JavaScript or even CSS. And Java applets are replaced by JavaScript code.	The Tiki community can quickly take advantage of new versions of PHP and browser technology, because site admins stuck on old versions of PHP can stay with Long Term Support (LTS) versions for up to five years. In the meantime, the regular releases take advantage of innovations. And since all developers have commit access for the whole code base, it's easy to go through all the code and update the parts that need it for support on the most recent versions of PHP. Another example: Tiki converted the whole code base to Bootstrap, which would be an unthinkable task when there are thousands of plugins.
Problems with lifecycle Drupal: slow core cycle WordPress: No Long Term Support (LTS) version	In Tiki, you have the choice of frequent releases to get the new features or to stay in Long Term Support to minimize updates, while still getting bug and security fixes
Complexity and Technical debt Trying to support all the various permutations of all various plugins causes the code base to be more complex. Plugins must handle versioning. Some plugins are in full development and adding new functionality, while others are very stable. This asymmetric situation makes things tricky. This presentation illustrates the code complexity of Drupal vs Xoops vs Tiki	In Tiki, development happens in the most recent versions, while old versions are in bug fix only mode, or security-fix only mode.
Theme management is harder The nice theme you got will work with the core software but can't possibly be designed for all the plugins.	A unified code base makes things more harmonized. And as of Tiki 13, everything is moving to the Bootstrap CSS Framework.
Terminology and translations coherence The sheer number of plugins makes it very difficult to converge on a terminology. Thus, various plugins will use different synonyms, and the end user won't have a consistent interface. The same thing is true for translations.	In a centralized code base, community members can discuss and agree on a terminology, and then correct all instances in one operation.
Bad architecture As they innovate to address a use case, plugins end up doing things that really should be a system-wide functionality. Plugins end up doing too much because they can't count on features being there in the core, or to avoid adding another plugin as dependency. Eventually, the core may end up doing that but in a different way, so the plugin may need a lot of work to adapt. Or it may just never be ported to the new version. And you are stuck. To illustrate, here is a related situation: In WordPress, themes are PHP files, which add power and are necessary to add functionality because the theme can't expect that a given feature is in the current WordPress install. Thus, in these cases, when the theme changes, some functionality is lost.	In Tiki, developers add / refactor / move the code to the most logical place, and they know that, within a reasonable amount of time, it will be in a stable released version. And when you change a theme in Tiki, you don't lose any functionality, as the theme is for visual customization only.
Effective development because of huge size of communities, but major inefficiency in the development model Joomla!, WordPress and Drupal have huge communities, and hundreds of millions of dollars in VC funding behind various companies in the ecosystems. Drupal, WordPress and Joomla! have more plugins than Tiki has files (!). A typical plugin can contain dozens or even hundreds of files. And thus, there is at least an order of magnitude more code and complexity to maintain.	Tiki covers the vast majority of features that these 3 systems offer via the thousands of plugins. So just about any project you could do with Joomla!, WordPress or Drupal, you could also do it with Tiki, with way fewer files, and much less complexity.
Hosting platforms with limited features The big hosting platforms know how perilous it is to try to support all the plugins. Thus, they don't let you choose freely, and you are limited to their approved recipe. So if you want to change platforms, you are not certain to get access to the same features	With Tiki, all the features being built in is one of many benefits for a hosting company

To avoid the plugin problems of Drupal, Joomla! and WordPress, take a look at Tiki, the Free / Libre / Open Source Web Application with the most built-in features

Objections

If it's so bad, why is it the dominant model?

The thought model of a traditional operating system and apps
- A web app is different
  - Database storage and not file storage
  - We expect more interoperability from features in our web app, than between various desktop apps
  - In desktop apps, most of the functionality is via options.
Business models
Human nature

But users want plugins

No, users want functionality and if they get them via built-in options, they are happy.

Why don't these plugin apps move to a more integrated model?

It's happening in browsers:

Changing the model to exclude some plugins will make some people unhappy. It could cause political complications in the communities.

When are plugins OK?

When no data saved/stored and thus no risk of lock-in of data (ex: browser plugins typically don't store data)
When it doesn't make upgrades difficult
When it's something no other part of the application is depending on
When it's something which is rarely used
When it's about connecting to another app (or service)
When it's code from an external library
When there is very little change from one version to the next
When it's simple
When it's at the periphery of the app / code
When there is no duplication / overlap
When there are no other dependencies (if several things depend on something, it should not be a plugin)