Wednesday, September 7, 2016

The story of my open source project turned SaaS

This story begins roughly 5 years ago.

I was working mainly on Line Of Business applications in Asp.Net MVC and a recurring task was to setup a way to create PDF docs, for business flow or reporting.

In the past I used a lot Cristal Reports, it had a very nice editor that users that weren't programmers could use with ease. Sometimes, though, it was problematic when installing on new servers and it was expensive, especially for projects where the requirements did not involve producing new layouts frequently.

Then I found the wkhtmltopdf command line tool, tried it and looked at opinions on the web. The first experiences where great, it was fast and the PDF docs came out pretty nice. And it was free...

It required some manual installing and some code to write. It wasn't that easy. The code was a bit strange, it involved spawning a external process, not a usual activity for web development.

Project after project I copied and pasted this "strange" code and every time I did, I tweaked it a little bit more. Made the helper method easer to use. And finally found a way to integrate it in the Asp.Net MVC flow.

This constant improving led to a very nice code interface. It turned using wkhtmltopdf in Asp.Net MVC from "hard" to "trivial". What an evolution! I was quite content with my work, so I thought about sharing it with the community.

I looked at Github and Nuget. It didn't look that hard to wrap the helper classes in a library and make it available on Nuget. So I did! It took just a few hours, all the work was already done! Just some wrapping and configuration for the Nuget package. I named the project "Rotativa", Italian for rotary press.

Made some "marketing" activity, like answering questions about PDF creation on Stackoverflow, writing posts on CodeProject and this blog. Not long and the project went ahead under its own steam. Got a few pull requests, some really useful. Downloads on Nuget started flowing rapidly. People started talking about it.

And so came the problems. People reported issues on Github, wrote to me directly, added questions on Stackoverflow and so on. Most of them weren't for bugs in the library code. Some were for wkhtmltopdf issues or problems with the original HTML and CSS, a lot were for installation problems. The latter were almost impossible to debug, they depended on what was installed on the server, what graphics library were supported, what security policy was enforced and so on; with all the possible variants a server or web hosting environment can have. This debugging activity took some time, a lot more then the time spent to publish the library and the code. Friends suggested I should have charged for support.

More and more of those issues were related to using Rotativa in Azure web sites (AKA app services).

On the other hand Rotativa gave me lots of dev love and recognition. Lots of praising. But from a professional standpoint, it gave me nothing. At least here in Italy, in the MS/.Net field, not a lot of the people that hire developers or manage software project even know what Github is or care if you created a popular Nuget package. Open source software? A weird and dangerous activity.

So I more or less abandoned the project. Preferring activities like watching TV and sleeping (sometimes simultaneously).

But a thought just kept lingering in my mind: Why not helping all the Rotativa users with wkhtmltopdf compatibility problems by setting up a service on Azure so that you wouldn't need to install wkhtmltopdf to use Rotativa. I would charge for that and, perhaps, make it profitable and finally make all this effort worthwhile.

I knew that this would be a big effort, with a lot of question marks but somehow I sensed a feeling of inevitability. I just had to do it. I could, so I would have to. That force was strong enough to overcome my (tired old man) laziness. One step at a time, just doing what was absolutely necessary to get to the next step and get more feedback.

So here we have it: RotativaHQ (stands for Rotativa Headquarters).

Perhaps I'll add some details to the story on another post, if anyone is interested.

How to unit test PDF creation in .Net

This is a quick recipe to set up in an easy way unit testing for PDF documents in .Net.

The idea, since it wouldn't be possible to verify the layout of a PDF, is to check its text contents.

In order to do so we can use the iTextSharp library. This library enables creating and editing PDF documents. It's commercial but is free for this kind of usage, as long as you don't make it part of a commercial solution.

First of all you should install iTextSharp Nuget package:

PM> Install-Package iTextSharp

Then you can use the following simple method to check if a given text is present in a PDF binary: