| Mike, did you choose to follow up to my email with that reminder because of something within my email or was that just random chance? If the former then please point out what caused you concern.
Mark. Sent from my iPhone On 14 Nov 2022, at 14:53, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
All,
As a general reminder, both MicroProfile and Jakarta EE are
consortia of Eclipse Foundation Members which must comply with the
Eclipse
Foundation Antitrust Policy. Although membership in the two
groups overlap significantly, they are not identical and must be
treated as two separate organizations. It the strict policy of the
Eclipse Foundation to permit competing projects, and that extends
to specifications as well. We will never endorse the allocation of
a market to one coalition of vendors over another set of vendors.
I will be instructing staff to put a review of the Antitrust
Policy on the agenda of upcoming steering committee meetings of
both MicroProfile and Jakarta EE. I do think that would be helpful
for everyone. To help set the stage for those discussion, the
Eclipse Foundation cannot give any member legal advice or
interpretation. We can (and will) describe the policy, but it is
up to each member to seek its own legal counsel on compliance with
that policy. I encourage all to do so.
Thanks.
On 2022-11-14 4:45 a.m., Mark Little
wrote:
Hi Ondro,
I think collaboration is definitely the right way to
go. However, our definition of collaboration seems to differ.
Let’s start by looking at what the dictionary may say about
“collaboration”:
- [uncountable, countable] the act of
working with another person or group of people to create
or produce something
Seems pretty clear. Now what about compete?
compete
[ kuhm-peet ]
verb (used without object), com·pet·ed, com·pet·ing.
to strive to outdo another for acknowledgment, a
prize, supremacy, profit, etc.; engage in a contest;
Again, pretty simple, I think you’d agree.
Now let’s try to apply this to our situation and
maybe Red Hat is alone in this regard (I suspect not, but I
don’t want to put words in the mouths of other
people/organisations): within MicroProfile we’re working to
define “standards” that abstract away implementation details
of specific underlying approaches to achieve the same task,
with a focus on microservices. We’ve made the conscious
decision to do that work within the Eclipse MicroProfile
community. Not within Jakarta EE. Not within the Apache
Software Foundation. Not within CNCF. We chose within the
Eclipse Foundation and MicroProfile specifically. I don’t see
moving of functionality and effort from MicroProfile to
Jakarta EE as collaborative at all. It’s not the act of one
community working with another community to create something
for the benefit of users. Now I’m sure it’s not the intention
of people on the Jakarta side to appear to be striving to
outdo MicroProfile as per the definition of “compete” so
perhaps that’s not the right word but it’s certainly not
“collaborative”.
Over the years as open source has evolved there
have been a number of examples of collaboration and
competition (forking, typically). I’ll throw out a few but
these are just examples:
- Knative Eventing, which enables Apache Kafka as
an implementation - collaboration;
- Hudson and Jenkins - competition;
- Linux - that’s an interesting mix of
collaboration upstream and competition downstream;
- Netty - this began life as a JBoss project but
we span it out when Trustin Lee left in order to have a single
upstream community for cross-vendor/cross-group collaboration;
With the exception of one of these (exercise left
to the reader), they show communities, individuals and vendors
coming together to work across various projects or within one
project. They’re successful not because one group decided to
fork and rename the work of another community but because the
recognised that communities can leverage the work of each
other without having to rename, rebadge or change.
If we look at standards there are some similar
examples. I’m sure many of the people on this list know about
SOAP-based Web Services. Some of you may have developed
solutions using them. Some of you may have been involved in
the development of some of those standards and in which case
you may recall that back in the early 2000s standards efforts
tended to be split between OASIS and W3C due to competition
between the vendors. Again, some examples of collaboration and
competition:
- WS-Addressing from the W3C - collaboration.
Fortunately the vendors at the time recognised that they
really needed to standardise on a single addressing mechanism
rather than two or more and WS-Addressing became it. All other
WS-* specifications adopted it regardless of the makeup of
vendors working on them or the standards organisation within
which that other effort may reside. Specifically we ended up
with many WS-* specifications within OASIS using WS-Addressing
from within W3C and they DID NOT rename it, or fork it;
- WS-Reliability and WS-Reliable Messaging -
competition. Both attempted to solve the same problem and
eventually, due to a number of reasons not least of which was
confusion for end users, WS-RM became the agreed standard.
In conclusion, I agree with you that collaboration
should be the way for these two groups to function. However,
collaboration in my view means using specifications as they
are defined in each group and not copying/forking.
Mark.
I would also like to understand whether we
want MicroProfile and Jakarta EE to collaborate or
compete. I hope we all want them to collaborate, it's
just not clear to me what some people understand as
collaboration.
For me:
- Moving functionality or even whole
specs between MicroProfile and Jakarta EE ->
collaboration
- Duplicating functionality ->
competition
- Forcing one or the other to consume
specs from the other -> competition
I think the last point above is what is
causing all the controversy and disputes in this
thread. I believe that collaboration should be
voluntary, not enforced. And therefore it's not
collaborative to prohibit Jakarta Security to
implement support for JWT, if the Security team
wants to do so and even planned to do so even before
MP JWT existed. And we all know that Jakarta EE
cannot depend on MicroProfile specs, for various
reasons already discussed elsewhere. It's simply not
an option even though it may seem logical.
For me, collaborative means that both MP
and EE try to find a solution that is suitable for
both. I see one such solution, which I already
mentioned:
- JWT support is added to Jakarta
Security, ideally with some support and feedback
from the MP JWT team
- Jakarta Security creates a Lite
profile (with just JWT, or maybe some other
things suitable for MicroProfile)
- MicroProfile can then replace MP JWT
with Jakarta Security Lite to unify the API, but
doesn't have to, if EE Security Lite spec isn't
(yet) good enough to replace MP JWT.
MicroProfile would certainly be consulted before
EE Security Lite is added to EE Core Profile.
All steps here are voluntary and don't require that
both MicroProfile and Jakarta EE agree on anything.
But with this approach, there are also a lot of
options how MP and EE can collaborate to improve the
final solution for both.
Or am I wrong in how I understand
collaboration vs. competition?
All
the best,
Ondro Mihalyi
Director, Jakarta EE expert
Omnifish OÜ, Narva mnt
5, 10117 Tallinn, Estonia | VAT: EE102487932
Well said, David. I
know I feel the same way and before I ask Red Hat
engineering to do further work in Jakarta or
MicroProfile I want to know whether it's under a
collaborative or competitive basis as that will impact
where we do such work, if at all.
Sent from my iPhone
> On 10 Nov 2022, at 20:02, David Blevins <dblevins@xxxxxxxxxxxxx>
wrote:
>
>
>> On Nov 10, 2022, at 11:09 AM, Mike
Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
>> Good points. There are indeed non-technical
differentiators between MircoProfile and Jakarta EE.
No one would dispute that.
>>
>> But since we are discussing important
philosophical points, let us add the fact that the
Eclipse Foundation has always and will always permit
competing projects, and that extends to specifications
as well. We will never endorse the allocation of a
market to one coalition of vendors over another set of
vendors. So just because MicroProfile has a
specification in a particular domain in no way
prevents Jakarta EE from creating a similar spec. That
work may or may not be based on prior work done at
MicroProfile, so "move" doesn't really factor into the
discussion.
>>
>> As you point out, there are important
non-technical differences between the two. Any one of
those could be a good reason why Jakarta EE may wish
to have its own specifications which overlap or
compete with MicroProfile specs. In other words,
there can be a myriad of reasons why competing specs
may occur: business, technical, community, vendor
support, etc etc. But "MicroProfile did it first" does
not provide it with any sort of veto.
>>
>
> I think these are all very fair points and it's
healthy to remind people and have that conversation.
>
> I think it really comes down to if we want to
continue to ensure both can live in the same box as
many of us have been doing. If we think that's
important, then there are some values we would need to
maintain.
>
> If we don't want that and do want them to
compete, then it might be better for us to explicitly
decide that so everyone is fully aware and can plan
accordingly.
>
> Given the status quo has been they co-exist in
the same box and don't compete, I'd greatly prefer an
explicit decision that they will now compete vs slowly
making them compete one spec at a time with no
explicit conversation or decision that the two will
now compete.
>
> Now, I certainly don't always get what I want,
but I find if I do my best to make myself at least
understood I tend to feel a lot better about the
outcome when things don't go my way.
>
> My $0.02
>
>
> -David
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Mike Milinkovich
Executive Director | Eclipse Foundation AISBL
Twitter:@mmilinkov
|
