It is probably a good idea to prefer simple language. However, I don’t think we would use that particular conception of it, which is really a constructed artificial language based around a very limited list of words and simple grammar.
@till — on the specific points: the discussion on each of them over the next few months should both provide expanded explanation for what each means and give opportunity to sharpen them.
I think the header “leads in linux distribution development” is confounding me bc I don’t read the items below it as being development of a distribution. (Distribution development to me means letting people make their own distributions like remixes / etc.) They seem to be community maintenance and technical leadership things. So I think maybe a less ambiguous heading like “Fedora is a Linux leader” or something like that…? Not sure.
The other thing is I was kinda disappointed that there isnt a high level thingy for containers and development. We have the containers (as in Containers · GitHub) community as a close peer / sibling… and the idea would be, generally, the OS platform is freed, but we want containers to be free as well… see A new conceptual model for Fedora – Fedora Community Blog for the idea there.
To me, “Linux distribution” covers what Fedora, Debian, Ubuntu, openSUSE, Arch, etc. create., while if we say just “Linux leader” here it tends to narrow things towards kernel type features. As much as I dislike their stats page, I basically mean “things that might be covered by https://distrowatch.com/”. I’m open to a different way of saying it, though. Maybe it’s the word “development” that needs a tweak? I think we originally had this as “Fedora leads in the distro space”…
I think we have aspects of this in two places: first, under the theme above, in the technology focus area, we have “Fedora is a popular source for containers and Flatpaks.” But if I understand correctly, you’re talking particularly about the tooling projects — that would fit in the “Ecosystem Connections” focus area at the end of the list… specifically, " Collaborate on tooling, practices, and offerings with peer distros and upstream projects."
But maybe you are suggesting something closer — bringing those things more officially under the Fedora umbrella? I’m open to that, but we’d need those projects to want that…
Another possibly-missing Objective under “Innovation and Leadership in Technology” might be: updating our packaging workflow, from things like rpmautospec to bigger ideas like Source Git and Packit.
I, for one, would like to see us move to a packaging model where the spec file (or equivalent) is clear of all boilerplate — something like 3 lines for a simple package. But, this might be an initiative we do separately rather than something that fits this plan. (Making packaging easier and more friendly to upstreams could be a way to increase active participants. But I’m not sure there’s a straight line to the “North Star”.)
Hey Matthew,
Re: wording confusion in distro leadership
“Fedora leads in the distro space” would not have confused me as much as the current title so I think I prefer that language. I think “development” probably is the key confounding word. It definitely makes sense as a category it’s just the words I’m hung up on, lol.
Re: development/containers:
OK yes, the ecosystem connections bit is really what I’m looking for, specifically with containers and developers. In the past we’ve had a focus on developers and their use case…
Yeh, it would be nice if the Containers projects wanted more of an explicit partnership there. I don’t think it makes sense to pull them under the Fedora umbrella because they are cross platform and distro agnostic (although, to be clear, there’s a clear preference / priority / advantage for using with Fedora & friends because that’s where we mostly all came from!) So I think we should state the implicit partnership we have going on there kind of more explicitly I think? And better - I don’t know the right word, cross-promote maybe isn’t really the right one but gives the sense - between the projects to better tell the higher level narrative that the silly F model I made outlines. Be friends out in public 
I think there could be a straight line to the north star in this - in that, for example, podman has growing leadership and influence in the container space, if Fedora Workstation is the premiere development workstation explicitly stated to work with podman where you get the best / latest build-in (which I think is the case, isn’t it?) and we actually promote that, could that bring in some Linux curious dev to choose Fedora over other options to work with Podman? (And IIRC on cross platform when you install Podman you’re getting it on Fedora CoreOS? So we’re getting Mac and Windows users of Fedora that way already )
A post was split to a new topic: Fedora Strategy 2028: What is a contributor? What is a contribution?
I disagree with the “doesn’t add value” part. Granted, it’s a chore if the ecosystem is not broad enough yet. Instead of ignoring the added value of having everything in RPMs, automation should be the answer.
My take: “doesn’t add value” is too strong, but it does not add nearly as much value as it could given the effort, and we have trouble demonstrating the (real!) value that I agree does exist.
It may be that “better RPM automation” is the best answer for us[1]. We intentionally phrased this in a broad way. But I think that must include allowing us to step-back and explore other ways we could address the problem and possibly do even more (and how we can get there from what we have).
But also, let’s talk about this one in specific in more depth when we get to the details of that objective. 
I’d love to see a typical next-generation spec file be just ~3 lines of metadata, and any other lines be by definition exceptional… ↩︎
@smooge asked a really good question that I think is so important that I’ve split it into its own topic:
One thing I think is missing from the next 5 years goals is to reduce Fedora carbon footprint by identifying areas where we might being wasting resources and optimize software we distribute to end user to optimize users electricity usage.
For example, I was about to write on devel to ask if the EncourageI686LeafRemoval change introduced in F37 could become the default in F39 or F40. We’re building thousands of packages in Koji for ix86 architecture by default, but the vast majority of those are never used/distributed to end users, since we’re not producing ix86 images anymore (as far as I understand).
I also remember a discussion about delivering optimized kernels to users based on supported features of user’s CPU, but I don’t remember is it was deliberated it was impossible or not.
I think there might be more areas which I don’t know in Fedora infrastructure where we can optimize resources and since it’s becoming more and more important to reduce carbon footprint it should be included in Fedora goals for the next years.
That’s easy to fix, just use the term “Lodestar” or “Polestar”. Done.
The tooling encourages more discussion, and does enhance the quality of the discussion. Case in point the use of Discourse vs. Mailing Lists. I won’t go into all the differences, because they are obvious.
For me, being more. workstation rather than server focused, the most important thing is consistent, reliable performance of all desktop environments. Linux is still a geek tool that is unlikely to attract new end-users in large numbers. Any little thing I want to install/tweak ends up needing hours of web searching and mind-reading. I have wasted untold hours fighting with bugs and performance issues. I think the every 6-month relrase cycle smacks of the same featuritis as MS and Apple. I would prefer fewer new features and more attention to making what already exists reliable.
Also, read Stephen Covey on mission statements and then ask yourselves how any of these things can help an employee or contributor decide what to do when a novel or unforseen situation arises.
The 7 Habits of Highly Effective People guy? I did a search on what he has to say about mission statements, and everything I came up with is about personal ones, and has guidance like “It reflects a strong connection with your deep inner life and recognition of your deepest and best self.” Is there something in specific you were thinking of?
We’re not planning on rewriting the basic Fedora mission statement or vision at this time — we went through that recently and I don’t see a strong need to revisit. We know where we’re going. Is there something specific you would suggest?
I think our mission, vision, foundations — and the north star statement here provide good guidance for how to approach a novel situation — and, we are working down to specifics from there, as I’ve outlined.
I think we’ve been doing a six month release cycle longer than Apple or Microsoft. (Especially if you trace back to Red Hat Linux before Fedora.) But, I think this misunderstands what we do. Fedora is fundamentally an integration project. We don’t directly develop most of the software we include — rather, we strive to make it all work together in a coherent way for end users, and for others who want to build solutions on a reliable base.
I know Linux can be frustrating some times — but so can all software. The unique thing is that this is our software — not Fedora’s, not Red Hat’s, but collectively a shared world of tools and applications we are building together. Part of Fedora’s role is addressing those bugs and performance issues. That’s a crucial way we give back.
But, this is big. There are many moving parts coming from so many different people, all with their own ideas. In the open source world, change is happening. We have found that integrating it on a regular six-month cadence provides a good balance: faster than that (as in a “bleeding edge” rolling release) and users have to accept large changes at any arbitrary time. Slower than that and change accumulates and accumulates, making it harder and harder to do the integration work and making the leap between versions a big deal for end users.
We have downstream distros — projects that (as in our mission!) build on what we do, and release at a slower cadence. These include Red Hat Enterprise Linux (on a three year cadence) and Amazon Linux (cadence TBD). Fedora ELN and CentOS Stream are Red Hat’s way of making that large jump easier for developers, vendors, and hopefully users. You may find that one of these downstreams matches your personal tastes more. That’s okay!
Or, you could consider running Fedora Linux “N-1” — that is, stay on a release one back from the current. You still get change, but with a buffer for the newest stuff to settle down. And you can help us! Make documentation better. Find the pain points and do what you can to smooth them.
Because — bringing this back to the topic at hand — while we want more users, our goal for this plan is to bring more people into the project of building this amazing, collaborative thing. That will allow us to serve more users, make things better and more polished, and ultimately reach a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.
Overarching target to grow active contributors is universal goals and objectives, in my view, and i’m thinking about how we can channel our efforts into the goals.
We would need to extrapolate meaningful success criteria (instead of saying metrics, for now) for each group. This is to match underlying efforts to achieve towards the goals.
Within my remit in Docs team and my interest area (Modularity/EPEL), I think there are a few success criteria (backed by stats we can access) to focus on.
Using a little bit out of topic analogy in personal fitness, pace (min/km) is my motivator to run consistently and how to keep everything else in check - hydration and recovery. What I’m trying to convey here we need specific goals in each group for concerted efforts. Raw power equals a number of active contributors. Knowing numbers that matter isn’t for competition, but for motivation.
That’s a good list, but more detailed than we’re discussing in this thread. Hold on to those. As we start discussing specific objectives, that will be great to add.
There’s an idea here — or I think so — that I want to capture somewhere but am not sure where exactly…
That is: while we have these focus areas and objectives as part of the “central” plan, teams which don’t for whatever reason fit into the model at the end could still look to the same guiding star and develop their own logic model for making an impact towards that goal. (And we could collect those somewhere to help make them visible.)
Okay, straw poll time! This is to help me get a sense of what we’re all thinking, not a binding vote. I recognize the that “North Star” isn’t immediately obvious in every culture, and perhaps especially to folks in the southern hemisphere. On the other hand, it is a well-defined, common business-strategy term. On the third hand, Fedora doesn’t have to be businessy. We’re not a business! (And I’m still stinging from that time in 2014 that people on Slashdot called me a corporate suit.[1])
So:
0 voters
And yes, I’m going to vote in my own poll.
I am not, actually. EIther stinging or a suit. ↩︎
… to double-click on Mairin’s point:
IMHO, most open source projects tend to focus on the perspective of the developer writing the code. Fedora is not an exception there.
Where I think Fedora has a contribution to make is in the releng process in particular and in meta-cognition about artifacts in general.
In other words, the future is more distributed, more collaborative and more platform agnostic. I think that Fedora can promote the practice of building confidence in code through testing and supply chain management.
If Fedora can make it easier for developers to answer the four enduring mysteries:
…then the whole community will benefit and it will be easier to engage with new contributors.
I know this is a tall order. In fact, question 4 got me disinvited from eng meetings at a (over capitalized) startup.
A more ambitious goal would be to facilitate trunk-based development perhaps using a combo of Gerrit and Zuul-ci, like the folks over at https://opendev.org or https://softwarefactory-project.io/
I’ll show myself out…
It’s up to you Matthew. You’re the author. The reality is that idioms usually don’t translate well between languages or cultures; but they make writing interesting. This is making a mountain out of a molehill. 