1:52 p.m.
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:
1.
Fedora has a diverse spectrum of end users to satisfy.
2.
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.
3.
The “Too Fast / Too Slow” problem and demand for access to select
content provided with different life cycles.
4.
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.
5.
Drastic, incompatible changes can be extremely disruptive to many users.
RHEL adds to this a few nuances based on user feedback:
1.
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.
2.
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.
3.
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.
4.
Users had trouble understanding the life cycle of upstream software
compared to RHEL’s 10 year life cycle and support.
5.
Most organizations or users may fit multiple personas at the same time,
according to different needs that they have.
6.
Feedback from Software Collections (SCL) adds:
1.
Users loved having more options to meet their workload needs.
2.
Most users only used a single version, except for a few programming
languages. Parallel installs of applications were better served by
containers or VMs.
3.
Alternate install paths were confusing and non-intuitive to find
(/opt/rh/usr/bin/…).
4.
Alternate, name versioned packages were often confusing and
non-intuitive to find (rh-python36).
7.
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:
1.
There is a need from Linux distributions to provide more application
content options that are curated and tested as a complete set.
2.
There is a need from Linux distributions to make it easier to consume
and understand software with different life cycles.
3.
Linux distribution [developers, packages, maintainers] need the ability
to create.
4.
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/
[4]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
[5]
https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-c...
[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-...