Bruno Lowagie, Creator of iText: From FOSS to COSS

Bruno Lowagie is the creator of iText, a Java / C# library for generating PDFs. The first version was released in 2000, under the MPL/LGPL, (two FOSS licenses), and in 2008 the project transitioned to a dual-license model (AGPL and Commercial) with version 5. Ten years later, in 2018, he and his wife sold three quarters of their company for eight figures.

In 2021, Bruno published a book about his journey, called Entreprenerd. It is a candid firsthand account of what was involved in building iText into a multi-million-dollar software business.

I recently got in touch with Bruno, and he agreed to answer some of my burning questions in an interview for the Code Code Ship blog. That interview is recorded below.

Bruno, first of all, thanks for agreeing to this interview. In 2004, iText was 4 years old, and in widespread use. Can you tell us what factored into the decision to commercialize your library?

iText started as a project that I maintained after hours, together with a Portuguese developer, Paulo Soares. I had my day job in Belgium (where I live); Paulo had his job in Portugal.

“Gradually I understood that I was creating plenty of value for other people and other companies, but not for myself or for the library. Something had to change.”

FOSS was far from being mainstream in those early years. When asked why I allowed people to use iText for free, I always answered: “No money, no worries! If I don’t ask for money for my work, I won’t have any worries about it.” That was a very naive point of view. By 2004, hundreds, maybe thousands, of companies were using iText, including big corporations such as IBM, SAP, Amazon, and Google.

As none of those companies were paying me for my work on iText, I needed a full-time day job to make a living as a husband and a father of two sons. Nevertheless, plenty of developers were urging me to answer their questions for free. Somehow the message that “free software doesn’t come with free consultancy” was lost on most of them.

Allow me to quote Marijn Haverbeke (@MarijnJH) who once tweeted: “Between my kids and my OSS users, I seem to be spending a lot of energy on people just because they are so endearingly dependent on me.”

The pressure from users was quite counter-productive. I hardly had time to focus on further development because of the high demand of “personal” support. Back then, I could get angry at users posting questions that had already been answered repeatedly. I wrote several tutorials and even books about iText, yet many developers found “asking the original developer for help” more interesting than “reading the documentation.”

Gradually I understood that I was creating plenty of value for other people and other companies, but not for myself or for the library. Something had to change.

Then suddenly my own country decided that my dedication to iText was considered a form of self-employment. I was retroactively charged social security taxes, even though I didn’t even make any money selling the software. That was the final straw for my wife and me: we decided to start a company and create a business model for iText.

You incorporated the first company, 1T3XT BVBA, in 2008. Summarizing a little, between 2004 and 2008, you completed an extensive IP review and wrote a book, iText in Action. With the benefit of hindsight, and considering the changing times, if you were commercializing iText in 2023 instead of 2004, would you choose the same approach?

I wrote the book so that I could refer to it in my answers to the abundance of technical questions about iText. Once the book was written, I received plenty of legal questions: “Who owns iText? Is it safe to use iText from a legal point of view?”

Just like Dr. McCoy often says things like “I’m a doctor, not a bricklayer” in Star Trek, I used to respond to these questions with the answer: “I’m a developer, not a lawyer.”

“I am sure it’s still possible to create a healthy business based on FOSS, but I won’t claim that I know how to do it.”

I had the luck that IBM and the Eclipse Foundation were extremely eager to get a better answer. They initiated a research agreement between Actuate, one of the members of the Eclipse Foundation, and my employer at that time, Ghent University. The deliverable was a complete IP review of the iText source code. This review established that I owned most of the intellectual property rights, together with a small core of developers who all signed a Contributor License Agreement in which their copyright was acknowledged, but in which they also gave me permission to commercialize their contributions. As soon as I started making money with iText, I started paying core contributors such as Paulo Soares.

If I could return in time and do it all over again, knowing what I know now, I would probably have started thinking about a business model at an earlier stage. And if I had to start all over again with iText in 2023, I think I would need to use a different approach because the world has changed in the last twenty years. My editor wanted me to give my book the subtitle “How to build a multi-million-dollar business with open source software”, but I refused and I changed “How to build” into “Building” because developers shouldn’t use my book as a recipe book. What worked for me in 2004 won’t necessarily work in 2023.

There’s a chapter in my book in which I describe three lessons I learned from the television series “House MD”. Those lessons are still valid, especially the last one: “Tests take time; treatment is faster.” It’s easy to propagate some theory about how to monetize FOSS, but those theories are worthless unless you can put them in practice. I am sure it’s still possible to create a healthy business based on FOSS, but I won’t claim that I know how to do it. I would have to show by example how it’s done. It would involve plenty of “trial and error”, just like plenty of “trial and error” was involved when I first went into business.

Some of the open source maintainers I talk to are nervous about the potential fallout associated with changing licenses. Were you worried about this? How did your users react when you told them they would have to pay for iText 5 if they wanted to use it in commercial projects?

Was I worried about the fallout? Yes. Was I justified in being worried? In the case of iText: No!

I did get plenty of angry reactions from people who called me names, such as “traitor”. I was “greedy”, “shameless”, “unscrupulous” … I must admit, such comments often kept me awake at night. Fortunately, I was surrounded by people who supported me. My wife, Ingeborg, but also my good friend Andrew Binstock, who was the first managing director of iText Software Corp. in the US. He explained the concept of the “loud minority”: Out of 1000 users, there might be 999 who understand that there is no such thing as a free lunch. They understand that developers must make a living too. I wasn’t hearing what those 999 people thought; I mainly heard the noise made by that 1 person out of every 1000 who called me names.

I also identified an inconsistency in the rationale used by those who complained that I was “not true” to the FOSS spirit. I didn’t make iText proprietary, did I? The license change did exactly the opposite of what they claimed. The AGPL prevented companies from using iText in their own proprietary software without contributing anything back to the community.

• If they wanted to keep using new versions of iText for free, they were obliged to distribute their own software under the same FOSS license, a big win for FOSS in general.
• If they wanted to keep their own source code closed and proprietary, they had to purchase a commercial license, a big win for iText and its users, as the money was used to further develop and maintain the library.

Somehow, that elementary logic escaped those with the loudest complaints.

Eventually you had a team of software developers working on iText full time. What kind of an impact did that have on the quality of the library? Would iText be the same library today if you had decided to not commercialize, but to stick with FOSS?

I must admit that there was a time that I considered “sales” to be a “dirty word”, but once I started making money, I understood that “sales” meant “fuel for further development.”

“Commercializing iText had a significant impact on the quality of the library”

I’m old enough to have known a time before PDF existed, but for many people, it feels as if PDF has always been around. Some even consider it “ancient” technology, almost an anachronism, but I don’t agree with that point of view. In 2007, Adobe donated the PDF specification to an organization that made it an ISO standard (ISO 32000-1:2008). PDF experts from all over the world meet at least twice a year for ISO committee meetings to further develop the standard.

Before I made money with iText, I didn’t have the means to join those committees, but once the business was thriving, I participated in person and even contributed to the standard. At the same time, our development team kept iText up to date with the standards.

Allow me to give you two examples why this was important for iText:

• Digital signatures depend on hashing and encryption algorithms, and that’s serious business. Think of Heartbleed, the security bug in OpenSSL that put thousands of internet servers at risk. You don’t want to be the FOSS developer responsible for such a disaster. Many companies are using iText to apply digital signatures to documents. They depend on iText, so we have the obligation to make sure we comply with the most recent standards. This can’t be achieved without a significant (financial) investment. My heart sometimes bleeds (pun intended) when I see questions on Stack Overflow about applying digital signatures with (forks of) MPL/LGPL iText versions dating from 2009 or earlier. The hashing algorithms that were used back then were proven to be broken. They have been deprecated in recent versions of the PDF standard and should no longer be used. I honestly don’t understand why so many developers fail to understand that.
• As a second example, I want to refer to PDF/UA. UA stands for Universal Accessibility. A document that conforms with the PDF/UA standard can be read by the blind and the visually impaired using Assistive Technology (AT). The PDF/UA standard was released in 2012 and we decided it important enough to invest in its implementation, as opposed to other FOSS “competitors” who didn’t have the budget to do so. We were rewarded for that decision in 2016 when the US government issued a law requiring customer-facing documents to be accessible in certain industries. For instance, if an airline produced a boarding pass in PDF, it was mandatory for that document to comply with PDF/UA. That year, we signed up almost every American airline as a customer.

I could give you many other examples, but yes, commercializing iText had a significant impact on the quality of the library, and iText wouldn’t be the library it is today if I had stuck to offering it as FOSS only.

Did you worry about new FOSS competitors (or even a fork of iText 4) emerging after you released iText 5? Why do you think new FOSS libraries failed to emerge or were unable to compete with iText?

Without going into details, I can tell you that Google wasn’t my best friend. Google was using iText heavily but stopped upgrading to newer versions in 2009 because of the change to the AGPL. The company also refused to become a customer because “Google doesn’t buy software, it buys companies.”

“You shouldn’t underestimate the advantage of having years of experience solving real-world problems for paying customers.”

Google Analytics was one of the first projects in which they replaced iText with a competing product. I used to download nice reports in PDF created with iText, showing how the iText website performed. I was surprised when the new reports suddenly looked extremely ugly. I checked the metadata and I saw that Google had replaced iText with another library (and they would replace that library with another one in the years that followed).

I feared Google because of the sheer power the company had (and still has). I was afraid that Google would someday release a competing library and wipe out my business. That never happened. It wasn’t until I discovered the killedbygoogle.com website (aka “Google Graveyard”) that I understood why not. Seen from the point of view of the business, it didn’t make sense for Google to compete with iText.

I didn’t fear other FOSS developers creating a competing library, because:

• I knew that it would take them many years to catch up with iText. You shouldn’t underestimate the advantage of having years of experience solving real-world problems for paying customers.
• Being a member of the ISO committees for PDF and an active member of the PDF Association, we also kept our finger on the pulse of new evolutions in the world of PDF.
• Furthermore, we started writing a new PDF project to rewrite the library from scratch. More and more I was experiencing the phenomenon that is commonly referred to as ‘technical debt’. Some of the design choices that I had made in 2000 were suboptimal when looked at in the context of newer standards such as PDF/UA. I asked myself: if I would want to compete with iText by creating a new PDF library, which mistakes would I avoid? The result was a completely new library: iText 7.

In other words, we did everything in our power to stay ahead of potential competition on the FOSS front.

Aside from the quality of the library itself, are there reasons your customers might want to pay to use a commercial software library? For example, in your book you mention decreased IP risks. Are these reasons as relevant today as they were in the late 2000s and in the 2010s?

Protection against IP risks was certainly an important reason for “users” to become “customers” in the early years. Our first customers were banks and insurance companies. In the early 2010s, many of them had a policy that downright prevented the use of FOSS. Obviously, these policies have changed now, but over the years, I saw the emergence of a new role in the business: the role of the compliance manager who makes sure that there is no illegal use of software within the company. Sales requests to purchase iText licenses were often triggered after an internal audit of the company’s compliance manager.

Ensuring continuity is also an important reason for purchasing a license. When you start using FOSS software, you make an investment, if not a financial, then certainly in time and effort. You don’t want to “compromise” your project or product because it depends on FOSS software that can be discontinued at any given point in time.

See my earlier example regarding digital signatures; suppose that you use a FOSS library in a product that digitally signs PDF documents. To comply with new hashing and encryption algorithms, you’ll need to upgrade the underlying library on a regular basis. But what if the maintainer of the FOSS software doesn’t have the means to keep that library up to date?

• In theory you could dive into the code and implement the new standards yourself. I know from experience that this is not as easy as it sounds in practice. Most FOSS projects I know consist of thousands of lines of code. It takes quite some time to understand how that code works, and it takes even more time to adapt it to meet your needs. It’s better to leave the job to a specialist who knows the code inside-out.
• You could pay the original developer to implement the functionality you need. As far as I know, that’s how the OpenSSL developers used to work. We all know how that ended. Personally, I don’t believe in the business model of offering professional services where one company pays for development that can be used for many other non-paying users. It’s not sustainable. You need to be proactive and invest in new technological evolutions before the market discovers they need the results of your R&D.
• You could decide to stop using the FOSS library that no longer meets your needs and replace it by another one. The cost to “migrate” might be high, though, and you might end up in the same situation once more after a couple of years.
• I think it’s better to pay FOSS vendors for using their software, rewarding them for the effort of continuously maintaining and upgrading the technology. If you want the assurance that you can keep on using their software, this is the way to go.

In my last years at iText, we stumbled upon another advantage. We noticed that we were getting questions from customers about PDF issues related to the use of competing products. We answered them out of courtesy and while doing so, we learned that some of them were paying invoices to a dozen different PDF vendors. They were using product A because they needed functionality X, using product B because they needed functionality Y, and so on. We surveyed our customers’ use of PDF software and we discovered that they could replace almost every competing product with iText. We advised them to standardize on iText. Their benefit was that they could replace a dozen yearly invoices issued by a dozen vendors by a single yearly invoice from iText. Obviously, the figure on that single invoice was much lower than the combined sum of all the invoices they were paying before.

I know that many of you expected me to answer that paying customers want support and documentation. That’s true, but that’s the “easy” answer and maybe even the “outdated” answer. Support and documentation should be part of the minimum service you offer your customers, but you need more. Surely, you don’t want your business model to depend entirely on something developers can also get for free on Stack Overflow? Moreover, AI chatbots are getting better and better at answering support questions.

When you deal with large corporations, developers usually aren’t the decision makers. As a software vendor, you’ll need to convince managers that they should pay for the software their developers are probably already using for free. Having strong strategic arguments involving continuity, standardization, efficiency… will help those managers decide whether it makes sense to pay you for your work.

How did you distribute your project? Would you have used Code Code Ship (or something like it) if it had existed at the time? (NB: a "no" is also fine, please be honest!)

If you read my book, you’ll learn that I made serious efforts to avoid having to start a company myself. I was even willing to donate the code to a local company in the hope that I could avoid the burden of going through the process of setting up a business, hiring people, doing sales, marketing the product, and so on.

“Being a FOSS developer is fun when a project is either small or unsuccessful”

If Code Code Ship had existed at the time, I would certainly have considered it as an option. Although I must admit that I only looked at the website superficially, I like the idea of separating what developers do best (writing code) from what businesspeople do best (selling software), but I would like to share some thoughts based on my own experience.

In my book, I mention the concept of ‘iText as a Platform’ that was developed by our first external CEO. The idea was to encourage developers to create projects based on iText and allow us to package those project as add-ons to iText. Our marketing and sales staff would then market and sell those “third party add-ons” using the iText brand, sharing the revenue with the original developers. After reading my book, the new CEO of iText told me that the company had indeed closed several revenue sharing agreements with developers, but going forward, all those projects ended up being acquired by iText.

Maybe the developers of those add-ons preferred the certainty of immediate cash over uncertain revenue in the future. Or maybe it was easier to have full-time iText developers maintain the add-ons because the original developers often lacked the time or bandwidth.

Being a FOSS developer is fun when a project is either small or unsuccessful, just like iText was when I first released it in the year 2000. It’s a whole different ballgame when the project starts to grow both in size and popularity. At first, I tried solving that problem by finding a potential acquirer or an investor who could help me. I was quite disappointed when those weren’t impressed by the exceptional number of iText downloads and users. They asked me: “If we put money in iText, how are we ever going to make a profit on our investment?” It took me quite some time to realize that having a couple dozens of paying customers is worth much more than having thousands and thousands of users. The Code Code Ship platform could provide developers with proof that people are willing to pay for the software they created. This could convince potential acquirers or investors of the value. They might see opportunities to scale from a dozen to a thousand customers.

This might also be a risk for the platform. Once they have sufficient traction, developers might be tempted to leave the platform.

• Some developers might decide to do what I do, start a company, and create their own business. However, when I am asked to give a lecture at a University, I always warn against “survivorship bias”. I am invited as a guest lecturer because I was successful. For every Bruno, there are probably a hundred other people who didn’t have the luck I had. Those people are never asked to give lectures.
• Other developers might decide to sell their project. If you see that happening, it might be interesting for the platform to pivot into becoming a broker between on one side, developers with a project people are willing to pay for, and on the other side, corporations having the knowhow to scale the business for such a project.

I’m not saying this will happen, but it’s something to consider for the owner of the platform:

• What will you do if you’re successful? Maybe you’ll start hiring a team that markets and supports the projects on behalf of the developers on the platform.
• What will you do if you’re not successful? Maybe look for an additional business model.

Would you like to see more software developers consider commercializing their projects?

If I were still in the business, I would stay away from FOSS projects created by developers who hadn’t thought of a business model. Why? For the same reason I have always avoided a dependence on APIs that are offered for free. Such APIs can be closed overnight, and you might wake up with a serious hangover when that happens. So yes, I would like to see more software developers commercializing their projects on the condition that they invest sufficient money in further development, ensuring continuity, compliance with standards, safeguarding of intellectual property, and all the other things I mentioned throughout this interview.

In 2018 you left the company, and in 2020 you sold the remainder of your shares. How is life post-exit? Can you tell us a little about your projects?

The first years, I tried to do what many technical founders try doing after an exit: I started investing in local startups. I soon discovered that this was a mismatch for me.

I had hoped that investing in emerging technology would keep my skills as an engineer up to date, but I underestimated how fast you lose touch with the nitty-gritty details if you don’t have the daily hands-on experience of being actively involved in a company. I was a member of the advisory board of these companies, but I got frustrated because I didn’t have as much impact on the business as I had when I was CTO at iText.

I decided to stop all investments in tech companies, and I even decided to leave the IT business altogether. I am now pursuing a career in the cultural sector.

“We can afford to pick projects of which the societal return of investment exceeds the financial return on investment. These projects give me the purpose I am looking for in life.”

My wife left the company in 2016 and she started investing in real-estate. One of the projects she did was turning a boxing / gym club into a table tennis venue. My youngest son is running this place. He had the bad luck that the opening was scheduled in April 2020, one month after Covid-19 shut down all social life for two years, but fortunately business has been picking up; not as fast as we had wanted, but we’re getting there.

Following that example, my wife and I decided to buy the real-estate of the oldest, still active arthouse cinema in the historical center of the city of Ghent: Sphinx Cinema & Café. In the last nine months, we have assembled an expert team of architects, acoustic engineers, stability engineers, energy specialists, and so on, to do a feasibility study with the goal to renovate and upgrade the building that dates from 1912.

More recently, we joined a consortium that will restore the Winter Circus in Ghent in all of its glory. That building dates from 1894 and it was originally used as a permanent circus until 1945. It even had an entrance for elephants. After the Second World War, it became a garage, and later on a depot of old timers. It was then abandoned for many years until the City of Ghent bought it and renovated it. The consortium I belong to is now preparing the building to host the opening of the Flanders Technology & Innovation event that starts on March 15, 2024. In the future, it will be a hub for all kinds of activities that involve technology or innovation in one way or another.

People who know me, know that I am also very much into film. Earlier this year, the movie “Sea Sparkle” (original title: “Zeevonk”) was selected for the Berlinale where it won a special mention from the jury (2023). The movie has been sold to different countries. If you ever watch it, take a close look at the credits: I am mentioned as the “executive producer” of the movie, which is a posh name given to me because I invested in the movie.

Having had an exit, I can finally realize some childhood dreams, writing books being one of them. I know it’s hard to make money as a writer and we probably won’t make much money with table tennis or screening movies either, but that doesn’t matter much anymore. We can afford to pick projects of which the societal return of investment exceeds the financial return on investment. These projects give me the purpose I am looking for in life.

Bruno, thank you so much for answering my questions. I know that there are many engineers out there that will be very interested to hear what you have to say. To everyone who enjoyed this interview: the print edition of Bruno’s book is 400 pages long, and contains much much more than we could ever fit in a single interview, to say the least. I have read it from cover to cover, and I can say that it is well worth a read.

You can buy Bruno's book here, and follow him on Twitter.