Resources not Services
60 Blank White Cards is dead; long live Video Underbelly.
It has taken me 11 years, I think, to come to a simple conclusion: I prefer building resources over services. I define a "resource" as content you may be able to interact with; a "service", on the other hand, is primarily something you interact with, with content as complementary. When Disobey first started in 1997, it was all resources: I held high the mantra of "content is king", and produced as much of it as I could. As I became a programmer, I moved closer to services, building software that re-purposed content in ways the user desired. Most of my modern-day Perl scripts continue to do this. While the years wore on, though, I think I found myself building software for the sake of building software - why I rewrote Case Tracker, I don't really know.
Services tend to have shorter lifespans than resources: when everyone is making map APIs, social networks, and photo and video sharing, they crash and coalesce into one, stranding Site B's complementary content or sub-services when Site A takes the cake. Good content, however, good information, tends to be copied and passed around, living forever, never requiring a specific API or site or service.
I'd still like to make 60 Blank White Cards (perhaps as a Noteworthy or Lexicon; interested?) but, when it's over six months after launch, will anyone really remember it three years later? Will it even still be operational? When I'm working on something else and a new vulnerability is found, do I really want to drop everything to upgrade and then ensure it still runs with API changes I haven't been monitoring for years? Especially when no one cares about it anymore (save me, aghast at the idea of removing it from the net entirely)? When no one else but me can provide an upgrade path, do I really want to keep doing so ten years down the line?
Resources last longer than services because they tend to stand alone - there's little custom code involved when your entire intent is to just make content. One could lament "well, hey, you're using MediaWiki, and you've got to upgrade that continually!", but the difference is that that's pre-packaged software, much like PHP, Apache, Linux, and ever upwards - other people depend on it, so it'll just get done. Custom code for a project that has a finite life-span, or has been made irrelevant by new advances, just doesn't have the same life-support.
Years ago I asked where was my Lord of the Rings? Fiction, content with no custom code, tends to have a finite life-span for the author, but never for the reader. A service may have an intended finite life-span for the programmer, but when your goal is to make something available forever, technology and software just doesn't work that way. Whilst my goals for 60 Blank White Cards were to create a large body of interactive fiction, it was too ensorcelled inside custom, and nearly non-reusable, code whose public (or open sourced) release would actively prevent the mystery necessary for a game of its type. This is quite different from, say, Ghyll, which required no custom code, but was still an immense and enjoyable game of fictional tendencies. 60BWC's content was what I wanted, but there was too much "maintenance always required" to make it work. I was building a service with content as complement, and that's as bad as adding puzzles "just because" that's what ARGs are supposed to have.
I want to build resources that require little technology to operate and that are still important years from now. If that just means a reader is enjoying an encyclopedia last authored in 2005 and which, at any moment, could be expanded upon by the sole act of writing, I'm OK with that.
Video Underbelly took a few weeks to finalize some ideas, but is already "up and running", awaiting new and improved content. It is a resource for films that are often disregarded as unimportant or with no redeeming qualities. This is exactly why the site exists: it is a resource that needs to be retained, not a service that could be replaced. Its existence continues through mere copy and paste, not APIs or upgrades. It doesn't require six months of planning for the next "feature" or the next "version" - it just requires little trickles, each week, applying continuous torture to the rocks that line its shores. You never notice a rock being rounded - you only appreciate the patience it took to get there.
I'd much rather be trickling at creation than treading water with maintenance.
