Cloud Code – A new set of plug-ins for IntelliJ and VS Code | Hacker News Reader

Cloud Code – A new set of plug-ins for IntelliJ and VS Code

cloud.google.com

138 pointssandGorgon58 comments

I believe this was said when the Github repository[1] was posted yesterday, but... It's pretty wild that Google's releasing a closed-source plugin for Microsoft's open-source code editor in 2019.

1. https://github.com/GoogleCloudPlatform/cloud-code-vscode

Pretty weird decision overall, considering you can always download the extension package and look at the code in there.

It seems like a similar situation to the web. Source is not available for most of Google's websites, even though you can decompile the minimized JavaScript.

Everyone understands you can't put secrets in there.

Being able to see the source is not the same as open source. Being able to see the source doesn't mean you can fork it, resell it, or even use it without permission.

Plenty of proprietary products are made in languages where the code is not compiled, such as proprietary PHP platforms.

Presumably, since the plugins are free here, if Google isn't open sourcing it, they don't want other companies to lift their work and use them in competing projects. Or, just as likely, the Googler that wrote it has some bureaucratic process they didn't go through yet to open source it, and they intend to change the license later.

Open source also doesn't necessarily mean any of those things. They can make the source code public on GitHub under a proprietary license, which doesn't let anyone reuse or resell it.

I'm not too familiar with open source licenses, but does a license exist that allows someone to (enforceably) open source their code with the stipulation that it is for academic/security purposes, but forbids forking/reselling/other usage?

Sure there are such licenses, but they aren’t Open Source. By definition they are proprietary.

That depends on what you mean.

Sometimes "open source" means "you can see the source code".

Sometimes "open source" means "meets the requirements for software licenses under the Open Software Initiative's definitions."

Similarly, sometimes "free software" means "provided at no monetary expense" and sometimes it means "meets the requirements for software licenses under the Free Software Foundation's definitions."

People really, really like to pretend that "free software" and "open source" are extremely simple concepts and synonymous terms. They're not. People like to pretend they're controlled terms and that the plain English meaning isn't valid. That's absurd. Neither one is particularly easy to understand because both are much more deeply nuanced than you see at first glance, and one look at free and open software licensing comparisons [1] will tell you that there is obviously significant complexity going on.

[1]: https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...

This was settled many years ago by coming up with an official definition of "open source" [1] that was then popularized. It's a well-known industry standard. While nobody can prevent you from using the term incorrectly, you're going to get a lot of pushback if you do due to the confusion it causes.

There are a lot of other possible licenses and just because they don't meet the open source definition doesn't mean they are bad. I disagree with the people who say the opposite of "open source" is proprietary.

[1] https://opensource.org/osd-annotated

That's not really what I'm trying to argue. What I'm trying to argue that you can have OSI open software that is not FSF free software and you can have FSF free software that is not OSI open software, and either of those types of software are labelled as proprietary by the parties that exclude them. My point is that just because something doesn't meet the OSI open source defintion doesn't mean it's proprietary.

However, if I do consider your argument, it's not very good. The argument would be that the Open Source Initiative is not the authority for the plain English meaning of terms. If the argument I'm making is that OSI's definition is not authoritative, you can't cite the OSI's definition as an authoritative counter argument. You're begging the question. Yes, people are going to assume "open source" means "OSI open software," but that doesn't meant that everybody is always using it to mean that.

Both FSF and OSI fundamentally recognize each other as "not proprietary", even if they have different goals and different preferences on how FOSS ("free/open source software") is licensed.

And the OSI is not the authority for the meaning of English terms, correct. But the developers who use those terms are (much as language is determined by how people use it), and by and large, most everyone understands and agrees that open source software is software that meets the qualifications set by the OSI.

I'm usually a descriptivist for most English usage, but in this case we're fortunate to have an official, useful definition and should promote it over others, rather than letting it slide into becoming a meaningless buzzword like "agile".

I'm not sure how common non-standard usage is yet but I don't think it's too late?

I think the accepted terms are "open source" (free software that may or may not be "copy left", eg: gpl, bsd, mit) and "source available" (proprietary, you can see the source, but not redistribute etc. This is a spectrum from old qmail ("no forks, verbatim copies ok) to tarsnap (code available so user can audit) and code available under strict NDAs (I believe Microsoft provided source to dod in order for dod to consider windows for secure systems, for example).

Not a licensing expert myself, but I'm sure that exists out there. Creative Commons has some pretty close variants, for example CC-BY-NC-ND (attribution, non-commercial, no derivatives).

https://creativecommons.org/licenses/by-nc-nd/2.0/

EDIT: I do understand that CC licenses aren't really designed for code, and that these restrictions probably don't make sense under the label "open source". Just wanted to link a possible starting point.

They aren't open source licenses then, by definition. But there are definitely things comparable. Microsoft's "Reference Source License" is a good example: You're allowed to use their source as a reference for debugging and security, but not able to fork or redistribute any of the code: https://en.wikipedia.org/wiki/Shared_Source_Initiative

Sometimes these types of licenses are called "source-available" rather than "open source", which distinguishes the significantly different type of permissions associated: https://en.wikipedia.org/wiki/Source-available_software

Semi-related, was wondering how much telemetry / user tracking this does.

Figured we'd be able to look at the source to know. Guess not. :(

Microsoft has numerous closed source plugins and pieces for vscode, so I guess it's hard for me to see what is that wild about it?

(If you really want me to blow your mind: the pm on the Google project was the pm for vscode)

So what's the closed sourced about? I would hazard it's about Amazon or Microsoft not forking the product for their eco-systems? Which prompts lock-in, but I guess that's fine as Google is not the clear winner in this fight.

I'd turn it around: What does open sourcing it buy them?

The number of community contributions/involvement in this type of thing is small (in most cases), it also requires a lot of work upfront to integrate well with the OSS community (or you just end up pissing people off), and in practice you want to control the experience and product direction anyway (since it is part of your baseline experience for your platform), so you just piss off the community.

What is the net positive? Not just for Google, but for anyone?

I don't think it's about lock in so much as no perceivable benefit for trying to get this particular thing off the ground ATM.

I don't think anyone is going to succeed with locking someone in with IDE plugins, and i don't think anyone is trying (even MS).

(I'll make the disclaimer that i actually could have changed this decision but chose not to and i'm even a card carrying member of the FSF)

Would that not also suggest poor leadership/stewardship? Open sourcing something shouldn't suddenly mean that a community turns up and takes over the project with unreasonable or out-of-scope demands.

You can be open source without requesting contributions or building a tribe around it. You can be open source and say no to things you don't like: go ahead and fork and adapt it to your own needs.

No. It suggests open source is simply non-trivial to get right and requires a lot of time and effort that isn't always well spent doing that when you first start out. Time you spend on that is time you spend not on your product. I would strongly suggest you choose one or the other (IE either do a good job of it or don't do it at all).

I also think you are vastly oversimplifying this.

You also seem to have an interesting view of what happens when you open source stuff that is not at all consistent with what i've seen over the past 20+ years across a variety of projects. But YMMV, of course.

The most obvious benefit would be adding similar functionality to other IDEs. But really, why assume that you can guess what the benefit would be? Open the code and let the community decide what it can do with it. It doesn't have to come together with an open development process, necessarily.

Some other generic benefits that would apply here are the ability to debug issues, and interop/compatibility. The first one is often dismissed on the grounds that most users are unable to do this; but we're talking about dev tooling here, where the target audience has the necessary skills. From my own experience working on open source dev tools, this is probably the biggest benefit - not PRs, but detailed bug reports that already mostly narrow down the problem. In cases where the original bug can be very environment-specific or otherwise hard to repro, this can make the difference between resolved and closed as no-repro.

Interop/compatibility is also an important angle, and very hard to predict in advance. But any extension that interacts with this one, or is used by it, could potentially benefit. This also ties into the ability to debug it somewhat - if extension A breaks extension B, it's much easier for the author of A to figure out why, exactly, and what's the best way to avoid it, if they have the source for B.

Then there's the ethical angle. VSCode itself is open source. So far as I know, all extensions that this one relies on to enable various customer scenarios - e.g. IDE support for various GCP-supported languages - are open source. For something that derives a substantial (arguably, the majority) of its value from those, closing the source runs counter to the spirit of the whole thing, regardless of the license terms. I can understand doing so for some specific business reasons - e.g. use of some proprietary components, or trade secrets in the code - but if it's only a question of not wanting to make the extra effort, it's kinda disrespectful towards people who did make that effort. Even that would be understandable if we were talking about a non-profit project that has limited resources and has to ration them. But this is Google, and the product itself is a part of the subscription-driven GCP ecosystem.

In general, the reason why open source is so widespread today is because for-profit corporations subsidize a lot of it. They have their own non-altruistic reasons, of course, but the entire arrangement is beneficial to all. So it's a commons, and we should all strive to maintain it and the cultural norms that make it sustainable.

(Full disclosure: I am a developer working on one of the relevant Microsoft VSCode extensions. Everything I write here is strictly my personal opinion. I do not speak in any official capacity.)

"It doesn't have to come together with an open development process, necessarily."

I think the amount people agree with this varies wildly.

There are plenty of people who consider it an attractive nuisance if it doesn't.

You don't have to look very hard in hacker news threads to find google/MS/etc getting blamed for occupying a space by doing this.

I really don't think you want to push the ethical angle - vscode was definitely not open sourced for ethical reasons as part of some grand altruistic gesture and to push forward a great ethos. I was told that directly by the people who started it and made those decisions. That isn't a statement that it was a secret evil scheme (it certainly wasn't), but those were just ancillary benefits, not the main goal.

I will leave alone the fact that your argument does not seem to have convinced MS in a number of places where there is no perceivable user benefit (see, e.g., the C++ extension) and it runs directly contrary to your claims, since you want to speak in a non-official capacity :)

Bottom line: I think this is a fairly simplistic view of the tradeoffs.

I'm certainly not exactly elucidating it in huge detail, but that's because i'm surprised people want to believe these are fairly simple issues amenable to a few paragraphs of analysis.

To clarify, my point isn't "open source good, closed source bad", nor that things get open sourced primarily for ethical reasons.

With copyleft, the basic principle wrt code reuse and sharing is "take what you need, contribute back the value added", and it is encoded in the license itself. With non-copyleft licenses like MIT, the only thing that's encoded is "take what you need" - but I would argue that there's also an implied "... contribute back what you can", that is broadly respected in practice, and is an important part of what makes the model sustainable.

I remember what the industry was like when the biggest bar to shipping open source in for-profit environments was the default attitude of "why even bother?", and in practice that meant a lot less of it all around, even where not having the code made life much more difficult for others. This attitude took a lot of collective time and effort across the entire industry to change, in many cases by individual employees inside those FOSS-hostile environments actively working towards that goal for altruistic reasons. In the end, I think we're all better off for it - individual devs and companies alike - and should strive to maintain those gains, and the culture that enables them. Arguing for closed source by default is contrary to that, in my opinion. Closed source itself is not.

"Arguing for closed source by default is contrary to that, in my opinion."

I didn't, and never have ;)

It's mostly the opposite, which is that i usually am the person telling people to open source things by default.

Here, there turn out to be IMHO good reasons not to open source it at the start (it will be eventually).

The counter argument of "Google makes billions and they can certainly afford to do X" always seems to be a bit silly to me, since companies are made of people and not money, not to mention that most things companies open source will not be driving revenue in any meaningful way (again, some does, but it's the minority of open source for most companies). Open source is more of a development methodology than a sane economic model.

I've also changed over the years. After watching open source try to create a lot of products, these days i would definitely rather see good products than open source ones. Those things are 100% not mutually exclusive by any means, and in an ideal state you don't have to prioritize or choose between them. However it does mean that when i have to prioritize my choices, i'd rather have people concentrate on making good stuff than open source stuff. To start. In the end, i'd like it all to be open source :)

Others are different for sure.

Hiding how much it tracks you, most likely.

No, quite unlikely. You can't hide network traffic (or much of anything else) just by compiling your JavaScript with Closure Compiler and Google engineers know this.

Looks like there is a config setting for this: "cloudcode.enableTelemetry".

Part of the reason why some things are kept closed source is because of the quality of code itself that might hurt brand image. For things like IDE plugins it always makes businsess sense to make them fully open source if not from day 1.

I wish they would at least open-soure the linter. I just quickly compared it to https://github.com/garethr/kubeval, and it did uncover some valid additional mistakes.

Upd: looks like the plugin is using https://github.com/mulesoft-labs/yaml-ast-parser combined with https://github.com/Microsoft/vscode-json-languageservice

It'd be indeed nice if this was open source. Having a server yourself somewhere using a VPN that you could run some stuff on while working on a slow laptop would be nice.

*Google Cloud Code

The Kubernetes bit seems (somewhat) agnostic but it looks like a big part of this is adding integration for GCP APIs.

Which is all fine. Just wish it was branded a bit more specifically.

It's annoying that pretty much every single Google project comes with an underlying attempt at vendor lock-in.

So that we really feel the pain when they shut it down :)

This and the parent vendor-lock in comment are so over-played out it's tiresome.

> This and the parent vendor-lock in comment are so over-played out it's tiresome.

It's also tiresome that I'm losing access to my preferred music streaming platform that I pay $20/month for. No other platform lets me seamlessly put up a playlist with music from their streaming library and my own uploaded music[0].

People aren't dredging up the past here and being needlessly cynical. It continues to come up in discussions because it continues to happen.

[0]: Any streaming service that doesn't let me listen to Neil Cicierega is inherently flawed.

People HN act like they are entitled to a product they like existing and being supported forever.

> People HN act like they are entitled to a product they like existing and being supported forever.

No, people here are more predisposed to understand the business needs behind a given service. You're more likely to find people who understand why a service is being shut down here than picking out of a crowd.

However, they're also apt to perform a deeper risk evaluation than the average person. And a glance at Google's track record shows that their services are pretty likely to be axed, and so should not be relied upon.

It's not entitlement to be upset that a paid service is being shuttered in favor of another paid service with fewer (or at least very different) features by the same company. I'm paying for it. If it wasn't profitable, they wouldn't be actively developing a clone of their own product.

You mean like this list? https://killedbygoogle.com

Overplayed? These comments have never been more relevant.

GCP is arguably doing the most among major cloud providers to prevent vendor lock-in and support multicloud implementations.

It's really their best play to try to get some business when they're so far behind AWS and Azure in market share.

Hope they'll allow the same for this tool since it sounds pretty useful.

Are people still moving to Docker or is Kubernetes where things are going?

In general, you run a Docker container on Kubernetes. Most people do not do Kubernetes without Docker.

Can you do kubernetes without docker? Does it support other container engines?

Several others. containerd (spawned by Docker), CRI-O, something called frakti (https://kubernetes.io/docs/setup/cri/)

Somewhat off-topic.. I really wish the Kubernetes setup guides would also have a paragraph about why you would choose each option, rather than just listing how to install them.

The CNI guide[0] is especially awful here. It contains 9 (!) different options, some of which are combinations of others, with no explanation at all of how they differ. As it turns out, there is a separate page with descriptions[1], but there is no linking between the two pages, and it's in a completely different section.

[0]: https://kubernetes.io/docs/setup/independent/create-cluster-...

[1]: https://kubernetes.io/docs/concepts/cluster-administration/n...

There's an "Edit this Page" button at the bottom of each of those documentation pages. We appreciate pull requests with improvements!

I don’t disagree but that’s somewhat out of scope for Kubernetes I’d argue. The benefits or costs are varied and not simply explained. It’s probably best to just differ the docs for each runtime and have them explain it instead.

yeah getting into devops stuff from the outside is still very challenging. the official docs are always very working professional oriented

Personally I don't really differentiate to much between the two. Customers often don't know the difference, and assume that Docker will magically scale when needed. And if you have a Kubernetes installation available, why not just run all your Docker images there.

Unless you're just using Docker for the encapsulation you'll need something like Kubernetes pretty quickly.

Personally I don't really differentiate to much between the two.

I differentiate between is so much that as the app developer, Docker is my concern, Kubernetes is the concern of Infra/DevOps.

That's actually a pretty good way of looking at it. As an ops guy I don't really care that much about what the developers put into their containers, or at least I can shift a large part of my work with maintenance and patch management to the developers.

People are moving to Docker and Kubernetes

As someone who uses App Engine, it'd be nice if Google would stop treating their non-java languages as second class citizens. It seems, as per usual, there is only App Engine Java support...

I think their new 'cloud run' product is supposed to be a step towards addressing that (and vendor lock-in).

Where's the Vim support? According to the most recent SO survey Vim is being used by 43% of the DevOps/SRE market, which corroborates with my experience in DevOps. DevOps is a CLI heavy job, and having an editor that can run in a terminal emulator and has maximum integration is a must.

My which-list for G cloud: 1) Enable Websockets for the G cloud shell proxy 2) Break up and untangle the JavaScript client monolith library into small modules that can be self hosted. One module for each G cloud service. Try to limit the complexity while you're at it. 3) Make an API to make it possible to automatically manage G cloud services. For example execute commands on the G cloud shell on behalf of the user. 4) Expand the free tier so people that want to learn can try out all services without a credit card. 5) (bonus) Add a partner program so that channels can get a kickback for each user they bring to the G cloud services.

Reply on news.ycombinator.com