The open source YC experience

How it all started

VPNs were painful at every company I’ve worked in.

Slow VPN speeds are an eroding pain. One that makes every task 10% slower. Like loading my Kibana dashboard, and having to wait an extra few seconds, so I check my email or my phone. A 2-second wait that triggers a few minutes of lost productivity. A hiccup of 1 minute at the start of every Zoom call that throws off all the prep I had coming into it. “How does my mic sound?”.

Big pains come from blockers, like slowing the onboarding of a new contractor because internal resources were not segmented for least privilege. The contractor needs to spin up a web server, but access to our data center would mean access to customer data and other production servers.

Existential pains come from being breached (like at my previous company).

When I met my co-founder Jamil last summer, he showed me a solution to these problems. A new faster VPN protocol called WireGuard (read more about that here) and a modern UX built for end users. One that’s easy to self-serve for IT admins, SREs, and DevOps engineers.

The latter may seem like a silly differentiator, but it isn’t. In the past, software was sold top-down to large companies. The buyer was often not the user, so products with a laundry list of features won. They checked all the boxes.

In fact, for many of Firezone’s users, a VPN was a checkbox. A feature that came with their legacy firewall that’s cumbersome to deploy and configure.

This wasn’t apparent to us initially, but after we posted our project to HN, we quickly realized technical IT staff needed a product like Firezone.

Why open-source?

Firezone is core IT infrastructure. It deals with network security and cryptography and runs in sensitive environments - on your employee’s laptops and behind firewalls on your servers. Private data about your company and customers flow through our gateways and apps. And with remote work, almost every employee relies on it to get work done.

We don’t expect many organizations to run such critical software without knowing what’s in it.

We also don’t expect all organizations to leave control of their network to a third party. One that can experience outages, be targeted by hackers or has access to your sensitive data.

So, make our code available to users and make it simple to self-host on our user’s infrastructure.

Why Y Combinator?

After our ShowHN, a long list of feature requests appeared in our GitHub repo. A list we couldn’t close alone. At least not within a reasonable amount of time.

For a new product with no revenue (yet), VC funding fit. It would allow us to create something for the community and investigate the right model to build a sustainable business.

As first-time founders, YC is also a good fit. After all, they helped companies like GitLab and Mattermost get off the ground.

A brief summary of YC, for a stake in your company, YC offers three things: capital, advice, and community.

When we accepted the invitation, YC invested $125k for 7% of our company. We were offered an additional $375k as an uncapped MFN safe a few weeks into the batch. Lucky us! You can read more about it here.

The advice comes in the form of interactive workshops and long-form posts. They are invaluable resources and often come with snappy titles like “how not to fail”.

Community is YC’s magic. Thousands of past founders can make introductions to investors, give advice, and even become users of your product.

What we learned during YC

During YC’s three-month boot camp, your goal is simple. Make meaningful progress.

In our batch, we met a company that made powdered breast milk. Multiple hospital networks as customers and $150k+ of MRR. Their problems were scaling production and FDA approval.

Firezone, our company, had launched a few weeks prior on HN. We had a small handful of users, daunting technical challenges, and little idea of how we could generate revenue.

YC’s challenge is to give advice that helps these two companies and everything in between.

Open-source security is a relatively new category for YC investments. About half of the 240 open-source YC investments made by YC since S05 (17 years ago) were made in the past two years. Only 7 are security companies.

So, we came up with our interpretation of advice meant for traditional enterprise Saas or B2B freemium software companies. Here are a few topics we worked through.

Should I collect telemetry?

Yes. If you’re a VC backed-startup, you probably should.

Even with a crystal ball on what users want, metrics can still help identify reliability issues and add insight to reported bugs.

From a business point of view, they tell you who and how many people like your product and which features are getting used.

It’s a great way to focus the team on what matters.

Best of all, when the data points start lining up like a hockey stick, it can get you the funding you need to build a great product.

YC’s advice is to set a primary metric that captures your value to users. This primary metric should be paired with secondary metrics that drive the primary metric. Ones you can actionably move and iterate on.

In case you’re curious, we’ve set users in production as our primary metric. Our secondary metrics help add context to the growth.

For example, here are three different graphs of our progress near demo day. Our star count, number of live instances, and number of devices. Each graph tells a slightly different story. Star count shows growing awareness in the open-source community. Instances show steady growth in actual adoption. The number of users tells us more about the deployments of Firezone. Since it outpaced the growth of instances, we knew larger teams were adopting Firezone over time, and existing deployments were growing inside organizations.

Ok, so how do I collect it?

How do you measure usage? It’s more complex than you think for an open-source project.

For most software products, telemetry is a small script in the header of your website and an annoying cookie banner for users. Sometimes it’s also a few lines of code sprinkled through the backend. Most users expect to be tracked by the hosted services they use. They may not like it, but they usually won’t fuss about it.

Open-source is different.

Not everyone expects a self-hosted open-source project to report their usage. We had to be careful about what we tracked, how we anonymized it, and how we communicated it to users.

We spoke to a few other open-source companies we respected. Here’s the advice we received.

• Explain why you do it: Document what you track, how it’s stored, and what you use it for. We took heavy inspiration from companies like Mattermost and made our own page in our documentation.
• Make it clear and easy to opt out: To make it simple for users, we created a deployment script that streamlines the install process. In the script, we explicitly ask for permission and make it easy to switch off later directly in the UI.
• Don’t unnecessarily expose user data to third parties: Those annoying cookie banners on websites you visit generally mean one thing. You’re being tracked, and your information is being sent to third-party tools like CRMs and ad platforms. If you’ve signed up for an account and checked the box for terms and conditions, you agree to that as well. With Firezone, we use open-source and self-hosted products whenever possible. This includes our telemetry platform as well.

So, now we know about users in aggregate.

But our product is early, and legacy VPNs are painful in many ways. We need more information to prioritize what to build first. The best way to do that is by talking to users.

We don’t know who our users are

“Write code and talk to users” is consistently echoed during YC.

A great summary of why is in “do things that don’t scale”. I recommend reading the article, but it boils down to this:

You often build the initial product for yourself. The MVP is usually not good enough - it’s never quite right. You should get it in front of users as soon as it provides utility so you can get feedback to iterate and improve.

Again, for an open-source project, it’s challenging.

Firezone’s users are technical. Usually, they’re a system admin, IT manager, or DevOps engineer. They’re fully capable of setting up Firezone and reading our docs to figure out what the product can do.

Firezone does not require a valid email to sign up. It’s hosted entirely on your infrastructure. It would be weird to lock anything behind a signup.

The only place we see our user’s email is in our discussion forums and GitHub issues - generally, a distasteful place to ask for a user interview.

So, to generate more conversations, we increased the surface area of how users can reach us. Note, it’s important who you’re getting feedback from as well.

Often for developer-facing products, the person that’s deploying the product is not the person who decides what to use, what the budget is, or even the only one benefiting from it.

Firezone ties into security playbooks, compliance requirements, hiring plans for contractors, and risk planning from risk departments.

Here’s how we reach our users:

Why dig deeper?

Most founders don’t need convincing, but a small example may help. It involves a request to “load a custom logo” for our login UI.

We initially thought this was companies that simply wanted to show their logo. But, when we got on the Zoom call, we would uncover a group of re-sellers who wanted to white-label our product with their clients. It turns out they have other requirements they’d be happy to pay for if we had them.

These conversations helped make the product better and form our view on our business model.

This leads to the final piece of advice from YC, pricing.

Paying user feedback > free users

Figuring out your pricing model and generating meaningful revenue is the great filter between early MVPs and successful companies.

A key question during YC is when.

With limited resources, generating revenue is almost always a tradeoff. Less growth, slower development of features, and the potential to ruin a perfectly good story for investors. Queue Silicon Valley:

So, when to figure out revenue?

For B2B software, the answer should probably be “right now.”

Steering early user conversations toward pricing tells you if the product is viable and solves a big enough pain. YC echoes this advice.

Kite, a startup I led growth at previously, failed partly because we punted the question of “will people pay?” too many times. Kite built an AI-powered Copilot, an early iteration of GitHub Copilot.

When we finally tried charging users, it was clear the product needed to evolve to generate meaningful revenue. By the time we realized that it was too late. Adam, the founder of Kite and an investor in Firezone, recently open-sourced the codebase and wrote a great post-mortem.

For self-hosted open-source software like Firezone, the answer is not as clear.

Since we’re self-hosted, layering feature gating logic into the core product is problematic. Feature flags are complex to write and even harder to maintain as our product evolves.

Being critical infrastructure for remote work, we also don’t want your company to come to a halt when your credit card expires. There’s more to say here, but I’ll leave this to a future technical deep-dive from my co-founder, Jamil.

So, similar to other successful open-source projects, our early goal was to grow the community. Similarly, there’s more to this decision, but I’ll leave it to a future post.

During YC, we focused on building out the core parts of our platform, driving adoption, and optimizing for learning from our users.

One of the things we prioritized learning was how to build a business around Firezone. Our largest deployments all started with an individual spinning Firezone up without ever speaking to us. As usage grew, a pattern emerged.

Users from larger companies reached out. These users had requests about features and services that almost always fell into support, compliance, or management features.

We’re still early, but these features seem like a great way to monetize. As we continue to develop our pricing model, we want to ensure the following:

• Individuals and hobbyists can use Firezone for free
• Small teams can use Firezone for free (if they support it themselves)
• Large organizations can run a PoC without any calls with sales

If this sounds familiar, it’s similar to how GitLab thinks about their pricing. We’re big fans.

What’s next?

I’m not sure how to end this post, so I’ll paste links to resources I found useful. We’re still early on this journey, so take everything said here with a grain of salt.

Until next time!

Resources

• A16Z’s OSS commercialization post
• Unusual Venture’s field guide is great and recently added resources for open-source companies (starting OSS, community)
• Gitlab’s handbook is an incredible resource for all software companies, especially if you’re open-source.