I went to the RSS Neighborhood event on Monday, where Scott Young did a great job guiding a free form discussion about RSS in general. The group was pretty varied, but most had some knowledge about what RSS is already. Some people were looking for the description of what exactly RSS should be used for and how it is different than existing methods, and the group never came to a consensus on that. I personally think that’s a good thing. RSS is not a technology with existing well defined boundaries. It’s at the start of adoption for a whole new set of tasks. RSS was originally developed at Netscape to allow embedding headlines from one site into a portal site. We’re seeing it creep out into new areas of usage. I asked about adoption numbers, how many people read RSS of any sort? The rough response was 1% of the “internet public” consume RSS. Bill Flitter is supposed to get back to me with info about where that number came from, I suspect that even that number is somewhat inflated. Other people asked about the format itself, why use RSS instead of other delivery methods? There is no good answer to questions like that. I personally think that RSS is too early in the adoption cycle for us to be able to make predictions about what effect it will have on the enterprise. As such, there is no umbrella answer to when you should abandon other techniques and start looking at RSS. So why bother with talking about RSS at all?
I actually have a couple of answers to that question. I’ll start with the very simple technical one. The first one is that RSS fits well into the existing web server based application structure. Lets take a look at comparing delivering updates via email with exposing an RSS feed for a blog. With email, first we have to provide a way for users to sign up for the updates, so we probably need an extra form or two, and a data store for those email addresses. Then we need a component that actually delivers email, there are lots and many of them are very well developed, but it’s still another component which the producer needs to set up. “So what?” you say, “the mail notifications feature should be built into the package I use to publish my blog, I don’t have to worry about it at all.” This is the argument that programmers and administrators love to use. But the simple fact is the more interacting components there are to a system, the harder it is to debug. Sometimes the setup might be smooth as silk, but other times a potential new user might be frustrated and just give up. On the other hand, RSS feed generation doesn’t include any new servers or a new transport protocol. For most setups, producing RSS uses exactly the same underlying services as delivering HTML. It might seem like a stupid minor point, but the net result is that generating RSS is easier for the average producer. And in this new world of peer to peer publishing, with literally hundreds of thousands of content producers, anything we can do to make life simpler for them enjoys a fantastic economy of scale. So one of the geek answers is that delivering RSS shares much of the same infrastructure with delivering HTML. But I think this is really just a minor issue compared to the shift in mindset that has come along with the increased uptake of RSS.
What the hell does that mean? What shift in mindset? That’s one of those questions that doesn’t have an absolute answer, yet. But it does seem like people think differently about consuming an RSS feed than they do joining an email list. Is it because they can read feeds apart from their normal email? Or because they don’t have to give away their address? Or because they can merge posts from feeds and read as a group? Or any of a thousand other differences? At this point no one can say definitively. Will RSS even be the format used for syndication? Also hard to say. Will syndication ever really become widespread? Tough call. It is looking like it eventually will reach a large public user base. And if it does there are some issues that potential producers of feeds should be starting to think about. Issues like how to we control our corporate image? Who should be given the right to produce a feed and who should not? How do we apply a security policy to restrict the flow of information if we do have multiple producers within the organization? All of these are good questions to start asking now. These are the things that should be under consideration.
What I find disturbing is the number of people who are ready to throw themselves on one side or the other. Some people say that RSS is the future, absolutely. Others say that RSS is no different than other technologies, so they shouldn’t bother. Still others say that RSS is the wrong choice for them because of security concerns or issues of controlling corporate image. The simple truth is that we as technologists do not get to make those choices. A new technology is coming out, and people are starting to use it. Maybe it’s just a temporary blip, and it never reaches anything but a small percentage of users. But all signs seem to indicate that if it does reach large scale usage it will be a major disruptive force. It brings up a lot of questions that organizations will have a hard time answering. And the best way to answer some of those questions is through experimentation. Should everyone run out right away and setup a mechanism for producing RSS feeds? No, I don’t think so. But if a large part of your business involves frequent communication with your customers, you should at least be paying attention to the trend and thinking about a pilot program. And if you don’t fit into that group, at least trying to explore the issues that RSS raises is a start. If RSS does get picked up widely, no amount of arguing that it’s the wrong method of delivery is going to change the fact that it gets used. The issue isn’t in finding benefit or flaw in the technology, it’s in understanding the usage. What does RSS provide users that’s driving it to the front of discussion? Understand the users and try to do what you can to enhance their experience. If your users want RSS, and your competitor uses RSS, and you have a compelling argument for why RSS sucks, guess who wins? Don’t fall into the common technologists pitfall of assuming that what’s best for the computer is best for the system as a whole. What’s best for the system is what’s best for the users. If this trend does become a revolution, it might have nothing to do with technology at all.