Hello, Сommunity!
Recently, there have been a lot of questions about LTS release-building procedures. We are making changes in that area — not least due to specific patterns in user behavior, and now it's a good time to discuss that.
The approach to building LTS branches will change soon: it will be possible to build using our online building platform (VyOS Image Builder Enhanced) when it’s ready.
The service will be affordable but not free of charge — you will be required to pay for consumed resources like storage, CPU, and traffic used to build images. The alternative will be to build everything from source — we will keep rolling release package repositories available to everyone, but if you want to build LTS releases, the process of building custom packages, assembling them into repositories, and building images will be on you.
Historically, we made building LTS releases exceptionally easy. This is not an exaggeration: we are unaware of any distro that would provide an equivalent of our make iso.
One reason for the decision to make it so easy was that in the early days of VyOS, users had to choose between an outdated but well-tested "LTS" (not yet called LTS back then) based on the code of Vyatta Core and between the experimental, perpetually broken branch that was to become VyOS 1.2/Crux eventually.
Even in the early days of 1.2/Crux, our automated testing infrastructure was in its infancy, and the rolling release often wouldn't even boot, and if it did boot, it could be broken in unpredictable ways. The only way to give a working image to anyone who needed it but keep the “pay for prebuilt images” model (rather than introducing more intrusive commercialization) was to keep the LTS branch as easy to build as the rolling release.
We assumed that a large community of contributors would form once we eliminated all the technical debt in the old code. This never happened
Instead, we observe more people building LTS images to distribute them online rather than for personal use. GitHub repositories with automated LTS builds are popping up every month. We try to give all people the benefit of the doubt and ask them politely to stop and explain why we want them to stop. Still, we also see people who ignore our requests or refuse to cooperate, pretend that we owe them something, insult us, and think they are entitled to all our work because it’s all open source, so we have to resort to much more heavy-handed measures.
Let me reiterate why we don't want people to distribute images under the VyOS name.
No matter who distributes them, "VyOS" is associated with us. So, if an unofficial image is broken or backdoored, our reputation is at risk. We cannot take responsibility for the actions of random people, and we get to protect the project's reputation because the trust of the Community rests upon it.
That problem would be solved if people did the right thing and replaced the name and the artwork. Just like with RedHat Enterprise Linux, Mozilla Firefox, and other projects, the name "VyOS" is a registered trademark and the artwork is not under a free license — that's the usual way to protect the project's reputation and many other open-source companies guard it a lot more aggressively than we have done it so far.
If people replaced the branding and the name with something of their own, or even teamed up and started maintaining a "CentOS of VyOS", we'd have zero problems with it. But we are still to see anyone do it, even though it's not that hard to do — not more complex than it ever was to replace the RHEL branding for CentOS or ScientificLinux.
Last but not least, hosting and maintaining repositories in a way that keeps them available on the web all the time is not free, and neither is the bandwidth used by image builds, especially cold builds made on GitHub Actions that download the entire repository every time and don't cache packages. So, what is the benefit for the VyOS project? Does it facilitate contributions from the user base? The answer is no.
The era of the perpetually broken rolling release is long gone. Our test suite is not perfect, and we are constantly working to expand and improve it, but if an image doesn't boot or can't load a relatively wide selection of configs with various features, it's not even published.
We know some of our customers use rolling releases in production for features that still need to be added to an LTS branch. If it's good enough for them, it's certainly good enough for home and lab users.
All new changes to LTS releases also must go through the rolling release first and then be backported when they are proven stable, so having LTS access would only facilitate the contribution of bug fixes unique to older LTS releases — we saw maybe a handful of pull requests of that nature in all time. And speaking of which, let’s objectively examine the state of our community…
We love our Community, we are very grateful to all contributors who keep working with us and customers who have stayed with us from the beginning, way before VyOS was recognized and became what it is today.
Contributors have had free-of-charge access to LTS images for a long time — you just need to participate continuously in the project, and we are happy to share our work with you, just like you share your work with us. Customers have access to fantastic software and can focus on their core business, and our team is constantly trying to go beyond just simple support when it comes to business needs. We are very proud of our VyOS for Good program, which brings access to VyOS to various organizations, from schools, universities, and scientific labs to firefighters and rescue teams.
But how many contributors do we have? If you look at the GitHub stats, it's easy to see that most commits are made by people from the VyOS team (people paid by VyOS), with a small number of passionate community members. Then, we had about 150 people who made a few PRs and disappeared. Only 867 people, at the time of writing, bothered to click the “star” button on the vyos-build repository on GitHub (340 for vyos-1x). The number of people who made more than ten(10) pull requests to our repositories in the ten years of project existence is 52. Fifty two people in ten years. Let that sink in.
Let’s look at some other projects of similar age. OPNSense has twice as many contributors and ten times as many stars. Hugo — a static site generator — has 1500 contributors and 72k stars.
That's a Contributors Community.
Don't get us wrong: we are grateful to everyone who contributes and will continue to share our work on LTS releases with them; we hope the numbers will grow.
But let's not fool ourselves or allow ourselves to get fooled: easily buildable LTS releases did not facilitate Contributor Community growth.
Easily buildable rolling releases and LTS images for established contributors are not going anywhere — we want the project to be easy to contribute to, and we want to reward those who work with us. But if you call yourself a community member, you must put some effort into it — like we did and keep doing.