[microprofile-wg] MicroProfile and Jakarta EE, Surviving Failure with Hi

[David Blevins <dblevins@xxxxxxxxxxxxx>]

We would vote to continue MicroProfile as a Working Group.  We see Jakarta EE and MicroProfile as one ecosystem and advantages to us all in maintaining both.  Both to increase our chances of success overall while diminishing our risks of repeat failure and 7-year setback experienced with Java EE.

We see the proposal similar to going from microservices back to a monolith, or a highly available system back to a single large server.


GROWING UP TIED TO A FAILED TECHNOLOGY

We all lived through the failure of Java EE.  From the moment it started failing in 2014 to the first release of Jakarta EE with any new functionality (EE 9.1) it was roughly 7 years.

We publicly launched Tomitribe in 2014 and those were the first 7 years of existence.  A company tied to Java EE, born at the worst point in Java EE history.  We did not have an already successful business to lean on to coast through a rough patch. We had to grow or die in that environment.  We were not the only ones.  So like the generation that lived through the Great Depression, perhaps I am permanently changed.  The difference between having gone through the pandemic and having grown up in the pandemic.  Too disconnected from those who didn't grow up in that environment.

If anyone has the attention span, I have assembled some comprehensive thoughts below.  I respect other's differing views on this topic and want you to know I have many of the same thoughts.  My desire in writing this is to be understood more than change minds.  Just like with the pandemic, everyone experienced it differently and that is ok and understood.


IMPACT OF JAVA EE DEATH

First point is what was the impact on our collective opportunity for Java EE in the industry due to our 7 year gap in delivering new functionality?

- Spring Boot became the de facto Java standard for new applications, accelerating developer adoption with zero friction and an opinionated, batteries-included model.
• Docker and Kubernetes redefined deployment models, but Java EE’s stagnation left it unable to evolve, while lighter stacks (Spring Boot, Node.js, Go) integrated seamlessly.
• JavaScript/TypeScript dominated the full stack, with Node.js rising on the backend and frameworks like React taking over front-end development, pulling entire teams into different ecosystems.
• Python and Go exploded in popularity, powering APIs, automation, cloud tooling, and serverless — areas where Java EE had no presence and minimal evolution.
• Serverless platforms (AWS Lambda, etc.) marginalized Java EE, as slow startup and heavy memory usage made traditional Java EE runtimes a poor fit compared to lightweight alternatives.


HOW DID IT HAPPEN?

- Participation steadily declined until collapse: Over time, fewer implementations were certified, vendors stopped proposing new features, and their role shifted to blocking changes rather than driving innovation. As contributors dropped away, the ecosystem was hollowed out until only Oracle and a few individuals remained.  Vendors who find themselves the only contributor tend to stop their investment out of valid concerns of subsidizing their competitors.  When Oracle also withdrew, Java EE reached complete failure.

- Cost of participation discouraged engagement: Access to key decision-making in private groups required significant financial commitments. Sensitivity over these costs discouraged existing vendors from continuing, and raised the barrier to entry for new implementations, accelerating the decline in participation.

- Brand damage: Since the early 2000s, frameworks like Spring aggressively positioned themselves against Java EE, painting it as large, bloated, legacy, slow to start, slow to evolve, and overly complex. The lasting reputational damage diminished adoption, and accelerated the shift away from the platform.


ONE ECOSYSTEM

How are Jakarta EE and MicroProfile united:

- Both under the governance of the Eclipse Foundation

- Nearly all vendors participate in both Jakarta EE and MicroProfile

- Nearly all Jakarta EE implementations also implement MicroProfile

- MicroProfile directly depends on Jakarta EE

So in practice there is no significant division in community or technically.  The differences that remain are the working group and brand. 

- Jakarta EE requires a $1M budget, costs $300k for the largest vendors to participate at the greatest level of influence, and the committees are closed to the public.

- MicroProfile requires a $50k budget, costs $25k for the largest vendors to participate at the greatest level of influence, and the committees are open to the public.

There are distinct advantages to each.  


SURVIVING ANY FUTURE FAILURE

How can maintaining both better enable us to survive another 20 or 30 years without setbacks from a failure similar to Java EE?

- High availability: Damage to any one brand enables us to shift to the other.  Decline in one does not guarantee decline in the other.  Cost sensitivity can be mitigated.  Governance issues can shift participation to one or the other for periods of time without losing people entirely.

- Governance A/B testing:  We can try wildly different governance models and processes in one without risk of destroying our ecosystem as a whole.  Reduces friction to trying out new processes and can help us continuously test heavy vs light processes, compare and abandon process that don't bring us the best results compared to their cost.

- Delivering to opposing market segments:  Frequently trends emerge that directly oppose existing norms.  With two brands we have increased agility to tackle both segments with the least confusion.

- Canary in the coal mine.  Failure or stagnation in one can be an early indication of issues that may affect the other in a future date.  An early warning enables more time for potential corrective measures before a total failure.

We had a monolith that failed catastrophically.  We fixed that and not only got the first system, but a redundant system to mitigate that failure.  This redundancy comes cheap, less than 5% the cost of our main system.  Between both we're poised to weather almost any storm the industry can throw at us.

Our chances of total failure are greatly diminished unlikely to be a 7-year impact if they occur at all.


SHARED VISION REQUIRED

With my Industry Architect hat on, I think we've achieved something very critical.  We're setup to win.  This of course only works if:

- We see them as one system.

- We want both to win.

- We are in synch on strategy

I definitely see them as one, want both to win (who doesn't want more ways to win) and for us to be ok strategizing together.  It is clear this is where we have the most challenges, however.


PERHAPS TOO ADVANCED

It is an advanced strategy with some overhead.  Possibly beyond our skill and vision to actually pull off.  While I would be willing to give it another 5 years of effort, it's clear others are not.  This strategy requires a majority to pull off.

If others want to throw in the towel now, I don't fault you.  I just think it's a shame.  I like to play games till I beat them vs just skipping the hard parts.  But I get it.  We will vote -1 and will not interpret those who vote +1 as "not getting it", "bad" or "enemies."  We're still all one team.


IF WE RE-MONOLITH, LET'S DO IT FULLY

If we do move MicroProfile into Jakarta EE, I would want it fully absorbed including a namespace change to jakarta.  My interest in MicroProfile is not emotional but strategic as detailed above.  If we're going back to the monolith, let's do it right and not make our lives harder.



-- 
David Blevins
http://x.com/dblevins
https://bsky.app/dblevins
http://www.tomitribe.com