Open-core companies produce both open-source software and source-available proprietary software and follow the buyer-based open-core business model for determining what’s open source and what’s source-available. The open-source project is always free and downloadable without restrictions.
Most companies have a SaaS hosting option and will provide a free, hosted version of their software. This is not the same thing as the open-source project. A free tier comes with limitations, usually in the form of consumption, number of users, storage, or some combination of those things. From a business perspective, the goal of the free version is to drive people to upgrade to paid versions.
Pricing has a negative correlation with demand. When the price goes up, the number of customers willing to pay that price will go down. Optimizing pricing strategy is often a consistently evolving consideration for companies. In general, pricing alone should be the primary reason 20% of people are not willing to buy the product.
Buyer-Based Open Core (BBOC)Advantages of buyer-based open core:Module-based open coreOpen source versus free versionGood, better, best pricing tiersGood = freeBetter = premiumBest = enterpriseDiscount programsSubscription termsPricing strategiesPrice-based costingCost-based pricing and MarginsConsumption or usage-based pricingWhen to use TOS/Stripe click-through and when to use a Subscription AgreementCreating a pricing web pageWaitlistsCommunicating self-managed versus managed offeringsExamples:
Â
Buyer-Based Open Core (BBOC)
Buyer-based open core is a framework for determining which features are open source and which are proprietary. The BBOC method places features into tiers based on the most likely user. There are typically three tiers, and the order of increasing cost and tiers is based on the buyer. Features that appeal most to an individual contributor are open source and free. Features that appeal most to management or an executive are proprietary, and you charge the highest amount of money. It's no longer about "Where is that feature technically?" Or "How much more work was it to make?" Or "Where in the repo does it live?" It's about the end-user.
đź“ą Watch the full presentation on Commercial Open Source Business Models.
Advantages of buyer-based open core:
- Features are consistently added to the free and open-source version.
- You can serve different users with a single use case by building propriety functionality on top of existing open-source features. For example, you have a collaboration feature that is free to use, but approvals are paid.
- Executives are least likely to contribute to open source and have complicated use cases. They pay for features that meet their specific and possibly unique needs.
- Executives are the least price-sensitive. You can charge a lot of money for the features an executive needs.
With buyer-based open core, the plan scales with the highest-tier user. Everyone within a company is on the same plan and gets the same features even if they don’t use them. The disadvantage of buyer-based open core is that it's harder to keep the open source and proprietary code separate.
Module-based open core
The opposite of buyer-based open core is module-based open core, where features are separated based on functionality.
Module-based open core tends to have:
- Few proprietary features
- Features that are either open-source or proprietary
- Price-sensitive buyers
- Frequent open-source contributions from users
Module-based open core makes it harder to create proprietary features because functionality within the product is either solely open source or solely proprietary.
Open source versus free version
The open-source project and the free version of your software are not necessarily the same thing. The open-source project should always be available to download, use, and modify via the repo it’s stored in. It’s not usually available as a hosted SaaS product. The free version of the software is usually a hosted, SaaS product and it may be a forked version of the open-source software.
The open-source software may be hosted in a “sandbox” environment where users do not need to sign up with accounts. The hosted open-source “sandbox” operates as the free tier. When this is the case, the limitations on what a non-sandbox free tier may look like should focus on driving users to the paid tiers more quickly to reduce friction. A limited trial of premium features in place of an additional free tier is recommended to help reduce that friction.
Features that are available in the free version of the software should also be added to the open-source version. It’s important to maintain a good, usable version of the open-source project to contribute back to the open-source community and encourage bottoms-up adoption of the product.
Good, better, best pricing tiers
In its simplest form, the open-core pricing model has three tiers: good, better, and best. It’s recommended to use a price-based costing strategy for determining the market for pricing levels.
Tier | Free (Good) | Premium (Better) | Enterprise (Best) |
Potential Buyer | Individual Contributor | Manager/Director | Executive |
Price | Free ($0) | $$ (e.g. $9) | $$$$ (e.g. $25) |
Billing | ă…¤ | per user/mo billed annually | per user/mo, billed annually |
Good = free
The “good” tier is free and drives upgrades to a paid version. Even though the “good” tier is free and open source, it is usually a separate offering from the open-source self-hosted version of the product. For products that are solely self-hosted, the open source version may be your free tier and upgrades to paid plans will be driven primarily by features. Only offer one free tier.
Avoid free forever plans. The intention of providing a free tier is to let people try out the product. Free tiers should have limitations that drive people to upgrade. Examples of limitations include usage, compute consumption, storage, and/or a number of something (for example: searches, projects, users, etc.)
When the cost of goods is significant, offering them for free is not recommended. Instead, consider providing a generous trial period without requiring credit card information, allowing users to get a good feel for the product. A well-designed trial period can help users understand the value of the product and encourage them to upgrade to paid plans.
Considerations for creating a “good” tier:
- Should require creating an account
- Automatically starts as a 30-day free trial of the premium offering, then reverts to basic features
- User and/or consumption limitations:
- Collaborators (5 people)
- Storage (1 GB)
- Compute (10 models)
- Transfer (100 syncs)
Better = premium
The” better” tier includes everything in “good” and introduces source-available paid features targeted toward managers.
Considerations for creating a “better” tier:
- Can include base-level support
Best = enterprise
The “best” tier is the highest-paid tier that includes everything from “good” and “better” and includes enterprise-specific paid features and support targeted toward executives.
Considerations for creating a “best” tier:
- Includes support SLAs
- Usually includes SSO features
- No user limitations
Discount programs
As your company grows to over 100 people and you can handle more complexity, you can consider discounted programs.
- Education: Free version without user limitations or paid offerings at a discounted price
- Non-profit: Discounted per-user price for paid offerings
- Startup: 50-75% discount for startups that meet specific criteria. For example, a seed-stage startup with less than $X in funding and less than $X in revenue.
Discounting may also happen outside of a specific program on a case-by-case basis. Companies don’t lose their ability to discount by having a list price.
Subscription terms
Simplify pricing plans by only offering an annual subscription.
It makes it easier to instrument and finance your company when all customers are on the same plan versus segmenting by monthly and annual subscriptions. (Pilot programs where needed can convert into annual contracts).
The recurring revenue metric of annual recurring revenue (ARR) versus monthly recurring revenue (MRR) differs based on the yearly or monthly billing subscription renewal period. Upfront billing ensures 12x recurring revenue when customers are billed yearly.
Reporting metrics when a company has both annual and monthly customers is duplicated if both options are available to customers.
There is a risk of losing some business upfront in only billing yearly, but those customers are more likely to churn regardless. Often companies start with monthly billing and switch later to annual billing as they mature, but it is better to start with annual billing early on.
Annual contracts help:
- Reduce customer churn.
- Provide cash upfront, which is an effective non-dilutive way to fund the company (cash impact between monthly and annual contracts is substantial).
- Companies can offer flexible payment terms and a money-back guarantee if customers have reservations about annual commitments.
Pricing strategies
It is harder to change the dimension for pricing than to change the price itself. Prioritize getting the pricing dimension right early on.
Price-based costing
Price-based costing looks at what competitors or substitutes would charge to provide a similar product/service to get a sense of willingness to pay.
Additional Reference: https://www.priceintelligently.com/blog/price-based-costing
Cost-based pricing and Margins
Price-based costing is the recommended method for pricing a SaaS product, but cost-based pricing which accounts for determination of costs and establishing a targeted margin is also important to consider.
SaaS companies should typically target an 80-90% margin with a target of 15% or less of costs spent on infrastructure and a target of 5% or less of costs spent on support.
Calculating margin and markup
Margin = (Revenue - Costs)/Revenue = 1 - Costs/Revenue
Markup = (Revenue - Costs)/Costs = Revenue/Costs -1
Markup = Margin*Revenue/Costs = (1/(1 - Margin)) - 1
Markup = (1/(1 - 80%)) - 1 = (1/20%) - 1 = 500% - 1 = 400%
Consumption or usage-based pricing
An alternative dimension for pricing based on the number of users can be through consumption or usage.
The consumption-based pricing model is a service provision and payment scheme where the customer pays according to the resources used. The provider needs to track customer usage and bill accordingly. Consumption-based billing is best for businesses that can easily break down their offerings into small, variable units.
Advantages | Drawbacks |
Fair to the customer (paying for actual usage) | Difficult to predict revenue (can’t price annually) |
Align operating costs with customer usage rates (e.g. cloud storage) | Receive payment in arrears as opposed to in advance |
When to use TOS/Stripe click-through and when to use a Subscription Agreement
Â
If you’re starting with a low price point and offering self-serve onboarding (e.g., freemium models), it's best to use TOS/Stripe Click-Through for simple recurring payments. This approach minimizes user friction and streamlines transactions.
Subscription models and metered billing, on the other hand, are more complex and require more planning and thought, which can delay your launch. Unless you anticipate a significant volume of self-serve paid customers at launch (which is rare), it’s recommended to start with clearly defined pricing and terms of service (TOS). As customers cross payment thresholds, you can track this in your logs and manually invoice them. Once this process becomes unscalable, you can then automate and integrate billing solutions.
Creating a pricing web page
Â
The pricing page is often the most visited web page because it quickly tells visitors what the company offers. Considerations when building a pricing page:
- Make the most desired choice the primary call to action.
- Use font size to show information hierarchy.
- Clearly articulate the different tiers (for example, free, team, enterprise)
- Use “Cloud” to describe managed services.
- Use three tiers “good, better, best”
- Use the term “planned” when noting upcoming features. Don’t use “coming soon” because this can be interpreted as a promise.
Additional reading: 24 beautifully designed pricing page examples | Webflow Blog
Waitlists
OCV doesn’t recommend wait lists. It adds an extra conversion point where you have drop-off and creates extra complexity. Withholding the download isn't very open as in open source / open core codebase.
Communicating self-managed versus managed offerings
There are typically two ways to consume software:
- Self-managed: Customers host the software themselves on their own technology and infrastructure (this is sometimes called on-premises but since most customers host at a hyper cloud self-managed is a better term).
- SaaS: The company provides access to its own technology and infrastructure
Examples:
- Use Cloud to explain its “You pay the bill”
- Unless they sell an API, not an interface: