Content manifesto and the art of software releases

This is a blog, and an extremely typical one - I update when I feel like it and am able, and the main folks who may read this are those who I directly send the link to. Occasionally random people may find their way here and partially read an entry and then go on their way.

This is all fair, and likely largely unchangeable. Sites that meet with more success tend to have regular updates, original content, all that good stuff. And whatever I do, it is unlikely to be as compelling as blogs where people are able to sink a lot of time and always have something new so people will actually follow and subscribe to them.

But (and here is the manifesto part), I do want to at least pledge something. That something is that I will update at least weekly, targeting Sunday as "publish" day, with a new entry that contains original writing, original code, or both.

That's still not regular enough to really take off, but hopefully enough for people to consider checking that once a week (or adding to their feed reader). And while I will still link to places, I intend for every entry to have enough writing (and not just blockquotes/references) to have something that you can't just read elsewhere. There are better aggregation sites out there, so I don't want to just maintain a list of interesting links.

So, much like Conan O'Brien Show Zero, this entry you are reading now is "attempt 0" at what it is describing. What does it have to do with software releases? Simple - just like websites, software should evolve and update in a consistent and sensible fashion. Stale software will lose users just like stale blogs lose readers - just look at Internet Explorer relative to Firefox, Chrome, et al.

In fact, with "webapps" the line between website and application is blurred. The problem is exacerbated by the lack of versioning in webapps - when you use Gmail, you use Gmail. If Gmail changes something in the left nav, you now have a new left nav - you can't just say "I want Gmail 1.2 and not 1.3", while traditional installed software lets you do that (modulo security patches, but those tend to be maintained a bit longer).

So now we are left trying to balance evolution and avoiding staleness with having stability and backwards compatibility for more conservative users. There is no silver bullet here, it's arguably unrealistic to say that old versions should always be maintained, but it's also unrealistic to say that you should just push everything out the door and force the user to cope.

I would cautiously offer the following guidelines ("commandments" if you will), generalized so they apply to blogs/site content, webapps, and even traditional software.

1. Create new things (content/features) proactively, not reactively.
2. Maintain what you have and mimic content/features from others as needed (reactively, not proactively).
3. Support for the old should be proportional to the new change.

#1 means you need to take initiative - if creating content, do so originally and not just by linking to others. If creating applications, come up with your own ideas and designs and don't just copy what others do. This will keep your users interested (positive retention).

But #2 means you still need to follow others and keep what you have going. This should be a second priority to #1 ("be a leader not a follower" or some such nonsense), but it is important nonetheless. You won't come up with every innovative feature or good writeup, so you still need to pay attention to others and refer to them as appropriate (essentially as your users demand). This will avoid making your users unhappy by feeling like they've lost something (avoid attrition/negative retention).

#3 is the guideline for how to balance #1 and #2, and is related to user demand. If you do some new work (content or features) that is considered significant, then afterwards you should take some serious time to relate it and ground it in the established. Listen to your users, maintain what they care about and maybe even roll back things that lead to complaints (or for content, just make sure you place it in a greater context). If you don't you stand the risk of going off too far on your own - an aimless leader is not a leader at all.

So, that's it - thanks for reading. To practice what I preach, I will revisit the above and refine it over time, so watch for that and please give any feedback. As I said, this is not a silver bullet for success - but it is intended as guidelines against common failures I have seen in original creation, both content and software. Hopefully they make sense, and I at least will try to follow them here.

Come back at (roughly) the same time net week for another entry! Every week will either be me posting some update to a project (with fresh code in the repository) or some software-ish writeup like this. Thanks for reading!