Bootstrapping a Business Around Open Source

by Hongli Lai

See also the OSCON 2015 Amsterdam keynote recording.

OSCON 2015 Europe took place in Amsterdam on October 26th to 28th. OSCON is an event that celebrates, defines, and demonstrates the best that open source has to offer. We were honored to have been invited there to give a keynote about bootstrapping a business around open source (abstract).

This article is the transcript of that talk and dives a bit deeper into a few subjects that we were not able to touch upon during our keynote due to time constraints.

If you have ever entertained the idea of building a business around your open source project, then this article is for you. From business models to marketing, we will share our experiences in setting up a company like Phusion. Just keep in mind, there is no silver bullet, so your mileage may vary!

What you can expect from this article

In this article, we will cover:

  • Motivation behind starting an open source-based business
  • Business models, or how to make money if your core product is free
  • Caveats behind some of the business models
  • The importance of marketing
  • Case studies of open source businesses

This article is not about trying to discourage you from taking VC money, or trying to convince you that bootstrapping is the best way to run a business. Bootstrapping was the path we took, but may not be the right path for you.

If you are ready, let's move on!


A tale of two young computer science students

We are Phusion, a software company specialized in making Unix server software for mere mortals. We are based in the Netherlands and are probably best known for Passenger, our open source application server for Ruby, Python and Node.js applications.

Phusion was founded by my co-founder, Ninh Bui, and myself, Hongli Lai, while we were still studying computer science at our university. We did not know what we would do after graduation, but it was clear we didn't want to follow the beaten path of a 9-5 job, mortgage, job security, etc. So we decided to rebel against our high-expectation Asian fathers by suspending our study and starting a software company.

Intrinsic motivation

First off, ask yourself why you want to do a startup. Especially an open source startup where your main product is basically free! A common answer to the first part is being your own boss, but it usually gets a bit more quiet at the second part. This was our answer too, but we also wanted to do something that would positively impact the lives of many others.

If your answer is to be rich, then you may want to reconsider. While some companies such as Red Hat are very successful, they are rare. It is possible to make a good living via open source, but if your goal is to get rich quickly then you may want to reconsider.

So intrinsic motivation is key here. In our case, our desire for freedom and our desire to impact the world was greater than our financial motivation. You should write down your reasons on a post-it note so that you can reflect on them when things don't go the way you want them to. Because starting a business is full of ups and downs, whether open source or not.

Early business models

If you started out like us, then you probably do not have a lot of starting capital. We started with two laptops and about $500 in the bank. So we had to find a way to fund ourselves without requiring large up-front investments. There were two business models that we tried in the early days: consulting/outsourced development and support contracts.

Consulting and outsourced development

We initially planned for Phusion to be a consultancy firm that would also take on outsourced development jobs, while using Passenger as a marketing tool. Passenger's popularity would serve to give us credibility: people would use Passenger, see that we are competent, and feel comfortable with contacting us for projects. The funds we obtained from this would be invested again into Passenger development, maintenance and marketing.

This worked quite well in the beginning. All we needed was a website and reach out to prospectives. We were fortunate enough actually that most customers came to us for consultancy gigs via Passenger. We were able to make a decent income from these projects. Unfortunately, this model had several drawbacks in the long run:

  • Revenue was unstable and unpredictable. We had to constantly hunt for new projects.
  • It took a lot of time. We had to actively spend effort into making money.
  • It was a roller coaster. We had to fit ourselves into clients' deadlines, which were often very tight. Clients would also often change their minds about requirements during the middle of projects. We were passionate about customer satisfaction so we were always able to deliver satisfactory results in spite of changing requirements, but it took a large toll on us.
  • We spent so much time on consultancy that we had less and less time for Passenger development and marketing.

This last point is important. As Passenger's popularity grew, so too did the need for support and maintenance. We provided this to the community for free because support and maintenance was funded from consultancy. But maintaining Passenger ate away at our billable consultancy hours, while consultancy ate away from Passenger maintenance and innovation.

At the same time, our success as a business depended on Passenger's success. But we had to constantly divide our attention between working on Passenger and client work. This created a lot of mental context switching overhead.

The effect of context switching is documented in this table by Gerald Weinberg. As you can see from this table, people suck at multitasking! This only becomes worse as more tasks are involved. You can easily lose 50% of your time switching between projects and talking to your clients.

As a business, it is important that you stay ahead of your competition. It was important for us that Passenger stayed ahead of its competition. That requires focus and commitment. Context switching prohibits this, so be careful of doing consultancy as a way to fund your startup. Doing too much consultancy will put you at the risk of turning your business into a consultancy, and destroying your startup in the process.

Support contracts

The standard answer that people give about making money off open source is "support contracts". Red Hat is very successful with this model, but we found out that it wasn't quite as easy as people make it out to be. It depends a lot on the nature of your software.

Unlike our competitors, Passenger was built on these philosophies:

  • Ease of use and simplicity. If a task can be done by Passenger without having to bother the user about it, then Passenger will do that. Competing solutions required that the user perform a lot of configuration and scripting.
  • Self-supervision and self-healing. Passenger monitors its own health and fixes itself when possible. This is achieved with an out-of-process architecture, so that subsystems in Passenger can be restarted when they crash.
  • Disciplined testing. We wrote extensive test suits and tested Passenger extensively before releasing.

These philosophies meant that Passenger was "too good". It didn't cause many problems, so very few people needed support. Many users tell us that most of their problems are caused by everything except Passenger.

Our early adopters also mostly consisted of highly skilled hacker type of people. From our experience, many of them are willing to invest a lot of time and effort into figuring out solutions to technicals problems on their own, which is why they may be less willing to spend money on solutions created by third parties. The few parties who did need and want support were not looking for support contracts because they only looked for short-term engagements: they just wanted a few consultancy hours to fix a specific problem. Needless to say, that was not sustainable for us.

During our early days, we struggled a lot with selling support contracts.

Only in more recent years have we been successful at selling support contracts. It required a different approach. We realized that a support contract should be thought of like an insurance rather than a consultancy subscription. Customers looking for a contract aren't paying for fixes, they are paying for security and guarantees. So the customers we need to target are traditional and non-IT-centric organizations like banks, insurance companies, governments, etc. These types of customers did not appear until after many years because they are distinct from early adopters. And to sell to these types of customers, a dedicated sales person is required because they often have long procurement processes.

These types of customers also require a different type of support, namely that of guaranteed, 24x7 available support. They want to have the peace of mind of being able to call us if their servers catch fire during the middle of the night. This requires us to think about rotating on-call duties, routable phone numbers, etc.

So selling support contracts works, but it requires a large up-front investment and a long lead time.

Don't rely on donations

We also relied on donations early on. We received a lot of donations in the first few weeks. However, the amount of donations gradually tapered off and were mostly one-time only, even though we incurred ongoing maintenance costs and even though we kept releasing new features. There were very few recurring donations. Although we are grateful to all the people who have donated, the amount of money we received from donations was unable to sustain us. To give you an idea of the amounts, we would have probably been better off flipping burgers.

Don't rely on donations.

The lesson we learned from this is that we should not rely on donations as a stable source of income. Selling a premium version without offering extra features also does not work, because that is the same as a donation. People will not have enough incentive to pay you, and to keep paying you, even if they are grateful. This is just how things work psychologically.

So instead of asking for donations, make a good business proposition where customers know what they get for the money they pay. That brings us to our later business models.

Later business models

We thought hard about the limited success of our early business models. We came to the conclusion that we should aim for passive income. A way to generate income more efficiently. Something that scales better, business-wise. Something without big up-front investments. That means some kind of subscription, something that generates recurring revenue.

Selling premium features, subscription licenses

One way of generating recurring revenue, and without interfering with Passenger development like consultancy did, was by selling Passenger licenses directly. Passenger itself was open source, and we wanted to stay true to our open source roots, so we did not close off Passenger. Instead, we decided to build premium features for which we charged money. This is also called the freemium or open core model.

We monetized on Passenger directly by selling a version with premium features.

Thus, Passenger Enterprise was born. Passenger Enterprise is licensed on a monthly or yearly basis. In return, customers receive a steady supply of updates -- bug fixes and feature improvements. This gave us the recurring revenue we needed, without suffering from so much context switching overhead as was the case with consultancy.

The features we built were important features that many businesses have requested for a while, but that have always been put on the back-burner because of consultancy, such as rolling restarts, multithreading, etc. Thanks to direct funds, we were finally able to build them.

We were initially very nervous about the community potentially making this decision backfire on us. But the community turned out to be quite supportive. While not everybody agreed, by and large the community understood the need for something like this.

Mike Perham monitized his open source Sidekiq project by selling a Pro version. Sidekiq is now his full-time business.

This strategy has worked out for some others too. Mike Perham, author of Sidekiq (the Ruby worker queue system) sells a Pro version. This eventually became a full-time business, allowing him to blast past his free competitors, who had less funding and thus less development power. Mike even started a company and built more open source products around this freemium/open core model.

"Like Phusion, I've found the open core business model allows me to focus on building the best products possible. My interests and the customer's interests are well aligned: the customer gets copious documentation, a quality implementation and can participate in the development process on GitHub."

— Mike Perham

Selling paid services

Another way to make money off your open source product, and one which has become very popular the past few years, is by building paid services around the product. When your product has enough popularity, people will need services like hosting, monitoring, analytics, etc.

We also make money with Union Station, our analytics, monitoring and performance analysis platform for Passenger.

One example of this is Union Station. While Passenger itself is very stable, we noticed that our users have a difficult time with troubleshooting problems caused by their application codebase. So we built Union Station to assist them with, for example, solving production performance problems.

Don't be afraid of charging people money

If you are a technical person like we are, then you may feel a little ashamed of charging money. So much open source software is free, so asking for money may feel a bit "evil".

We learned that this is an important mindset to grow out of. Money is good for you. How often have we seen a popular open source project becoming abandoned because the author no longer has time and resources to maintain it? Money is what ensures that there is a future for both you and your project: with funding, you can keep maintaining your project. More importantly: if you make good products, then you deserve to get paid.

Some people in the community may not understand this initially, so it is important that you explain this to them. Good communication with the community is key.

The importance of marketing

Most of the time, your product's popularity will not take care of itself. That means that just being technically good doesn't guarantee you a lot of users. It is important that people know your product and know why it is good and useful to them.

Most people don't have time to research every possible solution out there in order to pick the best one. Even if they would, many decisions are based on emotion rather than pure ratio. That means you have to make an effort to get onto people's radars. You have to market your product.

Some people view marketing as a dirty word, associating it with shoving unwanted things down someone else's throat. But good marketing is all about connecting your product with people who are looking for the value that your product offers.

Word of mouth

It is said that the best way of marketing is through word of mouth.
So how do we take advantage of this? Open source is actually perfect for this if you think about it. With open source, a developer starts off scratching their your own itch. If they are happy with the result, they share it with others. If others are excited as well, this process will repeat, allowing the product to market itself organically from then on out.

Someone has to bootstrap this of course. Upon releasing your product, you should tell as many people about your product as possible. Relevant friends, acquaintances, project mailing lists, forums, websites, social media... whatever you can think of.

If word of mouth does not spread very far, then at least you have still scratched your own itch. So you can't really lose with open source. :-)

The art of repetition

Marketing is said to be the art of repetition. That means: don't just focus on improving your software. You should actively tell others about these improvements as well! Neglecting to do so may cost you a significant amount of mindshare. We learned this the hard way...

A few years ago, when Passenger had matured, other (open source) competitors surfaced. Passenger was no longer considered the shiny new toy by our community. Because Passenger was simple to use and required little maintenance, it was at risk of being considered technically simple by the hacker community, which slowed down word of mouth. This could not be further from the truth, because there was actually a lot of cool Unix technology going on under the hood.

Don't just focus on improving your software. Actively tell others about your improvements as well.

The problem was that we spent more time building this technology than marketing it. In contrast, competing products were not as simple to use and exposed more of the underlying technology, so they got more word of mouth through hackers who were excited about the technological aspects. Our assumption that people would be more interested in ease of use than in technology was wrong -- at least for our user base.

Case study: Raptor

We decided to set the record straight by highlighting the cool technology going on under the hood in Passenger, while releasing a lot of new cool features too.

At the time, we found that a lot of people were not even listening to our news anymore because they had the preconception that Passenger was old news. So we published our technology highlights in the form of a blog series and called it Raptor to rid people from any bias from Passenger.

Raptor, the brand name we used during a Passenger revitalization campaign.

The campaign and blog series was huge success on Twitter, Hacker News, user groups, etc. People were excited and some even compared it to Passenger. Then on launch date, we revealed that it was Passenger 5 all along.

Some thought it was genius. Some thought it was in poor taste. Regardless, we went from 350.000 to 450.000 active installs during that period. Will we do something like that again? No (also because it would not work anymore), but we do not regret it either. The campaign was much needed to renew people's interest in our product based on actual merit, not based on old biases.

Conclusion

Please let us know what you think by tweeting about us.

We hope that we have been able to make you excited about doing your own startup around an open source project. We firmly believe that monetizing open source is the best way to guarantee its future development.

To learn more about Passenger and how it can help make deploying and administering your web apps easier, see the Passenger website.

Thank you for reading, and let us know what you think by posting a comment.

With kind regards,
Hongli Lai, co-founder and CTO at Phusion
Ninh Bui, co-founder and CEO at Phusion