The 3 Stages Software maturity
From Hype to Abandonment
Last week, I wrote docker swarm is the best solution for early-stage infrastructure, and Kubernetes fans came into the comment section telling me I was wrong.
Soon after that, I went to configure my Jenkins instance to enable CI/CD for JustRM and realised the docker swarm extension hadn't changed in 4! years. It also has a vulnerability reported, and nobody fixed it.
I tried Kubernetes for science. My definition of done is having a service exposed with a configured Let's Encrypt TLS certificate.
I completed it in 2 days, while Swarm took me 2 weeks. Was Docker Swarm a mistake in 2025?
Software Maturity
It’s the risk of how much of a problem a library or 3rd party service will cause in the future.
The last GitHub commit or public release is a starting point. If what you want to use hasn’t changed in 4 years, like the Swarm Jenkins Plugin, it's a clear sign to avoid it. There won't be anybody to help with bugs or security issues.
A good sister metric is commercial support for open-source projects. If a company makes money from the software, it has a good reason to maintain it. Look at Confluent and Kafka, RabbitMQ and VMWare Tanzu or Spring and Broadcom.
Another perspective is the ecosystem of libraries and tooling. Does your new tool integrate with popular and sometimes niche partners? Java can integrate with anything in 10 ways, whereas for younger languages, integrations are missing. Take SOAP, for example. It is critical for the finance systems (still), yet hip languages don't have libraries for it. Good luck writing your own.
Last but not least is community. Do people actively publish articles and YouTube videos about the software they use? How easy or hard is it to find knowledge? Docker swarm is old, and there's little new material about it. Everyone talks about Kubernetes. The chance someone solved your problems in the past with Kube is way higher than with Docker.
There are others, like code quality and culture, but the four I mentioned should give you a good idea of maturity.
Levels of maturity
The next step is to rate the project's maturity, and I use a three-step scale to do so.
The Hype
Something engineers love—new tools straight from the minds of brilliant engineers. It's a lot of fun, but it's hazardous for business. Every problem is a fresh problem to solve and you need to figure it out yourself. There’s also no guarantee that the product will still be on the market in 3 months.
Projects at this stage are suitable for home lab or PoC in your company to see how they work. I know enough people with high-risk appetites can do the verification work for me. But, if you are a technologist and you thrive in the chaotic market of new technologies, it’s a great place to be.
For me, even with AI, I adopted it over a year after the first LLMs released. When I saw they were here to stay. I can't say the same about Web3.
The Stability
The most boring category is when software works.
When projects have regular new releases and there's a commercial supporter with an excellent reputation in the market. There are plenty of stable libraries and add-ons, and there's a YouTube tutorial published every hour.
It's what you want to use in production to keep the tech out of the way of your product. You pick product problems to invest in. The technology problems are solved, making it easy to build new features and hire for your tech stack.
There's a very low risk that something will go wrong.
The Abandonment
This one is tricky when established and popular technologies lose support over time.
You can't avoid it if your company has been on the market for a decade, but you can make smart choices today. It won't be visible first in the core project, but when you look at tooling and community, you will see the engagement dropping. People lose interest; eventually, all that's left is the few companies who invested enough that they can't get out.
A great example is VMware and VirtualBox, which were titans of small-scale virtualisation. However, because of docker and questionable commercial decisions, nobody remembers their existence today.
The lifecycle
The path from birth to abandonware isn't linear, and context matters a lot.
Even Java was a hyped new technology one day. C developers said it was a fluff that would never last, and nobody would want to run a heavy JVM when they could have a small and efficient binary. They were wrong.
Eventually, Java became popular. Even browsers had Java applets. It was the technology for everything.
Today, it lost a lot of the market. And for a good reason. The context where it excels is pretty narrow. It stays relevant in corporate engineering with a focus on integration.
Eventually, every technology will be forgotten, and a new one will take its place, but it will never fully die. Fortran and Cobol are still present and maintained by a few organisations because they can't just shut down critical systems using them. It's like this one server in your company that only a few older engineers know about, which Karen uses in accounting, and nobody can touch.
The software doesn't die; it loses its relevant context. Sometimes, it never reaches wide adoption but stays strong in what it excels. More often than not, it's a context of Fortune 500 companies to get you vendor-locked after following the hype.
Avoid those like fire; they are the worst. They are fully featured, extremely attractive, and easy win with all problems solved, but they aren't here to help you; they want your money.
NewRelic and VMware are great examples. Both were on the market for decades, but with commercial interest, they raised prices so that only the biggest and most profitable companies could afford them. They left the popular space in favour of the commercial support niche.
Docker
Docker is going in a similar direction.
Kubernetes swept it out of container orchestration, and they changed their license to stop free commercial users. Recently, I learned Kubernetes dropped Docker as their runtime in favour of containerd. I also discovered they changed the container build process for a "better one".
Based on my experience, Docker will join the commercial support niche, which you must pay to use.
It's not all bad, though. Every time a company pulls out of the market, it opens the door for new solutions to gain popularity. It's a decade or two long process, but technology doesn't like vacuum. Containerd takes space from Docker, and solutions like Colima and Rancher have time to shine.
My tech stack
Docker swarm isn't suitable for new production workloads. Weird moves from Docker, abandoned libraries, and a lack of community support signal the upcoming end of support.
Kubernetes is the way, but not in its pure form. I went with K0s, although there are plenty of other third-party lightweight distributions. It was the most mature and compatible with the original stack.
Compared to my swarm setup, I got a declarative CD, local console access, GUI to monitor the cluster in IntelliJ, an active community of people, and tools I can use when I need them. All of that in 10th of the time it took me to set up the Swarm.
It is more complex; it has a learning curve, but it's the right thing to learn in 2025.
Should you follow my philosophy?
I enjoy boring tech. You can love fresh challenges or the comfort of old tools you spent life with. There's no correct answer; it is only the context in which we use software.
What I like is terrible for startups wanting to bank investments on current AI hype. They live on the bleeding edge of technology and pave the way for the rest of the community to use what's best in new.
Folks who stick to their old software are great because they keep the lights on for the world to keep going. I may not believe in mainframes, but I'm grateful I can make payments daily, and a team of Cobol devs is making it happen.
I live in a space where the boring works best, and I spend time on making customers happy, not engineering the most hyped solution.
Know yourself, know your business, and pick the maturity that fits you best.
PS
If you’re an engineer or a contractor and you struggle with keeping up with your network and you’re tired of CRMs with 1000s of features aimed at big sales teams:
I’m working on JustRM - a simple CRM that does only what networkers, contractors need - help you stay on top of your network without the noise of corporate CRMs.
If it’s something you’d like to try - the waitlist is open NOW and it’s the best way to learn about Beta release coming late in spring. Sign up today.