So, you’ve built an open-source project that has greatly improved developer productivity and the community loves it – thousands of GitHub stars, contributors, and pull requests. Everyone’s chatting about it on Discord and Slack. Congrats. 🏆

It’s only natural that you’d think about taking the next step and building a company around the project. Your code could be the basis for the next Confluent or Databricks. Or could it? I wouldn’t get ahead of yourself just yet.

I’ve partnered with a number of founders who’ve made that leap and scaled their open-source companies. In this post, I’ll share what I’ve learned from those experiences to help you assess your chances of commercial success.

 

The 6 Fundamental Truths of Starting a Company Based on an Open-Source Project

To begin, I believe in six fundamental truths — all of which will help you gain a clear-eyed understanding of the opportunities and challenges for your solution.

1) A product is not a market.

A market exists when you have current or prospective customers who:

• face similar problems
• can afford – and are willing – to pay for a solution
• exist in numbers sufficient to generate meaningful revenue

2) Consider the extensibility, a point solution alone will struggle.

Open-source software is often developed for a specific use case, which won’t necessarily dovetail with the needs of other organizations.

3) Never underestimate the cost factor.

Open-source software is popular partly because it’s so easy to acquire and work with – i.e., free. But it’s a very different proposition when users need a manager to sign-off on a 5-, 6- or 7-figure PO to adopt a product. (That’s why I’m adamant that product-led growth [PLG] is a marketing channel, not a sales channel. But that’s a longer conversation for another time.)

4) It’s hard to pinpoint users and use cases.

Most users are anonymous, employing obscure usernames. They leverage the software in various ways, making it difficult to identify typical use cases that could be mapped to commercial applications. Open-source software doesn’t call home, making it very challenging to reconcile who the users are.

5) A perfect product/market fit is rarely achieved at the outset.

You’ll need to keep iterating and adapting to the needs of the market.

6) I’ll say the quiet part out loud.

If you’ve already raised some money, that doesn’t necessarily mean you have a viable long-term business; it just means you sold an investor on the vision.

It’s a high bar, I know, but not insurmountable. Just consider these companies and their founders who did it. They once were where you are now.

• Mark Fussell and Yaron Schneider at Diagrid
• Ganesh Pai and Uma Reddy at Uptycs
• Mitchell Hashimoto and Armon Dadgar at HashiCorp

 

The 5 Questions That Could Make or Break Your Company (And an Investor’s Decision to Invest)

Now that you have those fundamental truths in mind, you need to do some homework. There are five foundational questions that entrepreneurs should ask themselves as they build their companies. The answers to these questions not only shape the business, but they can make or break if you sell others (e.g. investors) on your vision.

1) What’s the problem you’re targeting?

Every good business solves a problem. Your problem statement should be a concise, clear description of the challenge or opportunity that your solution can address. Answer these questions:

• What is the specific problem or challenge that requires your solution?
• How does this problem hamper your ideal customer’s work?
• Is there a quantifiable cost imposed by this problem?

2) What is your value proposition?

What evidence do you have that users support your product? Here are some topics to consider as you craft your value prop:

• Define what makes your solution unique. For example, have you developed a new approach or achieved a technological breakthrough?
• Describe how a customer’s life would be better after using your software. Draw a before-and-after picture.
• Quantify the impact. How would a customer measure the benefits of your product on the individual and on the organization, and how significant is the change.

Remember, every product has competition: either direct (a product with similar functionality) or indirect (tackling the problem in a different way). You’ll need to articulate how your product is superior to all alternatives and crisply define a compelling reason to buy. Saying you have no competition isn’t credible. Even if there is not a perfectly competitive company, indicating who could be competition shows pragmatism.

Finally, you need to be realistic about potential barriers to buying your product. Key factors can include:

• Any changes in process or work steps that might need to be made to accommodate your product
• The possibility that a new budget category or line item would need to be created

When Norwest evaluates companies as possible investments, we’re after the same thing you are – enthusiasm for your project. But we need to know how deep and broad that enthusiasm is, and how long it may last.

So, prepare to share how you’ve measured the adoption and usage of your open-source software. GitHub stars, contributors, forks, pull requests (PR), and Discord/Slack posts — they’re all breadcrumbs we follow. Sure, they don’t tell us if folks are ready to throw money at you, but they hint at what users find valuable (and whether there might be enough enthusiasts to constitute a viable market). If a handful of people contribute PRs, that’s nice. If a couple hundred do, then you might have something with legs.

3) Who is your target customer?

Who are these future fans you want to target with your software? Be prepared to share some of these characteristics:

• What job title(s) do they have and what are their responsibilities?
• What kind of companies do they work for?
• Are there any industries or markets that make them more suitable customers?
• What does success look like for them?

4) Does your product fit into a category that people already understand?

New solutions are often a double-edged sword: innovation is valued yet change often creates uncertainty. The more radical a solution, the more difficult it may be for the market to understand and accept it. Customers often look for a “bucket” in which to place you and your product. You need to place yourself either in an established category — consider Gartner categories if applicable — or define a new market segment.

Side note: creating a new market segment may sound exhilarating and highly differentiated, but it is a lot of work. We’re talking years of market education using time and resources that most startups don’t have. It may also complicate your sales process if customers need to create new budget line items to purchase a solution. It can even hamper your ability to raise money; some investors will want to know the size and growth rate potential of this new market segment. Just level setting with you.

5) How will you monetize your product and who’s going to pay for it?

Getting people to try open-source software isn’t hard — it’s free after all. But if you want to build a viable company based on that software, you’re going to have to charge for it. Your challenge now becomes how much you charge, and how the paid product differs from the free version.

It’s not essential to have a pricing model at the outset. But you should at least have a vision for monetization in the future and a rough idea of how you will motivate users to keep paying for your product over time.

And for goodness’ sake, name your paid product something that sets it apart from the open-source version. That will help both you and your customers clearly distinguish between the versions.

For example, the developers of open-source project Dapr eventually formed their own company based on the software: Diagrid, the name they use for the enhanced services they provide on top of Dapr.

And consider how open-source project business models can change over time as demonstrated by HashiCorp’s recent migration to a Business Source License… following the open source footsteps of Elasticsearch, MongoDB, etc. Is this the natural progression for all future open-source projects?

To be clear, the developer who tries your open-source software and loves it is the start of the journey, not the end point. The key question to answer is: who has the budget to pay for your product?

 

3 Steps to Validate Your Vision of Building an OSS Company

If you’re counting your GitHub stars and perfecting your answer to the questions above, you may be thinking “I’m ready to start selling.”

Hold on; not so fast. You’ll need to do more homework. By this point, you should have a profile of your ideal customer — understand their challenges and how their life would improve with your solution. You should have an MVP (remember your OSS project is not your product), nailed your product description, and perfected your 20-second elevator pitch.

Even after you’ve got everything above, you still have more homework. All of this information is exactly what you need, yet it’s all just theoretical. If you want your product in the market, then you must validate your idea in the market.

Step 1: Test your assumptions with potential customers.

This is the fun part: heading out into the real world to learn if anybody agrees with you – or even knows what you’re talking about.

The methodology here calls for interviews with potential customers. These aren’t yes/no interviews like public-opinion surveys; they’re discussions based on a few well-honed questions that should elicit open-ended responses and honest feedback.

Who are these interviewees and where do you find them? They are individuals who match the description of your ideal customer. Chances are, many of them will be like you: developers familiar with the benefits and challenges of open-source software. But don’t just talk to your friends or colleagues. Seek out people who are thought leaders in the field. Maybe they’ve spoken at conferences, posted particularly insightful blogs, or written articles for trade or professional journals.

One thing is for sure: don’t solicit the views of venture capitalist or other possible investors. They have minimal value to provide at this stage.

The goal is to conduct 15-20 interviews. A subset (say, 3-6) ideally will be with managerial-level people who have the budget to pay for your solution.

Developing a discussion guide for these interviews is an art form, so get help from people with the proper skill set and experience (e.g., sales and marketing professionals). A portion of the discussion will be a high-level description of your open-source project and your plans to commercialize it. I emphasize that this is only a portion of the discussion; it’s not a half-hour sales pitch. It’s an invitation for honest feedback, constructive criticism, suggestions for improvement, and an informed judgment as to the viability of the product concept.

The objective of each discussion is to answer questions like:

• Do they see the problem the same way you do? Be attuned to the language they use. Be cautious of disingenuous confirmation; many people avoid conflict.
• What is their degree of urgency for solving this problem? Would your solution be nice-to-have or must-have?
• What would a solution mean to them and to their organization? Probe for how benefits would be measured.
• What solutions have been tried before, and what were the outcomes?
• What’s their reaction to the idea of a commercial product based on your project?
• What suggestions do they have for improvement?
• Who/what is the competition, both direct and indirect? If there is an incumbent vendor, what are their strengths and weaknesses?
• What’s the process for a product like yours to be specified, recommended, and purchased?
• Who has the budget to pay for your product, and up to what dollar amount?

The results of these discussions will vary widely. You may love what you hear, you may be discouraged. But you’ll have a view of reality. The best response you can hope for is one that’s detailed, not just “this sounds cool.”

Step 2: Find a design partner to provide feedback

Here’s the thing though: talk is cheap. As great as these conversations go, they’re just conversations. It’s time to turn that positive interview into usage. Here’s where validating your product becomes mission-critical.

Feedback is a gift, particularly in the early days of a venture. Your first step to real, actionable feedback is to find design partners. Design partners are the first few users you enlist to help you define your company’s problem space, and help you shape your solutions as you gear up your product for market. A good design partner represents your target market, has an interest in your solution, and has the time to test it. Depending on your project, you’ll want to build a team of 5 diverse design partners who will test your product in a sandbox environment. They’re not there to cheer you on, they’re there to dig in and assess the usability and need for your solution. Their feedback should guide you in building a useful product that solves a real problem for your target buyer.

At this stage of your company’s evolution, your priority lies in understanding the market and your users thoroughly. By observing their behaviors closely, you can develop a solution that effectively addresses the correct problem, ensuring a good product-market fit.

Step 3. Iterate, Iterate, Iterate

Remember, feedback is how we grow. As you collect user feedback, leverage it to align your product vision with the market’s wisdom. Make the necessary improvements, which might involve changing features, improving user experience, or adjusting your pricing strategy. The key is to be willing to make changes based on what users tell you.
Once you’ve iterated (and iterated and iterated), make an honest evaluation of all that you’ve heard, and answer these questions:

• Have you heard validation of your assumptions and hypotheses?
• Where is the strongest agreement? Where are there gaps?
• What are the common themes? Is there consistent feedback about product direction?
• Is there enough consistent feedback to give you confidence that there could be an identifiable and addressable market?

Ideally, you will have the answers to all these questions — and more importantly, the evidence and documentation to back it up. Even still, you’ll need to continue refining your product functionality, user experience and packaging depending on how far along you are.

As you continue this process, you’ll crystallize how your product functions, who would use it, why it’s needed, and how it will become market ready. In short: all the reasons why it would succeed in the market. Embracing a continuous feedback loop not only enhances the overall quality of your product but also fosters stronger relationships with your design partners — who may even convert into paying customers.

After all this, how do you make the leap?

Once this homework is done and you’ve validated the product concept through design partnerships, you may be ready to take your solution to market.
At a high level, here are some questions that can determine how you make the leap:

• How much capital do you need? To reach a meaningful initial product milestone, how many engineers are needed and therefore how much capital is required? Take that forecast and increase it by 50 percent. Things always take longer and cost more.
• Do you need angel or seed financing? If you’re raising a couple hundred thousand dollars, you’re looking at angel funding (individuals) or perhaps pre-seed funding on the slightly higher end. If you need a few million ($2 – $5M), you’re looking at seed financing from an established seed fund. If you need $10M or more, you’re targeting Series A which typically means you have several hundred thousand of annual recurring revenue (ARR).
• How will you price your software? Numerous factors affect how you price your product. At a minimum, look at the feedback from your design partners, including the ROI and cost savings that customers will see. Do your market research: how do your competitors price their products? What are their monetization strategies? Consider how your pricing will scale as your customer base grows.
• What features are next on your roadmap? This demonstrates your commitment to continuing to provide value for your early customers.
• How will you sell and acquire new customers? I recommend a read through April Dunford’s How to Build a Killer Sales Pitch.
• Does a product-led growth approach suit your software? Here’s a primer for figuring out if PLG makes sense in your go-to-market strategy.

Good luck on your journey!