I would guess that rss doesn’t show up in their JavaScript-driven web analytics so they mistakenly think no one uses it.
So they have some stupid conversation like “patching the rss code will take 5 units of labor, but I want to cyberdize the whoozit that also takes 5 units. Does anyone even care about rss and use it? Oh the analytics show zero. Let’s de prioritize that.”
I think the bigger problem is people on the team not using rss and knowing this is super dumb. And PMs now knowing the world their metrics don’t track.
Seems to kind with google once being great and now full of fat rich peoples’ kids just riding the slow and gradual suck. (Based on the theory that smart people have weak, pampered kids; then weak kids get destroyed by jerk fascists; then jerk fascists get overturned by smart people and the cycle completes).
Of course the dumb kids think they are geniuses because their parents are part. And the parents want to pretend their kids are smart. Etc etc
I have to imagine that for a chrome releases and developer updates blog that this has absolutely nothing to do with ensuring someone uses search or ads and more just plain priorities and no one bothering to add RSS after they upgraded the site. Occam's razor and all that
Or maybe they gaslight that as the reason. Their blog post talks about how they don’t have resources and they are prioritizing.
So I agree the real reason is that google doesnt want people using minimally tracked file downloads and thinks they can shovel people towards their more data rich analytics and content consumption.
I think you're falling prey to Hanlon's Razor. What probably happened here is something approaching the following conversation:
$PM: Hey $ENGINEER, it looks like this "arr ess ess" thingy has very few users, do you know what it does?
$ENGINEER: Yeah, it's a web standard that publishes a feed of updates to our website. It's kind of neat actually, if you have an RSS read--
$PM (waving hands): okay skip the wikipedia article, that's fine; but does it generate revenue?
$ENGINEER (blinking): uh...no, it doesn't. Anyone can query our RSS feed and update their local cache of articles and read them later, it's actually really useful if you're ever somewhere without interne--
$PM: So we can't monetize this?
$ENGINEER: ...no, this is an RSS feed for a tech blog. We can't monetize this.
$PM: If you remove this and integrate $FEATURE on $PAID_SERVICE, I'll write you a better peer review this year. It's reducing tech debt right? This sounds like an old school thing anyway, I've never even heard of it!
> I would guess that rss doesn’t show up in their JavaScript-driven web analytics so they mistakenly think no one uses it.
All it would take is ?utm_source=rss, but betcha readers would start stripping that, because once you've started abusing everything, anything will look like abuse.
bingo; you just found the kpi. everything needs a kpi.
Facebook did that with emails - slowly remove all the content to turn them into traffic generators for the feed team.
Hilariously when they launched workplace, the corporate productive product, they did the same thing, viciously spamming you with emails that have the first 15 characters of the workplace post that triggered them (and 2 more for the notification and every comment).
zero respect for your time, everything must drive traffic.
It probably is about analytics, you're right. But to be fair, maintaining RSS feeds requires some resources, even if nominal. If the usage of RSS is low or declining, the cost of maintaining it might not justify the benefits, leading to a decision to allocate resources elsewhere.
I find that rss output is just part of good architecture so it’s sort of something I’m going to make even if no one uses it. Because I want to have some static form of syndication that processes can check.
Of course there is some nominal cost to exposing the uris or something, but anyone complaining about this would be weird to complain. Especially given all the other odd feature requests going on.
Bro, what cost in maintaining? Maybe if you're building like it's the '90s and doing it by hand.
The static site generator I use (Pelican) can produce templated RSS feeds that are exactly to my liking. If I can use that off-the-shelf stuff for a small blog, then it's trivial to put together a template and plug in database data on relevant events. Could even just run a cronjob that tracks the site daily and forget about it, most people would not care.
More likely it is "analytics shows that only 0.01% of our readership arrives to us via RSS" or "an A/B experiment shows that the RSS feed only increases readership by 0.01%".
In the real world, the options aren't just an RSS feed vs. "load the page daily". Readers also come from search engines, social media, link aggregators and non-RSS news feeds.
Depending on the content of the RSS they were publishing it was either an exceprt or abstract of the article, or the whole article itself.
If it was the latter, it's almost certainly a cynical drive to get more 'page impressions' by making people visit the actual website to read the blog posts.
Not if you do things the Google way. What takes you 30 minutes takes them 30 weeks.
Google has two big strengths: (1) they build systems at huge scale and (2) they are wildly profitably.
(2) is also weakness because it means they can afford to have highly inefficient processes. It is the reason why Google keeps pushing trash software on the world like Kubernetes (takes that 30 minute project and multiples it by a lot all by itself) as well as cargo cult management processes like OKRs. (Ever see what happens to a startup that is just treading water when management stops everything and introduces a layer of meaningless paperwork?)
"Surely my user base will continue coming to the landing page of my website to check for updates every day."