Categories
Business Technic

It's right there in the code

<![CDATA[1361b: rss advertising: look at the rss and atom specs. what don’t you see? a place for advertisements. if you want it to exist, build it. reader and aggregator authors can decide whether or not to implement support for it, then. some will, some won’t. readers and aggregators emit http headers. solutions can be engineered. […]

<![CDATA[1361b: rss advertising:

look at the rss and atom specs. what don’t you see? a place for advertisements. if you want it to exist, build it. reader and aggregator authors can decide whether or not to implement support for it, then. some will, some won’t. readers and aggregators emit http headers. solutions can be engineered.

the way you’re doing it now, will not last. you’re not asking. you’re foisting. people will resent it.

Per my earlier exchange with the Lemur…. The question remains, how else to make money from RSS if making money as a publisher is a goal?]]>

2 replies on “It's right there in the code”

The short answer is: you charge for it, instead of inserting ads. The gist of what I’d alluded to was: use http authentication and a subscriber database. But you can broker the authentication (and content delivery) to an external agent, too, and use any means you like to perform the authentication.

Most of what I object to revolves around the introduction of a third party advertiser that then foists ads from N other parties into the mix. The traditional advertising industry is something I regard as inherently parasitic. And in most cases, the advertisements themselves, are nothing more or less than superfluous. But that’s just my opinion.

There are a lot of potential answers, but IMO the current “right” one is:

You work, collectively with peers, towards the establishment of relevant standards that enable you to do what you want to do.

The OPA isn’t addressing this as far as I know, and the only other potentially relevant body (the IAB) hasn’t addressed it either (which is probably good; the publishers ought to take the lead on this).

In the absence of specifications and standards, we’ll have chaos. I’m not opposed to chaos; it is usually where the good and innovative stuff comes from, but a lot of it needs to be kicked to the side; inserting ads into the body elements of RSS is one such example. That’s not innovative. That’s just lazy and annoying.

Ideally an organization of responsible folks (e.g. techs) in the publishing industry would look at that chaos, extract what was good and what worked, and hammer it into some form of specs and standards.

I’m not suggesting the publishing industry put themselves at the mercy of the W3C, the ATOM chairs or Dave Winer (though again, ideally… they would) but that they embrace and extend. Sorry, I know that term carries baggage. But it can work.

I, as the author of a piece of aggregation software, can elect whether or not to include advertising content when I pull a feed. The aggregation software will identify itself to the publisher; they in turn can elect to tell me “no. you’re not carrying ads; here, have the ‘lite’ version of our feed instead’. This can be negotiated via HTTP.

Similarly, subscription tokens can be exchanged and authenticated, between a client reader and a publisher server using existing/currently deployed protocols and capabilities.

I would be rather surprised if, in fact, there is no-one working on paid-subscription systems for syndicated content in RSS, ATOM, and future formats, at this point in time.

Comments are closed.