Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Ja

[Reza Rahman <reza_rahman@xxxxxxxxx>]

Thanks Scott for being forthcoming about this. To be honest it is not really a surprise as this is what I thought was the basic gist of a rather intriguing blog entry from Mark Little. I hope you can believe I have tested this hypothesis again and again many times since then using as many avenues as I can including the day job and beyond. The reason I have done so is because I definitely still don't think it is a completely illegitimate idea. Here are the basic reasons unfortunately this hypothesis really fails for me and why I see this as a very high risk strategy and one that is probably unnecessary.

* Comparatively speaking, MicroProfile continues to be a weaker brand as compared with Jakarta EE. This is despite essentially having a 3+ year marketing monopoly over Java EE and Jakarta EE. Beyond all of the customers I have talked to over these years, here is the public experiments I can point you to that is all but completely blunt: https://twitter.com/reza_rahman/status/1225968973843456000, https://twitter.com/reza_rahman/status/1164178227570626560, https://twitter.com/reza_rahman/status/1124499308970004480. There are more of these sorts of experiments I have in my pipeline that I hope won't alienate anyone as perhaps they will have an understanding of what I am actually trying to do.

* Basing a core, long-term, open standard on the concept of microservices (e.g. having a name like "MicroProfile") is very high risk as microservices themselves may not stand the test of time in the next five years or even past a serious economic recession when IT belt tightening inevitably happens. I think you likely know Thougthworks has essentially stated microservices may never enter the mainstream. In the blogosphere, there is an increasingly bold anti-microservices ethos. Lastly and most importantly this ethos is actually being realized in real world IT.

* There are a few cohorts of "Java EE" customers. There is a fairly sizable community that still hold faith in Jakarta EE for all the right reasons. These folks are rightfully vocal and passionate. There is a larger cohort now that is nervous and watching closely as to what is going on with Jakarta EE. There is yet another cohort that is actively moving away from Java EE. The problem with the strategy you are proposing is that it will inevitably create shock waves. The problems with shock waves is that their outcome is highly unpredictable. One outcome could be a successful transition to MicroProfile. Another equally probable outcome is that users many not view this transition so charitably and basically decide such a volatile and uncertain technology set is simply not for them and they need to seek out a more stable one that isn't asking them to make a giant leap of faith.

What I have been suggesting all along is a more conservative strategy that hedges your bets and does not require a huge roll of the dice. MicroProfile can continue on it's trajectory and still standardize some pretty conservative features into Jakarta EE to keep it fresh and relevant. Jakarta EE can continue to gradually evolve meeting the needs of its own user cohort on it's own right. In addition, Jakarta EE can be evolved so that it is more consumable by MicroProfile. If things really go the way you may be thinking, users will move over to MicroProfile on their own without causing massive shock waves and taking big, undue risks. I would also advise against positioning MicroProfile as an open standard. It is not really intellectually honest and most smart people in IT will see though it.

None of this is of course black and white. I do hope though that you carefully consider this viewpoint in addition to the ones of your colleagues at Red Hat. Again, I appreciate your having this discussion out in the open. Rational strategy one can talk about with some sanity. Raw emotions unfortunately are much harder to maneuver around and get sane outcomes.

I do hope others will chime in on some of this and hopefully you and Red Hat will gain important perspectives out of the dialog that you might otherwise miss.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On 4/6/2020 8:23 PM, Scott Stark wrote:

Yes, but I don't see why viewing MP and JEE as two extremes aspect of an ecosystem that is composed of many legacy customers unwilling to move off their monoliths to cloud native focused incremental or new development based on microservices does not cause doubts with regard to how to best handle these customers. So, here is a thought bomb.

Jakarta EE 10 would be the first opportunity to create a significant revision to the platform. There have been discussions about what should be updated in the platform along with what should be further deprecated. An idea that Red Hat has started to consider is one where EE 10 switches to a core platform that is based on MicroProfile and updates of its Jakarta EE dependencies. These APIs would be the only ones that would be updated and expanded going forward.

The remaining APIs would form a legacy profile to support existing Jakarta EE 8 and earlier customers who want support for their existing applications, but do not want to be forced to move. 

There are many details that would need to be worked out including support for JPMS, how Jakarta EE 8 / Java EE 8 support fit into the legacy profile, tooling, interaction of the MicroProfile and Jakarta projects, and finally, what APIs need to be updated and what those updates should look like.

On Mon, Apr 6, 2020 at 11:22 AM reza_rahman <reza_rahman@xxxxxxxxx> wrote:

My apologies Scott. I certainly do not mean to limit legitimate dialog. I hope it is also clear I really do wish the best for everyone involved certainly including MicroProfile. At some point though one does need to ask themselves what they really see as meeting the needs of an ecosystem and what really will work in the long and short term.

It certainly does not mean I have to be right. Indeed I am honestly hoping on some of this I am wrong and things are not as saddening as they seem at the moment. I really want to see this fundamental concept and ecosystem to stand the test of time. It is very hard for me to take a position that I genuinely think will put those things at risk. I don't want to see the Sony vs Betamax battle play out in the Java open standards space if I can help it. I think such a battle will cause a lot of harm and very little good for most.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Scott Stark <sstark@xxxxxxxxxx>

Date: 4/6/20 11:34 AM (GMT-05:00)

To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>

Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration   as Jakarta Configuration.

Then you really are not giving me anything to work with. You are
clearly a Jakarta only viewpoint and that explains why a fork is the
only thing that makes sense.

On Mon, Apr 6, 2020 at 10:15 AM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>
> To be honest, what you are suggesting is even more worrisome. What it implies is that there will be two standardization models in enterprise Java that are highly duplicative and basically competing. That will hardly reduce the fragmentation, confusion and divisiveness. That is why many of us would like to see Jakarta become the unifying standardization model.
>
> I would say this is all the more reason to fork and standardize right now.
>
> Reza Rahman
> Jakarta EE Ambassador, Author, Speaker, Blogger
>
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community