Purpose
This post is intended as a simple sketch of views on the “ideal” Reader Extensions business model. Suggestions for amendments or additions to the Manifesto are encouraged! If this post threatens to become a serious document, I’ll move it to it’s own page for further development.
Background
For these purposes, “Reader Extensions” amount to a “switch” within a PDF. When the switch is “flipped”, users with the free Adobe Reader may not only fill out a PDF form, they may SAVE a filled-out copy on their local computer. This single feature has profound implications for the Acrobat/LC business models. Enabling PDF forms for “ReaderSave” is one of the most powerful and horizontally applicable features in Adobe’s arsenal.
Reader Extensions: A Manifesto
1) Acrobat Pro should be able to “bless” PDF files with Reader Extensions (RE).
2) Acrobat Pro and Adobe Reader Extensions Server (ARES) should always complement each other, and never compete.
3) The pathway from Acrobat-driven RE LifeCycle-driven RE should be SMOOTH. Almost any type of application requirement should be easy to accomdate within either model.
4) Scaling from Acrobat Pro-driven RE to LC-driven RE should NEVER imply operational risk to the application. Users should never have to endure a “hard stop” to their workflow simply because (for example) orders peaked in the third quarter! “Crash” installations of ARES to overcome a limitation in Acrobat Pro won’t be good for anyone.
5) The limits on Acrobat Pro’s ability to add core Reader Extensions features should themselves be EASILY extensible via a simple pay-as-you-need-it scheme. For example, if Acrobat Pro were to have the ability to make 250 instances of a form “reader-savable”, then each licenced user should be able to purchase (without ARES) the ability to make the same form savable for 500, 1,000, 10,000 or 25,000 instances at additional cost, using a simple online payment method.
6) RE can be monetized at desktop and server levels alike, and the benefits of each should complement the respective solutions.
7) The correct role for ARES is as a way to CONTROL costs for PDF forms, not to IMPOSE radical new ones, as is currently the case. ARES could allow Adobe to charge for actual usage rather than estimated usage, and allows users to coherently manage Acrobat-enabled forms. Together, these advantages will offer clear savings to larger customers compared with the “pay as you go” method. In other words, the argument for ARES should be turned around - it should be sold primarily as a management and cost-containment tool, not an enablement tool as such.
8) NEVER tell the users how to manage their forms! Let them save, edit, submit, collate, print, scan, OCR, FDF - WHATEVER. Do NOT assume that “most significant use-cases” are reducible to (for example) the ability to convert form instances into a spreadsheet.
9) XFA or acroforms: the distinction should be transparent with respect to RE. Do NOT fail to support acroforms!
