Then you have a base product you market to new customers and a developing marketplace of plugins which you can likely sell for a lot if your product is focused well enough.
Then you have a base product you market to new customers and a developing marketplace of plugins which you can likely sell for a lot if your product is focused well enough.
Before deciding to build a plugin system, you need to decide in which dimensions it will allow extensibility. The answer to that should not be 'all of them', because then you've just badly reinvented a general purpose programming language without the tooling and with more awkwardness (c.f. Spring).
Plugin systems also increase code complexity. Extensible software is usually slower and less reliable than software which doesn't, even before you actually add any extensions.
Lastly, software has to have a big enough market of developers to create and maintain the plugins. So this works well for e.g. Emacs, but for each success story they are more specialized or less popular tools with a failed plugin ecosystem.
Consider Mediawiki as a cautionary tale. It's a big, popular piece of software with a lot of extensions. Most of them are unfinished, unmaintained, untested, insecure.