Source code for content is a really important idea.

Markdown provides a really good example.

Consider this very small Markdown document.

That's the source code.

Then there's the rendering of that code.

A simple message

I am feeling happy today.

A content system has to store both versions. Yet blogging software generally doesn't offer that capability through their APIs. If an app wants to store the source (and it must) it has to find another place to store it. Every piece of software that publishes, and that's most software, needs the ability to store the source. So the user can edit it and have it re-rendered.

The analogy to source and object code is near-perfect. Instead of compiling the code, we render it. The equivalent of the object code is called a rendering. I've added the ability to store the source in RSS in a new namespace I've defined, and it's supported in Fargo and all my software snacks. It allows for different renderings of the same content at the other end of the pipe or in the future. Why shouldn't you be able to view content I create in 2015 in full fidelity in 2030?

That's the idea.

The importance will be fully visible when the third server snack ships, sometime in the next few weeks. (The first two are Noderunner and PagePark.)