Hacker News new | past | comments | ask | show | jobs | submit login
To head off regulators, Google makes certain words taboo (themarkup.org)
437 points by caution 75 days ago | hide | past | favorite | 304 comments



Google (okay, Alphabet) is the only big tech company that I can imagine would ultimately _benefit_ from an antitrust breakup.

Google keeps killing low-to-medium profitable smaller product lines and tools because it can't spin them off successfully. Google can't spin off tools successfully because their internal codebases are deeply reliant on assumptions about Google's infrastructure and Google internal libraries, etc. (for example: Google Reader could not be spun off because it assumed things about Google's infrastructure + libraries.) So Google arrives at this strange position where medium-yet-small profitable products can't be spun off or divested because of Google's secret sauce (their internal infrastructure). So Google kills successful products instead, because it isn't interested in scaling up an only _modestly_ successful product.

This is insane and a sign that something is deeply wrong in Google. Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce.


It's not even so much about protecting the secret sauce as protecting user data. Every tool interfacing to the Google backend is a potential attack vector. When the time comes that nobody's willing to bear the cost to keep it updated as the core infrastructure changes, the product dies.

In a world where Google is split up, that'll still be true; it'll look more like "Google CoreCloud has just changed API foo to protect against backflooper attacks; all users must change by Q4 2022." And spin-offs that can't afford the change will kill features or products.

In fact, in a world where individual pieces of Alphabet are required to sink or swim based on their own profitability, I expect more products dead, not fewer. Ads pays for search. Who pays for search in a world where the government has stepped in and divested ads and search from each other?


That's why we originally had an IETF and RFC's were publicly commented on and why standards are supposed to be company agnostic.

The whole proprietary-APIs-over-HTTP was a giant step back. Before we did that interop between internet based applications was far more common and supported. Now every company treats 'their users' as their own private little walled garden when before 'your users' were not so much cows to milk as they were users you exposed services to at the protocol level.

We have been able to move very fast and very far because of this shortcut but the price is a very high one and I'm not so sure if in the longer term we will end up with an advantage.


I'm not convinced, though there are, obviously, advantages to RFCs and IETF.

The primary disadvantage is speed. A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes. Google has a streamed cloud gaming service running in its web browser right now; how long would it take the RFC process to kick out the protocols necessary to enable that?


> A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes.

But...that's part of standards process. It's quite common for the actors like Google to propose a new/revised standard after implementing it independently SPDY (became HTTP/2), HTTP over QUIC (became HTTP/3), Web SQL DB (became dead, but still started the standardization process), etc., all went this route.


Exactly.

I was talking to people at the IETF about this last year. One person said the ideal use of the IETF (and RFC process) is to take situations when multiple companies have solved the same problem. The IETF puts everyone in a room (/mailing list) together and lets us collectively figure out a single interoperable protocol that all the members can implement in order to make their systems compatible.

The golden path isn't "Joe blogs needs a protocol for something so he writes an RFC". Its "Joe need a protocol. He writes his own and iterates on it. Later he meets Sarah and Dave who've all written similar protocols to solve the same problem at their own organizations. Together they approach the IETF and form a working group to discuss a standard."

Reality is usually much more messy than this; but generally the IETF should never be a bottleneck for people who want to write code and try things out. Racing ahead of whats written in RFCs doesn't stand in opposition to the RFC process. The opposite - racing ahead is a necessary part of the process, because we need collective experience in how to solve a problem in order to write good standards.


There is another downside to IETF/RFC/public standard: it's hard to move forward.

My favorite example: e-mail. SMTP and IMAP are old and have so many issues. On the SMTP side it is hard to identify authorized senders, which is a reason for spam, IMAP doesn't really work nice with mobile devices. On the other hand there are messengers like WhatsApp which solves many of those issues and allows adding features (for good or bad) and contrary to mail is fully encrypted and signed (assuming Facebook didn't break it, yet, after adding Signal's technology)


RFCs don't get changed, they get replaced by new ones. Until we find something that is 'good enough'. SMTP and IMAP are now older than quite a few of HN's readers. They could be replaced by something better, all someone would have to do is design it and put out a new RFC.

What is true though is that once a protocol is 'good enough and it gains mass adoption that change is hard but this is more to be blamed on human nature and inertia than that it is to be blamed on the RFC system in itself.


And this is happening. The JMAP working group at the IETF is writing new RFCs to replace SMTP/IMAP, Caldav, and others with a much cleaner protocol built on top of JSON and HTTP.

Its already in use at Fastmail and a few other places. (The fastmail web client talks JMAP to get your emails from the fastmail servers.)

Specs and more here: https://jmap.io/

Still no sign of adoption by gmail / etc but hopefully we'll see the industry move forward eventually.


This was the final straw. I have been considering it for literally years but I believe in open standards including email itself. If fastmail is supporting and advancing that I have no problem paying for their service.

I just created a fastmail account and set it up on my devices. Now begins the long process of moving away from gmail.


Unless your plan is to change human nature, where the “blame” goes is pretty academic. The inertia is still an issue when going the RFC route, and less of an issue when standards are developed first to fill a specific need for an interested party.


The inertia is a good measure for how successful a particular protocol version is. See for instance IPV4 and how hard it is to get rid of it. And that inertia is good, you don't want to rip up your standards every two years.


Every two years, no.

When the standard starts to actively limit further development, though...

https://en.m.wikipedia.org/wiki/IPv4_address_exhaustion


Nobody stops you from adopting IPv6, the reason that many people don't do it is because they have legacy stuff that they can not reconfigure so they're stuck. But it will happen, and IPv6 adoption is steadily on the rise.


Here in Australia my expensive fibre connection still has no ipv6 support. I file an issue every year or so to my ISP asking when they're going to add ipv6 support, so at least they know I care. But the answer is always "Its not on the roadmap".

Its difficult to remember to write ipv6-compatible software when I can't use or test it myself. Short of writing to my member of parliament and asking them to legislate it, I'm not sure what else I can do.


And on the other hand, any mail client can connect to any mail server, and any two mail servers can exchange email between each other, so the service is fully federated. The benefits here outweigh the downsides.

But also, why isn't there a commonly accepted better email standard yet? It's not because the RFC process is slower - it may be, but it's not that slow. It's because none of the big providers are interested in this form of interoperability. It's plainly obvious when you look at the sorry state of affairs in IM.

We're really, really lucky to have the interop that we have, solely because early days of the Internet were more collaborative, and enough of it got early adoption and stuck around, because it was too hard to uproot. But the more we go forward down the present path, the more Internet is splintered into proprietary bubbles.


Inability to move forward has less to do with IETF/RFC/public standards than it does with email and SMTP, to use your example, being heavily entrenched. Anyone can come up with a new way of doing something, but it's a walled-garden until it's interoperable with other tooling that other people, everyone else, are using.


OnLive was streaming games years before Google entered the space, there isn't much novelty in what Stadia has done.


The novelty will be if it's profitable / something people want.


There are already RFCs for realtime streaming of data. Also IIUC the RFC process often starts with a draft based on am existing implementation.


I don‘t know that much about how the standardization in machine building is done, just from using this standards when working in this industry. However, I would assume a lot of those standards took very long to establish but they are stable, work basically everywhere and are easy to understand.

A lot of standards coming from Google are - so it seems - here to solve things just Google likes to solve and nobody else mostly does not care about. And it‘s not standardization if you‘re the only one caring about it and forcing it onto other.


this is what organizations that participate in the RFC ecosystem have always done - they just view protocol-level interop and open standards as important.


Sure, it would be nice to go back to IETF and RFCs. But it seems like the discussion has wandered far afield from a Google breakup (more standard APIs/protocols may not result from a breakup and may not need a breakup).

And what I hate about Google/Facebook breakup discussions is how they seem driven by a mob of all those having complaints against these tech giants, where the complaints contradict each other (too much censorship, too little censorship, Google too few or too many products, etc) but the likely upshot on success is states gaining more leverage over these companies and using them as even more effective control/propaganda outlets.


The IETF and RFCs are alive and well. There is no going "back" we are still there. That's a good thing.

I don't see a complaint that Alphabet has too few services. The complaint seems to be that Alphabet is killing viable businesses or products because it can't spin them off profitably. Alphabet controls some amount of innovative economic capability that is creating products which Alphabet then wastes. Conversations about breaking up companies like this are about reallocating that economic capability to somewhere it can deliver value.


> Who pays for search in a world where the government has stepped in and divested ads and search from each other?

Since most of the revenue from Google's ads are from ads on search, presumably the broken-up ads company would be buying the ad space on the broken-up search company's SERPs. All the search company's revenue would still come from the ads company.


Is most of Google's ad revenue from ads on search? They have a huge display ads business also.


https://abc.xyz/investor/static/pdf/2020Q2_alphabet_earnings... breaks advertising into: "Google Search & other", "YouTube ads", and "Google Network Members' properties". My understanding is the latter is the display ads business, and you can see that it is pretty small, relatively.

(Disclosure: I work in Google's display ads business)


I guess the first category is maps and Gmail and other such offerings. (Still plausible to me that search is the primary driver there)


It's clearly enough revenue to support the existence of search today.


> Who pays for search

If search is of value to you, the user, wouldn't you, the user, be willing to pay for it?


The people who can afford to opt out are the same people who's views are the most valuable. Not going to happen any time soon IMO.


I'm willing to pay $5/mo

Much of India will pay $1/mo

Most people will pay $.1/month

What will the price be?


> What will the price be?

If you allow Google/Alphabet to practice price discrimination, it will charge customers in richer countries more. You and I would pay $5/month, much of India would pay $1/month, and people who can only afford $.1/month would pay that.

If you insist that the price be uniform over all users, then it has to be $.1/month, or whatever the lowest common denominator is. Of course in that scenario it's much harder to get to a revenue number that is anywhere close to Alphabet's current revenue.


Another subthread here states that ads on search are a majority of Google's revenue. Looking at [1], we see the US being 46% of the revenue. So, assume that search in the US pays for 20% of Google's revenue. Apparently Google's revenue is $160B/year. Do you think the US would have 100M customers willing to pay $320/year for search? Or 10M willing to pay $3200? Or, any mixture of that to reach the balance?

Dislaimer: I'm a Googler, but only base the above on this comment thread and the first results in Google search.

[1]: https://www.statista.com/statistics/266250/regional-distribu...


Revenue isn't a good comparison and is more of a distraction than a usable data point.

Presumably, if Google is servicing paying customers instead of paying advertisers, then google has much less work to do. Their revenue can decrease without their profit decreasing.

They don't need to manage engineering to store cookies and track interests. They don't need infrastructure to store profiles. They don't need cpu cycles to correlate interests. They don't need lawyers to fight off regulators. You can easily imagine other things they would not need for those customers.

How much would paying customers need to pay so that google would make the same amount of money? Revenue isn't even an upper bound on that question.


> ads on search are a majority of Google's revenue

That's not the same as saying that a majority of Google's revenue pays for making search work. The relevant question is whether search as an application, regardless of what else Google wants to spend revenue on, could bring in enough revenue from users to pay for itself.


Good point. Good question. Confidential answer ;)


In detail perhaps - but vaguely the answer is that it's not that much money. Microsoft pretty much willed Bing out of thin air and while adoption has been quite an issue it does have pretty reliable results. Microsoft has a ton of money to throw at things but I think - from the ancillary manner in which Bing was launched - that it honestly isn't that expensive on a day-by-day basis to run that sort of large scale search. I do suspect there is a lot of economy to be saved by already having a wide coverage of the globe with computing resources though so I'd guess at the market being hard to enter and easy to sustain costs once you're in.

I suspect Google works hard to keep from letting out how severable and independent their search business is in a large part to keep monopoly breakup calls from getting too much momentum.


The problem is that even if every Google user on the planet paid $5/month, it would maybe just barely match their current revenue.


You'd need something over 3 billion users at that rate to match Google's current revenue (about $16 billion a month). Google currently has about 2 billion.

However, Google's current revenue pays for a lot more than just search. It doesn't seem unreasonable to me that search could pay for itself with revenue from users instead of ads.


Pricing would be based on value. Someone who's willing to pay X is more valuable than someone who's only willing to pay 0.1X, so naturally the former should pay more.


Presumably spinoffs would end up with their own copy of all software infrastructure, which would evolve independently at that point.


I'm not sure that's presumable. It sounds like a better way to do things in the short run (in the long run, there's a net loss from the loss of the cross-pollination benefits of security and best-practice on the backend that Google enjoys now).


It depends on how stupid the regulators are - the one with the google name will win. Seriously people - domain names and awareness matter ans you can't just partition websites to regions with an international web.


We already know how incapable the regulators are. 20 years after they went after MS for their dominance in personal computer operating systems, productivity software and browsers, MS is still dominant in two and the third doesn’t matter to anyone except for Google.

MS had the highest market cap in the US in 2000. As of today it is #3.

The government had a monopoly suit against IBM in 1969 and finally withdrew it in 1983 and nothing came of it.

People in tech have been wanting the government to go after Big Tech for years. Four of the CEOs show up for Congressional hearings and then the government goes after...TikTok and WeChat instead.


>People in tech have been wanting the government to go after Big Tech for years. Four of the CEOs show up for Congressional hearings and then the government goes after...TikTok and WeChat instead.

The Big4 are US based companies. WeChat & TikTok are foreign owned companies, and that country is currently a safe play to bash. The gov't can go after the low hanging fruit so they can have something point at to say they are doing something about evil tech.


A big part of it is that trust busting in US is just not what it used to be, since getting borked back in late 1970s: https://en.wikipedia.org/wiki/The_Antitrust_Paradox


> Who pays for search

who says that 'search' has to be a consolidated system that needs to be paid for?


It's a hell of a lot more convenient as one. Not really thrilled about going back to the days of a fragmented web where webcrawler would give you some results, lycos some others, altavista yet a third batch...


Sounds great. These days we only get the Google or the MS batches of results.


... which cover five nines of use case. A fragmented ecosystem would give us three to five sites to search that still cover only five nines of the use case, based on past experience.


Oh but the things you discover! I didn’t learn BASIC by searching for it. I learned it because someone stuck a manual in the young adult section at my library by accident and I was curious...


> Google keeps killing low-to-medium profitable smaller product lines and tools because it can't spin them off successfully

It's worse than that, Google releases products for free killing competitors in the markets they enter, and once those competitors are gone, Google pulls their products.


I feel like I agree with this statement, but I can't think of any examples. Google Fiber doesn't seem to fit, or Reader, or Wave, which are the most commonly cited examples of popular products that got killed.


Google Reader?


IIRC the incumbents were free, like Mozilla Thunderbird.


Yes -- I think this is far more important. If anything, Google kills off low-to-medium _adoption_ products, regardless of profitability.


It is worth noting when Standard Oil was broken up John D. Rockefeller's net worth went up. The sum value of the new oil companies soon exceeded the value of the old monolith.

Also for reasons I cannot explain, investors happily watch the failed conglomerate model re-invented time and time again, even though history shows conglomerates running their divinions into the ground.


Be careful not to confuse monopolies with conglomerates. You're right conglomerates mismanage (usually neglect) some divisions, but that wasn't the case with Standard Oil. Esso wasn't a neglected divison; oil is oil.

The new companies being more valuable is interesting. It helped that they were regional monopolies. Maybe people thought the added competition drove growth on its own. Maybe the new companies became crowded trades because rather than just being a bet on oil, it was a bet on oil and who would win in oil.


There's an interesting quirk of markets that can explain the broken-up companies being worth more. Prices in a market are set on the margins: the price of Bitcoin or Tesla stock is set by those who are actively buying and selling. If you think those assets are complete scams, you aren't going to go near them, which means your opinion doesn't matter for the purpose of setting the price.

When a company is broken up into competitive entities, there's uncertainty about which company is going to become dominant in the future. So if you think Esso is going to win the lion's share, you're going to put your money in Esso stock. Ditto Kyso, Calso (Chevron), Sohio, Amoco, Marathon, Mobil, etc. They all get their own teams of cheerleaders, who value the spinoffs at close to the value of the original because they think their preferred spinoff will take most of the market of the parent company. People who disagree with that valuation don't matter, because they aren't going to be trading in that stock anyway.

A similar phenomena likely occurred in the crypto bubble of 2017, where everybody had their pet crypto they were cheerleading and they all expected it to take over the whole economy - this was made even more complicated because many of them were priced in Bitcoin, which had to be purchased to buy any of them, which meant that price increases in Bitcoin were reflected in the price of altcoins as well. It's likely also a factor in Tesla speculation - Tesla shareholders believe it will take over the entire world car market, while Tesla skeptics drop out of the market and don't matter to the price action.

(The risk asymmetry in shorting also contributes to this. In a perfectly efficient market, if you believe something is overvalued you short it instead of dropping out of the market, which drives the price down to fair value. In reality, your downside with shorts is potentially unlimited, you can get rekt if the price stays irrational longer than you stay solvent, and few firms have the resources to maintain short positions in a long-term bubble.)


> If you think those assets are complete scams, you aren't going to go near them, which means your opinion doesn't matter for the purpose of setting the price.

Doesn't that reduce demand though, which lowers price?

> They all get their own teams of cheerleaders, who value the spinoffs at close to the value of the original because they think their preferred spinoff will take most of the market of the parent company. People who disagree with that valuation don't matter, because they aren't going to be trading in that stock anyway.

Doesn't that only make sense if only those cheerleaders are doing buying and selling?

I imagine there's three groups that matter for this argument, yay-sayers, regular people, and nay-sayers.

If yay-sayers are basically all in, they've brought the stock up I imagine, but they're probably not doing a lot of movement I would guess?

nay-sayers aren't buying anything, but that means there's less prospective people to buy what's being sold (stock-wise).

Regular people then buy and sell. There's less people to buy what they are selling though, so does that reduce the price at which they can actually offload shares?

Then again, maybe yay-sayers are willing to gobble up stock below a certain price (which is still a high valuation), propping up the market?

To me it seems like both have effects on the market, opposite of each other. Then again, my knowledge of the stock market is more theoretical than anything, so I'm happy to have my assumptions explained wrong.


> Doesn't that reduce demand though, which lowers price?

Yes, but "Seems fine, but I'm not interested." and "LOL. I've researched this extensively and am confident that this is a scam" both send the same 0 demand signal.


> The risk asymmetry in shorting also contributes to this

Sounds like "markets can remain irrational for longer than you can remain solvent." I hadn't thought of it as risk asymmetry, before.


I didn't imply Standard Oil was a conglomerate or that conglomerates are monopolies. How did you parse that? Alphabet on the other hand has characteristics of both.


You certainly imply that the "history" you refer to in your third sentence is the one described in the previous two.


Same with breaking up Ma Bell. Sometimes it’s that M and A helps the CEOs more than the investors.


Increased profits from downsizing the labor force as a short term result is probably a very attractive motivator.


His wealth increased but his power decreased. In Google’s case, their monopoly drives tremendous value to management at the expense of society and its shareholders.


The engineering effort required to split up a mammoth code base where everything has been written based on those assumptions about the rest of the codebase is making such a split extremely unlikely to succeed. We're not talking about a few millions lines of code, we're talking about billions[1] of lines of code. It would take more than a decade of having thousands of engineers work only on this and not do anything else (like, you know, actually develop features to keep being competitive). I don't see how it would work.

What I could see working tho would be to focus on exporting some of the very core internal libraries[2] and then go on a project by project basis and do the work required to be made to work externally. The latter would be a never ending effort but the end result would be a number of averagely successful projects that spin off Google.

[1] https://www.wired.com/2015/09/google-2-billion-lines-codeand... 2 billion lines of code in 2015, I'd imagine there are at least 3 by now, considering the increase in employee count.

[2] https://opensource.google/projects/abseil


Companies with millions of miles of physical infrastructure have been broken up before. You're missing the forest for the trees if you're fixating on the code.


Breaking up physical infrastructure is a lot easier than breaking up something like Google's monorepo, and that's not to mention all of the physical infrastructure Google has all over the world that would have to be divvied up as well.


Id like to think that if younger versions of sergey and larry (and other relevant eng working with them) suddenly time traveled to our times they wouldn't think its impossible to build a good search product that doesn't involved "mammoth code base"


Hear hear! All I hear is the lack of imagination.


But most of those billions of lines are not the low-level infrastructure relied on by many projects. To split out a single product would only require creating external versions of a much smaller subset of the code (and once that had been done once, other products being split out could build on that effort).


Is this a negative result of mono repo? There’s no natural boundary physics.


> perpetually killing small products to protect Google's secret sauce.

I doubt Google kills those products because it can't spin them off because of secret sauce. Google kills those products because:

- they are not profitable enough (profitable enough for Google)

- they don't drive engagement and ad sales enough (once again, not enough for Google)

- it offers no promotion paths for people who may run them, so it's hard to recruit internally (as many posts have shown, development of new shiny things, however superficial, is rewarded, maintaining is not)

And "spinning something off" is not a simple task in itself and will most likely cost more money than just shutting a product down.


Additional reason: all the infrastructure is changing underneath these projects.

Let’s say you have a Google product for feeding people, let’s call it “Google Feeder”. Now, you need big piles of food to feed people, so you build it on top of “Google Pile System” to manage all of those piles. People like Google Feeder, but it’s not successful enough to fund an engineering team.

At some point, Google Pile System gets replaced by a new system for managing piles, called Humongous. Now, what happens to Google Feeder? You’ve decide that it’s too expensive to migrate it from Google Pile System to Humongous, but the problem is, if you want to spin it off into a separate company, you’d need to migrate it off Google Pile System anyway.


That just suggests that building on top of proprietary internal infrastructure is a massive waste of value. If web app code were books, Google'd be burning the Library of Alexandria just because nobody else could read what the books were written in.

And that reiterates that breaking up Google would be good for Google's value. Not being able to rely on internal shortcuts means more dead products could be sold.


This is really the core of it. If you run the numbers, Google makes something like $1 million of profit per year for each engineer at the company. If a product has a 10-person engineering team and isn't bringing in $40 million / year at a 25% profit margin then there are just better things for those engineers to be working on and the product will likely be shut down so that the team can reprioritize.


I remember back when I was an industry analyst talking to someone at IBM about some initiative other. And one of the things he said--I might not have the number/metric quite right but the idea is the important thing--was that if an initiative isn't going to bring in a billion dollars, it just doesn't move the needle enough to bother with.

Every little project takes some number of cycles from everyone up the management chain as well as finance, HR, etc. etc. At some point, even if it is profitable on its own, it's just too small of a blip to bother with. Plus, of course, no one is going to want to work on it because it's that dead end thing that the company doesn't care about and may randomly cancel at any time.


As someone else mentioned elsewhere, Google has serious data security and privacy requirements to contend with. The “up the chain cycles” consumed by a small project are massively exacerbated when everything has to be done in a way that won’t open the company to risk of Chinese cyberattack or massive EU fines. Projects have to be large enough to justify the effort to build them to extremely high quality, because anything low-quality is a risk that outweighs any potential benefit.


>Google makes something like $1 million of profit per year for each engineer at the company

Gentle reminder that thisbis partly because Google isn't fairly compensating the people actually producing the value it accrues to itself: the users.

They could start by having accessible customer service.


That doesn't affect the balance of the equation much. The same analysis applies even if customer service cost more.


If profit were lower because Google were forced to address cost centers they neglect (to the dismay of a limited but utterly devastated portion of their clientele), then it would effect what they saw as "profitable."


> I doubt Google kills those products because it can't spin them off because of secret sauce.

If Google were actually killing off products for this reason alone, you'd think they'd start building products on GCP so spinning them off would be easy.


That's like saying "Google should build products destined for failure". No one builds a product with the intent of "easily spinning the product off".

And no, building something on GCP doesn't magically make something "easy to spin off". Amazon is building their products on AWS. I highly doubt that any part of their business is easy to spin off because of that.


I’m not sure that it’s insane to kill off profitable products.

Some folks were upset recently that Honda is discontinuing the Fit subcompact hatchback in the US. That’d be easily understandable if it were an unpopular, unprofitable product. But the Fit was well-loved and dealers struggled to keep them on the lots. So why did Honda kill it? The HR-V subcompact SUV based on the Fit has been produced for the US in the same factory in Mexico and is more profitable and more popular. If you’re Honda, maybe it makes sense to make more of the vehicle that makes twice as much profit and divert resources away from the less profitable model.

Still bums me out that I soon won’t be able to buy a new Honda Fit though.


It's possible that the Fit fell into a spot where it would be unprofitable under USMCA (The new trade agreement between US, Mexico, Canada.) Under the new agreement more 'value' of the vehicle (be it parts, or the cost of labor to assemble) has to be from within U/C/M to avoid being considered an 'import' and subject to additional tariffs.


But in the long term you'll hit saturation on the more popular model, so you should still invest in any model that clears some ROI bar. Especially when that car (or that google product) is already designed and in production!

And an already-working piece of software is much easier to keep running than a car production line. It needs servers but Google has a nearly infinite supply of servers for sale. The constrained resource is coder hours, and keeping something going with a few improvements requires only a sliver of those.


Yeah, nice story, but Google kills products without offering any alternative. There is no master plan at Google regarding non-search products. Just pure incompetency.


How does that make sense? On paper they just lose the revenue of the Fit without gaining any new revenue elsewhere. That’s just a loss. It takes some magical thinking to argue that these lost customers will move over to the more popular model, a qualitatively different car.


What I got from that comment is that they're supply constrained, and gain new revenue elsewhere by producing more of the HR-V.


Why would they think that demand of the HR-V is likely to increase if they remove the fit? I understand removing unprofitable lines, but if it’s making money why fix something that ain’t broken?

If they’re worried about competing with themselves, they’ve blatantly told you as a customer the car you want is too desirable for you to have it. Wtf?


They’re supply constrained on both Fit and HR-V. The factory is going all out, but building a new factory isn’t a short term thing. So they can build all of the more profitable HR-V and sell every one or they could mix in some less profitable Fits.


If you’re Honda and you’ve got a factory that can make 100000 cars a year, would you rather make 100000 cars that make $2000 profit? Or 50000 cars that bring $1000 profit and another 50000 cars that bring $2000 profit?

If you’re Google and you can only find N top notch software engineers, do you want to put any of them on marginally profitable projects?


I mean, you still need to convince people to buy the cars to get any profit, so I'm not sure what your point is.

>If you’re Google and you can only find N top notch software engineers, do you want to put any of them on marginally profitable projects?

Presumably this depends on what kind of work is needed. I've never worked at a place where profit is correlated to engineering talent, including and especially at Google.

Again, I'm not sure what point you're trying to make.


> Google can't spin off tools successfully because their internal codebases are deeply reliant on assumptions about Google's infrastructure and Google internal libraries, etc. (for example: Google Reader could not be spun off

This is a not a likely speculation. Did reader really require anything special that doesn’t already exist as a Google Cloud API? Or majority of their killed products honestly?

Or to look another way, do you think anyone who has a cloud services platform (Microsoft, Amazon, Google) can really afford having a separate, divergent infrastructure internally? Haven’t these services started for utilizing excess capacity and economies of scale of existing infrastructure?

Also you are idealizing code reuse, especially at scale. When you take a dependency the arrow goes both ways and now there is a cost for depended breaking things too. Each integration potentially creates non-trivial friction points, if not we would have open source code of the world converge towards a single codebase organically already.


> This is a not a likely speculation. Did reader really require anything special that doesn’t already exist as a Google Cloud API? Or majority of their killed products honestly?

Yes, absolutely. The Google software stack is custom end-to-end, down to a customized Linux kernel and a customized C++ compiler. If you stripped out all of the Google-specific code of something like Reader there wouldn't be anything left at the end.

> Or to look another way, do you think anyone who has a cloud services platform (Microsoft, Amazon, Google) can really afford having a separate, divergent infrastructure internally?

All three of the companies you mentioned had an internal platform before they had a cloud offering, and all three still have an internal platform that is widely used.

> Haven’t these services started for utilizing excess capacity and economies of scale of existing infrastructure?

No, the "excess capacity" part is a myth. It's a pervasive myth, especially about AWS, but it's not actually true.


> The Google software stack is custom end-to-end, down to a customized Linux kernel and a customized C++ compiler.

Are you really suggesting that the existence of an RSS aggregator hinges on custom linux kernels and C++ compilers?

> all three still have an internal platform that is widely used.

And your point is? None can afford running two divergent platforms simultaneously.

> No, the "excess capacity" part is a myth. It's a pervasive myth, especially about AWS, but it's not actually true.

Citation needed. (Also I didn’t say only excess capacity, also economies of scale.)


Pick a piece of infrastructure: server (k8s), container (docker), RPC protocol (GRPC), user auth/ACLs, etc. and now understand that the internal version is different, and you need to replace it.

At that point, you're rewriting the entire system, except for some of the business logic (and even a lot of the business logic will need to be rewritten).

> And your point is? None can afford running two divergent platforms simultaneously.

I think what they're saying is that all three do run divergent platforms simultaneously, today, right now. So clearly they can afford it.


> server (k8s), container (docker), RPC protocol (GRPC), user auth/ACLs, etc. ... At that point, you're rewriting the entire system

You are not writing any of those systems, you're merely writing the glue code between your application and those systems, none of which is application specific.

I explicitly made the point that cross-infra porting is not necessarily trivial, but it is also not cost prohibitive as the OP makes, and certainly there is no secret sauce involved to the extent of justifying a break-up.

> except for some of the business logic

You mention this in the passing, but barring mechanical limitations of the new infra, reusing your business logic means retaining your APIs, auth models, data models, even database schemas, replication and deployment design decisions and tons of portable code. That is where the overwhelming majority of engineer hours go in an ordinary product anyway.

> three do run divergent platforms simultaneously, today, right now

No, they don't. Trying to spin up your custom internal infra (or demanding special internal accommodation from externally available infra) will require justifying to management why you're not using the existing one, and most of the new products coming from these guys are nothing that specialized in terms of infra needs. I'm not saying there is a perfect external/internal service&API parity, but certainly convergence is the normativity here, not divergence.

Let me put it this way, majority of {Google, Amazon, Microsoft} services could be ported to run on each others cloud platforms, let alone on the external APIs of their own platforms, which means there is no secret sauce and there is no reason for smaller players to be complaining about it other than not having economies of scale thus pricing levels.


> you're merely writing the glue code between your application and those systems, none of which is application specific.

Yes, but if you have to modify every interaction with an external API (you do), or even many interactions between internal APIs (you also do), you have to rewrite the application. Most of an application is moving data, if you have to change how you move data, you have to change the majority of the app.

> No, they don't. Trying to spin up your custom internal infra (or demanding special internal accommodation from externally available infra) will require justifying to management why you're not using the existing one, and most of the new products coming from these guys are nothing that specialized in terms of infra needs.

Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong.

> Let me put it this way, majority of {Google, Amazon, Microsoft} services could be ported to run on each others cloud platforms, let alone on the external APIs of their own platforms, which means there is no secret sauce and there is no reason for smaller players to be complaining about it other than not having economies of scale thus pricing levels.

This is also wrong (i mean for some value of ported including "completely and entirely rearchitect", yes this is trivially true). But no, hosting AWS on GCP or Google search on AWS would not be, by any stretch of the imagination, a relatively simple process.

There are well known examples of systems that one service has, that another can't support. A simple example would be Spanner. But that's a different conversation than the one we were having. The original claim was

> Google can't spin off tools successfully because their internal codebases are deeply reliant on assumptions about Google's infrastructure and Google internal libraries, etc.

Which is true. You seem to be taking "can't" to mean "cannot technically, even given infinite resources" and not the much more likely "cannot reasonably". And this would be true in general, ask anyone who has tried to move an app GCE to AWS, and see if it was pleasant. It's not.


We are splitting hairs. Most of both what you say and I say is true and the point still stands. I never claimed cross platform porting is trivial, and that is not the point of this exercise. The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. (In fact the inverse case happens pretty frequently, whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending). No need to make it more complicated than that.

> Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong.

They are all entitled to their own opinion. I'm open to being proven wrong, but I'm sure you can guess how different opinions can be even in 'those companies' so let's not assume there is a clear, unquestionable truth they have access to. It is hard to attest anyone's credentials on a pseudonymous forum and that is OK.


> The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down.

That's not at all what they said. Their actual point was that because Google uses highly custom infra, it is not easy for them to open source or spin off a singular thing. This is valid even if Google's internal infra is strictly worse than what is available openly. Their point has nothing to do with magic infra. It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform.

> I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot.

Yes, you claim this, and you were and continue to be incorrect.

> whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending

There is a difference between a situation where you are acquiring a thing for $LOTS, and are therefore willing to invest $EXTRA to make it work with your stuff, and the situation where you are divesting from a thing and therefore don't have the same budget.

But even if you reject that: the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of). And, even when they aren't, "you decided to purchase them" is a really good justification to management, to use your words, to make additional exceptions.

> They are entitled to their own opinion.

But these aren't opinions. You're just factually, demonstrably wrong. Your (now deleted) statement that there may be efforts underway to better align the internal and external infrastructures may be true, but if it is, it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive.

To address your other comment:

> You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc.

Yes, but you can't run an RSS aggregator built to run on Google's infrastructure without either rewriting it or using Google's internal cluster management infra. The useful about having ecosystems like those is that you can couple couple very tightly between infra and application.


> This is valid even if Google's internal infra is strictly worse than what is available openly.

Indeed it is, because Sod's, Parkinson's and Wirth's laws.

> This is insane and a sign that something is deeply wrong in Google. Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce.

Given such a massive rewrite will not be possible without bankrupting the company, and such an open source would just amount to going non-profit (they would essentially lose all trade secrets and profit-making advantages), forcing a public domain of intellectual property, replacing the top executives without severance and stripping of for-profit status will be way better economically, than splitting it.


> and stripping of for-profit status will be way better than splitting it.

The US can't just make a company suddenly a non-proft. The current shareholders would have, in the case of Google, about a trillion reasons to complain.


They would receive their respective share capitals in the liability payment stage of utilisation process, the business would continue too, so no valid reason to complain.


> It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform.

Completely foreign platform is moving the goalposts here. I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions.

Besides, the giant leap the OP and you make is that cost prohibition is the reason these spin-offs don't occur. I've been arguing not only the cost is not as high as you make, it is also unlikely to be the reason for us not seeing spin-offs. To invert your premise, if cost of giving the keys of any killed Google product to someone else was less than the money they could get, would they really transact away all of those products? I voted a strong no since my first reply to OP.

> the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of)

Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer. As I stated, that accommodation game becomes combinatorially explosive. Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large. Which is why the internal and external versions of could offerings don't diverge but converge too, their infrastructure is general purpose enough.

> it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive.

I explicitly stated multiple times that I am not claiming 100% API/service parity, so you are fighting a strawman here. Not being identical, while being are sufficiently convergent, doesn't prove cost prohibition at all.

> Yes, you claim this, and you were and continue to be incorrect. > But these aren't opinions. You're just factually, demonstrably wrong.

I don't hear any demonstrations or facts, only your willful assertion that "it is so". Which is fine in a pseudonymous forum, because as I mentioned we don't need to spill our credentials to just win an argument, but also like I said, don't ask people to ascribe any more authority to it than mere opinion.


> Completely foreign platform is moving the goalposts here.

No it's not, because you are consistently overestimating how similar the internal and public platforms are. I don't know how I can make this any more clear. Your estimation is incorrect. You are misinformed.

> everything Reader depended on is very likely to be available on GCP

This is, probably, approximately true.

> is very likely to be in a form that is very similar to its internal versions.

This is demonstrably wrong, and I and others have already provided examples, which you've ignored.

> I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions.

Moving from stubby to GRPC is a lot of effort. Moving from Google's internal user ACLing to OAuth or whatever is a lot of effort. Switching the APIs used for Google's internal monitoring infra with the ones that are used by GCP is a lot of effort. Removing dependencies on borg particulars is a lot of effort.

Doing all of those things is a lot of a lot of effort and reasonably cost prohibitive. And that's ignoring a lot of other sources of "a lot of effort".

> Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer.

You have this backwards. It is precisely because the internal infra supports thousands of engineering teams doing complex things, up to and including hosting the external infra, that it must be significantly more flexible.

Note however that this is irrelevant to the broader point, which is that even if they're exactly the same flexible, they're not the same, and as a result, you have to rewrite every place where you interact with an external system, which means essentially rewriting the entire application.

> Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large.

Yes, which is more flexible than the external infrastructure. Put simply, the internal infrastructure is what the external infrastructure runs on. This may mean that sometimes you can run things on the external infra, but when you can't, the internal infra is strictly more powerful, since it hosts the external infra.

> I explicitly stated multiple times that I am not claiming 100% API/service parity

Nor did I say anything about 100% parity. I said, and continue to say cost prohibitive. To rephrase, since you misunderstood: if they need to better align them, that means that there are large enough differences that porting (or perhaps just interoperation) is cost prohibitive, and so they need to change how the systems work to make it easier to move between them.


> This is demonstrably wrong, and I and others have already provided examples, which you've ignored.

I don't know what exactly you consider to be an example to demonstrate your point, but I must have missed it because I haven't read anything factual on the matter. If you think merely listing a bunch of infrastructure components and deeming the difference between external and internal versions is sufficient evidence, I have already stated that it doesn't convince me.

Maybe we have vastly different experiences in the software development we have participated in our careers, but I think the root of our estimation mismatch is you equivocating rewriting the infra glue code with the entirety of the application. I certainly don't see it that way.

> Moving from stubby to GRPC is a lot of effort. Moving from Google's internal user ACLing to OAuth or whatever is a lot of effort. Switching the APIs used for Google's internal monitoring infra with the ones that are used by GCP is a lot of effort. Removing dependencies on borg particulars is a lot of effort. Doing all of those things is a lot of a lot of effort and reasonably cost prohibitive. And that's ignoring a lot of other sources of "a lot of effort".

To my point, I have explicitly stated this infra glue code will be in need of re-writes. While "a lot" doesn't help quantifying your proposition much, you (or others in this thread) seem to equivocate this to designing and implementing the whole application from scratch, and that is where I disagree. Sure this going to be application specific, but I would estimate the engineering hours spent on replacing the infra glue code to be much less than that went to developing the business logic. I don't deem that to be cost prohibitive when we are talking about a company potentially selling that IP, much less so if it is going to run in their public cloud platform.

Besides, I don't know much about Borg, but if an application like an RSS aggregator is taking dependencies on implementation details of their replicated task scheduling and provisioning system, I think they must have been doing it very, very wrong.

> I don't know how I can make this any more clear. Your estimation is incorrect. You are misinformed.

Keeping repeating your assertions is definitely not going to help making anything clearer. Let your arguments do the talking, let the readers arrive to the conclusion on who is wrong or possibly misinformed. You are bordering on shallow dismissals which HN guidelines frown upon. It is bad form, please don't keep doing this.


> You mention this in the passing, but barring mechanical limitations of the new infra, reusing your business logic means retaining your APIs, auth models, data models, even database schemas, replication and deployment design decisions and tons of portable code. That is where the overwhelming majority of engineer hours go in an ordinary product anyway.

If you haven't read the Google SRE Handbook, I recommend it. It presents some good background on the topics here. Pretty much every aspect you listed is dependent on a custom Google-internal service, and would have to be rewritten.

https://landing.google.com/sre/sre-book/chapters/production-...

https://landing.google.com/sre/sre-book/chapters/release-eng...

> No, they don't.

They do. No need to come up with a rationalization for why it can't be the case, you can Google it and find out that it is true.


> Pretty much every aspect you listed is dependent on a custom Google-internal service, and would have to be rewritten.

Except those as OP states have both open source versions and SaaS versions available and they don't need to be written from scratch. SRE automation software and being able to run a particular application are completely different things. I don't get why there has been a constant confusion between application logic and infrastructure in this thread. You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc.


Yes, but you can't run Google's RSS aggregator without depending on Google's particular monitoring or cluster management infrastructure.

And migrating away from all of those hundreds of dependencies, many fo which are in extremely central parts of your stack, is a huge amount of effort. See this[0] for an example of the interfaces the infra supports, and now you have to rip basically all of that away and replace it with something different. And that's in addition to all of the application level changes, and that's in addition to any high level design changes due to potential mismatches in capabilities between the internal and external systems.

[0]: https://twitter.com/rakyll/status/1293026308524584960


> None can afford running two divergent platforms simultaneously.

Of course they can, all three actually do, right now, at this very moment!


It's probably true that now (in 2020) Google has cloud services that do everything which Reader needed, but it wasn't true when Reader was shut down in 2013. For instance, cloud Bigtable launched to the public in 2015.

(I don't know whether current Google products mainly rely on the public services, or internal near-equivalents to the public services, or significantly different internal services. I assume it's mainly either the first or the second.)


Well the point is there is no “secret sauce infra”, let alone Google specific infra as the OP speculates. If we were to claim timing as a factor, AWS was available since 2006.


You really missed the point. It does not matter if the "secret sauce infra" is better than equivalents. What matters is that the code you have is based on it. And since literally everything is based on Stubby, which has a hard dependency on Borg, once you remove the bits of the backend's code that are secret-sauce-dependent you're left with a Makefile ;)

Disclaimer: I work in Google, but the above is easily inferred from the SRE books.


> It does not matter if the "secret sauce infra" is better than equivalents.

That is what the OP suggested.

> What matters is that the code you have is based on it

It is the nature of infrastructure is to be independent from business logic. I’m not saying any migration would be trivial, but it is also not as cost prohibitive as you seem to be arguing for. RPC is a very old and generic concept, so unless reader was depending on Google specific RPC mechanics, the cost of swapping one RPC tech with another is not going to be to the extent of warranting uttering of concepts like anti-trust.


The distinction is less important at Google, where all of the code is in a monorepo and all of the infrastructure was custom-built to support the products.


Monorepo doesn’t mean a monolith, it is about code repositories, not about the extent of software reuse. You could convert the entirety of open source code into a monorepo too, but it wouldn’t mean they magically reuse each other.

> all of the infrastructure was custom-built to support the products.

That tells me you might not have experienced software development in a large company. I don’t know the specifics of Google, but custom tailoring infra is a combinatorially explosively problem if you have hundreds/thousands of products you need to “custom tailor” to. And if you could, would the result be really custom tailored anymore or general enough to have universal use? Your argument is self contradictory.


> Google Reader could not be spun off because it assumed things about Google's infrastructure + libraries.)

The reason to not spin it off Is less because of Google’s infra and libraries than it not fitting with Google’s revenue model. It existed only to tie user preference data to an identity, and sharpen Google’s ads business. Divested of that, it doesn’t make sense. Google has no interest in joining the hobbyist $5 a month RSS reader market.


And people wonder why kubernetes/Anthos is a thing...


umm, what's anthos?

I thought I'm well versed in k8s-onomy, but it seems I've missed this :o And worse, none of the search results are helpful!



That link doesn't really help explain anything.


As best I can explain it (being a non-expert who technically works in the Google Cloud PA but not really): Anthos is an abstraction layer that allows you to manage on prem and on cloud servers in ~the same way.

So if you have on prem infra that you can't migrate to the cloud (for legal reasons or because it's some big hefty SAP server or whatnot, or because you want to migrate but can't yet), but still want to have some stuff be cloud-y, and maybe have that stuff communicate, you can use anthos to make that work.

And that's the best I can give you.


This could be a good forcing function for them to get their act together on cloud. However, I've heard that teams internally can't build on google cloud for various reasons. It may even make more sense for them to directly spin off onto AWS. Even "seperate" companies like Waymo build their systems on the internal google infra.


I'd imagine (although I don't work there) that it has something to do with datacenter availability. Google probably has a lot more datacenters than are available in Google Cloud used purely for internal workloads that run on their commodity hardware, which was what Borg was designed to run on. It's much easier to manage internal workloads by saying "it has to work on this" instead of letting each individual team go wild on Google Cloud and spin up whatever they want, which is how you get into an unmanageable flustercluck of shadow IT. Coupled with "Google-scale"(tm), where every service has to be able to scale globally (which is why they have so many datacenters and boxes in ISPs, etc.), it'd be difficult to manage that real estate the same way as companies do on your cloud (what if you need to bring up a ton of Gmail or YouTube traffic and the datacenter is at 97% load because Google Cloud had a good sales month? Not an impossible problem to fix, I suppose, but you could suddenly find yourself without enough hardware when you're talking about Google sized traffic.)

I suppose AWS figured it out, although I always figured amazon.com didn't exactly compete for resources with outsiders.


Even analysts believe that Google's sum-of-its-parts is larger's than the whole. https://www.barrons.com/articles/alphabet-stock-is-worth-35-...


I was so glad when Google Reader died and I switched back to a real RSS reader. Google Reader was garbage. It wouldn't show 404s and had a ton of bugs. Every RSS reader I've tried since has been loads better.


If a Google employee uses these taboo words in an HN comment, will YC get a subpoena?


What? Why don’t they fork internal dependencies or push the developers of the infrastructure to support the dependent projects?


Your theory on Google reader is completely false. This fake news


> Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce.

I totally agree! But this assumes that what Google wants to do is healthy. What Google actually does is try to make more profit. A majority of choices made are guided by this one law: to accumulate as much capital as possible (after all, we live in a capitalist system).

This law is similar to other physical laws that govern our physical system e.g. "current likes to flow in the path of least resistance."

In a capitalist system, the mode of production is fueled by profit. Companies that aren't profitable or can't compete with larger companies cease to exist or get eaten up by larger corps. In turn, the wealth of these smaller companies get sucked into the larger companies, and they keep subsuming more and more. It's the natural tendency of the system. It's not like these companies really have a choice in the matter.. they're just operating within the confines and laws of the system.

In order to slow this tendency, an outside force must act on the system.


Google will likely go under if they are broken up.

The prevailing theory is that their ad success is solely due to data sharing throughout their service offerings.


The search engine alone is a money printing machine even without sophisticated ads.

As an example, if I search for 'nike' right now, the first result is an ad payed by Nike leading to nike.com, the second is an ad for an independent webshop selling Nike products and the third is the first actual search result (almost not on the screen anymore), again leading to nike.com

So, effectively Nike is paying Google (a lot) to get the result they would have if there were no ads, or if people would type 'nike.com' into the address bar instead of 'nike'.


I am shocked this isn't illegal yet. Basically what Google is doing in your example is selling Nike it's own trademark, with the subtle threat that if they don't, Google will use Nike's trademark to direct to a competitor instead.

The idea that Google can charge Nike to be the top result on a search for Nike is a form of subtle extortion, and I'd have to imagine trademark infringement. It's definitely a form of rent-seeking, as Google isn't actually helping advertise Nike: The people searching for it already knew where they wanted to go.


Trademarks are specific to context. Someone searching 'nike' could be looking for greek mythology. It's only trademark infringement when you use a word while engaging in the trade for which the trademark was registered

The same word can be (and frequently is) trademarked by multiple companies in different industries at the same time.


I would argue that when Google serves nike.com as the top real search result, over the nike.com ad it charges Nike to show, it's well aware of what context it's being used in. (I just tested, and Google does this, exactly. It stacks a pay-for-click Nike ad above Nike's home page, the top real result.


By context -- I am referring to the legally relevant context: use in trade. Google doesn't sell apparel, and they certainly don't sell apparel that is labelled 'Nike'.

Contrary to popular misconception, trademarks are not an exclusive right to a use word. They are an exclusive right to use a word for identification of a business' goods or services pertaining to particular trade.

If Google does not use the 'Nike' mark specifically to engage in one of the trades that Nike holds that trademark for, they are not infringing on the mark.

There may be another reason that Google's behavior here is not legal, but trademark infringement is not it.

Entertaining example of how trademarks are contextually scoped to a particular trade: https://en.wikipedia.org/wiki/Trademark#/media/File:LinuxWas...


>it's well aware of what context it's being used in.

I don't think so, I think it's just guessing. I just went and searched Nike to find the Greek goddess as suggested earlier, but it still showed me the shoes nike.com despite that being obviously wrong for what I wanted.


I have a suspicion a significant amount of their income comes from exactly that kind of extortion, and (very much relatedly) from tricking people who aren't Good at Computers into clicking ads that they think are search results, not from any machine-learning magic. At least as far as search ads are concerned.


I am very, very confident that this is true. I do not think people who actually know how the ad revenue is generated would like the public to know what percentage of Google's revenue is built on exploiting senior citizens' tendency to click on scammy ads, and trademark squatting such as this.

I spoke to a Googler a few days ago here about how a scam ad was being constantly perpetrated against seniors on Google's ad platform, screenshots included, here: https://news.ycombinator.com/item?id=24044837


I distinctly remember their experiments with inlining ads "ethically", and all the discussion about that by outsiders, and how the "ethically" part quietly went away and they settled on "clearly trying to trick people". I have no inside knowledge but can only speculate that those early experiments shot the profitability arrow so hard upward, and that every tweak making the results more deceptive did so even more, that they just couldn't resist becoming... well, what they became after that. And nearly all the difference between their numbers before and after those tweaks are, plainly, due to deception.

[EDIT] also and again directly related to their inlining of ads with search results, I've noticed a trend even among the reasonably tech-savvy to click an ad that is what they wanted... even when the natural result is just a couple entries under it. That's not sending people to the wrong place but it is gaining Google money from something that is exactly and entirely rent-seeking, as in it could go in an encyclopedia as a perfect and unequivocal real-world example.


Bear in mind designers at Google don't even realize/intend the harmful process they're doing too. If a "search page redesign" increases Google's revenue by 1%, it's a wild success... it doesn't really matter if the revenue when up by 1% because more people were "tricked" into clicking on ads. Some of the guilty parties might even just believe they were making the ads "look better".

It's also worth pointing out: Real search results actually go to the URL listed in the result. Ads can be redirected to third party tracking links which may or may not eventually send you to the correct real page. This has been exploited by scammers several times. Clicking the real search result is safer than clicking on the ad.


> It's also worth pointing out: Real search results actually go to the URL listed in the result. Ads can be redirected to third party tracking links which may or may not eventually send you to the correct real page. This has been exploited by scammers several times. Clicking the real search result is safer than clicking on the ad.

Oh, I know. I never, ever click ads even if they appear to (ultimately) go where I want, for exactly that reason, plus not wanting to give Google more scam-money. No one but us computer nerds know that, or should have to know that, though. (I'm aware I'm preaching to the choir here)


Using Nike as an example it's really just a judgement call on their part. If the next top bidder is a Nike retailer, they lose nothing if they don't bid on the term.

But they do it anyway, their call.

Of course there are examples where a company does stand to lose if they don't bid on their own name, and that sucks, but what's the solution? Give companies free top position on their name? How many variations of their name? Do they get related phrases too? What about when (as with Nike) the word can mean other things? What about when there are multiple claims on the same name? Does Nike the shoe company get a free spot over an educational page about Nike the goddess?

And so on... It's not an easy problem to solve, whereas letting companies choose what they want to bid on is simple.


Simple... and very profitable for Google. ;)


You can use a trademark as long as it's clear that you are not the owner of the trademark.

Sometimes there's an argument that a competitor buying an ad would be infringing. But google's definitely not infringing. The layman would never see this link and think it means that google search is a service from nike.

Definitely extortive though!


> So, effectively Nike is paying Google (a lot) to get the result they would have if there were no ads

Yes, but we live in a world with ads, so what they're actually paying for is making sure a competitor doesn't show up. That's why I consider branded keywords a racket.


DHH talks about this. https://mobile.twitter.com/jasonfried/status/116898696270498...

Edit oops: it’s not DHH, it’s Jason Fried - Basecamp’s other cofounder.


I like all the proposed solutions in that thread involving brandname keyword bans and giving ad accounts time-outs for violations and such when the actual fix is to go back to putting ads somewhere other than inline with search results, and making it very clear that they're ads. The move away from that was pure evil, but I'm sure it's made Google a lot of money. It's crazy it doesn't count as some sort of fraud.


I don't see it. All the spinoffs will presumably still use federated Google sign-ins. They can simply contract with the Ads spinoff to share user data.


> Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce.

There are probably many Googlers here who have sacrificed huge portions of their life and time getting the Google infrastructure to work. Forcing engineers to make changes to their creation is insane.

Personally, I’d rather not build anything than have someone force me to break up what I’ve built because I was too successful at building it.

I think we should all agree to just keep politics out of engineering. We build things because we like to, we should assume the same for Google engineers.


Engineers are forced by management to make changes to their creations anyway. What’s the difference between management telling an engineer to do something and the government telling management to tell an engineer to do something?


" Forcing engineers to make changes to their creation is insane." Really? Is it really insane to command employees to do what the company wants? One of the biggest issues google has always had is allowing engineers to do what they want to get them to work on various platforms. Do you know how many thousands of hidden commands are in gmail?


If you think Google isn't deeply involved in politics already, you are fooling yourself.


I don't work at Google but I had to take similar training too, where using words/phrases like 'dominant', 'market share', 'leading in a market' etc were discouraged. Specifically because the 'market' can be interpreted in a zillion different ways, especially for tech companies.

Don't think this kind of thing is new, rare or shocking.

Peter Thiel in Zero to One also gives examples of how a company can be considered a monopoly and not a monopoly by simply increasing the definition and size of the market that the company is operating in. (And how companies will generally try to avoid being classified as monopolies this way)

e.g. Google is a monopoly if you consider online advertising as the market, but if you stretch the market to all advertising (including print, radio, TV and billboards), Google might not be considered one.

Similarly Amazon in the e-commerce market vs general retail.


Yep. This is hardly new. I have been at Google since the mid 2000s and this stuff has been around at least since then. There was also a similar training when I was at Microsoft.

Btw, in the trainings I've taken, it's not just about avoiding specific words, but avoiding the thoughts behind those words. Our goal shouldn't be to "dominate the competition/market." The goal should be creating compelling experiences and products for our customers. Staying focused on the latter goal is long term better business and better global citizenship.

I think saying that Google does this to "head off regulators" is not really fair. That's like saying "asdfasgasdgasdg pays their taxes to head off the IRS." I guess? In some sense we all follow the law partly in order to avoid the consequences of not doing so but it seems pejorative to say it this way. It makes it sound like there are a lot of other people who are paying their taxes out of the goodness of their hearts, but I'm the bad person who is only doing so to avoid legal consequences.


> Our goal shouldn't be to "dominate the competition/market." The goal should be creating compelling experiences and products for our customers.

Googler also. I believe that the phrase used to capture the desired mindset is "respect the opportunity".


Ugh. I detest that phrase. :( It sounds so corporate.


Doesn't sound corporate to me at all. Corporate to me is things like "increase synergy". Respecting the opportunities available to you by showing respect for your competitors who are just like you at the end of the day seems like a pretty real and relatable recommendation.


If you need to remind yourself that you need to “respect the competition”, you’re probably a monopoly.


i disagree - to me, "respect the competition" means don't grow complacent.

ebay, for example, doesn't respect the competition (and has grown correspondingly complacent), and it's why sites like reverb are popping up and serving niches far better than ebay does.


I think it's about cultivating a healthier mindset about why you develop products, in particular avoiding the trap of zero sum, win/lose thinking.


> it's not just about avoiding specific words, but avoiding the thoughts behind those words.

People are always trying to control the thoughts of others by banning certain words. Is there any evidence it works? I've seen plenty of evidence it does not, as the new word simply takes on the meaning of the old one. Then that new word gets banned as well.


The intent was not to control the thoughts by banning the words. The intent was to discourage action based on thoughts of domination, because it is illegal. "These are some things you should not do. Writing down these words would indicate you are doing one of the proscribed actions do don't do that either."


> People are always trying to control the thoughts of others by banning certain words.

I can really only think of one truly banned word....


To give context, WalterBright is a libertarian with a clear bent to ignore white supremacy in western culture. He is also known for other reasons.


> Btw, in the trainings I've taken, it's not just about avoiding specific words, but avoiding the thoughts behind those words.

It could be to keep the trainings themselves from looking bad during discovery.


You can always come up with a sinister motivation for a good act. The question is whether there's evidence to support that surmise. I guess that's why sometimes it's best to look at the effects of the system rather than the intention behind it. Do the training actually have the effects that one would desire from them, if one had good intentions? At least in my case, the answer is yes. I have never thought about my work in terms of besting the competition. But then again I'm nobody important so what I think doesn't matter all that much. It would be interesting to know the mind of the executives whose thoughts on this subject might actually have an impact. Maybe during the upcoming lawsuits we'll be able to see more deeply into what they have been thinking.


> You can always come up with a sinister motivation for a good act.

You can also come up with a beneficial motivation for a sinister (or at least, not morally positive) act. (This is the one Google employs.) Google is a corporation, and it exists to extract money effectively from others to make it's shareholders rich.

If a corporation says it is doing something for the good of the public, it's because looking good has positive value for the corporate brand. To some degree, there is also value in convincing employees that they are benefiting society as well: They work harder and above requirements without you having to pay them more, and they'll defend and advocate for their employer on social media for free. ;) That, of course, also has a positive value for the corporate brand.

I definitely think the revealed internal emails (from all of Big Tech) will be exciting to see. It wasn't a surprise, for instance, but the emails about how Kindle purchases in iOS were shut down by Apple because of an Amazon ad about how Kindle books could come with you from iPhone to Android was very, very blunt.


[Google/corporations] exist to extract money effectively from others to make it's shareholders rich . . .

. . . by giving people something they want more than the money they're exchanging with the corporation. It's a positive sum game, at least in my estimation. But, yes, Google is not a charity, and I don't mean to pretend that it is more noble than it is. I'm not a charity either. I wouldn't do my work for free.

But I don't blame anyone for being suspicious of Google or any other corporation's behavior. It's important to verify that corporations are behaving, because there have been plenty of instances of corporate malfeasance in the past.


> there is also value in convincing employees that they are benefiting society as welll: They work harder and above requirements without you having to pay them more, and they'll defend and advocate for their employer on social media for free. ;)

Convincing one's employees of a particular perspective or belief has been a basic tactic of large corporations for decades. Tech culture disrupted this for a little bit, though.


Right, and it’s also a culture thing.

If you are operating in the Valley then you get startupy folks who really think in terms of “that’ll crush our competition”... Maybe that is an intrinsic sort of motivation, talking to yourself like that? But it’s not a great culture for the company as a whole because it creates an implicit assumption of a zero-sum game. Like strategically you want to instead be saying something like “they can have that space and we are going to differentiate ourselves by leading in this other space” then you foster a culture of creativity rather than competition. And that then infects the rest, like whether your employees are trying to squeak by on 4 hours of sleep—one culture says “fuck yes we gotta keep crushing it” and the other says “I need you to take a day off because I need you at your best and this is you running at 20%.”

Google is weird because the company internals seem to be structured for maximum recruitment; it is meant to be a developer’s paradise. Conventional companies are structured around their executives, it is a paradise for the leadership. Google culture is very focused on creating a paradise for the coders.

Not saying that it doesn't also limit Google’s liability, of course it does, so Legal probably also wants to limit discussion about beating the crap out of any other company in the market. But if you really think your employees are all artists, it is weird to hear artists get super-competitive.


they can have that space and we are going to differentiate ourselves by leading in this other space

Be careful with this one. It can be illegal to agree not to compete (INAL).


Could you elaborate on this? How would it be illegal to target a different market?


https://en.wikipedia.org/wiki/Cartel

Cartels are usually thought of as groups in the same market colluding, but it's not limited to that. Two companies colluding not to compete in their respective markets is still a cartel.


Right, but what was described is not collusion. It's just targeting a different market without much existing competition.


If Google colludes with Microsoft to decide each can have one market, free of competition, that would be illegal.

For example, Google trades the sub-thousand dollar laptop market (ceasing development of Chromebooks) for a monopoly in search.


> e.g. Google is a monopoly if you consider online advertising as the market, but if you stretch the market to all advertising (including print, radio, TV and billboards), Google might not be considered one.

Only a very narrow definition of online advertising would leave Google as a monopoly. Both Amazon and Facebook make a lot of money charging companies to promote products online.


> Courts do not require a literal monopoly before applying rules for single firm conduct; that term is used as shorthand for a firm with significant and durable market power — that is, the long term ability to raise price or exclude competitors. That is how that term is used here: a "monopolist" is a firm with significant and durable market power. Courts look at the firm's market share, but typically do not find monopoly power if the firm (or a group of firms acting in concert) has less than 50 percent of the sales of a particular product or service within a certain geographic area.[1]

1. https://www.ftc.gov/tips-advice/competition-guidance/guide-a...


Don't think this kind of thing is new, rare or shocking.

I think if you're entombed in the SV bubble, it might not be. But to the rest of the world, it's kind of head-shaking.

Maybe it's because of the industries I've worked in, but clarity of communication was valued, encouraged, and even something we had training in. Say what you mean, so misunderstandings don't lead to mistakes.

The public relations people were trained in what not to say, because that was their job. But for everyone else, internal expression wasn't squelched out of fear of external forces.


It really depends on how big the company you work at is and what space they work in.

A small company will usually not have that really. A large one has regulators looking at them and someone looking to sue to get a slice of the pie. Your emails and texts are subject to ending up in a legal case. They can use your stuff out of context and say you were doing something else. Remember they will lie about you. As they do not care about truth they want to win for their client (be it the gov or someone else). Can they get in trouble for that? Sure. But sometimes they just see if they can get away with it. Usually they just get told no, usually.

I have never worked a day in SV. This sort of training is common in big companies.


> But for everyone else, internal expression wasn't squelched out of fear of external forces.

I recall my reaction when doing that training; it was less a feeling of internal expression being restricted by force. But rather a vague feeling in the back of my mind, that if I care about the value of my stock comp, it probably makes sense to avoid putting my company in trouble by mistake.

I'm not saying that's the most rational reaction but that's what I recall feeling anyway (this was a few years ago). A slightly cynical take would perhaps be that my company bought my complicity for a few RSUs. :shrug:


> I think if you're entombed in the SV bubble, it might not be. But to the rest of the world, it's kind of head-shaking.

It's not an SV thing, it applies to any industry that is under close regulatory scrutiny.


Adam Levine mentioned this a few days ago in his column, when reporting on the Big Tech deposition. Bezos basically keeps expanding the definition of 'market' until he basically says Amazon can't be a monopoly since 99% of all sales in America don't go through Amazon, at which point there can never be a monopoly!


What's the point of saying "Peter Thiel says" when stating basic facts?

May as well say "Wikipedia says"

https://en.m.wikipedia.org/wiki/Monopoly

"Establishing dominance" section.


I had read the book, but not the Wikipedia article.


I think whether one finds this kind of newspeak shocking depends on how you view this:

Lens #1: This jumping through terminology hoops is a burden one has to undergo because of living in a litigious society. Having to resort to newspeak is not your fault, it's the government's, for creating all these rules and regulations.

Lens #2: If monopolies are bad for capitalism, then companies should not just in word but also in deed refrain from pursuing monopolization. Resorting to newspeak is hypocrisy: an attempt to continue monopolistic actions in practice while disclaiming them in speech.


Those both seem like bad lenses. A more positive approach is that it's not just about what you say, it's about what you do. People working at a powerful company shouldn't advocate doing things to crush competitors, not only for legal reasons, but because it's not right. And that's why there are laws.

As the comic says, with great power comes great responsibility.

But focusing on specific words adds concreteness for literal-minded folks who might otherwise talk that way out of habit.


Yes, because changing the words will change the facts - not. You can try to squirm all you want to try to make a monopoly into something that it isn't but that's a lot harder than it may seem and not everybody will be sensitive to such word games. Some might even say that such word games in and of themselves should constitute evidence that a company is a monopoly, it is knowingly misrepresenting the status quo as something that it isn't.


This isn't really uncommon. Part of my training at my current job for a large company which is decidedly not a monopoly includes these kind of suggestions, definitely directed towards avoiding anti-competitive legal issues. Honestly I think you could almost argue that it's helpful to change the language, because it keeps focus off of "crushing the competition" and on "serving the users best" (IIRC that's an exact example from my training).

Language matters in law, yes, but language also impacts company culture.


If you think this rule is silly because the lawyers ought to know that when an engineer says something that uses a term used colloquially that the lawyers will interpret legally, you aren't allowed to be pedantic when a non-programmer uses a programming term incorrectly either.

Like, you can't complain when someone says "growing exponentially" when they mean "growing really fast."

It's the same sort of problem, and it is unfortunate that the lawyers can do it. But It happens in every field, really.


Good point. But because being arrogant is more fun ...

... first a nitpick:

Exponential growth is a mathematics term and it's misused a lot by programmers and HN users (to mean "growing really fast.").

... then a wider sweeping comment:

Thanks to COVID-19, the understanding of what exponential growth means has probably increased a lot in the general population. It was quite funny to see people saying things like "Not only are the cases growing exponentially, but the daily increase is also growing exponentially."

Well, you can show them wolframalpha.com/input/?i=derivative+of+e%5Ex or there 10th class math books with all the content they knew they would never need once they left school.


or there[sic] 10th

Another reason to be wary of making corrections to someone else's work: Muphry's Law. https://en.m.wikipedia.org/wiki/Muphry%27s_law

FWIW when commenting on my phone, like I usually do, the autocorrect and I make some really cringeworthy typos and substitutions too.


All of these miscommunications are not a problem ultimately because this is the nature of communication. And lawyers especially know this.

The rule is silly because the idea was silly from the start. Some companies got themselves in trouble in the news due to their work emails. Let's pay someone (too much money) to establish some rules. That overpaid person now has to come up with something to justify getting that money. Result: a bunch of silliness and common sense wrapped up in a new training hassle for everyone.


Except that people really do lose lawsuits based on the lawyer's misinterpretation of what they say. The classic line from the Google-Oracle suit where a Google engineer says, "We need to license java" cost them millions of dollars in litigation, and some felt it was the smoking gun.

Rules that forbid such statements in the future aren't common sense, and make a lot of sense from a legal and financial perspective, annoying though they may be.


Isn’t this standard practice in big corps? These trainings are usually contracted to third parties and they tend to have similar content with small customizations for each company.


It's standard practice to tell employees things like "you shouldn't discuss these sensitive topics over email" or "we're philosophically opposed to lock-in so don't say our users are locked in". But I've worked in a couple of big tech corps, and I don't remember ever being handed a specific list of euphemisms I should use. (After all, what's the point of the euphemisms if an official document describes what they really mean?)


One of the leaked documents this article is based on explains a lot more of the background: https://www.documentcloud.org/documents/7016657-Five-Rules-o...

(Disclosure: I work for Google, speaking only for myself)


I immediately thought of mafia code words they would use to defeat wiretaps. Like:

Among the lines used were: "The sheep need shearing ... the shears need sharpening" or "The hay is ready." The Italian police said they do not believe the mafia members were discussing agricultural matters.

https://www.businessinsider.com/the-head-of-the-sicilian-maf...


I feel like in this case, regulators should be able to re-substitute any of the "good" terms, with the "bad" terms when citing email evidence, since clearly, Google has now shown that phrases like "valuable to users" are synonyms in their parlance for "network effects".


Not exactly. The key idea of the training is that rank-and-file SWEs don't realize that words have legal meanings separate from their colloquial meanings, and they can cause undue trouble for the company and for themselves with poor word-choice. It's more about "Don't say the product is 'dominating the market' when you don't have any idea what your product's percent share is in the market or, for that matter, how 'market' is defined, because if your email comes out in a subpoena it won't come out in the context that makes it clear you're talking out your ass."

Doug Melamed's comments in the article have the right idea:

""" “It’s not just trying to hide the truth, it’s really trying to avoid the use of inflammatory language,” said Melamed, a former acting assistant attorney general in charge of the antitrust division at the U.S. Department of Justice. “The use of the word ‘market’ could be very innocent, but it could be misleading and provocative to an antitrust enforcer. Antitrust enforcers really get exercised when they think someone dominates a market.” """


Right. People are reading into this way too much, in reality it looks like pretty standard "don't use legalese when you're not a lawyer" type training that I've seen at every BigCo.


Well, it also has the desirable side effect of heading off writing colorful things that look bad if leaked to the public. A classic example is Microsoft's "knife the baby" moment back in the late '90s: https://www.theregister.com/1998/11/06/were_talking_about_kn...


The Hal Varian quote there is a good illustration of this. If it was an attorney representing Google talking over e-mail, such an aside would be protected by attorney-client privilege and would not have been subject to discovery. It is a banal and funny comment that would have been fine to make in-person. It should not have been made in writing.

This is why stuff like Slack is like opening a Lebanese fertilizer storage warehouse right next to your fireworks factory. It is just stupid to make even more of your company communications subject to discovery. Email and note-taking software is bad and dangerous enough.


These terms are not 'legalise' rather, they are just specific terms with specific meaning that can be construed by regulators to mean certain things.

G is basically saying: "Don't actually say in writing that we are trying to take 100% market share, because that won't be perceived well"

Edit: for the most part, 'legalese' is just 'precise English', ie words mean what they mean.


Yeah, I feel like people are making a bigger deal out of this than it deserves.

This is just sound legal advice; don't say things in writing that can be taken out of context.

Google might be guilty of anti-trust behavior, and it is ok to be upset at them for that.

These guidelines, however, are not indicative of anti-trust behavior.


On the other hand, couldn't the document be used to suggest that the company is complicit in anti-competitive behaviour?

Keep in mind, it is addressing the use of language rather than discussing the company's motivations or objectives. To use one of the less inflammative examples from the the first excerpt, they aren't claiming that the company's objective is to "improve our product/service". They are claiming that there are ways to say "get ahead of competitors" with fewer legal implications.

While a simple "search and replace" cannot be used, it sanctions the use of non-inflammatory language to conceal intent by the company rather than disproving motivation.


I think this effort reflects the reality that anti-trust is ill defined and matters are decided by circumstantial "evidence".

The speculation of a rank and file employee on market share should have exactly zero bearing on antitrust, but it will be trotted out there for headlines anyway.


Did you read the slide that says

> "Bad: the defensive rationale for this acquisition is clear: Get ahead of the competition and cut off their access to the target's product"

> "Good: The rationale for this acquisition is clear: Integrate the target with Google and improve our products for users"

It takes some pretty serious mental gymnastics to believe someone writing a document explaining why Google should perform an acquisition, would not know why Google should perform an acquisition.


But they do know why they're performing the acquisition: to integrate the target with Google and improve products for users.


It wouldn't work because the mapping isn't one-to-one, it's many-to-one. Google is essentially taking advantage of the fact that it's basically impossible to reliably reverse a many-to-one function.

That is to say, you can never know which "good" instances are actually used in an honest way, and which are used in the "bad" way — and justice systems never go on to assume that all "good" instances of anything must be a substitution for the "bad" term.


At Amazon, all employees are trained not to use the words: "marketplace", "platform", and a few others.


Amazon's products are identified by a key made of marketplace and ASIN, so that's strange. Amazons "focus on the customer" principle turned out to be sham as they are acutely focused on their competitors, whether Quidsi, Walmart, or Amazon sellers.


Reminds me of Peter Thiel's observation that monopolies lie.[1] Also, IANAL but I can't imagine a memo/training that says not to use certain words because of "regulatory issues" is not itself evidence that Google knows of its own monopolistic status.

[1] https://www.wsj.com/articles/peter-thiel-competition-is-for-...


Surprisingly, it's not. It's evidence that Google knows some words are open to misinterpretation, so engineers are encouraged to use more accurate words and not stray into words with colloquial meanings differing from their legal meanings (because subpoenas lack context).

If I say I'm "killing it" this week, I'm not committing homicide.


Well, I’ve never known any colloquial use of “network effects”, it’s quite the technical term with well defined meaning.


Agreed. See also "barriers to entry". But the one that irks me the most is —

> "We’ve got lots of competitors, so don’t assume we control or dominate any market."

So basically... lie?. In search (their bread and butter), they certainly don't have "lots" of competitors and they absolutely do "dominate" the market.

It's one thing to discourage the use of certain phrases. It's quite another to encourage blatant dishonesty.


An awful lot of Googlers don't work in search.


Right, and they seem to be encouraged to be dishonest about Google's position in search.

Anyways, a majority of Google's non-search products are intrinsically tied to their search product so it's still relevant.


That isn't a lie it is more a memento mori sort of thing and well founded paranoia. Take MySpace as an example. If they really messed up do you think bing or duckduckgo wouldn't eat their lunch? The graveyards are filled with indispensable men.


It seems intentionally worded to provide plausible deniability. It's one thing to say "don't assume we will always dominate search" and another to say "don't assume we currently dominate search".

The latter "assumption" is an outright falsehood (in the context of the overall search market).


Bizzarely heurestic delusions and self-deception can be useful for taking to heart something which isn't literally true.

Take "the gun is always loaded" rule. Now nobody thinks it means that if they pull the trigger repeatedly on a gun with no ammo they will cause an empty gun to occasionally fire a shot or two after cycling through it many time. It means always treating it as such to avoid any slipups from when it is "not loaded" when it has one in the chamber even after removing the magazine, one loaded from the magazine after clearing the chamber before removing the magazine, etc. The costs of treating an empty gun you don't intend to use as loaded are nothing compared to a mishandling so it is perfectly rational.

In this case it could be argued a similiar thing for the company. Assuming they currently dominate search when there are up and coming ones, subsections which don't technically fit the same category and can take them by surprise (voice assistants like Alexa taking that role is quite optimistic but plauisble enough that consumers could wind up preferring it), or similiar?

It would be "monopolistic" in that it helps keep them on top but "anybody" can self-delude to drive their actions so it isn't anticompetitive any more than say being the only jeweler in the country with fifty years of experience is.


Fair points, and I agree this mindset is probably a good one to have.

But the document in question is not a training document for the purpose of curtailing employee complacency and remaining vigilant in the face of competition. It's a document specifically discussing ways to avoid anti-trust regulators. That's an important distinction.

If employees already believed it because of their internal training, there'd be no need to "remind" them what not to say.


> so engineers are encouraged to use more accurate words

These words aren't more accurate in all cases. In some cases these substitutions will be/are used they are less accurate or misleading.


Everything is evidence of something. It’s just up to the jury to decide what that something is.


I think the main message is “Assume every document will become public.”

It's not a natural thing to think about when messaging with a teammate.


That isn't surprising - lawyers love to pull propaganda Kafkatraps based on twistings of words and only taking what they want to hear/say as opposed to the whole message. And former lawyers make up those grandstanders.


Anyone who has ever worked in trading in the past decade should be familiar with these sort of rules. Anything that you say that can remotely be interpreted as manipulating the market will get you written up or possibly fired. It could be something as innocuous as "Tesla's valuation is insane right now."


as in the Billions tv-series when they actually do influence the market, they'd say: "I am not uncertain that [blabla]"


Every publicly traded company I've ever worked for made similar requests of words we shouldn't use, including "dominant" when talking about one of our products that had a large market share. I don't think this caution is unique to Google.


I have worked in blockchain / cryptocurrency for years. Remember team - it's a "utility token", not a "security"! Words matter!


I wonder where the line is. Is it ok for a startup like slack to attempt to 'kill email'? Is it ok for a startup like Slack to try to 'destroy' email? What about destroying Outlook specifically?

I'm also wondering to what degree this would apply if Google didn't have so many products; would it be ok for Gmail employees to destroy Outlook if Gmail was its own company, separate from all the rest?

As a personally competitive person, I tend to be motivated by a drive to destroy the competition and deprive them of business (through fantastic products and great customer service), whether that competition is internal or external to the business. The existence of upstart competitors is explicitly licensed by the failure of established competitors to failing to serve their customers well.

If you work at a place like Microsoft Office in 2010, do you just continue to excuse the existence of things like Google Docs? Would it be wrong to destroy their business prospects by getting in on the online collaborative editing game? Would it have been wrong to do so in 2003, when internal engineers prototyped it, before Google Docs was released?

Many companies that were dominant have seen their near-monopoly positions eroded by new entrants; I can't help but think they were hurt by lack of a drive to destroy the competition and keep it that way. One example seems to be Adobe Illustrator and Sketch. It would have been better for consumers if Adobe just came out with its newer tools like XD, rather than waiting for Sketch to force their hand.

I'm wondering where the line is between healthy competitive drive and anticompetitive behavior/thinking.


It is ok for a startup to want to 'kill' competitors. Regulators don't care if companies WANT to establish a monopoly.

They only care if they succeed.


What if years later you do succeed?


Regulators are looking for language that abuses an existing monopoly. Intent to create a monopoly is not evidence for the existence of one.


No but once regulators determine (based on other criteria) that it IS a monopoly, then all those internal messages that seemed to agree with that will be used as proof that the company "knew" about it so the fines will be much larger.


The real gist is you should assume all internal communication will one day be cited (even out of context) in front of a Congressional committee, so even what you think is harmless speculation, a joke, a casual opinion, or even sarcasm, could have you testifying under oath.


This same guidance is at every very large company. What a nothingburger


This is common, any big size tech company with a good antitrust lawyer would do something like this. Nothing shocking about this at all.


In fact suprised they have only just done this!


Isn't this just a form of theater? Word swapping doesn't change anything about the actual reality.


Exactly. The title even notes that this is simply a move to head off regulators


> "Bad: the defensive rationale for this acquisition is clear: Get ahead of the competition and cut off their access to the target's product"

> "Good: The rationale for this acquisition is clear: Integrate the target with Google and improve our products for users"

The conversion is very lossy so will likely hamstring Google's business processes, both immediately and by eventual morphing of the vague-wording culture into the bullshit culture.

Which it seems would serve the purpose of promoting competition - selectively handicapping companies big enough to worry about antitrust makes room for smaller and nimbler companies.


I know this is not much, but when I joined de-Googlefication initiative, I felt it's a right thing to do. Firefox with uBlock Origin, DuckDuckGo, Lineage OS on the smartphone. When I have to use Google products, say Maps or YouTube,I do it from separate "compartment". It's not that much. But when I stopped feeling like I'm a victim of strangely sophisticated, odd and dystopian evil, openly claiming "we are the internet", killing companies and products, I felt like I'm a part of a small, statistically insignificant, but determined and well-informed resistance.


I don't see how this is relevant to the article. Does every submission referring to Google need a thread about how to stop using their products?


>We use the term ‘User Preference for Google Search’ and never the term market share, >Instead of “market,” employees may say “industry,” “space,” “area,” or simply cite the region, according to the presentation.

Sometimes I feel like people take language far too literally and forget that the point of.language is communication and intent, changing the language really doesn't change the meaning behind anything, but because we live in a world where every word is being taken increasingly literally without any search for intent or meaning, we end up with utter nonsense like this.


"Dominance rule" is a common term in the science of combinatorial optimization. It felt a awkward when I first heard it, but the word fits pretty well to its meaning. I don't think it is a good idea to change such common terms because of such trends or even "Excel" (due to Excel's autocorrect, certain gene names are taboo and get renamed https://news.ycombinator.com/item?id=24070385)


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: