Buy the book

Open Source Survival

A Story from the Trenches

In this video, I discuss eight different ways you can make money as an open source developer.

The presentation consists of an introduction, five stages in the evolution of the iText business, and a conclusion:


With this talk, I want to help open source developers by sharing my personal experiences with open source survival. Open Source Survival: title slide

If you’re not an open source developer, please stop reading here. Open Source Survival: warning page
This is a story from the trenches and you may not like what you hear. This content is meant for open source developers only.

But first, let me introduce myself.
Open Source Survival: who is Bruno Lowagie?
My name is Bruno Lowagie.

After leaving the company, I wrote a book about the whole experience.

This slide is some shameless promo for my book:
Open Source Survival: Entreprenerd book promo

1. The Early Years

I started my first open source project in 1998. It was a PDF library called rugPdf and I released it under the LGPL in 1999. The library wasn’t documented and it wasn’t developer-friendly. I rewrote it from scratch and released a brand new PDF library in February of the year 2000. This library was called iText, and unlike rugPdf, it’s still around today.
Open Source Survival: title slide part 1 (The Early Years)

No Money, No Worries?

iText was available under the MPL/LGPL and it wasn’t only free as in free speech, I also promoted it as free as in free beer. My motto was “No money, no worries.” I thought: if I don’t ask any money, I won’t have any troubles.
Open Source Survival: no money, no worries
When people asked me for the price of iText, I told them they had two options: either use iText for free, obeying the obligations described in the MPL or LGPL, or refrain from using iText. That was a very naïve approach. Experience taught me that, once your open source project gains popularity, you need to release new versions on a regular basis:

Users will expect you to answer technical questions and provide documentation. You’ll also get plenty of legal questions from companies using your software, some of which you won’t be able to answer without hiring a lawyer.

Some people will hate me for what I’m about to say, but if you succeed in maintaining an open source project without a significant investment of time and money, your project probably isn’t very popular.

Gifts from Happy Users

In the first years of its existence, I was able to help iText users personally. I fixed their technical problems and this often resulted in a personal conversation about our job, our kids, and our hobbies. Some people insisted in rewarding me for the help I had offered, but I refused getting paid in money. iText was something I did on the side, next to my day job. I was reluctant to start my own company because I feared all the paperwork that was involved. I live in Belgium, and it’s an understatement if I say that Belgium isn’t the most entrepreneurial country in the world. Starting a company in Belgium isn’t as easy as starting a company in the US.

Because I refused money, people sent me books and DVDs from Amazon, but that wasn’t ideal. I remember having to pay quite some import taxes when people sent me books from the US. I also received DVDs that I couldn’t watch because I was in the wrong region.
My kids were always very happy when people ordered LEGO sets and had them sent to our home address. One iText user even sent me Nuernberger Cookies so that I could get acquainted with some authentic German culture.
Open Source Survival: gifts
Getting gifts is fun, but it doesn’t make a business.

Revenue from Ads

In the fall of 2004, I released a tutorial “iText by Example”. I was an early adopter of the Google AdSense program. As you can see, I had a nice revenue in 2004 and 2005, but I noticed that most of the companies advertising on the iText site were competitors of iText: Qoppa, Big Faceless, Antenna House... In a way, my competitors were my seed investors.
Open Source Survival: revenue from ads
I also discovered that making money with ads wasn’t a sustainable business model. In 2006, I had more pages with ads, more people clicked on the ads, but the revenue dropped from 14.5K to 6.2K. In the years that followed, revenue dropped even more because more and more people discovered Google AdSense and the revenue made with ads was distributed over more websites, some of which were specialized in creating content in function of ad revenue.

As a developer, I was interested in building technology, not in optimizing my website for ads.

I saw how Codehaus had to terminate its services because the revenue from ads wasn’t sufficient enough anymore to pay the hosting costs. I understood that SourceForge needed to make money, but I didn’t like their decision to take projects hosted on their platform and wrap them in a bundle along with Adware. I saw how more and more people started using ad blockers, resulting in less revenue for people living from ads.
Open Source Survival: the problem with an ad-based business model
Making money with ads is feasible for companies such as Facebook and Google who find new ways to serve ads, but in my honest opinion it’s not a feasible business model for an open source developer.

Selling Documentation

The online tutorial had a nice and unexpected side-effect. Suddenly publishers were interested in me as an author. I accepted a book contract from Manning Publications and I wrote two books about iText proving that I could make money by writing documen­tation.

I sold north of 12,000 copies of iText in Action, making about $33K. I sold about 10,000 copies of the second edition, making about $36K. I could even have made more money if every reader had actually paid for their copy. I found illegal versions of my book online even before it was officially released.
Open Source Survival: selling documentation
I may have been able to make a living as a technical writer, but the limited revenue would never allow me to hire employees for the further development of iText and to invest in providing better support.

Some people demanded that I help them solve their iText problem because they had bought my book and “the answer wasn’t in it.”

They were disappointed when I explained: “By buying my book, you made me about $3. You shouldn’t expect me to spend three hours finding the bug in your code for only three bucks.”

Selling Support

You could argue that I should have asked money for providing support. A common saying in those days was “it’s free software, not free consultancy.”

Charging money for support is a valid model, but it’s hard to sell support. The better the quality of your product, the harder it is to find—and retain—customers, especially if you or other users of your product already provide great support for free. In chronological order, I answered questions on Usenet, the iText mailing-list on SourceForge, and Stack Overflow.
Open Source Survival: selling support
I also faced competition from OpenLogic, a company that offered support for a stack of open source products, one of which was iText. I’m not angry with OpenLogic. I admire the business model: Why would a company purchase separate support contracts from different open source vendors when there’s a one-stop shop for support for a comprehensive set of products?

This is an example of a place where developers go to get support for free:
Open Source Survival: Bruno Lowagie on Stack Overflow
I joined Stack Overflow in August 2012, and I answered more than 2000 questions. When I’m at an event with a live audience, I often ask: “Raise your hands if you have a reputation higher than 70K.” Normally, I don’t see many hands.

Can I Get Some Help, Please?

By 2006-2007, iText was getting extremely popular. Google for instance, was using iText to create nice calendar sheets in Google Calendar, to create reports in Google Analytics, to produce PDFs from Google Docs. I thought that Google’s extensive use of iText meant that Google’s Open Source Programs Manager would be more than willing to help me find a way to solve the problem of the increasing pressure from the market to go into business. On June 15, 2007, I received a single-line answer in reply to my request to engage in a conversation: “Sorry, we don’t provide this kind of guidance.”
Open Source Survival: Google Case Story
I’ll let that sink in for a moment.

If you’re an open source developer and your goal is the prestige of having Google use your software for free, you should go for it and make your software available under a permissive license.
However, if you have friends and family, and you have to decide who deserves your spare time most, you might want to decide in favor of your family, for instance your wife and kids. Your family might show gratitude for the time you spend with them, but you should never expect Google to provide any help in return for your efforts if you ever need something.

2. Looking for a Business Model

In 2008, my wife and I were more or less forced to create a first company for iText. The circumstances are explained in my book; it would lead us too far to go into detail here.
Open Source Survival: Looking for a Business Model
We incorporated in Belgium in January 2008. In February, our son got diagnosed with Cancer. That year, we spent more time in the hospital than we spent at our desk.


Faced by this ordeal that also had an impact on our finances, I created an account on in March 2008. This was a service offered by a company that no longer seem to exist today: “Like It Tipit Ltd.”. The service allowed me to put a tip jar on my web site. Companies that were using iText and wanted to support its developer financially in his hour of need, could leave a tip. On July 24, 2008, I removed the tip jar. In four months’ time, I had made a grand total of 77.72 euros. That’s less than 20 euros a month.
Open Source Survival: Donations
With iText I had created value for hundreds, maybe thousands of companies, but I had failed to create value for myself. Due to my son being in hospital with Cancer, our first company almost went bankrupt, and I almost gave up on iText.

If you’re an open source developer, I want to make you aware that this could also happen to you. I don’t ask for your pity for myself. My son survived, and I didn’t give up on iText. Eventually, iText made me a millionaire. But maybe I’m an exception. Maybe there are hundreds of developers out there who are creating great value, but who end up empty-handed because they made the error not thinking about a business model.

No matter how successful your open source project is, even if companies such as Google use it, I am living testament that you won’t make sufficient money if you only count on donations.

Offering Professional Services

Open Source Survival: Offering Professional Services
It was tempting to accept assignments to work on projects from third parties to make some quick money, but offering professional services is not a scalable business.

Ask yourself: Do you really want to compete against large software integrators who have more money, more employees, more everything than you? I am going to answer that question in your place, based on a specific personal experience.

A Bad Experience

In May of the dreadful year 2008, I was contacted by a developer with a address. Colruyt Group is a Belgian family-owned corporation, managing retail stores and supermarkets. The group used to include an IT company, Dolmen, specialized in software integration.
The Colruyt developer mailed me because he wanted me to solve a problem he had run into with iText. I explained that my son was in the hospital getting chemotherapy and that I couldn’t help him, but he replied that he expected an answer because his employer had bought my book and he couldn’t find the solution in it. He insisted because he had a deadline to meet.
Frustrated, I contacted a C-Level Officer at Colruyt. I received a reply from the manager who was responsible for the project in which iText was used. He apologized for the behavior of the developer and explained that Colruyt had outsourced the project to TCS (that’s Tata Consultancy Services Limited in India). Outsourcing the project was less expensive than involving Colruyt’s own IT subsidiary in Belgium.
Open Source Survival: Colruyt Case Story
I immediately called that manager and asked: “If I understand correctly, Colruyt is hiring developers from TCS because its own developers at Dolmen are too expensive. Subsequently, the developers at TCS ask me to do their work in their place. However, I’m not paid for that work.”
He confirmed that this was probably the case. I asked if I could take over the project and get paid for doing the work TCS was supposed to do. The answer was negative; the deadline was too close and there was no budget for extra expenses.

I repeat the question from the previous slide: If you’re an open source developer, are you really going to compete with big professional services companies by offering professional services on top of your open source project?
I’ll provide another answer to that question when I get to slide 24.

3. Start-up Phase

Open Source Survival: title slide For Ingeborg and me, 2008 was the worst year in our lives. We almost gave up on iText, but a friend came to the rescue.

Selling Commercial Licenses

The name of this friend was Andrew Binstock, he lived in Silicon Valley, and when he heard about our ordeal, he said: “I need to help Ingeborg and Bruno.”
Today, there is hardly any software that doesn’t depend on free or open source software. FOSS has completely changed the way we look at software and software development. But it hasn’t always been like that. In 2008, there were still companies that had a policy that prevented developers to use free and open source software.
I had received requests from an insurance company on the East Coast and a bank on the West Coast. Their development team wanted to use iText, but they were only allowed to do so if they could purchase a commercial license. Andrew helped me close those first deals in 2009.

As an engineer, I thought that our product was the technology—the software. That’s a common mistake many technical founders make. The long negotiations resulted in the actual product we were selling, the end user license agreement (EULA) that was drafted in close collaboration with the legal departments of our first two customers. Obviously, we also offered a support & maintenance agreement along with the commercial license.
Open Source Survival: Start-Up Phase
Once we had an EULA, I shared a list of companies that had shown interest in purchasing a license with two sales people who agreed to work on commission. Together, we made about $300K revenue in the first three quarters of 2009. The revenue dropped to zero in the fourth quarter after my initial list with leads was exhausted.
The copyleft of the MPL/LGPL is rather weak and many companies were OK with using iText in their commercial offering without paying for a commercial license and support. I saw no other solution than to change the license from the MPL/LGPL to the AGPL, which is a license that is considered “viral” in the sense that use of AGPL components in your own software often comes with the obligation to make your own software available under a license with a strong copyleft too.

Dual Licensing Model

This would allow us to use the dual licensing model.

At first the license change didn’t have a significant impact on the sales. Sales started to boom after I quit my day job. Although many people disagree today, I consider myself quite risk-averse. I had kept that job in case something went wrong with the business.
The blue cylinders represent revenue generated by iText Software Corporation, our subsidiary in the US. In the third quarter of 2011, we opened another office in Europe. The orange cylinders represent the revenue generated by that company. In 2011-2012, we had two consecutive quarters with a revenue of almost $900K.

"Gratitude" from the Community

The license change was very controversial. Some developers said that I had lost my marbles and that the licensing policy was retarded. If I would copy/paste all the expletives that were used to describe me in 2010, this slide deck would be marked as “Adult content.”
Open Source Survival: Selling Commercial Licenses
Several years later, in 2013, I attended FOSDEM, a FOSS event in Brussels. I was in the audience of a panel discussion featuring Richard Fontana, one of the authors of the AGPL. I wanted to testify how the AGPL had been a lifesaver for iText, but when Richard recognized me in the audience, he singled me out and publicly claimed that my use of the AGPL was “nefarious” because I told users that purchasing a commercial license was mandatory in some cases. I have this tweet to remember that incident.

I was cut off and didn’t get the chance to explain that, in my opinion, FOSS usually benefits from the combination of the AGPL and a commercial offering:

The way I was treated made me realize that even the biggest promotors of open source were putting open source developers were at the bottom of the food chain. I perceived the great imbalance between the few unpaid creators of open source on one hand, and the many free users of open source on the other hand, as one of the most annoying problems of open source software.

Good Engineer or Great Engineer?

When you’re an open source developer, you have to ask yourself:

There is nothing wrong with being merely a good engineer. I love working with good engineers, but I won’t consider you a great engineer if you’re not able to create a business model in support of your efforts.
Open Source Survival: Community Response to License Change

4. Scale-up Phase

The license business went well, but I noticed that the dual licensing business model was under pressure.
Open Source Survival: Scale-Up Phase

Zombies and Vampires

I compared my situation to being caught between zombies and vampires.
Open Source Survival: Caught between Zombies and Vampires

As an open source developer, I just wanted to survive.

Be the Specialist and Establish an Ecosystem

In the scale-up phase of the company, I decided to become an undisputed and unmissable expert in the field of PDF.

As iText profiled itself as PDF specialist, we received requests from potential customers from all over the world who wanted us to do PDF projects. Instead of making money with these projects ourselves, we decided to “give” these projects to companies such as CSC, a company that is known as DXC today. These companies had much more manpower than we had, but not a single developer who was as specialized in PDF as we were at iText. Soon, they realized that they didn’t need to have such an expert on payroll, because they could always count on the expertise that was available at iText. The only thing we asked in return, was that their customers would buy an iText license and a support contract if iText was used in their project.
Open Source Survival: Be the Specialist
This way, we succeeded in creating an ecosystem that was beneficial for every party:

In the scale-up phase, we also tried to switch from a model where we sold perpetual licenses and yearly support contracts at 20% of the original purchase price to a subscription model where customers paid a yearly fee based on volume. With perpetual licenses, customers could produce as few or as many PDFs they wanted. In the subscription model, customers paid based on the number of PDFs they processed per month. This switch had a temporary negative impact on our yearly growth percentage, but a significant positive impact on our Annual Recurring Revenue.

5. After the Exit

My wife and I sold three quarters of our shares in iText Group in December 2015. I signed a commitment to stay on board for three years as CTO. I used this time to explore other business models for open source. Open Source Survival: After the Exit

Open Core 1: Commercial Add-ons

When we created iText 7, which was a complete rewrite of iText, we decided to keep the core library open source, but we introduced the concept of commercial add-ons.
Open Source Survival: Open Core 1: Add-ons
Let me give you an example: The AGPL version of iText 7 can create PDFs very fast using any font you want, but that version doesn’t consult the font tables to check whether ligatures need to be made. Such a check reduces the speed of the PDF production, but it results in PDFs with a much better quality. We created a closed source, proprietary add-on, PdfCalligraph, to achieve this. This add-on also supported many writing systems that aren’t available in the “free” version. Customers who want to use that functionality need to purchase a commercial license.

This is an example of what we call “open core”: the core functionality is available as open source, but if you need specific features, you might need to purchase commercial add-ons.

Engage the Community: iText as a Platform

In 2014, we hired Black Duck Software to organize a survey for iText. We received plenty of useful feedback, including the concern that the number of code contributions from outside iText had dropped significantly. That is usually a red flag for the health of a FOSS project. According to Black Duck, this was the consequence of choosing a commercial path for iText.
I didn’t fully agree with this explanation. In my opinion, we received fewer contributions because the specifications we were implementing were unknown to external contributors. For instance, we were implementing the ISO 32000-2 a.k.a. PDF 2.0 based on the draft of the specification, long before the standard became available to the public. Furthermore, it was hard to “compete” with our team of developers who worked full-time on iText.
Open Source Survival: iText as a Platform
To turn the tide, we decided to introduce the concept of “iText as a Platform.” Independent developers and small business owners claimed that iText licenses were too expensive. Price was a threshold to start creating a product that was built on top of iText. We decided to allow free use of iText by domain experts working on products that were outside our own area of expertise.

The first third-party addons were:

These add-ons were branded as iText products, and we shared the revenue on each sale. All parties benefit from such collaboration:

Open Core 2: Software as a Service

Before I left the company, I started a project codenamed Tyrion, named after one of the characters in “Game of Thrones.” This project resulted in iText DITO, a low-code solution to create templates.
Open Source Survival: Open Core 2: Software as a Service
The basic concept of this project is simple:

This is also an example of open core, iText is open source software, but users don’t need to download iText anymore. The open source library lives in the cloud, and is served to the customers and users in the browser who pay a fee to use the technology. I chose the codename Tyrion for this project, because Tyrion kills his father in “Game of Thrones.” I saw an opportunity to replace the revenue we were generating selling licenses with revenue generated through services such as DITO subscription. In other words: I was willing to kill the license business and replace it with a SaaS business. Once we had sufficient revenue, we were going to extend the PDF functionality offered as a service, and I wanted to change the license for the core iText library back to a permissive license.

The codename Tyrion was quite ominous in the sense that I didn’t expect that the new owners of the company would decide that they no longer needed the father of iText. The production-ready version of iText DITO was released after I had to leave the company. I don’t know if the current owners have any plans to make iText more permissive.

Use a Permissive License to Strengthen Your Position in the Market

Throughout the years, I’ve seen how large corporations first hated open source because it was disrupting their business model. When open source proved being an unstoppable force, they embraced it because they realized there was money to be made. Gradually, I saw how these corporations started to brainwash developers into thinking that copyleft licenses were evil and that all software should be released under permissive licenses, such as the BSD, MIT, and Apache license.
There are circumstances that justify choosing a permissive license, but as a FOSS developer, you should always ask yourself if the license serves your own business model or merely benefits third parties. If only the latter, you risk severe disappointment in the long run. Companies such as Facebook, Google, and Microsoft produce a lot of open source software because it fits their business model. Their main business usually isn’t selling software.
Open Source Survival: When to Use a Permissive License: reason 1
Today, these companies are perceived as FOSS heroes because they distribute plenty of FOSS products using a permissive license. They can afford to do so because they have a business model in place that generates sufficient money—selling products that are very different from the FOSS product.
They aren't sharing out of charity. The more developers adopt their FOSS products and frameworks, the more these corporations strengthen their position in the market. It’s only normal that the generosity ends the moment a reduced added value of the free offering no longer justifies further investment. Users building a business on top of a free framework may wake up one day, discovering that the framework they use is no longer supported.

I encourage FOSS developers to explore the SaaS model because it’s a solid recipe for success when done right. At the same time, I advise FOSS users to work with technology from a company that ensures further development and long-term support, rather than using free stuff that is merely a side effect of the actual business. FOSS users should always be aware of the business model behind the technology they use.

Use a Permissive License to Become the De Facto Standard

In the first years of the existence of iText, there were two alternatives to using iText with an Apache license: PDFBox and Apache FOP. I don’t think I ever met any of the developers of Apache FOP, not in the PDF Association, not in the ISO committees for PDF, not at any PDF event. I met someone who worked on Apache PDFBox at the PDF Association, but the only thing I remember from that conversation was that PDFBox didn’t have any plans to support PDF 2.0.
While these libraries are still around, I would never use them in any of my projects. Sure, they are free as in free beer, but that also means that they don’t have the resources to support the latest evolutions in PDF technology. Suppose that I invest in using Apache PDFBox, and suddenly I am confronted with some government regulation that all my PDFs need to comply with a certain specification that isn’t supported by PDFBox. That would be a serious show-stopper. I might run into unexpected expenses to meet new requirements that emerge.
This is not a theoretical example. In 2016, the “Rights of Persons with Disabilities Act” made almost all airlines in the US switch to using iText to create boarding passes because iText supported the PDF/UA standard whereas their existing solution didn’t.
The UA in PDF/UA stands for Universal Accessibility. PDFs that comply with this standard are created in such a way that they can also be consumed by the blind and the visually impaired.
Open Source Survival: When to Use a Permissive License: reason 2
Another open source alternative with a weaker copyleft than iText is OpenPDF. OpenPDF is a fork of iText that was created out of discontent with the license change. Its legal situation is ambiguous in the sense that all package names still start with com.lowagie (and is a domain that I own) whereas I have no affiliation with any of the people responsible for OpenPDF. These people don’t own any rights on the original IP and there’s a comment in the original iText source code that states that changing the “Producer line” without explicit consent of the original developers will be considered as an infringement of the intellectual property—a comment that the OpenPdf people chose to ignore.
I don’t know if that obligation can be legally enforced, but if the OpenPDF people ever want to get funding or go for an exit, they will need my consent, and that’s probably never going to happen. In spite of me being the proud original author of iText and therefore also the original author of OpenPDF, I would never advise using OpenPDF for the same reason as why I would never advise using PDFBox or FOP: OpenPDF is still maintained, but when I recently checked the codebase, I saw that much of the functionality is outdated. Nevertheless, I am happy that OpenPDF is around, because developers who start working with OpenPDF automatically get acquainted with iText. If OpenPDF meets their needs: fine. However, as their project grows, they might run into the limitations of OpenPDF. When that happens, they might decide to go for the real thing, and switch to using iText.
Sometimes, I pretend being angry at the OpenPDF people for their lack of respect, but in reality, all the marketing efforts they do for OpenPDF are automatically marketing efforts for “Lowagie.” This may lead to developers using OpenPDF also wanting to read my book.

Star Trek, not Star Wars

My plan to make iText more permissive once we had sufficient revenue from services was to make iText the reference library for PDF. If iText were available under a permissive license, the choice for a PDF library would then become a no-brainer. There would be no reason for developers to choose PDFBox, FOP, OpenPDF, and no developer would have any incentive to create a new, competing product.

As I said: I don't know what the current owners of iText are planning. I don't know whether they are fans of Star Wars, or if they prefer Star Trek.


I promised you a story from the trenches, and I think I delivered what I promised.
Open Source Survival: summary: 8 ways to make money with open source software
I shared eight different ways to make money with open source from my personal experience.

Why Open Source?

You may wonder why I didn’t consider pure closed source, proprietary software in my deck.
Open Source Survival: why open source (instead of closed source, proprietary software
Based on personal experience, I don’t believe in such solutions anymore.

This is one of the conclusions I made after a career in tech that spans a quarter of a century:
Open Source Survival: conclusion
Every adjective counts in this conclusion.

Thank You for listening!

Open Source Survival: contact
Open Source Survival: credits

As an Amazon Associate, I earn from qualifying purchases.