Steve,
I actually think that the difference between the US and the EU is a lot smaller than you think. I talk to a lot of large European companies and their viewpoints are almost identical to their US peers. Don’t forget that all technology companies have to operate on a worldwide basis. Mike Milinkovich (m) +1.613.220.3223
I would guess the reason that the Eclipse Foundation is uncomfortable about MP not using a standards process is likely to be patents, in particular declared patent grants from the organisations creating
the MP apis to those that wish to create independent implementation of those APIs.
As a European, where software patents aren’t really a thing, I tend to find if it is weird it is always about software patents.
IANAL
Steve
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Richard Monson-Haefel
Sent: 03 January 2019 14:56
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] MicroProfile TCK Process
Personally, I prefer a standards process to work on but I'm also aware of MP's unique process and its results. I think preserving that is far more important than bringing it under the umbrella of a formal standards process.
As for your characterization of "Hip and Agile": I think you are projecting here. No one is attempting to say that MP is superior; only that it is different and need not follow the same path as Jakarta EE. I believe that the industry
benefits from both approaches.
Sorry if I sound a bit sarcastic, but the whole “We’re so Hip and Agile, and Java/Jakarta EE is so slow and last century” is not productive at all either.
Werner
Sent from
Mail for Windows 10
Jakarta EE will probably never be as agile as MP, because it has a formal standardization process. You can't have your cake and eat it too. You can't be agile
and have a formal standardization process.
We can certainly be faster than the old system because we don't have a proprietary organization delaying or derailing standardization efforts. Oracle stopped
advancing Java EE because it had different market goals. That's fair. They can choose to do whatever they want. With Jakarta EE, there will be less influenced by a single vendor. Java EE has been a standard for nearly 20 years and changing that now even
with a name change would undermine confidence in the platform (IMO).
MP, on the other hand, is new and has been running as an agile process since its beginning. Why change that? My question is: Why is it so essential that MP
adhere to the EFSP? Why is that required? The only one that can answer that, as far as I know, is Mike Mlinkovich who I've CCed on this email.
I don't want to decrease the agility of Jakarta EE, how can we change the EFSP to accomplish that? Otherwise, how will Jakarta EE break out of the slow release cycle
that Java EE was suffering?
I think you're mistaken about what needs to be done to appease Oracle.
If the key difference is that MP is "not a standard" and Jakarta EE is (will be) "a standard", and that's going to make Jakarta EE less agile and suffer a slow release cycle, well, maybe we don't want Jakarta EE to be "a standard". Maybe, as you suggest, we
should be satisfied if it just has wide-spread adoption. If that's good enough for MP, why is that not good enough for Jakarta EE?
Richard Monson-Haefel wrote on 12/20/18 11:37 PM:
Good question. The EFSP process is far more formal than what MP has now and I believe it would slow down MP's progress and decrease agility of that effort. You
could not have had as many releases as you have had with MP already if it was constrained by a formal specification process like the EFSP. That's not good considering the primary reason MP was created was to break out of the slow release cycle that Java EE
was suffering.
Jakarta EE has to have a formal spec process to appease Oracle and the millions of organizations that have relied on it being a standard. The MP doesn't carry
that baggage.
Becoming a standard is not a guarantee of success. Just look at Spring. No formal standards process acts as an umbrella to the project yet it's very popular.
Or look at DCE or CORBA, very formal process with lots of specifications and very little adoption. You could nit-pick those examples apart, but the general idea is that standards and wide-spread-adoption are not synonymous.
Why do you not want Jakarta EE to be independent and agile?
Richard Monson-Haefel wrote on 12/20/18 2:24 PM:
Mike,
You have alluded to this problem before - that MP will have to adopt the EFSP - but I don't recall you providing an explanation. That would probably go a long
way in helping folks like me understand why other projects suddenly have to adopt the EFSP. I'm all for it with Jakarta, but MP has been doing fine without a formal process and I would like to see it remain independent and agile. Sorry if this gets people's
knickers in a kerfuffle but its a valid point of view considering how little we know about your position on the subject.
On 2018-12-20 11:54 a.m., Richard Monson-Haefel wrote:
Given that the MP has not planned to adopt the EFSP, I wonder if Microprofile should move to a new host? It might be the best solution for all.
I don't find that to be a very constructive comment given that you haven't even heard what our concerns are. And the issues that we are seeing are not going to go away if it's hosted somewhere else. Success comes with greater responsibilities.
Plus, as Steve pointed out we already have an example of a MicroProfile spec entering the JCP process. So there is already an entirely community-led precedent to follow.
Perhaps we should down tools on the email and discuss this in real time in January.
On 2018-12-19 12:36 p.m., Scott Stark wrote:
We should be looking at elements of the MicroProfile process that seems to work and attempt to accommodate the possibility of MicroProfile using a future EFSP,
but I'm not convinced that it is a requirement, and potentially not even possible.
Scott, et al,
I guess I was being too subtle in my previous email on this thread. In our opinion, simply maintaining the status quo is not an option. Adoption of the EFSP by MicroProfile is a question of when, not if.
The existing specification process and licensing regime for MicroProfile is causing the Eclipse Foundation serious concerns. We do not feel that the status quo is an acceptable long term scenario. This is the result of both the success
in the industry that the specifications are achieving, and what we have learned as an institution as we created the EFSP.
Happy to explain more details on a call.
<image002.png>
|
![Avast logo]()
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
--
https://www.tomitribe.com/
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
|
