In elastic/elasticsearch#54745, Elasticsearch removed the ability to disable basic features in order to simplify the implementations of other commercial features that depend on basic features. Their primary motivation:

Many of our basic-license features are important building blocks of higher-level features. For example, Machine Learning can use Index Lifecycle Management to easily manage internal indices. However, if it's possible to disable these basic plugins, then the higher-level features need to account for the case when the basic plugins are disabled, and sometimes even re-implement what those plugins can do in the case that the lower-level plugins are disabled. Further, allowing these settings to be disabled on a per-node basis leads to the unfortunate situation of inconsistent settings on different nodes.

Kibana's plugin dependency resolution is a bit more sophisticated than Elasticsearch's in that plugins may declare optional or required dependencies to ensure that a plugin is present if it truly is a needed in implementation. This allows us to avoid the problems encountered in Elasticsearch, however there are still good reasons we may want to copy Elasticsearch's approach here:

1. Optional dependencies in Kibana may be handled incorrectly by plugins. A plugin's dependencies are typed manually by the plugin and if they do not match the optional & required deps listed in the kibana.json it's possible for a plugin to encounter an "NPE" creating a bug for users.
2. We have implicit cross-plugin dependencies today. Registries allow plugins to implicitly depend on other plugins without realizing it. While there are ongoing discussions about how to fix this, this scenario already exists today and is a bug waiting to happen.
3. Disabling some plugins may result in a useless or even broken Kibana. In practice, there are a number of plugins that Kibana cannot do much without (eg. data plugin). There are also plugins that Core implicitly depends on (eg. home plugin) that would break if some functionality if disabled.
4. Two overlapping mechanisms for disabling functionality: feature controls & config. Since the advent of feature controls (which is available in the free Basic tier), Kibana admins now have two methods for disabling functionality. This can lead to confusion for users and support.
5. Consistency with Elasticsearch. There are multiple ongoing efforts trying to make configuration across the Stack consistent. Not allowing features to be disabled in Elasticsearch but allowing it in Kibana is a confusing experience.

I would like to open the discussion for removing the ability for users to disable plugins in production, but retaining this feature in development mode.

Reasons to keep this feature in development:

1. It enforces best practices while reducing risk to users. We should and will continue to ensure that implicit dependencies between plugins do not exist, but allows us to reduce the risk that an implicit dependency breaks a user's deployment.
2. Allows us to support "focus mode" to improve the developer XP. We can greatly improve the performance of Kibana in development by allowing a developer to specify the part of the application they need to work on and only starting those components. This is only possible if we have strict enforce dependencies between plugins.
3. Gives us flexibility in the future. If Kibana ever were to release different "flavors" that are focused on specific use-cases (eg. Observability, Enterprise Search, etc.), having this feature in our back pocket will make this much simpler.

Similar to elastic/elasticsearch#54745, we may want to consider the security plugin separately since it does have different implications when it is disabled. @elastic/kibana-security may have more thoughts on that as well.

Open questions:

• Are there legitimate use cases for disabling particular plugins in Kibana?
• Would this create future problems by making implicit dependencies harder to catch? (an aside: would the new build system on Bazel fix this?)

cc @elastic/kibana-platform @elastic/kibana-app-arch @elastic/kibana-operations