| Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration. |
With all due respect, it is clear we value different things. The things you suggest are unimportant are actually the things why some of us choose something like Java EE or Jakarta EE in the first place. The fact that MicroProfile does not have a vendor neutral working group, does not follow a well defined, structured process, the decisions seem be dominated by a narrow set of vendor commiters, has a weaker sense of compatibility, etc are very big defferences indeed. Indeed MicroProfile does not even aim to be an open standard whereas that is a central goal for Jakarta EE. That all said, these very things are what also makes MicroProfile valuable as a separate effort focused on meeting market demands faster through rapid innovation. I think it is also important to appreciate how important a sense of cohesion, both from a platform and ecosystem perspective is. Many of us choose the Jakarta EE model because we want to feel the APIs are are using are well integrated and uniform, following a well understood set of sensible norms from a common, trusted source. Again, if those were not preferences it makes little sense to use this technology set in the first place. With regards to your point with regards to API divergence, I think we can all agree at this point it is a necessary evil. Indeed that is a challenge more or less all standardization attempts or even software in general needs to address. Once the initial fork/standardization is done, there will be some need for further evolution. If the idea being standardized is mature enough, this should not be any more a challenge than it is for any other technology in Jakarta EE that also has non-standard alternatives in the market or even non-standard features in compatible implementations. With regards to Jakarta embracing innovation, I fully agree but even there I suspect we have very different values. Jakarta should remain a conservative open standard while allowing for the concept of standardization pipeline domains/projects of which MicroProfile could be one. Hope that provides perspective. We don't have to agree, but I do think it is important to recognize crucial differences in perspective. 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: Jason Greene <jason.greene@xxxxxxxxxx> Date: 4/6/20 11:00 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. > On Apr 6, 2020, at 9:05 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote: > > From what I can tell, most people are seeing this as a last resort. I certainly do. > > For the folks I talk to, standardization is definitely a very important consideration. Indeed the desire to utilize a credible open standard I don’t see much of a difference here: both are open source Eclipse Foundation projects, both are certainly “credible" > (with everything that means such as cohesion, Both define integration of technologies > vendor neutrality, Ownership for both is under the EF which is by definition vendor neutral > governance, There are slight differences in governance but it still mostly amounts fo Eclipse rules (e.g. contributors vote). > process, They also seem to have similar processes as best as I can tell. > compatibility, stability, backwards compatibility) Now we hit an actual difference. The goals for the specs under MP are to evolve rapidly, to prioritize innovation over never-ending compatibility. The big problem with using forking to achieve never-ending compatibly is that you can’t ever resync the fork, it is forever different and will forever lag behind the version that is still moving forward. Historically pruning takes years, so you are talking about pushing an outdated technology on users (which many will soon abandon) and then vendors will be stuck shipping it anyway just to pass the TCK. In any case, the need to evolve and the problems that it introduces won’t go away after you fork everything into EE. In fact I would expect the best way you would solve it would be to create a new platform within Jakarta that prioritizes innovation much in the same way as MP does. -Jason _______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community |