Today, we're launching a free and open-source offering. But I'll be honest with you: Briefer is a VC-backed company, and it must make money.

It's ironic to me that many for-profit companies can't say that out loud. Maybe it's because they're afraid that money will get in the way of making users happy. Or maybe they know it won't, but they're afraid of people thinking it will.

We don't think that way.

We think that doing right by your users is the best way to make money, and making money is the best way to do right by your users. That's because money allows you to invest in improving your product and offer a better service to more people, some of whom will use it for free, and that's fine.

Being clear about our strategy and intentions is part of doing right by our users and it's why I'm writing this post.

In it, I'll explain how companies can structure their open-source offerings, and how we structured ours in a way that's good for users and good for business. I'll also explain why we chose the AGPL license, how it benefits users, and how it benefits us too. Finally, I'll also explain some of the things we won't do, including changing our license.

Structuring an open-source offering

When companies open-source their software it means they can't really charge for the software itself¹. Thus, if you must make money, you need to sell something else, which is usually:

1. Support and professional services
2. Compute and infrastructure
3. A non-open-source version of the software

In the first case, companies scale as a function of how many support and consulting staff they can hire. It's a solid model but it doesn’t scale because hiring people is costly.

As a result, this approach often falls short of investors' expectations for significant returns, which makes it hard to raise funding and thus prevents most founders from being able to go full-time on their project. Consequently, it becomes difficult to build enough traction to generate leads for the professional services they would like to sell, especially considering there's no marketing budget.

The second case, selling compute and infrastructure, usually comes in the form of a cloud-hosted version of the software. This model works well for companies building complex and mission-critical software, like databases and managed Kubernetes clusters. That's because it's a bet that the company can provide a cheaper, more convenient, and more reliable service than customers could provide themselves.

The problem with this model is that it incentivizes companies to make it hard for customers to run the software on their own. This dysfunctional pattern manifests itself in many ways, like when companies insist on overly complex helm charts (ugh), withhold documentation on how to run the software, or require customers to operate a dozen pods when one would work just as well.

The third case, selling a non-open-source version of the software, is fair in the sense that companies will still give value away while carving out a subset of features upon which they can charge. That way, they can still make money to maintain and improve the open-source version, while profiting from the extra features in the non-open-source version.

The problem with this last model is that it creates a conflict of interest between the company and its customers. Customers want the open-source version to have more features, while the company wants the open-source version to have fewer features so that customers will pay for the non-open-source version.

Our model

Briefer's approach is a mix of the second and third models. We will sell a freemium cloud-hosted version of our software and maintain a generous AGPL-licensed version with fewer features.

Some people call our strategy "open-core" and that's technically right. Still, I'd rather say that we have two pieces of software: one that is open-source and another that is not. I think that's more direct because we're not trying to hide the fact that we're selling a non-open-source version of our software. Anyway, open-core is fine too, and there's nothing wrong with it.

We chose to do it this way because we want everyone to use Briefer. Therefore, choosing a service-based model would not be viable because it limits our access to funding, which is necessary to scale Briefer and pay our bills as we build it.

We then considered picking the second model, selling compute and infrastructure, but I was afraid it would corner us into having to eventually change licenses.

Another reason why we rejected that model is because we refused to compromise the software's quality just to profit from users' struggles to run and operate it. Making it ugly, inefficient, and poorly documented was not an option. That would completely defeat the purpose of having an open-source offering, and, as an engineer, it would cause me physical pain.

That's when we decided to mix the second and third models.

This choice allows us to have a small subset of features for which we can charge so we don't have to worry about how easy it is to run Briefer.

That way, there will be an incentive to make the open-source version as easy as possible to run because that helps us increase our user base, thus increasing the number of people who might eventually pay for the cloud-hosted version.

This incentive to increase the user base (our top-of-funnel) also means we can't simply reserve the best features for the non-open-source version. Instead, we have to find a balance between an open-source version that's competitive and attractive enough for people to use it and a cloud-hosted version that's valuable enough for people to pay for it.

In our case, we decided to charge only for the features that larger companies usually need (>100 employees) or those necessary to directly make money from Briefer, like embedding charts into your own application.

We thought that was a fair heuristic because companies with more than 100 employees usually have more resources to pay for software, and they usually get more value from it, so it makes sense to take a small cut.

Conversely, small companies are usually strapped for cash, and it wouldn't make sense to charge them pennies. We'd rather help them now and have them eventually pay for the cloud-hosted version when they're thriving and getting more value out of our software. That way, we can help them grow and make enough money to maintain, improve, and distribute both the free and paid versions of Briefer. That's a win-win.

Why we chose the AGPL license

We licensed Briefer's open-source version under AGPL for three reasons.

The first is that it's a well-known license, so most people will be fully aware of what they can and can't do with our software.

The second is that it's a great way to ensure that the open-source software will remain open-source forever.

The third is that the AGPL still allows users to implement any features they need, but disincentivizes competitors from copying our software and selling it as their own.

If they were to do that, they would have to open-source all their changes and commoditize their work, so it's not worth it for the vast majority of companies.

Here's where the difference between AGPL and GPL comes into play. We chose AGPL because it closes the "network loophole" that exists with the GPL. Under GPL, it was possible to modify the software and use it over a network without releasing the changes. But with AGPL, if competitors modify our software and offer it as a service over a network—like a cloud application—they must make those changes public under the same AGPL license.

We never considered using a license that's not in the OSI-approved list because those are, obviously, not open-source. Additionally, we have already made a compromise in not open-sourcing the whole codebase, so I thought it would be fair to pick the "freest" license of them all.

Our open-source strategy

The main reason we created an open-source offering is that it's the best way to align our user's interests with the company's financial interests.

On one side, more people can use Briefer because it's free and open-source. These people can implement the features they need, and distribute them to others.

On the other side, it's a competitive advantage for us because it increases our top of funnel, helps us improve our activation rates, and gives us a competitive edge against incumbents.

Here's each of these points in more detail.

Taking on incumbents

Briefer's main competitors are Salesforce's Tableau and Microsoft's Power BI. At this point, these companies aren't just companies anymore. They're institutions. They have a lot of money, a lot of engineers, and they're not going to go away anytime soon.

On the other hand, Briefer is a small company that's doing well, but that's just starting. We don't have the same brand recognition, the same number of customers, or the same amount of money. That's why people ask us questions like: "How do I know you'll be around tomorrow?" and "How are you different?"

Open source is a great way to answer these questions.

That's because open-source software outlives companies. If Briefer disappears tomorrow, people can still use the software, implement the features they need, and distribute them to others. That's a great way to assure everyone that using our software is a safe bet too.

Open-source software is also a great differentiator because it helps us build a strong community. These people can contribute features, fix bugs, and report issues, which makes our software better, faster, and more reliable.

Finally, by going open-source we commoditize our competitors' core functionality. This means they now have to compete against us in terms of innovative features, performance, and price, all of which are usually not their strong suits, let's be honest.

Helping more people while increasing our top-of-funnel

Making our software open-source means more people can use it because they won't have to "hop on a quick call" or swipe their credit card to get started.

Instead, people can just clone the repository and run a single command to get started.

That's great for people because they can use Briefer for free to study, work on their personal projects, or grow their business. It's also great for us because the lower barrier to entry increases our top-of-funnel.

Then, if they like our software, we win, regardless of whether they pay for the cloud-hosted version. That's because non-paying users who like our software will certainly tell their friends about it, and some of them will eventually pay for the cloud-hosted version.

As I mentioned earlier, this incentive to increase the user base also means we can't simply reserve the best features for the non-open-source version. Otherwise, we'd be shooting ourselves in the foot because no one would use it.

Furthermore, if we're successful, it's likely that more companies will create competing open-source offerings. That will push us to open-source more features so that we can stay competitive, which is better for all users, even the ones not using our software.

Improving activation rates

Most people out there don't go around pasting their database credentials into every SaaS product they find. Sometimes they don't trust a company they've never heard of, sometimes they can't punch a hole in their firewall, and sometimes they simply don't want to go through the hassle of getting management's approval.

This behavior makes it more difficult for people to see value in Briefer because they won't have real data from which they can derive valuable insights. As a result, they will churn.

We tried to solve this problem in many ways, including:

1. Creating demo datasets that people can use to get started
2. Supporting file uploads so people can upload their data without having to connect to a database
3. Devising a thorough document detailing all our security practices in an attempt to make people trust us

None of that worked well. All of these initiatives were helpful, but none truly solved the problem.

Looking back, we're now confident that the only effective solution is to make our software open-source. That way, people can run it locally, with their own data, without having to connect to the internet, and behind a VPN if necessary.

This change will increase activation rates, which will then lead to higher retention rates, which leads to more feedback, which leads to a better product, which leads to more users and more conversions.

Crowdsourcing innovation

It's difficult to figure out what people want, and it's even more difficult to figure out how to prioritize everything they want.

Open-source helps us manage Briefer's roadmap along with our users because there will be more of them, and because they'll have access to the source code. That way, they can help us figure out where to go, and help us get there by implementing what they need.

It makes us happier

The first time I worked with my co-founder was when we were maintaining an open-source project called Chai.js. It was the most fun I've ever had working on a project, and I want every day at Briefer to feel like that.

That may sound like a selfish reason, but it's not.

Building a company takes many years, and the only way to keep going is to have fun along the way. That's because building a company is hard, and it's easy to give up when things get tough, but not when you're having fun.

When you're having fun you don't mind the late-night coding sessions, all the "no's" you get from investors, or the bugs that keep popping up. You just keep going because you're having fun, and time will pass anyway, so you might as well spend it wisely and build something meaningful.

Things we won't do

Finally, I want to make sure I address some things we will not do.

The first is to change our license.

One of the main reasons why Briefer has two separate pieces of software is so that we'll always have a significant number of money-making levers to pull in the non-open-source version.

I think having separate licenses is a better compromise than risking our users' trust by changing the license of the open-source version in exchange for short-term profits.

The second thing we won't do is to stop maintaining the open-source version.

Open-source is a core-part of our strategy. It's the right thing to do for our users, and, consequently, it's the right thing to do for us because it makes people happy, and because it helps Briefer succeed in all the ways I mentioned earlier.

The third and final thing we won't do is to stop being transparent.

I want to build Briefer as a company that people can trust, and that means being transparent about our intentions, our strategy, and our roadmap. That's the right thing to do for our users and, honestly, it's good for business. Therefore, it is the right thing for us too.

If you have questions, email me at lucas.costa[at]briefer.cloud and I'll be happy to answer them personally.

Best,
LdC.

Footnotes

[1] You can charge for people for copy of GPL-licensed software if they're getting it from you. So, technically, you could make money selling software itself. The reason that wouldn't work in practice is that others could then redistribute the software for free. Therefore, it would be nearly impossible to compete with them.