Add an LTS CE subscription option

Feature Requests
1

Call to Action

If you want this feature, upvote it and comment with:

  • How much would you pay yearly for it
  • Do you want 4 year or 5 year support
  • If 5 year, how much are you willing to pay on top (this is a 33% higher engineering effort, roughly)

This could be a good in-between option for SMB (small and medium business, not the storage protocol): Still community support only, but a stable version that doesn’t need to be on a 6-month cadence. At a lower price than full-fat Enterprise.

Problem/Justification

The current unwritten CE EOL policy as per TTT 030 (Vibe Coding, MinIO Fork Fallout, and VMware Snapshot Shenanigans | TrueNAS Tech Talk (T3) E030) is that a dot two release deprecates the previous release. Deprecation means no more security fixes, with ixSystems reserving the right to be flexible about it. E.g. 25.04.2 would end security fixes for 24.10.2.2

This forces security-conscious CE users into a roughly 6 month upgrade cadence. Not all users may want that, particularly when major features change, such as virtualization changes in 25.04.

Impact

In this TTT, the idea of a paid-for LTS CE subscription is floated. Users would have the option to subscribe and receive N years of security fixes on the LTS version.

To make this engineering burden reasonable, a few things would need to happen:

  • Enough users want this to pay for it and then some
  • LTS is offered on a 2 year cadence, for 4 or 5 years. E.g. “every even-year dot 4 dot 2”. Similar to what Debian and Ubuntu do. It is not reasonable to make every 6-month release an LTS
  • Why even-year: Debian does odd-year. This means a TrueNAS LTS is on a proven but not too-old Debian LTS. Alternative could be “every odd-year dot 10 dot 2”, which gets that Debian LTS a little sooner. The advantage of even-year dot 4 is that the Debian LTS can be combined with that year’s LTS kernel, if desired. The kernel goes LTS at the end of a calendar year.
  • Using an LTS kernel would avoid needing to backport security fixes manually to “whatever kernel”.
  • LTS kernels are only guaranteed support for two years. The kernel Debian ships with receives updates for five years by Debian. ixSystems builds their own kernel and will better understand the best way forward to make that component LTS supportable.
  • A four year cadence is a considerably smaller engineering effort than five years: Two LTS at any time, rather than sometimes two and sometimes three. E.g. 26.04.2 would fall off with 30.04.2 on four year, but stay supported until 31.04.2 if it is five year.
  • LTS to next-LTS updates are fully supported. This is an engineering lift to be sure. E.g. 26.04 to 28.04 to 30.04, without needing to go through 26.10, 27.04, 27.10, &c.
  • Skipping an LTS update is not supported. 26.04 to 28.04 yes; 26.04 direct to 30.04 no.
  • LTS means security fixes to the appliance. It does not mean backported features.
  • Thought to be given whether bug fixes will be back ported and for how long. E.g. it may be reasonable to back port significant bug fixes for two years (until the next LTS), and only do security fixes after that.
  • LTS might be restricted to the appliance itself. Supporting apps on a 5 year old version is a whole another can of worms, and I’d call that “best effort” - if they can still be updated great, but it’s not guaranteed.
  • If bug fixes are back ported for 2 years then it’d be very friendly to make an effort to also support apps for 2 years
  • This would allow users to always be on an LTS: Bug fix and “probably apps” support until the next LTS is out; security fixes after that. Users with storage only use cases may want to update every 4 years; users with more complex use cases that include apps may want to update every 2 years.
  • “The time is right” - if ixSystems is to be believed, TrueNAS is rapidly becoming feature stable. Storage already is; apps hopefully are; virtualization I feel hopeful but unsure. 26.04 may be a good target for a first LTS.
  • It’s mentioned above and I’ll mention it again for clarity: A user that upgrades every 4 years would need to do two updates in a row. Old-old-LTS to old-LTS to LTS.

User Story

User subscribes to LTS CE on the iX website, with a clear note as to which versions are currently LTS. User is warned that versions after the last LTS can’t take advantage. Ideally this is initiated from the TrueNAS UI so the system can check whether the user is currently on an LTS-supported version, and get them there if not.

User submits payment, pays for one year, and receives automatic renewal reminders one month before automatic renewal a year later. User receives some form of token.

User enters token into TrueNAS appliance and switches to “LTS CE” channel. If the current version is not an LTS, that is, previous check failed or user upgraded after, user is prompted to upgrade to an LTS if available; and otherwise prompted to try again when the next even-year dot 4 dot 2 has been released.

1 Like
2

I will be touching grass in 2026 for an extended period of time.

I’d pay 100/year for a subscription that gives me an LTS for 3 to 4 years, so I can go from 26.04 to 28.04 and don’t have to teach my husband the intricacies of TrueNAS management.

3

I just don’t see how it is useful or helpful, even in your example of relying on someone else to manager your NAS in your absence.

My biggest fear if I’m away for extented periods isn’t worrying about (arguably) edge case security updates for my 1 home nas, but hardware failure that I am not physically present to fix.

I’d argue that I’d pay $100 to not have any updates done in any conceivable way if I’m away for a year. Just to not have to deal with chance of "oh whoops, update x.2.1that should have fixed y sadly has an unexpected issue, it’ll be fixed in x.2.2 soon, systems may fail to boot, revert to previous version on boot’. That’d be fun while I’m away.

4 Likes
4

I think LTS gives you that. You already have “no auto updates”. LTS adds “and a guaranteed upgrade path to the next LTS”. So your NAS just runs, and every two years you install a major version upgrade. Optional minor upgrades in between, from 26.04.2 to 26.04.2.1 &c

This feature request came out of the 6-month release cadence discussion. New versions of TrueNAS every 6 months It not getting traction is a completely acceptable outcome.

At least now there’s a place to vote for it and comment. ixSystems can then gauge the response and see whether it’s worth going for.

1 Like
5

Hmm, maybe I’m just not seeing the bigger picture & I’m way off point.

6

Not sure if it makes financial sense. TrueNAS is GPL so any LTS like this would also release as GPL and at this point why would users pay for it if they can download it for free?
Seems like much work for little pay.

7

This would appeal to SMB, small medium business. The last thing they want is “download something so they don’t have to pay for it”.

Btw the license is mixed. There are proprietary pieces in enterprise and this could work in a similar way.

Whether there’s enough paying customers to warrant the effort: That’s what this feature request aims to find out.

If Kris and Chris hadn’t mentioned that they want to know whether there’s a market in TTT 030, this post wouldn’t exist.

Maybe the right mix isn’t 2500 users at 100 bucks … maybe the right mix is 500 SMBs at 500 bucks.

My SMB didn’t need this kind of storage. If it did, a TrueNAS for 500 a year for stable software would have been “yeah here’s the credit card” without even worrying. Even 500 a month would have been extremely good value for what TrueNAS is.

Now - how many SMBs are there that can’t pay for enterprise but want to pay for an LTS. I have zero clue.

That this idea goes nowhere is a perfectly valid outcome.

2 Likes
8

You are right, SMBs will rather pay.
Well, in that case I am looking forward how will this turn out.

9

I’d honestly be more interested in paying a reasonable amount for a “support contract.”[1] I understand why iX would be reluctant to do that with any user’s random hardware, but I’d seriously consider it. I’m just not that interested in staying on, say, 26.04 for three years since iX are moving so fast in making changes to CE.

  1. I’d expect support at this level to be minimal, certainly not “we’ll fly an engineer to your location,” or even “we’re on call 24x7,” but some definite level of support that’s higher than what’s currently offered to us freeloaders. ↩︎

2 Likes
10

GPL does not mean “free download”. The GPL mandates[1] that whoever gets a binary distribution should have access to the source code. It is remains perfectly possible to put the binaries and source behind a paywall, with a user license preventing unauthorised redistribution.

  1. and let’s not even discuss whether the GPL would have any legal standing if someone ever tried to enforce it through courts… ↩︎

11

The GPL does not allow this–it mandates that anyone who receives the source receive it under the GPL license, which explicitly allows redistribution. So RedHat doesn’t have to release RHEL to the world, but anyone who buys it can still legally share any source (well, source of anything that GPL’d). See GPL3,[1] section 10:

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.

  1. https://www.gnu.org/licenses/gpl-3.0.en.html ↩︎

1 Like
12

You can look at WordPress ecosystem of GPL plugins. They want to sell those plugins to people but all it takes is one person publishing the source and anyone can legally take it and use it without paying.
That’s why they don’t even call it pirated plugins, they call it nulled plugins, because it’s legal.

13

I’d definitely be interested, mostly in an SMB capacity.

An enterprise system for 5 figures with a support contract to get access to the “enterprise version” and some stability expectations has been very hard to argue for, especially compared to a “familiar” Qnap System for significantly less money.

And using the free “Community Edition” also isn’t really an option, because a 6-month release cadence with an (effective) 9-10 month EOL cycle is pretty brutal. Especially if there are any blockers in the new release. You can’t just “wait for the release after” without running an unpatched system for like 3 months.

We’d happily pay what we save compared to competing prebuilds by building our own system for running an LTS version of TrueNAS, even without a “proper” support contract, SLAs, etc. Hourly billing on consulting/support might be an option for some, but in general we haven’t needed much “support” for our storage systems in general. With some actual sysadmins on staff that’s just not a major concern and would be even less of an argument for enterprise because we’d be paying for a contract we as a company don’t really need.

What we need is just something stable that doesn’t need require a major migration effort twice a year and has some flexibility on WHEN we can perform the migration without falling into the EOL window if we need a few weeks after the X.Y.2 release. And TrueNAS would be especially appealing since most admins are already familiar with it.

I don’t really see the need for LTS in a homelab, mostly because spending two Saturdays a year isn’t really a big deal for a personal machine, especially if some downtime isn’t costing anyone money, but to each their own.

2 Likes
14

What I like about @yorick LTS idea is that it can be used as the basis for CE support as well.

It’s very hard to offer support for early adopters and random hardware. Make sure the system is on LTS and then offer support makes more sense.

It doesn’t solve the hardware issue…however.

Certainly, I appreciate this discussion…

15

Would you be open to a more flexible model of optional TrueNAS updates every 1-2 years with reasons?

It would allow us to only use "mission critical versions’, but we can change versions if needed. Apart from kernal, we have major other components to consider.

The user would have option for no update (e.g if system is near EOL)… and we could make sure rollback works well.

16

I don’t think the forum members need to worry about this.

TrueNAS engineering can manage piracy issues if and when we design a solution.

We’re more interested in:

  1. if there is demand
  2. what constraints on software development would be imposed
1 Like
17

Fully agree.

To me, the appeal to stay on a version of SCALE is driven by how much conversion work is necessary to transit from one version of scale to the next, see VMs in latest switcheroo.

The base functionality of the file server has stayed for the most part stable, with a few pruning steps like eliminating AFP support along the way. That can be a problem for edge cases like hardware that has to stay at a MacOS level where modern SMB is not an option.

But if having a local file server is your main use case, there is little downside to the upgrade cadence. Most of the hubbub / change is around virtualization / apps and that’s for the most part an unpaid hobbyist thing?

There are alternatives - paid - that do virtualization as a professional product, with available service contracts, and so on. I’ll bet a donut that far more businesses engage that kind of contract for VMs than use the “experimental” VM / app features on TrueNAS.

It’s not like setting up VMs on CORE was all that intuitive either. But I appreciate how much work goes into getting them going and hence the reluctance to chuck all that work and spend hours doing it again in incus or whatever.

If anything, it forces you to carefully document how you did it, especially the obscure stuff, since many on this forum do this kind of work once every couple of years. I’m so glad I did it for my SSL work since it took days to get right on CORE, and less than a few hours in SCALE because I had the recipe.

18

Absolutely. The exact parameters of an LTS are up for debate and subject to market discovery. Nothing’s off the table.

19

We’re not worried, we’re stating the obvious:
You cannot legally do this.

You can make it annoyingly hard with things like signed updates and verification, but that just means someone is going to make a fork without your signature crap.

I know one company that did this somewhat successfully: Only Office.

They made their build-process so impossibly hard, that only them and their employees could even dare to navigate the mesh of GitHub projects and dependencies.

Dont forget it’s not all “your” code either, there is code in there that is not legally property of iX.

And I also dont advice playing games on GPL of the Kernel with the linux foundation either.

So I would ask the obvious thing:
Is making money so important, that you want to risk the support of the OpenSource community or, even worse, antagonise them/us?

20

ontopic:
Imho the best solution is to lengthen the major revision from 6 months to 2 years, with 6 months of BETA and 6 months of RC.

This would get is the lengthened dev cycle the product needs and, essentially, 2 year lts releases. Which is more than enough when the releases get more stable.