Hello Fedora Community!
I would like to start a dedicated thread to focus on the “why” and use case contexts to help clarify past and future decision making related to Application Streams and Modularity. As I follow some of the Fedora mailing list threads and Pagure issues, I have noticed a recent trend of requests to understand better “why” certain decisions were made, including use cases, user stories, or other constraints. I would like to ask that we keep this thread focused on better understanding end user needs and problems rather than delving into various reasons for not liking particular decisions or implementation details. Warning - there is a lot of reading required for participation ;)
For those of you who are not familiar with me, I am a long time Fedora user having started with Red Hat Linux 7 on DEC Alpha workstation in 2000 and am now on the Product Management team for RHEL. I joined the team near the end of 2016 when modularity was already started but still being defined. You can find me on IRC (tmoney) in a handful of Fedora channels.
First, I would like to challenge all of you with some background reading to better understand some user personas. I learned that Fedora had completed some research starting in 2013 that is still relevant and is very similar to research that we did for Red Hat Enterprise Linux, though there are many differences as well. You can read some of the user personas and use cases in the Product Requirements Documents for Fedora Server [1] and Workstation [2] circa 2013-2015. Additionally, some of the background context was explained in Fedora Classroom Session: Fedora Modularity 101 [3] which is also a great read before you continue here.
Lastly before we dive in, I want to highlight a theme we’ll be revisiting: Users. There are many. They are diverse. They have different and sometimes conflicting needs. They are awesome. Red Hat wants more of them. From what I have observed in communications from Fedora’s Council and Project Leader, Fedora wants more of them too. Again, Users are awesome. They are the reason we are doing this. How can we empower them to benefit from Fedora and be an answer to their problems and goals? Without them, what are we doing all of this for?
Okay, let’s dive in. Everything below is paraphrased from many documents and discussions over the past few years. Hopefully I did not miss anything. From the personas above, as well as what we have learned from other research activities and countless conversations with end users, we have a number of takeaways:
Fedora has a diverse spectrum of end users to satisfy.
Fedora has multiple personas of Developers: Two in particular being Fedora distribution developers/maintainers and non-distro developers who use the tools, languages, and applications to solve other goals. I emphasize this because these developer personas often have conflicting but equally valid needs.
The “Too Fast / Too Slow” problem and demand for access to select content provided with different life cycles.
Third party repositories, as great as they may be, sometimes introduce incompatibilities as they are not inherently built and tested as a part of the distribution. This applies to Copr as well. Some Users worry that using content not curated and tested as part of this distribution will cause them future headaches. Other users embrace this and want to play with the latest versions with less concern of breakage.
Drastic, incompatible changes can be extremely disruptive to many users.
RHEL adds to this a few nuances based on user feedback:
Users mostly care about their business needs, usually in the form of their important workload application or managing their environment. In the end, most don’t care about the novel technology solutions. What they care about is: “Does it make the workload app that I care about faster, more stable, or more manageable?” At the end of the day, all of our technical shenanigans are irrelevant. Only their workload applications, and making their workload infrastructure more manageable, matters to them.
Average users have trouble finding and staying current on many different content sources (repositories). RHEL had Extras, Optional, Supplementary, and many more when factoring in layered products such as OpenStack and similar. Anything not in the default repositories were confusing or non-intuitive to find.
Users wanted more options provided as a vendor curated and tested content set. Third party sources are often not trusted to maintain compatibility over time.
Users had trouble understanding the life cycle of upstream software compared to RHEL’s 10 year life cycle and support.
Most organizations or users may fit multiple personas at the same time, according to different needs that they have.
Feedback from Software Collections (SCL) adds:
Users loved having more options to meet their workload needs.
Most users only used a single version, except for a few programming languages. Parallel installs of applications were better served by containers or VMs.
Alternate install paths were confusing and non-intuitive to find (/opt/rh/usr/bin/…).
Alternate, name versioned packages were often confusing and non-intuitive to find (rh-python36).
Drastic, incompatible changes are extremely disruptive to most users. This may hinder future adoption of new releases for fear of disruption. GOTO #1.
From this and other survey and research data, the following Market Problems were deduced:
There is a need from Linux distributions to provide more application content options that are curated and tested as a complete set.
There is a need from Linux distributions to make it easier to consume and understand software with different life cycles.
Linux distribution [developers, packages, maintainers] need the ability to create.
Linux distributions need to provide innovation that is consumable and not disruptive to its user base.
As we explored with Fedora Engineers, Council, and FESCo members, what features and solutions we could provide to both RHEL and Fedora end users, the following evolved:
RHEL 8 Application Streams [4] [5]
Fedora Modularity [6] [7] [8]
To be clear, RHEL Product Management considered Application Streams (AppStreams) to be the User facing feature benefit. Modularity was Engineering’s (Fedora + RHEL Eng) technical implementation answer to enable AppStreams. But clearly, our goal for AppStreams was to provide more options to end users to meet their workload and business needs in a way that was curated and tested as a complete distribution. We worked on the fact that upstream applications often had natural, shorter life cycles upstream and how we needed to communicate and manage that to make it consumable to our enterprise customers. Also taken into account were our RHEL + Fedora package maintainers and what they needed in order to sustainably provide and maintain all of this.
Similarly, Fedora leadership communicated that this could be a way to satisfy some of the long term requests from Users who said that Fedora moved too fast and desire for different streams that are easier to maintain across Fedora, EPEL, and CentOS Stream projects. The Fedora Project Leader communicated these discussions often at Flock and DevConf events. Most recently these goals were summarized in the Council’s latest vision and goals for modularity [9].
There have been many discussions on the mail threads lately and I hope this helps provide some background clarity on what led us to where we are today. I thought this was mostly all communicated before, but I could not find where this was written up as a comprehensive set. The closest were the Fedora Modularity overview [7] and FAQ [8] which do an excellent job at explaining much of what is often asked. If there is still use case or context information missing, please let me know.
This is a good start but I’ll post some follow ups to provide more insight to some of the use case requirements that led to Engineering’s recommendations for things such as default modules and similar topics.
Thanks, and happy reading!!!
Terry
[1] https://fedoraproject.org/wiki/Server/Product_Requirements_Document
[2] https://fedoraproject.org/wiki/Workstation/Workstation_PRD
[3] https://fedoramagazine.org/fedora-classroom-session-fedora-modularity-101/
[5] https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle
[6] https://docs.pagure.org/modularity/
[7] https://docs.fedoraproject.org/en-US/modularity/
[8] https://docs.fedoraproject.org/en-US/modularity/faq/
[9] https://communityblog.fedoraproject.org/fedora-council-and-the-future-of-modularity/
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
