How a Group of Developers Took Back Control of Enterprise Java: The Spring Story, And Why It Still Matters

In the early 2000s, building enterprise Java was a slog.

If you weren't there, it's hard to convey what it actually felt like. You had Enterprise JavaBeans (EJB) at the center of a sprawling specification-driven world, application servers that took several minutes to boot, deployment descriptors written in XML so verbose that the configuration was longer than the code it described, and a development cycle where running a single test could mean redeploying half your environment. The official path to building enterprise software was, by design, complex. The complexity was treated as a feature, not a bug. It was the price of being "enterprise-ready."

Developers paid that price with their nights and weekends.

Then a consultant named Rod Johnson published a book, included a working code example in the appendix, and effectively asked the entire industry to look at what enterprise Java had become and admit that it was broken.

That code became Spring. And the story of what happened next, told in the new documentary from Tech Documentaries, is one of the most important stories in the last 25 years of software. It's the story of how a small group of developers took back control of an entire ecosystem from the top down, and built something that today runs the systems most of us depend on every day without knowing it.

HeroDevs is proud to be the platinum sponsor of Spring: The Documentary. This post is part history lesson, part tribute, and part honest conversation about what the Spring story means for the millions of organizations still running on it today.

‍

The world before Spring

To understand why Spring mattered, you have to understand the world it was born into.

By the early 2000s, enterprise Java had become dominated by a specification body — the Java Community Process — that produced standards aimed at solving very large, very abstract problems. EJB 2.x, the flagship specification, required developers to write multiple Java classes and XML descriptors to express what was essentially a single business object. Every method call had to traverse layers of container-managed infrastructure. Testing meant standing up the entire application server, because the components couldn't run outside it.

The standards weren't malicious. They were trying to solve real problems: distributed transactions, security, persistence, remote method invocation. But the solutions had drifted far away from the realities of how most teams actually built software. The specifications were written by committees of vendors who had business reasons to make their products look indispensable. The result was a development model that punished the very thing developers needed most: the ability to build, test, and ship working software quickly.

A whole ecosystem of "alternative" or "lightweight" approaches sprang up in response — frameworks like Struts and Hibernate took different parts of the puzzle and made them tolerable. But there was no coherent answer to the underlying problem.

That answer arrived in 2002, in the appendix of a book called Expert One-on-One J2EE Design and Development, written by Rod Johnson.

‍

The book, the code, and the quiet revolution

Johnson's book was already going to be controversial. It argued — politely, with code — that much of the prevailing wisdom about enterprise Java was wrong. EJB was overkill for most problems. Plain Java objects, properly designed, could do almost everything the specifications were claiming required heavyweight containers. Testability mattered more than architectural purity. Real-world constraints should drive design, not the other way around.

The appendix included a small framework that demonstrated these principles working together. Dependency injection. Inversion of control. Configurable plain Java objects (POJOs) wired together through a lightweight container. It wasn't pitched as a product. It was pitched as a proof.

Other developers picked up the code, ran it, and understood immediately. Within a year, Johnson had partnered with Jürgen Höller and the framework was open-sourced as Spring. The first official release came in 2003.

What followed was one of the fastest organic adoptions in enterprise software history. Developers didn't need executive buy-in to try Spring. They didn't need to migrate entire architectures. They could drop it into existing projects, replace one painful EJB with one configurable POJO, and feel the difference within a single afternoon.

The early Spring framework still used XML configuration — a lot of it, by today's standards — but the XML was different. Less verbose. More focused. Configuring real Java objects rather than describing layers of indirection. And critically: the configuration was a means to an end, not the architectural center of the system. The Java code was the thing. The Java code was testable, comprehensible, and yours.

‍

Why Spring spread the way it did

Spring didn't win because it was the most innovative technology, although it was deeply innovative. It won because it respected developers.

Three principles ran through the early framework, and they're worth naming clearly because they explain everything that followed:

Simplicity is a feature, not a compromise. Spring's design assumed that the cost of complexity is borne every day by every developer who works on the system. Complexity has to earn its place. The default is to keep things simple, and to add complexity only when the problem genuinely requires it.

Testability is a non-negotiable. Spring's emphasis on dependency injection wasn't just an architectural pattern — it was a commitment that any object in your system should be trivial to test in isolation, with mocks or stubs, without standing up infrastructure. This single principle reshaped how millions of developers think about software design.

The community is the standard. Where the JCP wrote specifications top-down, Spring built consensus bottom-up. Decisions were made in code, in conversations on mailing lists, at conferences. The framework evolved because users pushed it forward.

These principles shaped not just Spring, but the broader Java ecosystem. By the mid-2000s, even the JCP had begun to absorb Spring's lessons. EJB 3.0, released in 2006, was effectively a rewrite of the specification along Spring-influenced lines: lightweight, annotation-driven, testable. The official Java standard had moved to where Spring already was.

‍

Spring's second act: Boot, microservices, and the cloud

By the early 2010s, Spring was the de facto framework for building enterprise Java. It was so pervasive that "Java application" and "Spring application" had become essentially synonymous in most enterprises. But the team didn't rest on the framework's dominance. They kept watching how developers were actually working — and what they were watching was the rise of microservices, containers, and cloud-native deployment.

Spring Boot, released in 2014, was the answer. Boot took everything Spring had become and made it dramatically easier to use. Auto-configuration. Embedded servers. Sensible defaults. A single command to bootstrap a working application. The friction that even Spring still had — the XML, the dependency management, the configuration that had to be assembled by hand — was largely engineered away.

Spring Boot is what made Spring viable for the cloud era. It's what made it possible for a small team to spin up a microservice in an afternoon, deploy it to Kubernetes, and run it at scale. Today, Spring Boot is one of the most-downloaded artifacts on Maven Central, and it sits at the heart of systems at Netflix, Alibaba, every major financial institution you can name, and countless organizations whose names you'll never know but whose software you depend on every day.

That ubiquity is also the reason this story isn't just history.

‍

The hidden cost of being everywhere

Here's the part of the Spring story the documentary touches on but that we — as a company that lives in this world every day — want to make explicit.

When a framework becomes infrastructure, it stops being optional. Spring isn't a library you can swap out on a Friday afternoon. For most enterprises, Spring is woven through years (or decades) of business logic, integration patterns, security configurations, and operational tooling. The investment in Spring isn't just code; it's the institutional knowledge of how that code works, why it works, and what would break if you changed it.

That investment compounds in two directions. On the upside, it gives organizations a stable, well-understood platform that has supported them through technology cycles most of their competitors never survived. On the downside, it creates a real and growing problem when versions of Spring reach end of life.

When Spring Framework 5.x reached end of OSS support, when Spring Boot 2.x followed, when individual modules within the Spring portfolio aged out of community maintenance — the official path forward was always: upgrade. And for greenfield projects, or systems with engineering bandwidth and clean dependency trees, upgrading is absolutely the right answer. We say that often.

But for the systems where the Spring code is twelve years old, where the original architects have moved on, where the integration tests are flaky and the surrounding ecosystem is pinned to specific versions for reasons no one fully remembers — for those systems, "just upgrade" is a multi-quarter, multi-team project that often gets bumped behind whatever the business is asking for next.

That's where end-of-life becomes a security and compliance problem rather than a technical debt one. A vulnerability in an unmaintained Spring component is a vulnerability that nobody is going to patch. Not the Spring team — they've moved on to the supported versions. Not the upstream contributors — there's no economic model for sustained backporting. The CVE will sit there, in production, until the organization upgrades or until it's exploited.

‍

What the Spring story tells us about open source

There's a temptation, when you watch a documentary like this one, to treat the story as finished. The good guys won. Spring transformed enterprise Java. Roll credits.

But the Spring story is, more than anything, a story about how open source actually works at scale — and that story is still being written.

Open source software runs the world. We say that so often that it's lost most of its meaning. But the people who maintain it are mostly volunteers, or employees of companies who fund maintenance for as long as it serves the company's interests. When a project ages out of active development, the maintenance burden doesn't disappear — it just gets distributed to whoever still depends on the project. And in enterprise software, the people who depend on a 10-year-old version of a framework usually have the least capacity to maintain it themselves.

The Spring community has done a better job than most at managing this transition. The Spring team's communication around end-of-life timelines is clear, their upgrade paths are well-documented, and the surrounding ecosystem (VMware/Tanzu, Spring I/O, Devoxx, the broader Java community) does real work to help organizations move forward.

But for enterprises stuck on legacy versions, the gap between "what the project supports" and "what the business can realistically migrate to this quarter" is real. That gap is where security risk lives. That gap is also where HeroDevs lives.

‍

What HeroDevs does in this story

HeroDevs builds Never-Ending Support (NES) for end-of-life open source software. For Spring specifically, that means we provide drop-in security patches and compliance support for Spring Framework, Spring Boot, Spring Security, Spring Data, and the rest of the Spring portfolio after upstream maintenance ends.

The point of NES isn't to compete with the Spring project. It isn't to encourage organizations to stay on old versions forever. It isn't to suggest that upgrading isn't the right long-term answer. It is, every time.

The point is that real organizations have real constraints, and the gap between "we should upgrade" and "we have completed the upgrade" is often measured in years. During those years, something has to keep the production systems secure and compliant. NES is that something.

That's why we sponsored Spring: The Documentary at the platinum tier. Not because we want to be in the credits — although we're proud to be there alongside JetBrains and Moderne, who do incredible work in this space too. We sponsored it because the story the documentary tells is the story of why our work exists.

Spring exists because a community of developers took back control from a system that had stopped serving them. NES exists because that same community now maintains the systems on which businesses depend, and because supporting those systems through their full lifecycle — including the long tail after upstream maintenance ends — is part of what it means to take open source seriously.

‍

Watch the documentary

If you've worked in enterprise Java, Spring: The Documentary is going to feel familiar in ways that are hard to describe to people who weren't there. Rod Johnson, Jürgen Höller, Rossen Stoyanchev, Mark Pollack, Sébastien Deleuze, Josh Long, Stéphane Nicoll, David Sayer, Scott Frederick, Steve Poole, Marit van Dijk, Marco Behler, and Sergi Almar all appear in the film, telling the story in their own words.

It's a piece of history worth understanding — not just because it's a good story (although it is), but because the dynamics it describes are still the dynamics of open source today. The same questions about who controls the standards, who maintains the code, and who pays the cost of complexity are being answered right now in every framework, every language, every ecosystem you depend on.

Watch it on CultRepo.

And if you're running on Spring today — whether on the latest Boot release or on a version that the project has long since stopped supporting — you're part of the story too. We'd love to talk about what comes next.

Learn more about HeroDevs Never-Ending Support for Spring, or visit our Spring End-of-Life Resource Hub for a complete picture of where the Spring portfolio stands today and what your options are for keeping legacy versions secure.