Raising Spring: An 18-Year Journey

I recently had the pleasure of speaking about the history of Spring at SpringOne in Austin. It was an opportunity to reconnect with committers and community members and prompted me to reflect on the Spring journey and the lessons that come from it.

I wrote the oldest code in the Spring Framework codebase 18 years ago. I've had this milestone on my mind, as my elder son recently turned 18 as well. In Australia, Spring would be able to drink and vote, which made me wonder what Spring would say over a beer.

You may also like: Spring and Spring Boot Frameworks: A Brief History

My full talk is here, but I'll summarize some of the lessons.

Lesson One: Fairy tales can offer wisdom
I almost subtitled my first book, "The Emperor's New Clothes," because I'd begun to realize that early 2000s conventional wisdom, as codified in J2EE, was pure fantasy. It's essential to question what's in fashion and make your own decisions. The industry learned from the follies of early enterprise Java, but there are always new frontiers for excessive, indefensible complexity. The lesson: Fairy tales can be useful unless they're sold at the golf course

Lesson Two: The Need for Clear, Shared Values
Spring was successful and progressed so rapidly partly because it was based on the ideas expressed in that book, which the first generations of committers and users signed up to.

Shared values are important. These values should be controversial, and they should distinguish your effort from the world at large. What will it add that's unique? Everyone loves kittens.

Lesson Three: Know Where You're Going
Values describe how you do things. Vision defines where you go. Spring's mission was big — to radically simplify enterprise Java, stand up to the prominent vendors, and innovate in open source. We stuck to it!

Having the clarity of vision to know where we were going was instrumental in our successful execution.

Lesson Four: Quality Beats Quantity in a Team
It takes a village to produce and release a successful piece of software, not a city. Spring's core has always had a great team, not a large team. This is something it has in common with many other critical pieces of infrastructure software.

This exceptional group of contributors made Spring's success possible. Spring is unusual among open-source projects in that its developers have the same skill set as its users, which facilitated fresh talent joining over time. Most notable was, and remains, Jürgen Hoeller. His contribution has been such that he has earnt his verb. To "juergenize" a piece of code is to take it to a level of polish and robustness that most of us seldom reach so that its original author recognizes that this is what their code wanted to be.

Lesson Five: Market and Sell Your Technical Solution
The village is necessary but not sufficient. To reach a higher level of quality and impact a larger audience, you need a community. In open-source, we know what "community" means. However, the same concept is equally valid inside an organization. In any context, it isn't enough to build a great technical solution. You need to market it to bring more folks on board, who will contribute in different ways.

A community needs a healthy environment in which to grow. We built the Spring community by defining and modeling our principles: respectful and inclusive engagement with others. That meant, for example, being patient and helpful when people would ask questions in the forums. By modeling that behavior, others in the community would jump in and exhibit those same qualities

Lesson Six: Other People Have Great Ideas. Borrow Them, but Acknowledge Their Work
No project or group has a monopoly on good ideas. When we saw worthwhile ideas coming out of other projects like PicoContainer and Rails, we borrowed some of them. As functional members of the broader developer community, we always made it a point to acknowledge the originators of those ideas.

Lesson Seven: The Developers You Want Need Autonomy
Spring originated from my experience across many early J2EE projects, including seeing many in-house frameworks. All were created by architects in order to constrain developers. All failed. Spring had a different philosophy: Make the right thing easy to do. Don't constrain developers: empower them to do the right thing more efficiently.

Respecting developer autonomy proved a key element of Spring's success.

Lesson Eight: Question the "Enterprise" Mindset
There is a time and place for architectural complexity, but most applications don't benefit from a traditional "enterprise" philosophy. At its height, Rails showed that thinking of software as potentially throwaway led to faster application development. In the new world of microservices, this is especially true — developers need to be able to create and iterate quickly. Java developers today have largely thrown off the old enterprise mindset, and, along with Spring Boot, it's resulted in a productivity breakthrough.

Lesson Nine: Some Spring Advice
How would I use Spring today?

Do use Spring Boot if you're not already doing so.

Don't fight the Spring way. It is proven, tested, well-documented, and searchable on Stack Overflow.

How Spring approaches every problem isn't right for all users, but it's always worth considering first. If I were writing a Spring app today, I would strongly consider Kotlin. It brings the same kind of simplification to Java code as Spring did to J2EE.

Lesson Ten: Raising Software is Like Raising a Child
Thinking about raising a software project like raising a child turned out to be useful. Start with clear values, nurture it, prefer the carrot to the stick, and eventually, it will become independent and go onto bigger things.

Have questions for me about the eighteen year Spring journey? Reach out on twitter.

Further Reading

Spring and Spring Boot Frameworks: A Brief History

An Introduction to Spring

Put a Spring in Your Step: Spring Framework Tutorials