I’m building a SaaS platform using Spring Boot + Hilla, and I’m getting increasingly concerned about Broadcom’s ownership of Spring Boot. For those who haven’t been following, here’s what Broadcom has done since acquiring VMware:
Sent cease-and-desist letters to VMware perpetual license customers, demanding they stop using updates and threatening audits (Ars Technica report)
Raised VMware prices by up to 300% in many cases after ending perpetual licenses (Ars Technica report)
Streamlined product offerings by discontinuing or consolidating “unprofitable” features
Broadcom operates fundamentally differently than the old VMware/Pivotal approach to Spring. They’re a hardware company that treats software acquisitions as revenue optimization targets.
My concern: What happens to those of us using Hilla when Broadcom changes Spring Boot’s licensing model or starts charging enterprise fees? Right now, Hilla is completely tied to Spring Boot - the documentation explicitly states it’s “designed to work hand-in-glove with Spring Boot.”
So here’s my question for the Vaadin team: What’s the contingency plan?
Are you:
Monitoring the Broadcom situation and preparing a Hilla migration to another framework if necessary?
Considering support for alternative frameworks before it becomes an emergency?
Planning to continue with Spring Boot dependency regardless of what Broadcom does?
I appreciate what Vaadin has built with Hilla, but the Spring Boot dependency is seeming more and more like an architectural risk.
Spring is published with an Apache 2 license which means that everything that has already been released will remain freely available regardless. Hilla is far from the only party that would be in a peculiar situation in a hypothetical scenario where a future Spring release would use an incompatible license. Considering the wide use of Spring throughout the Java ecosystem, I would expect the ecosystem to step up to maintain a fork based on the last Apache 2-licensed version. The viability of such a fork might not be certain in the long term but I’m relatively confident that it would be enough as a contingency plan.
Hilla’s tie-in to Spring Boot is actually relatively light on a technical level. We’re mostly just using some relatively straightforward request dispatching and making sure you can inject other Spring beans into Hilla endpoints. From that point of view, moving to another underlying framework, e.g. Quarkus, would be relatively easy. But what we don’t want to do unless absolutely necessary is to build and maintain the abstractions needed for supporting multiple underlying frameworks in parallel. This kind of abstraction would cause a significant drag on many aspects of development as well as surrounding aspects such as documentation and marketing.
Makes sense to me.
I’m not exactly eager to rewrite all the Spring code that I just wrote, so I am much more interested in how to mitigate that risk while still using Spring.
Completely understand (and think it’s smart) not wanting to support multiple frameworks.
Forking Spring does seem like the best move in that hypothetical situation. Hopefully there are enough companies that are willing to step up if that becomes necessary. It’s not like Spring has a small footprint in the Java world, and it’s not like Java / Spring aren’t heavily used by some of the most profitable companies in the world.