Don't default fork MP into Jakarta EE

There should be no default rule for the relationship between Jakarta EE and MicroProfile because each MicroProfile specification is often driven by a mix of different developers, vendors and communities who may not want their efforts forked. To ignore them is tantamount to a hostile take-over. The Jakarta EE communities should work with them and try to persuade them to see their point of view. However, if the MP spec community cannot be persuaded then I caution continuing with a fork. Embed and try to work together because the MP spec should still be usable within Jakarta EE. And working with the original community is a far better path to future success than trying to split efforts - anyone remember Hudson these days?

If no way to collaborate can be found, including simply embedding that spec into Jakarta EE, then I'd suggest that there is something fundamentally wrong with that specific MP community or those in Jakarta EE. I really can't see this ever happening though so it's not worth further consideration.

Then there's the notion of changing the namespace of a MP specification if it is "imported". Well I also don't think that should be a hard and fast rule either. It should be something that is worked out between the MP specification in question and the Jakarta EE community. It should also not be a reason to reject importing and collaborating with the MP community and defaulting to a hostile-like fork.

And that brings me to the final question: where does work on the MP specification continue, assuming it does need to continue? Well guess what? I think that's up to the MP spec community since they are the founders of their work and their future destiny. If they feel that innovation should shift entirely to Jakarta EE then go for it, with all of my support. But likewise, if they feel innovation should continue in MP and maybe they are a part of the corresponding Jakarta EE community they work to pull updates across when it makes sense. A great collaboration.