The Irony of Writing This on LinkedIn

I learnt a new concept this week. Or rather, I re-learnt an old one. RSS — Really Simple Syndication — the technology that, in the mid-2000s, was going to democratise how we consumed information on the internet. You subscribed to feeds. Content came to you. You chose what to read, when to read it, with no algorithm deciding what you should see. It was, for a brief and glorious period, how the web worked.

Then social media arrived, and we collectively decided that we'd rather have an algorithm choose for us.

I think about this more than is probably healthy.

The thing that prompted this particular bout of nostalgia was a practical problem. I subscribe to several LinkedIn newsletters — thoughtful people writing about technology, public sector, leadership — and I kept missing editions. LinkedIn's notification system is, to put it charitably, inconsistent. Sometimes I'd get an email. Sometimes I wouldn't. Sometimes the notification would appear three days after publication, by which point the conversation had moved on. (I must admit that my notification settings are probably a mess, but I'm not entirely convinced that's the whole explanation.)

It seemed to me that this was a solved problem. Or at least, it had been — in 2005.

The Hundred-Line Solution

So I built a thing. linkedin-newsletter-rss is a small tool that takes any public LinkedIn newsletter and converts it into an RSS feed. You take the newsletter ID from the URL, append it to linkedinrss.cns.me, and point your RSS reader at the result. The entire thing is about a hundred lines of JavaScript, running on a Cloudflare Worker, costing essentially nothing to operate.

It scrapes the newsletter page, extracts the articles (including full content, author, publication date, and cover images), and generates a standards-compliant RSS feed. It's not clever. It's not innovative. It's the kind of plumbing that arguably shouldn't need to exist — but does, because we've built platforms that are excellent at capturing attention and rather less good at letting people consume content on their own terms.

And yet.

Thirty-two people have starred the repository on GitHub. Twelve have forked it to run their own instances. For a hundred lines of code that does something the web knew how to do twenty years ago, that's a surprising amount of interest — and I think it tells us something about the state of how we share and consume professional knowledge.

Walled Gardens and Open Standards

Tim Berners-Lee built the World Wide Web on open standards. HTML, HTTP, URLs — protocols that anyone could implement, that no single company controlled. RSS was part of that tradition. It was an open format, supported by every browser, every blogging platform, every news site. The web was, by design, a place where content flowed freely between systems.

It seems to me likely that we've drifted rather far from that vision. We now write our professional insights on platforms that actively discourage you from leaving. We publish content behind authentication walls, in feeds controlled by algorithms we don't understand, in formats that can't be exported or syndicated. The knowledge is there, but it's trapped — visible only when the platform decides to show it to you.

However, I believe there's a parallel here to something I think about in my day job on the National Digital Exchange. One of the challenges we face across UK public sector technology is that valuable work gets trapped inside organisational silos — not because anyone intends to hoard it, but because the systems we use don't make sharing the default. A council in Devon builds a planning tool. A council in Durham builds the same thing six months later. Neither knows the other exists.

We've been tackling this from several angles: cataloguing 24,500 government repositories so we can see what's out there, building semantic search so teams can find each other's work, and providing free cloud sandboxes through NDX:Try so local government can experiment without procurement. Want to try an AI-powered council chatbot that answers residents' queries? Fifteen minutes. Need to test document translation into Easy Read and multiple languages? Fifteen minutes. Every use case is shared openly.

The common thread is the same one that RSS represented twenty years ago: making information flow freely, in open formats, so that people can consume and build on it in whatever way works for them. We should prefer open over closed, syndication over silos, standards over proprietary lock-in. (This is also, I should note, why the repos.json data behind the leaderboard is published as a plain JSON file with a stable URL — so anyone can build on it without asking permission.)

The RSS Reader as an Act of Resistance

I think there's something quietly radical about using an RSS reader in 2026. It's a small assertion that we should get to choose what we read, when we read it, without an algorithm deciding whether a particular post deserves our attention based on its engagement metrics. It's the same impulse that drives coding in the open, publishing data in open formats, and building tools that interoperate rather than lock in.

Perhaps I'm reading too much into a hundred lines of JavaScript that scrapes a website. (I have been accused of this before.) But I think the instinct matters: when a platform doesn't do what you need, you can build the bridge yourself, publish it openly, and let others use it too. That's how the web was supposed to work. That's how we should build public services.

If you'd like to follow any LinkedIn newsletter via RSS, the tool is free and the source code is open. There is a certain irony in publishing this on LinkedIn, but perhaps that's part of the point.

The Hundred-Line Solution

Walled Gardens and Open Standards

The RSS Reader as an Act of Resistance

Links