From toilets to techcomm: tallying tool risks
I’m about to replace an old toilet, not-so-affectionately nicknamed the Lazy River.
As you might guess, the Lazy River is barely doing its job. I’ll give the toilet points for longevity—it was installed in the mid-1980s—but the Lazy River uses three gallons of water for each leisurely operation. It’s beyond time for a more efficient model.
The leading contender to replace the Lazy River was an aesthetically pleasing option (well, as far as toilets can be) with an impressive warranty and a highly competitive price. And then I read a forum post about that product that changed everything.
The flushing mechanism and water supply line for this toilet rely on proprietary technology. (Proprietary. Toilet. Technology.) That would probably mean ordering any replacement parts directly from the manufacturer. What if the company decided to discontinue making toilets? The so-called “universal” replacement parts wouldn’t work, and I’d be stuck with a nice-looking toilet that I couldn’t repair. No thanks!
I ended up choosing another option. Replacement parts for it are more widely available, and universal parts will work, too. I have no worries about buying a unit that will become obsolete if the manufacturer quits making that model.
The lessons I learned with my toilet purchase most definitely apply to the technologies and tools that produce technical content. Consider the long-term risks associated with choosing a particular tool.
Proprietary storage formats for source files are a large consideration, and you should account for both a toolmaker’s longevity and the continuity of its products. For example, is there is a history of products being poorly supported or discontinued altogether?
Poking around industry forums and wikis can help you gather this crucial intelligence. Talk to your peers at conferences and industry events—and don’t get snowed by fancy vendor demos and slick marketing that camouflage risks.
Before you choose a solution, figure out an escape hatch that will let you extract your content from the tool. For example, can you export source files to a generic format that you could transform and modify further? This is where having XML as a base technology is very useful: you can often programmatically transform one set of XML tags to to another with minimal human intervention. In a sense, XML is a universal replacement part.
Open-source tools should not be exempt from scrutiny. Sure, an open-source technology may not rely upon a proprietary file format like many off-the-shelf tools do, but how well supported is that technology across the industry? Has it reached a critical mass that means you could, for example, choose from several consultants to help you develop your implementation? Or are you pretty much on your own with an open-source tool that has spotty or nonexistent documentation? And always remember: the free license associated with an open-source tool does not mean it will be cheap to implement and maintain.
While evaluating content development tools, it’s critical to consider the longer-term risks of choosing a particular solution and to understand your options if you choose to move to another tool later. Otherwise, you may find yourself up a not-so-lazy river without a paddle.