How about https://en.wikipedia.org/wiki/Vert.x - this began life as a VMWare project, but after Tim Fox left for JBoss it was very much competing with the Reactive stack at Spring. VMWare even tried to take it back, but eventually it also ended up as an Eclipse Project ;-) Werner 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.
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. - 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, 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
|
