I think you are partly right here. The problem I see is the use of the word "they". It's a big company, and different people have different goals.

IME (I worked there for a long time, but no longer), individual (and small groups of) engineers with a passion for OSS drive publishing/sharing.

Execs with the interests you outline approve/agree to the sharing.

The motivations are not monolithic, and a corporation is not a person, it's a group of people.

Well, they are still part of a hierarchy serving the goals of the owners (which for a public company means profit) of course that boils down to different things in different groups and I listed different goals for different projects they are involved in. But on a first assumption I, as an external, don't care much about internal structures. (Maybe I care a bit about Google vs. Alphabet, but not by much)

Some open source projects might also be (partially) for employee retention. Letting some high-performing developer(s) open source internally developed projects because it is what they want to do. Might be particularly relevant for developer tooling where commercial potential is generally quite low.

> Publishing libraries like protobuf and abseil serves to drive standards in directions they like.

Could you elaborate on why they care? Do they have some kind of competitive advantage when it comes to Protobuf?

For abseil this is a bit simpler, so I start there: On the one hand it is a library they publish so that other libraries they publish (Googletest, protobuf, ..) can use it on the other hand it drives development of the C++ standard and adoption according to their needs ("see our hashmap is faster and more efficient, make it part of the standard! (Then we don't have to maintain it anymore, but compiler vendors will)")

With things like protobuf/grcp it's a bit harder, but if they define the standard for data exchange between machines they can eventually - use it as apart of their search indexer - incorporate external services into their products while keeping their standard architecture - integrate acquired software into their stack (you hope being acquired by google? Prepare ;) ) - it reduces risk of alternative approaches from becoming defaults, which could harm Google's integration wishes - if job candidates are used to protobuf there is one thing less to reach a new hire

This certainly isn't a conclusive list, and I can't judge relevance of each for their decision, but those things certainly impact the decision aside from "we think it's cool"

Moats, moats everywhere.