> This is the most sickening sentence for me.

it's three sentences you quoted.

imo this is a quite harsh & pointed take you have presented. you seem to focus on some very-nearby headline sentences that do focus on performance, where-as the real story is much more interesting & the tech much more promising.

> blatant exploitation that’s occurring as there is too much centralised ownership

what makes you think this is so lopsided? yes, the spdy drafts released in 2012 originated from google. and google spent enormous amounts of effort, time & money championing & supporting development of QUIC as it made it's way through the IETF, where other non-Google engineers also worked to improve HTTP and build a powerful new transport protocol that shows enormous progress & is opening doors.

where is the exploitation?

> The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’

actually they made two standards. this is much better than where we were. with http2, we had built a true monster of a specification, untame-able. for good reason! we wanted good things! but the http2 spec was trying to shoe-horn a bunch of streams inside tcp, a streaming transport protocol, and that never quite fit (head of line blocking problems resulted), but just as bad, it made http2 a massive work that was hard to evolve & grow & reuse & enhance.

they took an extremely broad view, & said, these pieces don't belong together. they delegated responsibility into component pieces. they made pieces re-usable.

the result is that there are now a couple dozen efforts related to improve the underlying QUIC transport for lots of interesting use cases. the QUIC working group lists a couple dozen efforts[1] & enhancements, such as multi-path, load-balancing tuning, multicast, ack controls, satcom capabilities, & webtransport, a potential radical simplification & rework of websockets in a more connection-friendly manner. this is all work being done outside of http, being done with quic, because of these advances by these very careful, considerate, thoughtful, aware engineers, & their willingness to work with other engineers & the IETF to figure out how best to improve things, how best to decouple http2's transport protocol from it's application protocols.

> In my opinion this is predatory behaviour packaged up as open source good for all

i would very much like to hear some of what you feel or think any of your numerous very heavy accusations are due or deserved. using acerbaic words like "most sickening sentence", "myopic internal focus", & "blatant explotation" are big big words, big angry moods, and it's really uncomfortable, really hard for me to process & deal with such emotional turmoil directed at something that seems so innocent & like such a natural refinement & progression over the very good solid ideas & improvement that were http2, as it tried to move on & progress beyond http1.1 pipelineing, which everyone wanted very much wanted & in many cases did give up on.

so why do you hold your opinion? it really hurt me to hear your opinion, stated so pointedly, at such a lot of work that so many engineers all over the industry have contributed to & worked hard on. is this new dissent you have? are there other anti-http3 anti-quic folks who have staked some of their problems & claims & issues, or who have other ways they want the community to work through standards & specifications to improve the internet? what are the issues here, what's wrong? i for one thank my lucky stars that there are corporate patrons paying engineers good money to improve the world with works like this, to do the logical & consistent task of breaking http2 into it's transport (quic) and application (http3) protocols, improving the speed & reliability of the net.

thank you Google & IETF for doing all sorts of good for us all, imo.

[1] https://datatracker.ietf.org/wg/quic/documents/

there's a lot here beyond performance. i encourage you to investigate a little further & to see what quic + http3 bring & how they emerged from http2. that there is some performance win is good, but don't let that one statement narrow down your own understanding of this important enhancement.

the best evidence i can point to is a quic look at the IETF work group's active & related documents[1]

[1] https://datatracker.ietf.org/wg/quic/documents/