I was catching up on emails this weekend (I get so many mails that I don't succeed in reading them all anymore) and this article referenced in last Tuesday's newsletter from Foxit caught my eye:
The blog post starts like this:
There are literally hundreds of PDF exporters and converters out there. Of course, there’s the downloadable type, such as the Free foxit reader. But there are also free online software versions, written by many different developers for the main reason of avoiding paying for the high cost of Adobe Acrobat to create PDF files.
Several things are mixed together here and that's confusing. The paragraph starts by talking about PDF exporters (such as iText) and converters (such as Thinkfree's DocsConverter). So far so good, but then Phil takes a PDF reader as an example of such an exporter / converter, which is odd. Phil ends the first paragraph by claiming that developers create their own PDF software to avoid paying for the high cost of Adobe Acrobat to create PDF files, ignoring the fact that PDF Reader can be downloaded and used for free. We're two sentences into the blog post, and already we are lost.
I am a developer who created software to produce, process and manipulate PDF documents, but the reason why I wrote iText wasn't the price of Adobe Acrobat. In 1998, I needed to create PDFs on a server in an automated way, and at that time (almost 19 years ago) I couldn't find any existing Java library that was fast enough to meet my needs. Yes, there was Adobe Acrobat, but that wasn't a Java library; it was a desktop tool that people used to create PDF documents manually. I created PDF software for a very specific purpose, and I released this software as a free / open source software library. It was the first enterprise grade PDF library that was available for the Java and .NET platform.
And therein lies the problem.
Anyone with a penchant for open source software knows that one of the drawbacks can be the “Wild West” of compatibility. Which matters when the document you create or convert isn’t compatible with someone else’s version of the same software, or won’t render onscreen.
Without bringing any valid argument to the table, Phil suddenly calls out open source software as the culprit for a problem many businesses are struggling with: the lack of compatibility with respect to PDF (and other) documents. This assault on open source is uncalled for, and that's where it gets personal: iText is an open source library, and as its initial developer, I have been a member of the ISO committee for PDF for many years, long before Foxit joined the ISO meetings.
If Phil had attended any of these meetings, he would also have known that the problem of incompatibility has been discussed many times, especially in the context of a closed source product that is considered being one the most disobedient viewers when it comes to respecting the PDF standard. We often refer to that product as the viewer from "that fruit company from Cupertino." Why do you pick on open source software, Phil? Did you forget that Foxit is responsible for writing PDFium, the open source viewer that was used by Google as PDF viewer in Chrome?
And yes, Foxit may be following the PDF standards, but at iText, we have been actively contributing to the standard for many years. Moreover, I know for a fact that many of Foxit's solutions, anything related to DRM to name one example, depends on a proprietary specification, written by Foxit engineers, which results in a vendor lock-in once you decide to go for Foxit as an enterprise-wide solution, and that's clearly Phil's goal if you read on:
Also, all of these bits and pieces of software offer different features. For example, one user may want to export the links in pdf documents. Another may need to archive the whole document with graphics. Yet another whole department may be tasked with archiving PDF documents in PDF/A for long term readability and searchability.
Can these situations result in incompatibility issues? Of course. Can they even create situations where the end user is faced with a document that won’t even convert to a PDF? Absolutely.
While all these scenarios are not entirely unavoidable, they do stem from a common problem: standardization.
Standardization isn't the problem, Phil, standardization is the solution. And a typical trait of standards is that they are open, as opposed to proprietary specifications. A standard can be implemented by anyone who wants to contribute to the solution. In my opinion, the best way to ensure that the standard is respected, is to create implementations that are open source. This way, people can inspect the code, and if they find something that is in violation with the standard, they can fix the problem, and contribute the fix back to the community, so that all the users of the open source software can benefit from the fix. That's how we work at iText, and we have received many valuable contributions, even from employees of companies that could at some point be considered a competitor. That's the beauty of standardization: we don't have to compete; we can work together. At iText, we have made a clear choice never to create a PDF viewer. That felt like a waste of energy, given the fact that there's already an abundance of PDF viewers on the market. Instead, we decided to create something unique, something that was different from everything that existed before. Many companies, including Foxit, have tried to copy our unique solution, but I'm quite sure we're still ahead, especially now that we've released iText 7 as a platform.
You conclude your blog post like this:
We recently discussed the benefits of standardizing on a single PDF solution across the enterprise. Not the least of which are your ability to rely on a unified set of underlying standards for how the PDF Software solution you use works, what types of features it offers, who supports it and who you can rely upon if you need said support.
If you’re relying on a dizzying array of PDF viewers, editors, exporters and converters, perhaps it’s time your organization considers standardizing on a single solution that can handle all users’ needs across any platform you can throw at it.
So... you recently discussed the benefits of choosing for a vendor lock-in across the enterprise? That is the complete opposite of what companies need and want. By choosing a technology standard, companies try to avoid a vendor lock-in. The underlying technology standards are more important than the software that implements those standards.
Dear prospective customers,
- If you choose an open source solution, you will always be the master of your software. Since the source code is open, you can choose any developer you want to fix any problem you might encounter. Obviously, we at iText take pride in the fact that we have excellent support, but it also happens that customers fix small bugs on their own, or even add useful features. We know this because those customers usually contribute that code back to the community.
- If you choose an open source solution, you are choosing for software that wasn't created by the limited number of employees of a single company. The code you are using has been seen by thousands of eyes, and many thousands of companies have tested the quality of the software, even before they became a customer of the open source vendor.
- Choosing an open source solution is also the most secure approach if you are dealing with documents that might contain sensitive information. You might not want to use software that sends data to a foreign server, or send your documents into a cloud where who knows what can happen to them, do you?
Dear Phil, I think you were rightfully addressing existing issues of compatibility, but if you blame open source software for those problems, you are choosing the wrong enemy. The real culprits are companies that want to establish a vendor lock-in. One of the most blatant examples of such a company is the closed source company we all know as "that fruit company from Cupertino." Closed source is the real mousetrap.