31
I haven't thought enough about it to endorse these ideas, but it seems like a really interesting discussion and one the open source development community ought to be thinking about
A few ideas for what this could look like:
- A modern, content-focused subset of HTML and CSS. I think companies should be trusted to brand and promote themselves, and the failure to make this part of the RSS specification may be one factor that might have turned off publishers from investing more deeply into RSS. So, let’s give it to them in the form of some basic design, including access to fonts, graphics, and simple layout intended for a narrow space. The content should be static, to be clear—no JavaScript here—but it should allow for enough flexibility that if people want to experiment, they can. We already have an existing spec that does much of this—the open-source AMP standard, developed primarily by Google—though I understand if we don’t want to use it, due to its controversial history. Whatever this theoretical looks like, it should be flexible and easy for end users to implement.
- Features to encourage use of rich text. Adding features like data visualizations, graphics, and embedded video that are not part of the regular RSS specification could add appeal to this new format by offering something that newsletters do not have, while giving it advantages over a standard RSS feed.
- Built-in access management. If you, as a publisher, want to gate all or part of a feed item, you can do so, and offer your own integration as to how to resolve the block. Essentially, build subscriptions or regwalls directly into the feed—and make it so that you don’t have to work with a middleman like a Substack to do so. Don’t want the bots or the LLMs to access your life’s work? Build in a regwall.
- Built-in integrations for distribution. RSS is built for distribution, but I wonder if this new thing I’m suggesting should talk ActivityPub, or easy to distribute in a newsletter format for people who still want to read in their inbox. Make it so that people can follow you wherever they’re comfortable, rather than being forced to read in a newsletter format, or a social media format.
- Limited, but useful, analytics. You should know how many people read your newsletters, and you should know how they’re read, but you probably shouldn’t know much else. Podcasting has benefited from a lack of data poisoning the well—and honestly, resetting the conversation around data could really help strengthen the content ecosystem at this juncture.
Archived at https://web.archive.org/web/20240207155759/https://tedium.co/2024/02/06/rss-creator-economy-rethink/
I think this article starts with an interesting premise (basically: RSS works to support podcast content creators, how can we make it work for written content creators?) and... misses the point.
Podcasts can make a lot of money off of sponsors and advertising that listeners are less likely to skip over. Maybe you're busy doing something else when the ad comes on, maybe you don't clue in that it's an ad right away, maybe you just don't know how long it is so as you skip around you hear enough anyways. Advertising works in an audio format.
Text content can't advertise as effectively. Your eyes can just skip over to the next part you care about. Adblockers work pretty well. A reader is way less likely to engage with advertisement, so it's going to pay less, so written content creators are going to make less. Usually to the point that they can't support themselves with it.
None of the author's points really address that. The problem isn't with the RSS standard, it's with the format and how it can make money.
I get the impression that for most people, text also isn’t the preferred format. Many prefer video/audio. Many people I know will put on a podcast in the background while they work, commute, cook, game, etc, leading to more ads per piece of content. They probably also can get more per ad due to targeting when compared to Google ads.