Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

developer.ibm.com

Post reply on HN
Print view View original

31–40 of 114 posts

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#31

Post by tracker1 »

ForHackernews wrote: post #21
Zafira wrote: post #16

Earlier quoted context omitted.

My understanding is that there is a faction in Google that believes that making Kubernetes freely available as it did was a massive strategic mistake on the part of Google[1], tantamount to giving away the crown jewels. With this in mind, my impression is that there is a strong suspicion that Google is trying to find a way to continue to control the direction and ability to monetize Istio (and future projects if this…

That's interesting because there's also a vocal contingent who believes Google giving away Kubernetes was a punji trap that the rest of the tech world has falling into. Is k8s an amazing force multiplier or an unmanageable white elephant? Can it be both?

It's a bit of both. In the end, I appreciate it and have been an advocate for the use of k8s. The harder part is actually hiring or developing in-house skills to manage the cluster(s). Not every company can afford a 6-7 figure consulting contract for a couple small clusters.

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#32

Post by tracker1 »

pjmlp wrote: post #29
polotics wrote: post #25

Earlier quoted context omitted.

K8s is a perfect weapon to drag internal IT Ops into the cloud: once good ops has been commoditized, then the economies of scale kick in and any non-enormous IT systems operator will eventually realize they can be a pure-play no-fixed-costs service provider. The only challenge is of course that good ops is not the same thing depending on scale, so hype is essential to bring the plebs into accepting maximal complexity…

Depends pretty much on the stack. With Java and .NET, or now serverless middleware, I never felt the need for something like k8s, as there were already solutions to deploy a bunch of EAR/WAR/DLLs into some cloud based server, including having cloud based DB servers like Amazon RDS. Taken to an extreme, I don't care where and how those packages are executing, k8, jails, containers, bare metal,...

I'm not sure I completely agree... or at least disagree to the extent that docker/containerization of applications is a huge boost to being able to deploy consistent applications.

The harder part is when there are byzantine libraries that tether deep into the OS. Often this is the case for some .Net on windows (and even with Java), mostly around commercial licensing models.

Spent the past two years pushing for getting (most) of the applications being worked on to at least be able to containerize and two major application developments are now targeting kubernetes for deployment. It's been uphill to say the least.

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#33

Post by tracker1 »

mehrdada wrote: post #8

For the uninformed, IBM is mostly in the business of selling expensive old-school consultancy solutions by marketing snake oil and packaging open source in proprietary label. Need evidence? Watch this cringeworthy video, for example: https://youtu.be/iNVM8vGCZjQ

While that is mostly true... they also have massive contributions to open-source.

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#34

Post by Macha »

maffydub wrote: post #20
deanCommie wrote: post #15

Earlier quoted context omitted.

While I generally believe in Google's altruism in their open source contributions, that good faith does not carry forward to any of their open source initiatives when it comes to Google Cloud. Maybe I'm cynical, but it seems pretty obvious to me that Google embraces OSS with Istio, Kubernetes, etc only out of necessity and being a distant 3rd in the Cloud race, and this is their attempt at some sort of differentiator…

I suspect Google felt they got burned with Kubernetes - doing a lot of the initial development, donating it to the CNCF and then not profiting much from it (e.g. still being distant 3rd in cloud).

To profit from cloud services at the level AWS/MS do, you need big customers, the long tail is just marketing that happens to make you some pocket money. To get big customers, Google's reputation for losing interest and moving into the next big shiny plays very hard against them.

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#35

Post by pjmlp »

tracker1 wrote: post #32
pjmlp wrote: post #29

Earlier quoted context omitted.

Depends pretty much on the stack. With Java and .NET, or now serverless middleware, I never felt the need for something like k8s, as there were already solutions to deploy a bunch of EAR/WAR/DLLs into some cloud based server, including having cloud based DB servers like Amazon RDS. Taken to an extreme, I don't care where and how those packages are executing, k8, jails, containers, bare metal,...

I'm not sure I completely agree... or at least disagree to the extent that docker/containerization of applications is a huge boost to being able to deploy consistent applications. The harder part is when there are byzantine libraries that tether deep into the OS. Often this is the case for some .Net on windows (and even with Java), mostly around commercial licensing models. Spent the past two years pushing for gettin…

I guess that in my case it helps that Java applications have been mostly application container based and the .NET libraries for such deployments are managed by IT's NuGET server with validated libraries.

The only ones that I have had such issues with OS integration were anyway in desktop context, which were deployed via VM snapshots, for access via RDS.

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#37

Post by ksec »

sg1234 wrote: post #24

Disclaimer: i work for Google Cloud and use istio daily. I don't think this matters to practitioners, it's a solution to fix trademark issues. Open Source Licenses (like Apache under which istio is released) doesn't solve the trademark (TM) issue, they are vague around this topic, so the use of the name/logo/mascot to release any sort of managed or supported solution based on an OSS tool becomes a hurdle, a lot of mo…

So Apache is sort of like BSD+Patents, are there any licenses that are BSD + Patents + Trademarks?

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#39

Post by fcantournet »

maffydub wrote: post #20
deanCommie wrote: post #15

Earlier quoted context omitted.

While I generally believe in Google's altruism in their open source contributions, that good faith does not carry forward to any of their open source initiatives when it comes to Google Cloud. Maybe I'm cynical, but it seems pretty obvious to me that Google embraces OSS with Istio, Kubernetes, etc only out of necessity and being a distant 3rd in the Cloud race, and this is their attempt at some sort of differentiator…

I suspect Google felt they got burned with Kubernetes - doing a lot of the initial development, donating it to the CNCF and then not profiting much from it (e.g. still being distant 3rd in cloud).

Google did profit massively from kubernetes, moreso than any other big company (Hello Red Hat lol)

It was (for better and for worse) the #1 reason to adopt GCP for our main cloud platform, and we're not alone.

It's has seen immense adoption that it wouldn't have had if it hadn't been in a neutral foundation. The work was definitely not done by Google alone (~30%).

IS GCP "still" #3 ? Yes. Is it because they didn't get a tighter grip on k8s and try to use it as a competitive advantage ? absolutely not. Nobody would have touched k8s with a 10 foot pole in that situation.

The strength of k8s is in its eco-system and that wouldn't have happened without the CNCF.

And I'm saying this as an early adopter of k8s, it's insane for the Google brass to see anything other than an immense success in the handling of k8s, at least from the perspective of how much money it made Google (indirectly)

It's not because of K8S strategy that GCP is #3. It's just because MS & AWS are better. PERIOD. Better at service, better at marketing, better at some product design sometimes, better at abusing their current dominant position (hehe it sucks doesn't Goog ? heh? Doesn't it ?)

Re: Why IBM doesn’t agree with Google’s Open Usage Commons for the Istio project

#40

Post by jka »

It looks like the Open Usage Commons organization handles trademarking, so roughly speaking (I'm not a lawyer) they set and enforce rules under which other entities may use their hosted project names and brand identities.

When GCP's container engine launched[1] in 2014 it was initially referred to by the anagram 'GKE' yet corresponded to the name 'Google Container Engine'.

After achieving CNCF certification in Nov 2017[2], GCP began using the term 'Kubernetes' within the product name, rebranding it as 'Google Kubernetes Engine'.

At least as far back as Oct 2017, members of the CNCF did not have to pay any fees[3] to participate in the conformance program.

Is it possible that executives within Google were unhappy about the marketshare gains of GKE and attribute this partially to the time it took their product to achieve certification?

If so, could that have led them to push other open source initiatives within the company to retain their trademarks under tighter control, even if that required creating an organization with less experience handling international trademark registration?

As per the post, IBM's stated standpoint is: "IBM continues to believe that the best way to manage key open source projects such as Istio is with true open governance, under the auspices of a reputable organization with a level playing field for all contributors, transparency for users, and vendor-neutral management of the license and trademarks."

[1] - https://www.infoq.com/news/2014/11/google-cloud-container-en...

[2] - https://cloud.google.com/blog/products/gcp/introducing-certi...

[3] - https://github.com/cncf/k8s-conformance/commit/34683a3316473...

Post reply on HN