Interview with Peter Fournier of Samalander Software

When I was compiling a list of DITA-supporting software tools recently, I ran across one firm based out of Ottawa in Canada called Samalander (not a typo) that didn’t just make one DITA-related tool, but at last count has made no less than ten of them, ranging from DITA metrics tools to link checkers and packagers, none of them costing more than $50 CDN (and some of them are free)! I got in contact with owner Peter Fournier and asked him for an interview. He kindly obliged, so we talked about how he got into building DITA software tools, why he prefers working with DITA over DocBook or S1000D, where DITA CMSes do (and do not) fit in, and how the name “Samalander” came about.

DITAWriter: What’s your background in technical writing?

Peter Fournier: I originally got a Technical Writing job with Bell Northern Research, the research arm of Nortel Networks back in 1984. This was the start of a fifteen year career in creating my own jobs in Bell Northern Research and Nortel. In 1990 or so I landed a technical writing job with the Silicon and Board design groups there, where I led group in developing a context-sensitive help system called UniHelp. It was based on compiled LISP along with FrameMaker MIF. I believe our group was the first in the world to ship all of the technical documentation for a complex product as an online help system.

At about the same time I read the SGML standard. I believed it was too complex to make any real headway in the Tech Writing domain (except for Defense, NATO, etc.) but it was equally obvious there would be a “son-of-SGML” out sometime soon. That turned out to be XML.

I then got a job as a manager in the Data division at Nortel, and by the late 90’s we were responsible for the tools enabling the editing and push-button publishing of 150,000 source pages to PDF and our context-sensitive help system, and through that to HTML. HTML publishing amounted to more than 5 million pages per year. No document accessed through HTML was more than 12 hours out of date from the last edit.

By January of 2000 I concluded that Nortel would collapse so I sort of arranged to have myself laid-off. I was laid off in May of that year and started my freelance career. Over the summer my wife Catherine Fournier and I published the first of three Catholic family best-sellers through Ignatius Press. I then pursued various tech writing jobs in Ottawa Ontario Canada.

DITAWriter: How did you start developing software tools for DITA?

Peter Fournier: In 2005 I discovered DITA. I played around with the early versions but had to wait until 2008 before the editing software was mature enough ready for average technical writer to use. Even back in 2005 DITA was obviously a winning strategy, and the fact that it was backed by OASIS only added to that potential.

In 2008 my wife and I ended up working for a product line called WaveReady at JDS Uniphase. We sold them on the idea of moving the tech docs to DITA BUT had to agree that we would eat the cost of producing online help and PDF and future HTML-based deliverables. From 2008 to 2011 we increased the tech writing productivity from 1,200 pages to more than 7,000 per-writer per-year, all due to the reuse features of DITA.

In 2009 my son Matthew needed knee surgery and since he had a Math/Physics degree and was just lying there recuperating, I put him to work developing DITA tools. I thought it was a good choice since the IP potential of his background was better than a typical computer science graduate.

Between 2009 and 2012 we developed the Samalander Software Center concept and software. As proven by previous experience at Nortel/Bell Northern Research, it seemed a good idea to have the developer deliver tools directly to the tech writer in an agile-like manner. So we ended up developing what is actually needed to do DITA in a small group (and only that!), and what’s developed is usable by the writers immediately.

I’ve become very aware of the maintenance cost portion of total life-cycle cost of various tools. Samalander believes that a DITA tool should be deployable in the month it is adopted and should have an ROI of one month or less, excepting the authoring platform course. That necessarily implies zero maintenance cost after adoption. It also implies paying for what you use; that’s why we developed and deployed the concept of the Samalander Software Center. All the modules are independently priced and you only pay for what you use.

DITAWriter: Who’s the main focus/audience for your DITA tools?

Peter Fournier: Small tech writing groups within large corporations, independent contractors and Small to Medium-size Enterprises. I believe that an intelligent approach to DITA tool development will give small groups and independent contractors more than 90%, maybe even 95% of the benefit promised by DITA for a very reasonable cost – likely a maximum of about $150 US.

From previous experience I know that good publishing and document maintenance tools are scalable from a single independent contractor handling 1,500 pages for a client to a small group handling 15,000 pages, to a fairly large group handling 50,000 to 100,000 pages. They also go a long way to enabling the productivity of writers. We’ve seen productivity grow on average from the older industry average of 800 to 1,200 pages per year per writer to easily 3,500 pages per writer per year.

The adoption of DITA has been, so far, largely driven by large groups in large corporations. They have the two- or three-year time horizon to create a large corporation business case. But the benefits of DITA, such as doubling, tripling, or quadrupling tech doc productivity are in principle available to even one-person shops – given the right tools!

DITAWriter: Where do Content Management Systems fit in?

Peter Fournier: That’s a really tough question, mostly because “CMS” is a vague concept. Given excellent file system organization and basic tools for assisting in link management and validation, both operating at the suite level, the business case for a CMS can be very tough to make.

Advanced CMS’s do the file and link management requirement, just like our tools operating in the file system. To that the advanced CMS’s add excellent change tracking and version control, but that’s partially available with free tools like SVN and GiT.

Where they do add a lot of value is in meta-data management, review tracking, easy integration with translation memory tools, very easy publishing and similar advanced functionality. But that means the business case has to be made at the extreme edge of the value-add proposition. The more basic stuff doesn’t need a CMS.

DITAWriter: Why just DITA (and not DocBook or S1000D)?

Peter Fournier: Why DITA? It has close to an ideal mix of rigid structure and flexibility while maintaining predictability in the publishing pipeline. It is also suitable for small groups and independent contractors.

Why not DocBook? It’s too much like MS Word – it allows too much freedom to do anything you want and that way lies chaos, in the original Greek sense. Therefore it is not suitable to low maintenance cost deployment because one cannot predict what will come down the pipe.

Why not S1000D? Other than some informal testing of our SW architecture to prove its adequacy, we don’t have a lot of experience with it. Also, it tends to be used only on large projects, especially National Defense / NATO, and so are not accessible to the small groups and independent contractors we market to. Here in Ottawa, as far as I know, all of these S1000D projects are all “big-iron”.

One of the keys to the success of many of the extremely aggressive projects I’ve led over the years is a direct connection between software engineering or template engineering and the user group. Having been in that environment for many years I became conscious of the total life-cycle cost of many tech writing technologies. I am sure that MS Word has cost the industry literally hundreds of millions of dollars in wasted time over the years on just a single easy-to-fix feature: list numbering. Overall I think the adoption of MS Word has cost the technical writing billions of dollars in lost productivity.

DITAWriter: I notice you offer free tools along with paid ones — why did you adopt that model? Also, what are the main differences between your “Basic” and “Pro” packages?

Peter Fournier: Some of the tools are too simple – I’d be embarrassed to charge for them. The same functions can usually be done with GREP. But why learn GREP? Just download our tools. If you find yourself doing something over and over again, and the solution is so simple it should be free, tell us. We’ll add to our offering.

We think it is important to maintain a distinct difference between basic functionality, such as packaging what is published, and more advanced functionality, like packaging what is published along with all of the source files for integration with other corporate functions. For example, Sanity Checker Basic will suffice for low-intensity operations for independent contractors, but Sanity Checker Pro adds the ability to check for business rule violations that are valid within the DITA XML, and therefore invisible to the author. As time goes on we will continue enhancing the business value of the Pro modules, and perhaps increasing the price, while keeping the basic modules (with some features migrated down to the basic version) at a very low cost.

DITAWriter: Judging by the information on your site it looks like you are planning even more tools! Where are these ideas coming from?

Peter Fournier: Hard-won experience. These are all tools we thought valuable at some point and brought to the Beta stage. They were abandoned when our major clients weren’t interested. However, having reached Beta stage all they need is to be slightly re-tooled to fit our current core architecture.

As time goes on we will deploy at least another 20 or so modules. At no point will our software be out of reach of the independent contractor or small group in a large corporation. For the future of DITA, we believe this commitment to independent contractors, small groups, and SMEs generally is absolutely critical and in the current environment, mostly missing.

We would be very interested in feedback as to what tech writers want and need now!

DITAWriter: How did the name “Samalander” come about?

Peter Fournier: Samalander is an example of the typical early language development inversion and insertion of vowels and consonants you often hear from young children. Other common examples are “pasghetti”, “maj-gick”, “babloons” and “ephalent”. For us, “Samalander” represents the attitude of creativity, activity and insight so often found in children in this stage of development.

From a biological and ecological point of view, salamanders are surprising little creatures. Almost always hidden from view, they are the top predator in the forest litter and supremely well adapted to their role in the forest ecology. Many are beautiful and an absolute delight to children in that time before they learn to fear “slimy” things, about the same time they always pronounce “salamander” as “samalander”.

Besides that, I started my working life as a biologist, naturalist and professional bird watcher. Sometimes I wonder how I got here…