Acrobat 8 meets the Extended Rights Manifesto: Article 2
This post is part of a series based on the “Extended Rights Manifesto“. See this post for some context.
| Article 2Acrobat Pro and Adobe’s LiveCycle Reader Extensions Server should always complement each other, and never compete. |
To monetize the gap between the free Reader and for-sale desktop software, Adobe developed the LiveCycle Reader Extensions Server. This software “blesses” PDFs with “Reader Extensions” that can switch on latent capabilities in Reader, allowing users to save the contents of a form, import or export form data and add annotations, among other powerful functions.
Whatever you may think of this arrangement, the Reader Extensions Server is sold as “enterprise-class,” with price to match.
Adobe has been easing the Reader Extensions concept into the Acrobat Professional desktop software business for a few years now. This software costs a (mere) $449, but until Acrobat Professional 8, was incapable of “blessing” PDF documents for “Reader Save”.
The ability to add the Reader Save Extension to a PDF is the key new feature of Acrobat Professional 8. But was the move consistent with Adobe’s server software business model? Is there a unified strategy, and if so, what is it?
The answer may (or may not) emerge over the course of this series of posts. However, what does seem clear is that the desktop and server products in the current model don’t complement each other in any direct way. Yes, there’s an indirect connection via a notional increase in exposure for the server product, but it’s all very understated and subtle, if it’s even intended at all.
The Acrobat EULA (End User Licence Agreement) advises users of the “legal limits” of their usage of Extensions added via Acrobat 8 - in other words, the EULA limits imply the need to “step up” to Reader Extensions Server, or else your application will fall off a legal cliff. (Fullest Disclosure: The author is NOT an attorney, and this is NOT a legal opinion. The word “cliff” is an editorialism, and does not appear in the EULA).
Oddly, while Acrobat is replete with warnings and dialogs on almost every other occasion, the only place you’ll find the EULA discussed is in the 7,000 word document itself, buried in your Program Files folders (and posted here, as a public service). You are looking for Section 14.13.3.
Apart from the EULA, the other method chosen to “communicate” the limitations of Acrobat’s Reader Extensions (and therefore, one assumes, the benefits of the server product) was simply to leave out many of the more sophisticated Extensions in Acrobat 8. While Reader Save and FDF import and export are supported, for example, spawning new pages from templates, importing XML/XDP to XFA forms and SOAP are not.
Adobe’s logic seems to be that if your form is “fancy” on some metric that includes the use of specific Extensions, then your application is “Extensions Server only”. Want to build it up first, then buy the Extensions Server if business conditions avail it? Sorry buddy, you’re out of luck.
OK, I understand the need (desire, at any rate) not to undercut the Reader Extensions Server product by just throwing EVERYTHING into Acrobat. What I don’t understand is the way Adobe chose to go about it.
Part of the problem is the basic organization of the LiveCycle products. The Reader Extensions Server offers no value other than the granting of Extensions - indeed, it’s not really a server-type product at all. Rather than attempting to “trap” revenue in this specific product, Adobe should be leveraging Extensions themselves to draw desktop-product users towards the rest of the LiveCycle technologies, Policy Server in particular, where the need for a server in the loop is clear-cut.
The Acrobat 8 EULA as it stands is unworkable, even for the honest citizen, and is thus ill-considered on that basis alone. Adobe should have offered a more creative and gradual mechanism, with any and all Reader Extensions available via Acrobat, perhaps using a smooth web-based licencing model, (as mentioned in the Manifesto, Article 5).
Just as with PDF itself, the focus with Reader Extensions for PDF should be on helping hundreds of thousands of forms-developers (and others) to know and love the concept for any purpose that suits them with a minimum of interference. It was a good business strategy for Acrobat, it will be a good one for many of the Reader Extensions as well, when Adobe finally gets around to implementing it.
The Manifesto Score Card, Article 2
“Acrobat Pro and Adobe’s LiveCycle Reader Extensions Server should always complement each other, and never compete.“
December, 2006, Acrobat Professional 8.0: 3 out of 10.
These two products now not only compete, but the competition isn’t even very “friendly”. There are no guideposts to implementation, not even a simple comparison matrix. There’s little evidence that the server and desktop products have been considered in complementary terms at all. Instead it is simply left to the (often unsuspecting) implementer to bump into the limitations (both operational and legal) in Acrobat, doubtless in many cases long after x, y or z result has been promised to the boss.
Not the way to win friends and influence people.
