The purpose of this survey was to get feedback on Modularity. The survey was published on public Fedora devel and an internal Red Hat mailing lists in April 3, 2020, and also shared on Fedora’s devel-announce and epel-devel mailing lists. We received 193 responses in 3 weeks. Read more below or download the PDF of the results.

Survey setup

The survey consisted of four sections:

• Information about the respondent (optional)
• Modularity & the respondent
• Problems with Modularity that the respondent  may have experienced
• Glossary review – what does the respondent think the terms mean

The survey followed privacy / GDPR rules:

• The raw data including any personal information provided, were shared only with Red Hat’s Modularity team (approximately 10 people) to evaluate the survey
• The raw data are not to be provided to anyone else at Red Hat or any 3rd parties
• Only aggregated (anonymous) results of the survey are published

Structure of respondents

21.9% respondents shared their email address from redhat.com domain, 22.9% from other domains and 55.2% were anonymous.

Contribution to projects

Roles of respondents

33.5% of respondents answered that their primary role is developer, 32.5% packager, 11.5% system administrator and 7.9% power user (can use shell, has some admin skills). The remaining part was fragmented in other various roles. Because the survey was published on devel and rhel-devel mailing lists, the developers are mostly system components developers. Many of developers/packagers cover a packager/developer role as the secondary one. It means that the survey did not cover developers of end user applications.

Satisfaction of respondents with Modularity

12.4% of respondents answered “I like it”, 38.9% “Neutral” and 48.7% “I dislike it”.

15.1% of respondents confirmed that Modularity solves problems for them, 70.3% answered negatively and 14.6% “I do not know”.

Highlighted benefits in the survey:

• Parallel availability (7 respondents)
• Life cycle (4 respondents)

Conclusions and plans

We were very pleased with the large quantity of participants who took the time to complete this survey. This excellent feedback is helping us to focus on multiple problems and solutions to help improve the Modularity experience for both end users and developers. Below is a summary of problems interpreted from the survey results and plans to resolve them. 

The description of Modularity and the terms used causes confusion to many users and negatively impacts the user experience.  

Plan: Fix Modularity documentation, improve clarity by creating a glossary. We are going to use the survey feedback as an input.

Problems with system upgrade

Plan: System upgrade improvement is scheduled in Fedora 33 [Module Obsoletes and EOL].

Problems finding modular or non-modular RPMs hidden by an active module Stream

Solution: The problem is fixed in Fedora 32 already by the patch.

Problems with modular RPMs overriding non-modular RPMs

It works per design. Any change proposals should be discussed first.

Problems with querying modular RPMs (most likely repoquery)

Plan: Lower priority, stretch goal in Fedora 34.

Problems with building, managing and distributing modules

There are currently missing end-user tools that can manage modules. New tools need to be developed to cover:

• build modules locally
• manage (edit, create) modulemd data locally
• download individual modules from remote repositories
• manage custom repositories with cherry-picked modules

Problems with switching module Streams

Plan: The problem is considered to be fixed in Fedora 33 or 34.

Problems with source control management (most likely dist-git)

Plan: Branching policy needs to be reviewed.

Reporting issues

General issues can be filed in the General Modularity issue tracker. You can see more details on how to report bugs and issues, in the Modularity documentation.