What to consider when transitioning your open source business to a revenue-based model

Can SQL as a language be integrated and standardised into Java through a set of simple formal language transformation rules? Yes it can.

Data Geekery saw the idea gain some traction when the Zurich, Switzerland-based open source company kicked off a new database abstraction software project called jOOQ. As founder and CEO, I in the beginning, I felt that jOOQ was meant to be a proof-of-concept for a greater vision. We licensed it under the terms of the Apache Software License 2.0, and thanks to this liberal license, the idea got some traction. jOOQ grew to be a niche product for hardcore Java/SQL users, with 25,000 yearly downloads by 2013.

This success meant that customers were relying on a central piece of software for which they then needed support. Quality assurance. Warranties. SQL is at the core of all of jOOQ's customers' end user applications. So, to be able to continue growing jOOQ, we needed to start up a business.

We had to ask ourselves:

• Will we continue to ship jOOQ as free and open source?
• Will we need to close the source code and switch to commercial software?
• Can we keep the source code available but under a commercial license? Is that legal?
• Will our existing customers embrace or reject such a substantial change?

It's true that many companies make the transition from closed source to open source. From commercial to free. For those companies' customers, that change a no-brainer and obviously not going to be a problem that now they will be getting the product for free that they paid for before. We, on the other hand, were considering asking for money from our customers for a product they had gotten for free before.

In the end, we chose dual-licensing. Here's why.

First and foremost, we simply believe that our niche product has matured beyond the point where we can actively offer it for free and maintain quality and growth.

We considered a support-only based revenue model, but in our opinion, support-based revenue models work best for all products that induce "devops efforts." Servers, operating systems, databases. Everything that can crash for hundreds of reasons. And when it crashes, it needs expert personnel to mend it.

Our software is middleware. It's easy to understand, it doesn't go far beyond modeling the SQL language. Complexity lies "below" our product (in the database), or "above" our product (in the Java application). Our product adds the most value at development time by offering our customers' developers type safety when writing SQL, reducing error-proneness and increasing productivity. Much like Eclipse, Netbeans, and IntelliJ (the latter is commercially licensed).

From our perspective, a commercial license would allow us to make a profit from the business, but we were conflicted because open source had allowed us to:

• grow faster: we owe a lot to our passionate early adopters, who helped us produce an excellent product and get where we are today
• display more: by making our source code available, we can show everyone the quality of our product
• work better: proprietary software companies have to pay for services like GitHub, Maven, etc.

We talked to many of our customers, friends, and competitors about what it was like for them when they chose dual-licensing for their software. We also kept in mind what happened with Sencha's ExtJS. Conversations centered around some of our considerations, like the popular AGPL and the LGPL licenses. Many of our customers argued that we should invest in new enterprise features that would only be available to commercial licensees, but jOOQ was already mature and it would take months, if not years, before we would have any revenue based on a "basic version" and an "enterprise version." Other customers suggested that we build more development tools, like editors, IDE integration, and profilers. Though we agreed we wanted to build that eventually, we felt that now the product was ready for a change now, not later.

Our solution ended up being very simple. We simply removed DB2/Oracle/SQLServer/Sybase-specific code from the open source edition's deliverable. Customers using our product with open source databases have access to it under the open source ASL 2.0 license mentioned above. Customers using our product with commercial databases have access to it under a commercial license.

The advantages are:

1. No copyleft involved. We liked the ASL 2.0 and our customers liked it. We didn't need to introduce any legal disruption.
2. Previous contributors signed license agreements. We purchased all commercial code and didn't risk due-diligence cases, as around 97% of the code-base would not change licensing.
3. Most of our customers understood and pragmatically supported our plan to continue supporting them! Tying our license costs to the underlying database's license costs was considered by many to be honest and true to this open source business model.

We saw success. The transition to dual-licensing worked. But, 2013 was still a tough year for us. There was a lot we wished we had known from the beginning, so next I'll share the lessons jOOQ learned that anyone thinking of transitioning their open source business to a revenue-based model should know.