I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry project. Pivotal employs many members of the Spring team. I am not speaking for either Sp

I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry project. Pivotal employs many members of the Spring team. I am not speaking for either Spring or Pivotal. Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...). I'm personally only familiar with Spring. And by "familiar" I mean I've learnt enough to be dangerous. But I've also learned to ask, before doing something: "Have the Spring team already solved this?" Take, for example, retrying an operation. A slightly hacky way to achieve this is to nest try-catches. A slightly less hacky way is some sort of loop. Then we extract this functionality out. I dunno, lambdas maybe? Or: I could use Spring-Retry[0]. That's just one example from my own experience. It used to be that Java EE was it. And it had to be: the mega-buyers insisted that there were sufficiently rigorous standards that they could switch vendors. Every giant corporation bleeds gold to some ancient vendor and they have an immune reaction, nearly a spasm allergy, to vendor lockin[1]. Opensource tools kinda sail around this, because ... uh ... what vendor lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's opensource. You can wait for community action, or engage a consultancy, or a related product company, or hire specialists, or sponsor something ... you have a wider range of options. Oh sure, there's tech lockin, but that's true of any decision. Either you exploit the features of a platform and tie yourself to it, or you write a rubber-room abstraction layer and tie yourself to that instead, but at your expense. In my observation as a 1st? 2nd? party, the Spring team pay close attention to the standards and support them. And, not coincidentally, many standards look -- gee, just awfully similar to something Spring had road-tested a few years prior. I think a lot of the shade thrown in this debate is happening because of money. Pivotal backs Spring very strongly, because it helps to sell our version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry). Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as well as being the stewards of the Java EE standards process. Red Hat own a solid suite of Java EE-capable and platform products, a portfolio largely overlapping with Pivotal's, IBM's and SAP's. In each of these cases there's a zero-ish sum-ish game underway. A company that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle (RIP your chequebook) isn't going to buy much from Pivotal. Meanwhile, the Spring team are just writing software. I lurk some of their internal Slack channels. It's almost exclusively technical and usually very thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a very different example of how to develop high-quality software. [0] https://github.com/spring-projects/spring-retry https://github.com/spring-projects/spring-retry [1] You will often find companies accusing each other this.