Ionrock Dot Org

The other day in the break room I noticed an short headline on the cover of E-Content magazine regarding RSS. This sparked my interest since I am becoming more and more convinced that RSS/Atom will be a preferred format for almost all web based systems. My excitement quickly was destroyed when it became clear that the article saw RSS as a means of distributing potentially valuable information. In short, I was appalled.

After being in music and reading quite a few articles on how book publishers work, it is clear when it comes to content (creative or otherwise), the goal is one big hit. You have to make one release that pays not only for itself, but everything before and after it in order to be really profitable. This puts a high level of value on content because supposidely people buy it to gain access to it. While this may be the sad truth behind the music/publishing industry, it makes no sense whatsoever for organizations that publish as a means of support (read not revenue).

Take Nokia for example. They released the Nokia 770, a small internet tablet that runs a version of Debian and uses GTK+ for their toolkit. The great thing about this is that they have signed up the whole GNOME community as a resource. The platform is open, *users* are writing applications and the platform is well documented. This all happened because there was a community built around the technology. When a company makes a decision to charge for documentation they immediately lose the ability to create a truly vibrant and revenue building community. They are forced to rely on advertising and customer word of mouth where little to no momentum can be created.

The concept of momentum is very important because it makes it possible to push a product or technology over the edge. This is what has happened with Apple and their dedication to creating a culture behind the Mac. They now have a dedicated community that cares about the company and each other, which means they are like a good friend, sticking it out through good and bad times. Apple does this by getting customers excited about using their product and I believe ePublisher can do the same thing.

When you think of ePublisher as simply a product, you are missing the point. ePublisher defines a platform. The platform is simply a base for greater things. We have to get customers excited about the "greater" things the platform offers. The only way to do that is to get the word out and a great way to get the word out is through documentation.

The concern is always in reference to support. If you blog about chaining AutoMap jobs and rewriting job files and someone actually gives it a try then you are hosed because you can't support it. I would argue that if I "blog" about anything then there is no support period. The paper publishes an opinion page that is known not to be fact. We can publish blogs that are essentially the same thing. This is also the case with a Wiki. Wikipedia is seen a valuable resource, not because it is fact, but because it is relatively reliable and robust. If something is wrong on wikipedia, then the people behind the site are not responsible. Again, there is an inherit accountability on the reader to digest and analyze the content as being something they can use.

This is why it is silly to be so concerned about RSS/Atom for documentation and content. It is simply a mechanism for providing users more resources with less responsibility on the author. Assuming the organization does enforce some quality standards then the content should be helpful without causing a support nightmare. In fact, I believe that it could increasingly *decrease* support requests because there will be more resources that may fill in the gaps of traditional docs.