We’d like to share an idea and gather feedback from the community, especially from those working in companies using NixOS.
As you know, NixOS has a regular release cycle with two new versions per year. While this keeps things fresh, we’ve heard from some companies that frequent upgrades can be a challenge, particularly for larger or mission-critical environments. To address this, we’re planning to offer paid long-term support (LTS) starting with the current 24.05 release.
Why we think LTS is good for the NixOS community:
Freeing up resources: Companies won’t need to spend as much time on upgrades, allowing DevOps teams to spend more time on contributing to NixOS and open source.
Broader adoption: Offering LTS could make NixOS more appealing to businesses that require long-term stability, increasing overall adoption.
Reinvestment in the community: Revenue from LTS services will be used to support the NixOS ecosystem through event sponsorships, community-driven initiatives, and upstream contributions.
Key Features of our solution:
Security updates: Continued CVE fixes and patches beyond the usual support window.
Extended support: Companies can avoid frequent upgrades, staying on a stable version for a longer period.
Tailored support: We’ll offer dedicated support options for companies with specific needs.
About Us:
Cyberus Technology is a German low-level engineering & virtualization company with headquarters in Dresden and employees all over Germany. We strongly believe in Open-Source, since our entire code is publicly available. Furthermore, we have extensive experience NixOS, have been using it internally since 2018, and many of our engineers are active contributers to the nixpkgs repository. We aim to support businesses using NixOS while contributing back to the community.
We’d love your feedback:
Would LTS be useful for your company?
Would you / your organization consider signing up to a paid long-term support subscription?
What concerns or challenges do you see with this approach?
What specific features would make LTS most valuable for you?
I appreciate the effort but it could lead into tricky situations as the new features will only be accepted into master/nixos-unstable regularly and might not be as well tested but that is probably a detail and upstreaming especially fixes is always welcome.
I think the most important point for the community is that the customers go through you and not through the community support as they won’t receive much help when using an EOL version.
I personally do not believe in LTS. 6 months is indeed challenging and I think we should try to extend that to 12 months but anything over a few years, especially over 4, is just insane and holding the industry back as whole and establishing a culture where you never upgrade and cannot deal with breaking changes and when the upgrade comes the system is rather done fresh because there are breaking changes everywhere.
I absolutely agree with you here but with 1 month transition period every 6 months is just too short for my workplace.
I personally reckon the update cycle will get faster once we would’ve migrated to NixOS but we would probably need 3 months minimum to migrate all systems.
That’s similar feedback I’ve heard from others as well. Maybe that is the best place to target then? i.e., extending this transition period by a couple months and providing a smoother migration path than “here’s the release notes, hope there’s no other breaking changes that snuck in!”
Trying to actually provide an LTS for a number of years seems like a losing proposition.
I think this would be really valuable and could certainly help with NixOS adoption in the enterprise. I can handle running unstable or updating every 6 months but I don’t think maybe other teams at my company would want to try.
One thing (probably an unpopular idea here) which an LTS could do that I think might be interesting is expose a loosely and collectively versioned global FHS-like structure that Nix-naive or proprietary software could build against. Given that it would just be symlinks into the Nix store just like everything else under NixOS, multiple such releases could live side-by-side on a system, allowing more incremental transitions to new NixOS releases. Naturally that adds a lot of complexity to where a Nixer would doubtless rather put together proper Nix packages for their in-house apps, but it’s an idea I might like to at least experiment with if an LTS release existed.
A more serious feature that I think would be valuable is supporting security backports for customer dependencies in additional to whatever minimal base system you end up supporting for LTS. Idk how you’d work out supporting that or charging for it in a way that doesn’t punish companies for being the first to ask for support for their dependency, but maybe you could find some way to charge in inverse proportion to the number of customers using that extra package that disproportionately benefits the customers who first requested support for the package.
Our plan is to work with early customers and arrive at a sub-set that provides most value to everyone. With nix it should be possible to figure out what packages & dependencies are actually needed and provide for those.
Are y’all at NixCon ? Id love to let you know about Mercury’s pains and wishes with the current release process.
I do agree with the sentiment here that the 1 month cutoff period is kinda harsh. Ubuntu for example has a 3 month cutoff period. This would already help us tremendously
To extend the transition and support period we need more people that support the stable version. There are often backport PRs for stable that need review and tesing or security fixes which need to be backported. Many of the active people are on unstable and not always have a stable system to test on around. If there is more support on those tasks an extension becomes possible. Right now it sometimes feels like by the end of a stable cycle you are very relieved to no longer need to create/review backport PRs which you can’t always test or deal with missing features/updates/etc on stable.
I think, right now, there are 2 sort of challenges for an LTS or to even have a longer overlap period at a “global” nixpkgs/NixOS level:
The set of people cherry-picking patches from upstream or even adjusting them so they can be backported to stable is quite small. Even with the current 7 months period sometimes we already have no other real choices than to set meta.knownVulnerabilities
It requires additional build/CI capacity (+ people to manage that) to publish the changes in a timely manner. Backporting patches/versions for things like OpenSSL/cURL/glibc/… is a source of a massive rebuilds but not something you can ignore.
Trying to determine a smaller subset of packages to support might make things more sustainable but I suspect it is not easy.
Also, maintaining an LTS also requires some planning work before the release, you want to be include, as much as possible, at least one version of software that will be supported by upstream maintainers for (most of) the targeted period. It is already something that is done to a certain extent but having a 7 months target is quite different than to have a multiple years one.
I believe both of those challenges are meant to be solved by this offering, since you’re paying people dedicated to backporting, and build capacity is more or less trivial.
While I’m personally sceptical of the whole notion of LTS branches (and even our current stable releases), if there are companies that find value in this service I see no reason you shouldn’t be able to provide it for them. My only worry is about the potential additional burden this may place on upstream Nixpkgs. Please make sure you have appropriate branding that makes it clear that your fork of Nixpkgs is not the Nixpkgs that everyone else contributes to, that your backports aren’t officially endorsed by the project, and that users of your fork go directly to you rather than reporting any problems they run into upstream, even if they don’t think they are related to using a release branch we no longer support.
Would the source for the LTS fork be publicly available under Nixpkgs’ MIT licence (with payment for support and a say in what gets backported), or is the source intended to be proprietary?
@emily I agree on clearly separating concerns and responsibilities, and protecting volunteers from support requests, but as I presume Nixpkgs would actually benefit from dealing with LTS in-tree and in the same issue tracker.
A commercial actor would be obliged to triage issues as they come in and label them appropriately. Doing that on the public tracker leaves it open for anyone to collaborate. By construction it would also mean that someone is looking at them at all. Providing LTS releases on official channels will keep ease of use and increase visibility; all we’d need to do is make clear who contact for support.
I’d be in favor of leaving room for overt commercial activities — much preferable to work not being attributed or being done somewhere else entirely — as long as there are precautions that take volunteer contributors’ and users’ interests into account. This would need strong leadership on the Nixpkgs side and close collaboration with the company in question. Still a stretch judging from past experience, but not impossible. I’m hopeful this can work out.
I think including it in the Nixpkgs repository and issue tracker is a very different proposition to a separate commercial LTS branch. We’d effectively be officially endorsing these LTS branches and the company in charge of them, which I’m not sure we’d want to do from a security or maintenance perspective if nothing else, and it would be basically inevitable that it would take up volunteer time which is already stretched thin.
I’d definitely want to see an RFC or similar for that kind of arrangement, and I think I would personally be opposed. At the very least I’d want to see this done as a separate public but unofficial offering for a while first, so that we can see that the quality of maintenance is up to standard and that it hasn’t resulted in additional burden for Nixpkgs maintainers, which would only increase if it’s brought in‐repo.
I have a niche use case in my org (Google) and having LTS would make it easier to switch to NixOS from Ubuntu.
Would LTS be useful for your company?
I think so yes. 6 months right now is too fast a cadence when we have many other internal competing priorities for project work. Not sure we need 4 years, but 2 would be great.
Would you / your organization consider signing up to a paid long-term support subscription?
I think I could make a case to leadership if the value was there. But I’m just a SWE, so…
What concerns or challenges do you see with this approach?
That’s beyond my expertise
What specific features would make LTS most valuable for you?
Slower release cadence, back port of security patches, stability, and some basic consultancy on configuration syntax would be awesome.
We’d also need to deploy an intermediate package store so we have full control of what we receive from upstream. You folks sound like you know how to do that…
I think that if there’s a party willing to keep maintaining release branches after the “official” EOL, on commercial basis or otherwise, I see no inherent reason to prevent them. Such a party must be aware that 1) no other maintainer is obliged to spend time reviewing their changes or replying to their customers’ tickets, 2) any other maintainer is free to interfere or block their changes for whatever reasons. Such a party would have to ensure that there are maintainers to review and merge their work, and, if needed, defend that there’s no conflicts of interest or imbalance of power, whatever might mean.
We’d effectively be officially endorsing these LTS branches and the company in charge of them
Side note: I’d only double down on the notion that there’s no homogeneous “we” and no “official” anything beyond what is required to comply with regulations, protect ourselves from IP and copyright laws, make Nix &co look less “unsafe” for corporations and institutions, or similar “exceptions”…
