Mike, I’m pretty sure you didn’t answer my question.
Mark, As I said in my email I cannot provide legal advice or
interpretation of the Eclipse Foundation Antitrust Policy.
On 2022-11-14 10:01 a.m., Mark Little
wrote:
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
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
_______________________________________________
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
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
