Four failures and one hit

No hay notas en la diapositiva.

I had my first computer at the age of 12: A Texas Instruments 99/4A. The year was 1982 and I lived in Ypres. I was the only guy I knew who owned a computer and I only had one game: Space Invaders. Although this is a really cool game, I got bored pretty soon and I started to teach myself how to program in BASIC. I had to teach myself, because I was the only guy I knew who knew how to program.
One year later, my parents bought me my first portable: a Tandy RadioShack TRD/80 4P. (May RadioShack rest in peace.) It was bigger than my mother’s sewing machine. At first, I wrote myself some games, but when you write a game, you soon discover that you also need “serious” software, such as a database. And that’s how I wrote my own flat file database system.
In order to test it, I visited some people who were active in the social and cultural world. I asked them: can I borrow the address lists with all your members? By that time, I was 14 years old and although people were suspicious (“why is this 14-year old interested in our member-list?”), most of them saw no harm in sharing their data. I used this data to fill my database, and when I returned the lists, I added a set of printed labels.
The year was 1984 and when organizations needed to send a mailing to their members, they had to manually write all of their member’s addresses on envelopes or labels. Now they suddenly had a set of printed labels which most of them immediately used.
And when the next mailing was due, they would come and knock on my door asking: “Hey Bruno, can you make some more of these labels?” My answer was very predictable: “Of course, I can make some more, but… I have to buy those labels and they aren’t for free…”

People didn’t know they needed preprinted labels. They had been fine writing addresses manually for decades. However, when I gave them their first set of labels, they discovered a need they weren’t aware of before.
If I had been 24 at that time, instead of 14, I could have become “The Label King of Flanders”, but my action territory was limited to Ypres.
This was my first failure in business: the cost of my TRS/80 was over 2500 euro. I sold the printed labels at double the price I bought them, but the price I charged for one sheet of labels was only 2.5 cents. To be profitable, I had to sell more than 200,000 sheets of labels. That never happened.
Moreover, at the age of 16, I discovered that I was interested in girls and I abandoned my computer until I finished college.
Nevertheless I had learned three valuable lessons: find out what people need, show them what they need, then scale if you want to be successful.

We skip to1996. The programming language Java existed for about a year. The Java version was 1.0.2 and one of the first applets I wrote (apart from Hello World and a Connect Four game) was an applet showing the map of Belgium.
Google didn’t exist yet and unfortunately I have no copy of that applet anymore, so let me just show you what a web browser looked like in those days and what an applet was about. It was a rectangular object in a web page that could interact with the end user. In my case, the Belgium Applet show a very simple map of Belgium and allowed you to enter a postal code.
Then the map would zoom in on the corresponding city and each city in the zoom window was a clickable dot that showed you a list of addresses of shops. I had manually created a database with ShoePost, Delhaize, Tom&Co and other stores. It was my intention to “sell” this cool app to one of these (preferable all of these) chains.
Unfortunately, I had a hard time finding the e-mail addresses of the people responsible at ShoePost, Delhaize, Tom&Co. The year was 1996. Some of the chains I listed didn’t even have a web site yet. E-mail wasn’t commonly used. The Belgium Applet failed miserably.

Applets were never very popular. In 1996, there were problems to make applets work on Netscape as well as on Internet Explorer, because of important differences in the way Java was interpreted on the different browsers. Eventually this was fixed, but Flash was far more popular than Java applets and the Java developer community focused on servers rather than browser clients.
The idea of having an interactive map in a browser was great. The popularity of Google Maps proves that there was a market for it, but the year was 1996: who was online in Belgium in 1996?
I also did a bad job at marketing my idea. I tried to explain the concept from a pure technical point of view (in case you hadn’t noticed yet: I’m an engineer). As a result, nobody understood what I was talking about. The applet did get me another job, though. I showed it during a job interview and I was immediately hired.
Again I had learned three things: technology needs time to mature, ideas need time to mature, and most of all: engineers are usually bad at marketing their ideas. Or more specifically: I used to be bad at marketing my ideas. Fortunately, I changed.

In 1998, I saw an ad for a job at Ghent University. It required knowledge of C and Perl. I knew how to write C code, but I had never used (or learned) the programming language Perl. I applied for the job anyway, and I bought myself a book about Perl.
One weekend later, I knew how to program in Perl. Yet another weekend later, I wrote something called Perl Server Pages. It was very similar to Active Server Pages and Java Server Pages. ASP and JSP were technologies that allowed you to write simple HTML and enhance it with code that makes the pages dynamic. PSP was similar, but instead of ASP or Java code, you could enhance your HTML with Perl code.
Eventually, I got the job at Ghent University and I managed to change the project requirements: instead of writing a new intranet application in Perl, I was allowed to write it in Java. I used my own PSP code for a handful of sites and I promoted it in the hope that other Perl programmers would adopt it, but that never happened. That was yet another failure on my track record. There was no market for Perl Server Pages.

Why did nobody else use my PSP project? The opinion of a diehard Perl developer is that whatever code he writes himself, is better than code writing by somebody else. Perl code can be very hermetic. Even if you have written the code yourself, you can have a hard time understanding what it was you were trying to do.
So when somebody suddenly proposed something that could make the life of a Perl developer easy, “Perl Server Pages”, nobody was interested, because the attitude of a Perl developer is “We don’t do easy!” The lesson I learned after this failure was that my knowledge about the audience I addressed was insufficient.
Furthermore, I must admit that I wanted to copy something that already existed: why invent PSP if you already have ASP and JSP? That lesson became very clear after my next failure.

In 1998, Durk Jan de Bruin, created a web site called startpagina.nl. When thinking of his target audience, he had his own father in mind: an inexperienced internet user who had just gone online and who wanted to know which links were interesting.
Early 2000, I registered the domain loogje.com to do something very similar. This name allowed me to create subdomains such as cata.loogje.com, techno.loogje.com, etc. I made a database with different categories and I allowed people to add links. The idea was that the web site would grow organically thanks to the users. I would moderate and add links to sponsors. When startpagina.nl was sold for 13.5 million euro to the VNU, I was really jealous. Cata.loogje.com had some visitors, but it was far less popular than startpagina.nl or even other competitors. I never made any money with the site.
That is: if you don’t count the American check for 2 cents that I never cashed. The last snapshot on the Wayback Machine dates from January 2002. That’s more than a year before Google AdSense was introduced (June 18, 2003).
Cata.loogje.com was an MFA site (Made For Adsense) avant-la-lettre. When I saw the first MFA sites, I really disliked them, and I asked myself: why did I ever make something like cata.loogje.com. It’s not something you can be passionate about, is it? Today I would never create something that I don’t like myself.

So here are some more lessons I learned: it’s OK to look up to successful people. It’s even OK to be jealous of them. By all means: be jealous! Just avoid trying to copy what they do. Instead do something you’re really passionate about and write your own success story.

The first PDF specification was released in 1993. The PDF format was originally meant as a format that would allow documents to be rendered in a uniform way across platforms. It was initially adopted in the printing industry because it offered a way to print documents in a predictable way. Over the years, PDF evolved, but in 1998, it was still pretty much a format for documents that were created on the desktop. That is: manually, by a human being.
Fortunately, I didn’t know that. I was working on a project that involved rewriting an application that previously was only available on Windows/DOS. The goal was to make sure that it could also be used on Apple computers, SUN Solaris, Linux,… A decision was made to make it a web application, and I thought it would be cool to produce documents in PDF so that they could be viewed on all these systems in a platform independent way. So I promised my employer (Ghent University, the one from the ad): we’ll produce PDF! Little did I know that there weren’t any tools available that could create PDFs in an automated way.
But a promise is a promise, so in the Christmas holidays of 1998, I read the PDF specification. I really hated the PDF format. I thought it was an awkward format, but I managed to write my first PDF library in about 6 weeks. There were several problems with that library: (1.) In order to use it, you had to know the PDF specification. (2.) I was the only person who understood the code, and that was annoying, because that meant that I was the only one who could maintain the code, (3.) in the year that followed, I started to love PDF and I realized that my library didn’t honor PDF.
However, there was very little enthusiasm when I asked my employer “Can I completely rewrite this code?” Why change something that works? And that’s why I started iText as a hobby project: I really wanted to create something I could be proud of. iText was the first enterprise-grade PDF library that liberated PDF from the desktop and made it something that could be created on a server. Today, everybody takes this for granted, but at that time, my library was very innovative.
Initially I distributed iText for free as in free beer as an open source library licensed as LGPL. I thought: if I don’t ask any money for iText, I won’t have any troubles. That was very naïve.

An open source project is fun when it’s not that popular. But as soon as everyone starts using your software, it can be very hard to maintain. In the first couple of years, I really enjoyed answering technical questions, but once iText became more popular, things suddenly got more serious. I took away revenue from Adobe, so I ended up on their blacklist. Corporate politics kicked in, and there was a lot of FUD (Fear, Uncertainty, Doubt) about open source: it wasn’t well documented, the IP wasn’t‘ clear, it wasn’t backed by a company. That’s why I decided to work on a plan to fight the FUD, focusing on the three main concerns listed on this slide.

In 2004, I took some vacation to write a free online tutorial. I knew from my experience with cata.loogje.com that some people were able to make money with ads and I had been following the evolution of the advertisement business. When I started writing the free online tutorial, I decided to add Google AdSense ads.
That was a success: as I was an early adopter of AdSense, I made about 1000 euro a month with these ads in 2015. Making money using ads wasn’t a sustainable business model, though. As the years passed, more people started to work with Google Ads and revenue dropped to 100 euro a month and less. I decided to remove the ads altogether because I noticed that the main advertisers were actually competitors of iText.
Fortunately, I found another source of revenue: thanks to the success of the free online tutorial, I was offered a book contract, first by O’Reilly, then by Manning. I decided to write a book for Manning and they told me that the book would be considered a bestseller if I sold 5000 copies. Eventually, I would sell almost 12000 copies of the first edition, and 9000 copies of the second edition. This solved the problem “open source projects aren’t documented.”
The book dealt with the technical questions, but I also received more and more legal questions: who owns the IP of iText? Is the IP of iText 100% clear? I was in luck: two multinationals who were using iText for free, IBM and Actuate, decided to sponsor an IP review. In 2006-2007, I’ve spent about a year cleaning up the intellectual property of iText. It was one of the most boring jobs in my life because I had to go back in time and document who contributed what when. I also had to ask the core contributors to sign a contributor agreement.
Today, we have the discipline to keep record of every snippet of code that goes into the codebase. I advise everyone to do that as it will save you plenty of time (and troubles) in the long run. This solved the second problem: “The IP of open source isn’t clear.”
With the IP review done, we created our first company. Today, I must admit that I should have done this at a much earlier point in time, but hey, I was a developer, not a business man. Little did I know we would end up having a successful company. I participated to BizIdee in 2005 and 2006 and the jury had told me that I would never be able to make money with open source. Boy, were they wrong!

The lessons I learned from the early years of iText is that you should always document your product from the start. Good documentation is key. If people don’t know how to use your product, they won’t use it, especially if it’s a very technical product. Also document your IP from the start. STDs kill. And by STD, I don’t refer to sexually transmitted diseases, but to Software Transmitted Diseases. If you build an application that depends on a bunch of open source products from third parties, make sure that you have checked who owns the IP and if it is legal to use an open source product in your application. You won’t survive the most basic due diligence if you don’t have this information. Finally, don’t be like me: create a company from the start, even if you don’t have a product yet. Having a company will protect you and may even cut costs.

When I first released iText, I contributed to a number of disruptive changes. There was the technical aspect of bringing PDF to the server, but there was also the business aspect of providing a PDF library as an open source product. When I talk to people at Adobe today, they tell me how worried they were about this change. I wasn’t aware of that. The first time I noticed that Adobe was following me was when they started to see me not as much as a competitor, but as an ally to promote the use of PDF.
Are we still disruptive today? Yes, but on a different level. If we compare how much iText is used in the business with the number of sales we have. We still see a large gap. For instance: we know for a fact that a dinosaur such as RealDolmen is using iText in quite some projects. However, RealDolmen nor RealDolmen’s customers where iText is used, are on our customer list. This is probably in violation with the open source license. We have contacted RealDolmen about this, but only after resending the same mail three times, we received a mail saying: we aren’t interested in talking with you.
There are two different ways to approach this. There’s a negative approach and there’s a positive approach.
The negative approach would be to put some lawyers on the specific cases we know. We see this as a last resort. Turning a user into a customer by dragging him to court is not a sustainable approach, is it?
The positive approach is to completely ignore the dinosaurs and to partner with their big competitors, such as CSC, and small competitors, such as Roots Software. The idea is to create an eco-system where we create business for our partners, and in return our partners generate revenue for us by reselling our technology. To the dinosaurs who remain deaf to this approach, we say: “comply or die!”
I have recently written a new book that is available for free on condition that you share some information, such as your mail address and the country you live in. If we receive a mail address from Japan, then we forward this address to a partner in Japan. This partner then writes a friendly, inviting mail in Japanese, explaining the added value of becoming an iText customer.
It is not our ambition to compete with a Japanese Software Integrator or a Japanese Value Added Reseller. We don’t have the bandwidth to do that. We don’t know the language; we don’t know the culture. So we share business opportunities with a Japanese partner. By sharing, we also benefit, because this partner generates deals that we would otherwise have missed. This is our disruptive approach and it works: already the revenue generated in Japan exceeds the revenue we generate in a neighboring country such as the Netherlands.
This is what made us win the BelCham Entrepreneurship Award “Most Promising Company of the Year 2014” and that is also how we were acknowledged by Deloitte as the winner of the Technology Fast 50: between 2009 and 2014, iText Group was the fastest growing technology company in Belgium. We ranked 28th in the EMEA region.

When I was 18, I read the book “Walden; or, Life in the Woods” by Henry David Thoreau, a book first published in 1854. I kept a diary at that time in which I copied the following advice: “If you have built castles in the air, your work need not be lost; that is where they should be. Now put the foundations under them.”
I didn’t want to make this talk a “7 mistakes that can kill a start-up” sermon, nor a “10 rules to be successful” lecture. I wanted to share my very personal story, with its ups and its downs. Be aware that the lessons I learned, aren’t necessarily the lessons you need to learn. Except maybe one: don’t allow frustrations to get the better of you. Keep working on those foundations and one day you’ll reach your castle in the air.

Four failures and one hit

Bruno Lowagie

Four failures and one hit