Being a long-time user of Arch Linux and Chrome OS, I am a fan of rolling release software. I am also a user of Adobe Creative Cloud and the experience is so much better than the previous ‘versioned’ Photoshop and Lightroom where plugins would break after each major upgrade. Now, I get updates on a weekly basis without anything breaking.
Recently Microsoft announced a Windows as a service model for enterprise customers, which hints at rolling release Windows upgrades. I can see a lot of people fretting at that idea.
I love it because, to my mind, rolling release should be the future of all software.
There are some genuine concerns, but they are technological challenges and companies like Google and CoreOS have already solved them.
The real challenge doesn’t lie in technology; it lies in mindset. We have this mindset of point releases that we can stick to because they have been working fine. This is the mindset of “If it ain't broke, don't fix it.”
But software is always broken and is always changing. That’s its nature.
The real problem with the "if it ain't broke" mindset is that it stops you from keeping your software updated. You are missing out on bug fixes, new features, support for new technologies. If you aren't updating your software you are pushing it towards its own death.
As Greg Kroah-hartman, the leading Linux kernel developer, put it, “If your operating system does not change, it is dead. It's that simple. If your device does not change based on the world it interacts with, it is dead. It's that simple.”
The good news is that mindsets can change. Just as DevOps has changed the way people look at IT infrastructure, a new movement is needed that encourages the always-updated software development and delivery model.
Here are some points in favor of moving all software to rolling release:
- Users don't have to worry about keeping up with updates and upgrades. Those are done in the background automatically. That frees users from ‘maintaining’ their systems and allows them to focus on getting work done.
- Since these are small, incremental updates there is less chances of breaking something.
- In the event of breakage, rollback support allows users to go back to the previous version while a fix is being developed.
- Small changes make it easier for developers and users to find what's broken, which means quicker and easier fixes.
- Since the system is getting updates continuously it’s harder for hacker to attack, because by the time they exploit a hole, it’s automatically patched.
- A subscription model creates a continuous stream of revenue for developers, which is incentive for them to keep upgrading the software.
Some valid concerns:
- There is concern that once you subscribe, companies will try to cut costs by not upgrading or updating their software, because unlike ‘selling’ the next upgrade for features, there is no incentive.
- On a personal level, my greatest fear is losing complete access to the software if I plan stop my subscription. As an example, at the end of 5 years I would have paid over $2000 for my Adobe CC subscription, and even though I've paid for it, if I shut off my subscription I won't have access to even an old version of the software.
- Breaking device drivers and third-party apps. This isn't an unsolvable problem, but developers have to look at software from a different perspective where changes to the core doesn’t break things. For example, Firefox extensions used to break with each upgrade. That doesn’t happen on Chrome browser which also supports extensions and follows a rolling release kind of model.
Despite the concerns, I am all for rolling releases to become the defacto development and delivery model for software in the future. I think most users are like me in that I want to focus on using my computer to get work done, not working on my computer. Of course, there will always be a tinkering community that will do their DIY thing. And once again I am reminded of the example of Chrome OS and Core OS that allows you to tinker on top of an always up-to-date yet stable base.
This article is published as part of the IDG Contributor Network. Want to Join?