由于不少用户反应目前RHEL（Red Hat Enterprise Linux）9普遍缺乏模块，红帽（Red Hat）在博客解释当前模块状态和计划，并表示RHEL 9不会包含任何默认模块流媒体，在一般情况还是使用传统RPM，以简化应用程序版本管理。
在RHEL 8中，红帽加入了一个称为应用程序流媒体的新概念，目的是要比核心系统更频繁地交付和更新用户空间组件的版本，如此红帽便能够在不影响平台和特定部署底层稳定性下，提供更大的灵活性。
针对用户反应RHEL 9缺乏模块的问题，官方解释，模块只是一种封装技术，仅为应用程序流媒体的格式之一，以应用程序流媒体供应的组件，可以打包成传统的RPM组件、模块和SCL（Software Collections）。官方会根据组件特性、支持时间和上游社群计划，选择最适合的应用程序流媒体格式，因此当模块是适合的选择，则应用程序流媒体就会使用模块，反之则选用其他格式。
用户常需要在重叠的时间区间中，支持不同的应用程序流媒体，红帽表示，传统的RPM很难满足这项需求，因为RPM总会是选择最新版本。但很多时候必需要避免这种情况，特别是不少软件本身并非向后兼容，像是发生在数据库的例行更新，就可能导致系统故障。
而在RHEL 7中，首选的格式是SCL，使用户可同时安装多个版本，但是当只需要唯一安装版本，SCL便不适合。所以当用户不需要同时安装或是执行多个版本，则模块便是理想的选择，通过将软件的主要版本构建成模块，并以组件管理工具进行控制，即便多个版本同时可用，用户也可以在维护系统更新时选择他们所需要的版本。
不过，除了根据格式特性选择之外，红帽认为RHEL应用程序流媒体格式，还有两个需要改进地方，第一是要尽早确定完整的生命周期，使用户可以将这个低端计划资讯，应用在采用计划中，另一个改进则是让用户，能够简单区分在RHEL发行版生命周期受支持的软件版本以及短期支持版本。
要能完成这两个改进方向，红帽需要在RHEL初始发布时，就确定特定版本为应用程序完整生命周期版本，而传统RPM便是更好的选择，尤其是针对第二项改进，而这也代表当用户完全依赖完整生命周期应用程序流媒体，就可以略过管理模块所需的工具和程序。
官方预计在后续的RHEL 9版本，发布支持持续时间更短的应用程序流媒体，因此当应用程序版本间存在重叠或是冲突，模块仍是最适合的应用程序机制，但RHEL 9不会有默认的模块流媒体，用户在没有指定的情况下，都会默认使用传统RPM版本。红帽期望通过这样的调整简化应用程序流媒体管理。