We’re working on Fedora Strategy 2028 — our next five-year plan. We are now reviewing those Objectives and their associated Impact. Read this guide for details on the current planning phase.
This Objective is part of the Theme “Fedora leads in Linux distribution development” and the Focus Area Technology Innovation & Leadership. For general discussion of this focus area, please see the topic Fedora Strategy 2028: Focus area review (Technology Innovation & Leadership).
Objective and Impact
Objective: We integrate programming language stack ecosystems.
Impact: Developers choose Fedora Linux because we provide a straightforward programming environment that works the way they expect.
At the dawn of Linux, there was really no such thing as package management. Then, distros built tools like RPM — consistent ways to describe how to build software, attach important metadata, and distribute pre-compiled binaries. This worked very well, and is the method by which we include all software in Fedora Linux.
But, meanwhile, every programming language — Java, Python, Perl, NodeJS, Rust, Go, etc., etc., has developed their own “native” packaging format. Developers tend to avoid rpm (or dpkg, or whatever else), possibly begrudgingly producing something in distro format as a last-step output. And not without reason — modern languages tend to have nicely integrated package management with a lot of convenient features (and less of the accumulated complication of decades-old RPM specfile syntax).
We currently go to great lengths to re-package libraries and modules from these language package formats into RPMs — doing so in some way is currently a prerequisite for getting an application using those dependencies into the Fedora package collection. This process does provide significant value, but it also causes a lot of friction, both in Fedora and for people coming to Fedora.
I have some ideas, but I don’t know what the right answer is here — and the Council does not want to dictate one. Maybe we find a better way to automate language-specific-to-RPM conversion. Maybe we teach DNF how to work with those language-specific packages directly (and host our own repositories in those formats?). Maybe something else entirely! But: no one else has solved this. If we do this well, it will be easier to provide more software in Fedora Linux directly, and it will be easier for developers to come to Fedora and work comfortably as they are used to.
Our goal now
For this Objective and related Impact, validate that:
- If the Impact is achieved, it’s reasonable to expect an increase in active Fedora contributors.
- Success in the Objective logically results in the intended Impact.
- That link is reasonably sufficient — that is, it represents everything needed to have the Impact.
- While there might be other ways to have similar Impact, the chosen Objective is the right one for Fedora right now.
- The wording is precise and clear. The Objective is concrete, and the Impact is (at least a little bit) inspirational. Together, they fit into this Focus Area.
Bonus. If you can improve the longer explanatory paragraphs at the top of this post, that’s helpful too!
As outlined in the roadmap, this post will close in one month.
See this devel list message and replies — there is a lot to talk about here! ↩︎
which ties into the container and flatpak Objective ↩︎