[Cwizard]

Can anyone explain why? I see almost no downside in keeping it running? Infra costs must be minor, there is no licensing costs, it’s a simple app so I would assume very little developer cost.

The upside is that Android can come with a ‘native’ podcast player. Just like iOS comes with a native player.

A big downside with shutting it down is that it reinforces the idea that Google products are eventually killed so don’t rely on them.

[taeric]

Google being a giant monorepo is almost certainly at play here. Maintenance costs are always high on products. But upgrades and constant progress on underlying technology is, itself, often a large part of the need for maintenance.

Please don't take this as an argument against monorepo. It is a discussion point there, but even if you view this as largely negative, I assert a lot of these negatives come with the size of Google.

[msm_]

Interesting, i've always considered monorepo to be a maintainability win. Your code doesn't rot (as much) because it's constantly rebuilt and tested. When someone improves some downstream code (for example makes some code faster or safer) you get the benefits immediately. And most importantly - you can do huge interface-breaking refactorings on the whole codebase at once, without versioning dance. For example you can remove a parameter from some function in the library and make sure all clients still work, atomically. I think this is a huge maintainability win - as long as you actually want to maintain something and not let it rot.

But really, do you have a choice? Sooner or later someone finds a security bug in the code and you actually have to dig out the code and deploy an update.

[taeric]

The catch, of course, is a lot of the "migrate to newer versions" of some libraries brings in new features. These new features can be the source of new security concerns. Especially when added with a lot of the changes requiring some reworking on how things are used for the migration.

This would be akin to trying to move a car to a system that shuts off during stops. Totally doable, but requires a massive change in how reliant passive systems are on the serpentine belt/alternator for power.

[digging]

I'm not against monorepos but this seems like such an obvious case of one being inappropriate. I'm very curious why it's important to G to maintain their products in a colossal monorepo. Obviously they have very smart people working on these issues, but they're also not infallible.

[crazygringo]

> I see almost no downside in keeping it running?

The way the Google monorepo works, there's actually more cost in keeping things running than you would think.

You have to keep up-to-date with all of the library and platform upgrades and occasional migrations that are happening internally that your product is built on.

[kredd]

Replaced by YouTube podcasts, feels like they’re consolidating all entertainment under YT brand.

[stuartd]

Keeping it going requires engineering resources which I imagine they want to redeploy

[i_am_jl]

I imagine Google sees a benefit in funneling people into YouTube Music's ecosystem, ostensibly to sell YouTube Premium subscriptions.

[benf76]

It’s big tech war on rss / anything open. They want everything in their walled gardens // YouTube