Hi Greg,
Being able to do whatever you want at the project level is completely useless if you're trying to build something that is supposed to be part of an umbrella project that has requirements for specs, approval, etc.
You might as well just create your own library/app/framework, and toss Jakarta EE to the wayside.
That's the point we're trying to make here.
Nobody is disputing the project level interaction. That will work the same way any FOSS project has ever worked (for a given idea of "any"). People will contribute, some will report issues, some will find fixes, some will advance the code, some will complete the docs.
That part will be organical enough. No issues there.
Yes, committers will have a lot of power at the project level, that's not being disputed.
But they'll have pretty much none when deciding which projects are actually worth being labeled as "Jakarta EE Ready/Compliant", or when defining what those compliance tests must be, what the specs must be for any tech within Jakarta EE, or even which technologies are wanted as part of Jakarta EE.
If you can have a few hundred people working on a project, organically, only for the big vendors to decide that they don't care for the tech that project covers? There you go, your project might as well be a third-party library that doesn't check any Jakarta specs compliance.
I don't want to throw any stones in any direction, but what would keep big paying companies from doing what Oracle did with Java EE, when the Java EE Guardians had to fight for a year for the community to be told what Oracle wanted out of Java EE (much less for them to continue working on it)?
Yes, now we don't have Oracle as the be-all end-all of the process, but the issue is still there, just a bit more diluted between multiple companies.