I could imagine you're violating some pretty strict policies doing this?
You're taking proprietary code and running it on a competitors platform?
I like to think I'm pretty open minded about stuff like this, and I've actually done something similar, but I'd be surprised if you didn't get your ass handed to you for that type of thing?
We ported it by using Google Web Toolkit Java->JS compiler, and replaced OpenGL with WebGL, and all of the other bits with Web APIs (websocket, pointer-events, fullscreen-api, filesystem api, etc)
The assets (proprietary artwork, levels, etc) were not hosted on AWS, it simply downloaded the EXE file from ID servers and extracted it in the browser.
> No, no proprietary code was used, the port was done from the Open source Java clone Jake2: https://en.wikipedia.org/wiki/Jake2
We ported it by using Google Web Toolkit Java->JS compiler, and replaced OpenGL with WebGL,
That sounds like you wrote code, code on which Google holds copyright, and you really need to read up on the Google company policy on that. I'm not sure you understand fully what distinct things copyright and software licenses are, and how Google policies apply to them.
There's a reason people who join Google have historically "disappeared" from open source: It's because they can't just contribute.
Back when you did this it definitely was explicitly and strongly violating policy. Nowadays maybe it could get away without opensource review by counting it as a "patch".
I'm pretty sure when we did this, we didn't just drop it without talking with anyone, after all, it uses proprietary assets and we presented it at I/O. It's been a long time, but IIRC, Chris DiBona was involved at least as far as getting an opinion (I don't recall if OSPO existed back then), as well as some lawyercats because of the proprietary assets it dynamically loads. This was semi-official, it was shown at all-hands by Eric, the media team helped us create the trailer (https://www.youtube.com/watch?v=XhMN0wlITLk), it was hosted by Chrome DevRel who deal with OSS releases all the time, so this wasn't just some random engineers off doing a secret private project and uploading it unannounced.
My first few years at Google, I worked almost exclusively on official OSS projects (no google3 commits).
Edit: looking at the trailer, I forgot we released this on April 1, as an April Fools joke. LOL
Ah. Yeah ok that paints a different picture than your other comments.
I'd hate to see people get in trouble after reading what you wrote and reason their way to thinking because it's opensource and their own time they can do what they want.
No biggie, my initial wording was problematic. I really only wanted to express at the time I was racing to get a private demo ready for TGIF that we could link people to, and I ended up having to use AWS which was frustrating.
For the most part, I think most Googlers are thoughtful about the rules, god knows we go through enough training decks, but also as a xoogler? you know Googley behavior means people are pretty reasonable about obeying license restrictions and adhering to desires of OSS authors.
Although as the number of employees at Google skyrocket, the probability of bad actors increases and company culture was probably much different than when there were only 5-10k employees vs >100k
> As a Googler, it's often easier for me to setup a GCP consumer account, AWS, or Heroku account to demo something, compared to using anything internal.
I get you're trying to make a point of saying you can do something easier elsewhere, but then why even through in the "as a Googler bit" without clarifying that you're not really working on anything of consequence where you'd be actually asked to host things internally.
You're basically hosting open source projects on AWS.
Why does it matter whether I'm working on something for production, or working on a 20% project? The point is, it shouldn't have been so hard for me to setup and run a simple server cost (billed using my divisions cost center), and then have to pay out of my own pocket to use a competitors product (and go through the hassle of expensing it). That's a bit of a sad pill for someone working at a company that had one of the most advanced data centers in the world. There are lots of times when developing a product internally that we need to host internal prototypes for demos, and GCP/AWS is a lot easier to use than the internal tooling. Even today, using our internal GCP instance vs the external one is more difficult.
A bigger reason AWS was chosen was because AppEngine, IIRC, back in those days could not support WebSockets (among other things), as Google's frontend Load Balancers that the predecessor to GCP used didn't know how to deal with it. The Chrome team was pushing heavily on new Web APIs like WebSockets, but by the time they were ready to ship to market, our own cloud infrastructure didn't support it yet.
I'd go further and say that, using internal infra to host employee 20% projects that are not really for production, is the kind of dogfooding that would have generated the pain points necessary to make a product like AWS, because those hobby workloads are far more similar to the workloads the average GCP customers deploy. Because we didn't really prioritize that, we kind of missed the boat on Cloud and was a late entrant, even though most of the foundational technology (eg Containers) we already had a long time ago.
An interesting contrast: for as long as I can remember (I've been at Amazon for 5 years) we've had burner AWS accounts available for testing/prototyping stuff that get auto-closed after a week. Many devs, myself included, also have a personal long-lived AWS account for infra stacks of the services we're working on. These accounts get billed directly to the team's fleet budget. As long as you're using them for work-related things (i.e. not mining crypto or hosting a minecraft server) and not racking up massive bills without a good reason then it's fine.
OMG, this is exactly what I want. GCP burner accounts that are billed to the team's cost center, perhaps with preemptable VMs that sleep dormant when unneeded, and eventually expire unless renewed.
Typically the problem is that employees with the ability to just stand up random servers within an environment also have the ability to start using them to run production workloads, handle sensitive information, and just build little silos entirely outside the operating standards, and if regulated, compliance requirements of the company.
These things typically ride on a pendulum over the course of 10 years or so, swinging from high speed to high friction. As the costs associated with approaching one extreme stack up, someone eventually says enough and the direction reverses.
Good point, although Google's internal monitoring systems are pretty good (even aggressive) at detecting abandoned, low-use, or high cost un-approved systems. I've gotten a number of my old projects flagged by automated monitoring, and asked to delete them, shut them down, or move them.
In recent years, there actually is an internal framework for standing up servers quickly along with end-to-end everything else a Google production service usually gets. The frontend uses Wiz. It's still not as easy as say, NextJS/Vercel, or Heroku, or even throwing together a Kube deployment, but it does provide a lot more than any of those, so the medium learning curve pays back quickly.
I said this in my original post but was downvoted to oblivion because my view was unpopular. I fully understand why you did it, I've done it myself for the same reasons.
I was just saying there is a line you can easily cross and you need to be careful when you take something and put it on other platforms. I've seen people get in trouble for enabling a Slack / GitHub integration, which actually made sense when I thought about why it was an issue.
They do, but you generally also need to do so following some best practices and guidelines.If everyone in every company just put stuff on whatever provider they liked, then there would be a lot of issues.
I mean, do you have any idea how many people have exposed confidential data by hosting it on a publicly accessible s3 bucket?
If I took my companies code and hosted it anywhere execept where I was authorized to do so, I'd expect flack for it. I'm less worried about Amazing stealing it, but it seems like a silly place to put it nevertheless.
Just to reiterate, that’s not what happened, no proprietary code was exposed externally, as the OP is based off of Java clone of the Quake2 code both of which were released as open source.
I don’t know what the policy of Google is with respect to hosting stuff that’s proprietary or sensitive on AWS but I imagine it requires approval just for lawyercat reasons, especially if any PII is collected given all of the regulations these days.
This is what separates companies that get things done from companies that pay a lot of people to hopefully maybe get things done.
A server for a multiplayer Quake port...
Who is Google paying to hand their ass to them over that?
Who has both the authority to hand their ass to them, and a lack of discretion to not let it end at "well in general we don't do that, but I see why you did it and there's little to no risk"
-
At some companies yes, someone is paid to go "I caught someone putting our proprietary code up on a competitors platform!!!!" and no one will actually think critically about what exactly was proprietary, so someone putting up a quake demo might as well have put up the Coke secret formula
And now OP who actually generated some value at little to no risk gets their ass handed to them and someone who simply lacked the skills to realize the risk profile gets a notch on their "I add value and earn my paycheck" badge.
You're taking proprietary code and running it on a competitors platform?
I like to think I'm pretty open minded about stuff like this, and I've actually done something similar, but I'd be surprised if you didn't get your ass handed to you for that type of thing?