There is no perfect playbook, but there are proven strategies you can use to build open core businesses that scale with community support. I recently shared these strategies with the Open Core Ventures portfolio companies, summarized below.

You need proprietary IP to monetize—it’s not negotiable

If you don’t have any proprietary IP as a software company, you’re in for a bad day. Without proprietary features, you’re essentially competing on support and services, which rarely leads to venture-scale outcomes.

I see this mistake often. Founders think they can build a business entirely on open source software. If you keep all the code open source, then not only will your competitors compete with you, but if you get popular, other people will start offering the same thing as a SaaS solution. This applies even when you’re not the original maintainer of the upstream project. You must create differentiated value through proprietary features that solve real customer problems.

Make all code source-available

This might seem counterintuitive, but transparency in your proprietary code creates significant advantages. I recommend that all OCV companies make all their code source available so anyone can contribute, even to the proprietary parts. I don’t think there’s a great reason not to do this. Maybe competitors are copying you, but I’ve never seen a startup die because of this. Startups die because no one cares enough about them, no one is using their product, and their product is not improving fast enough.

Automate yourself out of a job

Every time you run into a problem or need to hold someone’s hand, improve the code, improve the docs, and make it so that hands-on support is no longer needed. Many open source companies fall into the trap of building their business around support and implementation services. This is a dead end for venture-scale growth.

It’s tempting not to automate yourself out of a job because you think, “then they won’t need us next time.” But integration and automation are what unlocked the growth of GitLab. The installation became much, much simpler. Resist the temptation to build a support/services business around your open source project.

Keep all code in a single repository

I cannot stress this enough: separate repositories are technically clean, but drastically reduce monetization potential. Instead, integrate both open source and proprietary code into a single repository using subdirectories with separate license files. Make it available for both self-hosted and SaaS deployments. Use OCV’s licensing template. This makes it very clear which parts are proprietary and which parts are open source while maintaining the tight integration necessary for effective development and monetization.

Integrating the code is where I see the most resistance, and it’s where companies make their biggest mistakes. Put everything in the same repo. The companies that opt for “technically clean” over a single repo are often the companies that fail.

Offer both self-hosted and SaaS options

Most companies should offer a SaaS version of their software. This isn’t about replacing self-hosted options but rather providing customers with choice and creating an additional revenue stream. Keep your SaaS version and your self-hosted version as similar as possible.

Typically, the SaaS version will have all of the open source features offered in a free tier, but with usage limits like “no more than three users per team” or other restrictions. The code itself should still be visible and modifiable. Make the proprietary features available in both options. If you create them in the SaaS version, make them source-available in the self-hosted version, too.

Distinguish between open source version and free SaaS tier

This is a crucial distinction that many founders miss: There can be a big difference between your open source version and your free SaaS version. The open source codebase should not have artificial limits built in—that would be antithetical to open source principles. Someone would just send a PR to remove that limit. But you can build a free SaaS version and impose limitations. This applies to proprietary features, too. A free SaaS version may offer limited access to some proprietary features, creating an on-ramp to paid features.

When you don’t control the upstream repo, build trust first

Ideally, you’re in control of the repository, but many open core companies build on existing open source projects they don’t control. If you’re not the maintainer of the upstream project, focus on becoming an active contributor before seeking integration. You should be contributing to the open source codebase to the extent that project maintainers see you and your company as a positive influence. Once you’ve established yourself as a trusted contributor, consider asking the upstream maintainers if you can add your proprietary code directly to their repository.

This approach hasn’t been tested widely, but I believe it could work because you don’t necessarily need control of the repo. You just need someone’s OK to have a subdirectory in there. The key is demonstrating that maintaining separate repositories is creating extra work and inefficiency.

Improve the open source code faster than before

A common community concern when companies form around open source projects is that development will slow down as resources get diverted to proprietary features. It’s important that the open source part of the codebase expands more rapidly than it did before the company existed. Most of the people at your company are net new. As long as one of them sometimes adds something to the open source codebase, the open source codebase should be better off.

Focus on value creation over reputation management

Many founders get paralyzed by concerns about how the community will perceive their commercialization efforts. The best way to maintain community trust is to consistently deliver value through your open source contributions and maintain transparency in your approach. If you’re contributing meaningfully to the open source project and being transparent about your business model, the community will generally respond positively.

Use buyer-based open core for feature segmentation

The buyer-based open core model is straightforward: Ask for money for features that managers and up want, and make the features that individual contributors want open source. Consider the user persona rather than the technical implementation. Management features like access controls, audit logs, and compliance tools naturally fall into the proprietary category, while individual contributor features often belong in open source.

When in doubt, don’t default to making a feature proprietary, thinking you can open source it later. Feature placement decisions are sticky. Once something is proprietary, internal reluctance to open-sourcing it grows over time.

Make sharing free, monetize the control

Don’t put barriers around fundamental behaviors that drive growth. Sharing is a viral thing. Keep that free. But after sharing comes the complications. Managers will ask, “Can we limit public sharing? Can we get an overview of what documents are shared with whom? Can we prevent people from sharing documents outside of our organization?” Make sharing wide open by default, but charge for the governance and control features that managers and executives need.

Become the obvious choice

Make your software more user-friendly than alternatives. Make your open source offering better than other open source options in the same space. When you become the default choice for open source users, converting them to paid plans becomes much easier. You want people to come to you regardless of whether they are looking for open source software or a paid product.

Don’t be afraid of competition. If a large company like Microsoft is adopting your technology, embrace it and use it to establish yourself as the expert. If competitors are white-labeling your software without attribution, make sure everyone knows it is based on what you made. Make a page on your website that lists all the companies building on your software. Make your company look as big as possible. Then, look at what they’re selling, as it’s probably an indicator of demand. Look at which ones are successful and what they are selling, and go build that.

Now, the door for developers is the CLI, and the door for consumers is Claude and ChatGPT.

You ask a question or describe an outcome, and the agent produces it. In the past, every software application was accessed through a UI or API. But how do agents interface with software?

MCP—Model Context Protocol—is how agents interface with software. Like HTTP for browsers or SMTP for email, it’s a protocol that defines how a calling agent connects to a system, reads its state, and writes back to it. Anthropic introduced it in late 2024. Competing protocols have emerged, but they solve different problems. Google’s A2A handles agent-to-agent coordination, IBM’s ACP handles local orchestration. MCP is the standard for tool and system access, and it’s won that category fast: OpenAI, Google, GitHub Copilot, and Cursor have all adopted it, and the public server registry has grown nearly 8x in the past year.

Every major platform shift forces software companies to rebuild their surface area. With the internet, you needed a cloud strategy. With the iPhone, you needed a mobile strategy, and if you didn’t have one, you watched your users disappear into apps that did. Those shifts also created entirely new categories: SaaS, the app store economy, on-demand everything. The agentic shift is the same forcing function. If your software can’t be reached by an agent, it won’t be reached.

Salesforce just made the most dramatic bet in its 27-year history. At TDX in San Francisco, they unveiled “Headless 360,” a sweeping initiative to expose every capability in the platform as an API, MCP tool, or CLI command. The next generation of Salesforce usage won’t happen in a browser. It’ll happen in ChatGPT, Claude, OpenClaw, and whatever comes next.

At Ramp, Teddy Riker wrote recently that “the 80/20 has flipped: the new 80% of interaction with software will be through agents.” Weekly active users on their MCP grew 10x in three months as more customers started reaching into the product through Claude, ChatGPT, and other agents. His prediction: unless a product can be reached by an agent via MCP, API, or CLI, it won’t survive.

Garry Tan, CEO of YC, is a good bellwether for technical trends. Late last year, he posted that “MCP sucks honestly”—too much context window, bad auth. A few weeks later: “I am coming around to the fact that MCP, done right, can be magic.” By April 2026, he’d open-sourced GBrain, his personal AI infrastructure, exposing 30 MCP tools with full MCP support.

This shift is moving fast, and the tooling hasn’t caught up. It’s arguably a bigger disruption than the shift to cloud or mobile. The entire SDLC needs to be rebuilt for the agentic world: tool schema design, prompt capture, evals, quality gates, production monitoring, regression testing, and observability into what agents are actually doing.

The explosion of APIs in the mid-2000s is a helpful analog. Before Postman, testing an API was manual, inconsistent, and painful. Postman made it visual, reproducible, and shareable, and unlocked an entire generation of API-first development. But Postman was just the start. What followed was an entire ecosystem: Swagger for documentation, OAuth for auth, Kong and Apigee for throttling and metering, Datadog for monitoring, and Stripe for API-based billing. MCP needs all of that built from scratch.

MCPJam started as a fork of Anthropic’s own MCP Inspector and quickly became the most popular MCP testing tool on GitHub. We used it to build our own MCP integrations at OCV, and it spread organically through our portfolio. Almost every company we work with has ended up using it independently. I haven’t seen that kind of unprompted coverage across a portfolio since Stripe and PostHog at YC.

Right now, most MCP integrations ship blind. Teams can’t see what’s working, what’s breaking, or what callers are actually trying to do. Your actual users are invisible to you inside an agent conversation you’ll never see. MCPJam breaks that invisibility and gives you visibility into what’s happening between the agent and the MCP server.

The front door to the internet has changed before, and it’s changing again. This time, the door isn’t a browser, a search bar, or an app store. It’s an agent.

MCP has won the protocol layer. What gets built on top of it, the tooling, the infrastructure, the developer primitives, is still wide open. Every category that got rebuilt for the API era will get rebuilt again for the agentic era. The teams that don’t make that transition won’t survive it.

That’s why I’m bullish on MCPJam. It has the right wedge, the most popular MCP testing tool on GitHub, already spreading organically through the best development teams, and a long-term vision for what the agentic SDLC needs to become. The front door is changing. MCPJam is helping teams build for what’s on the other side.

Getting agents right means building them from the runtime up. Runtime is what actually holds credentials, executes tool calls, and manages memory. It’s the foundation everything else rests on. To build it correctly, three things need to be true: it needs to be open, secure, and accessible without a terminal. Each missing piece undermines the others.

Even OpenClaw only delivers on one front (open), despite being the most popular personal AI agent. OpenClaw recently grew from zero to over 350,000 stars and surpassed React as the fastest-growing open source project in GitHub’s history. Run OpenClaw for a week, or any of its current siblings, and two problems become obvious: it’s not secure, and it’s not accessible.

Open but not secure

Peer-reviewed papers now catalog a systematic taxonomy of vulnerabilities in OpenClaw’s architecture. SecurityScorecard’s STRIKE team found tens of thousands of exposed OpenClaw instances — 15,200 directly vulnerable to remote code execution, and 53,300 correlated with prior breach activity. Nine CVEs dropped in a single four-day window in March. Over 800 malicious skills, roughly 20% of the marketplace at the time, were flagged as credential-stealers. Users are losing funds. Users are leaking API keys into LLM provider logs they never consented to. Some have stopped using OpenClaw altogether because they no longer trust it with anything private.

OpenClaw’s core issues have been public for months, and most of them still aren’t fixed, because they’re architectural rather than incidental. Credential handling, skill sandboxing, and network egress weren’t first-class design concerns, so patches land on top of a runtime that wasn’t built for them. New skills and integrations keep expanding the attack surface faster than fixes can close it. That’s why the Claw family of forks and rewrites exists in the first place, and it’s why the fix has to happen at the runtime layer, not in a patch cycle.

Open but not accessible

When an agent holds your most important keys, you should be able to read the code, swap the model and provider underneath, and take your context when you leave. Open source provides this visibility, but it doesn’t guarantee access. Most of OpenClaw’s 3 million users don’t want a developer tool; they want an always-on agent that remembers them, runs while they sleep, and works across every surface they use. OpenClaw wasn’t built for that. Its architecture reflects its origins: a fast-moving project optimized for developer extensibility, not persistent personal memory or multi-session continuity.

Setup requires opening a terminal: using the command line, editing JSON config, generating and pasting API keys, and reasoning about gateways and providers. The median OpenClaw user today is a developer. The median user who would benefit most, the operators, recruiters, solo founders, and small business owners, can’t get past the first config file. The gap between “I want an agent that watches for competitor pricing changes and Slacks me” and “I have that agent running” is still measured in hours of YAML for technical users, and never for everyone else. Workflow integration is where most users give up. The product is trapped inside the audience that needs it least.

The many problems with OpenClaw have spawned a dozen alternatives and rewrites in under three months, each picking an area of weakness to build around.

Yet, none of these has solved the thing that matters most: making any of it securely usable by someone who doesn’t have a terminal open. That’s the gap we want to close.

Building on top of Hermes Agent to close the gap

Hermes Agent, an MIT-licensed project with 100K+ stars from Nous Research, comes closest to closing the gap. It’s a personal AI agent that lives on your own server and remembers you across every session, every model swap, and every device. Memory is stored as plain Markdown files in your filesystem, so you can read it, edit it, and take it with you. The model underneath is swappable: Claude today, a local Llama tomorrow, no rewrites. A built-in scheduler runs tasks while you sleep. The same agent reaches you on Telegram, Slack, email, a browser, or the terminal (once you configure each one), with full context wherever you pick up.

Hermes solves the architecture. What it doesn’t yet solve is getting any of this into the hands of someone who doesn’t live in a terminal.

That’s why OCV is starting an open source agent company, building on Hermes Agent, to ship what’s missing today: onboarding without a terminal, security built into the runtime, and workflow integration that doesn’t require rebuilding your workflow in a config language.

We’re looking for a founding engineer to lead it. You’d be joining as a founder, with OCV’s incubation resources behind you: capital, GTM, recruiting, design, and a portfolio of agent-adjacent companies to learn from. The right person has shipped systems software, cares about security at the runtime layer, and has strong opinions about UX for people who don’t write code.

If you’ve been watching the Claw family and thinking we can do this right from the runtime up, now’s your chance—apply here.

One of the pitfalls I see founders and early product development teams fall into is over-valuing the requirements of potential customers. When a potential customer says, “I’d love to buy the product… if it only had XYZ feature,” the worst thing to do is to make that. It seems counterintuitive, but if a sales conversation has taken this turn, the most likely outcome is that it’s not a good fit. Potential customers are looking for an easy way out of the question of why they won’t buy.

It’s tempting to do whatever it takes to secure early customers, but adding features to satisfy one potential customer is a high effort for short-term gain and detracts from more meaningful improvements. Potential users frequently ask for things that are a low priority. And, if there’s no signed contract, there’s no guarantee that the potential customer will buy the product once the feature is added. Sometimes people use missing functionality as an excuse when the truth is the budget for the tool never existed in the first place or has since been slashed. For all you know, the last requirement of a potential customer could be nothing more than a carrot on a string serving as a buffer between you and the hard truth that they are simply not going to buy your product.

There are plenty of times when the suggestion is well intended and the potential user really believes their feature request will make the product better. Exercise caution if you decide to implement that feature request. Someone who has never used your product can’t really know how to make it better. Even if the features sound like a good idea, get used to the idea that you could be wrong. In these scenarios, take a highly iterative approach to feature development. What’s the smallest possible improvement you could make? Keep it small, simple, and agile as you may need to adjust course midway through or multiple times.

A similar approach can be taken for larger organizations where sales teams are involved. Features are rarely sourced from feature requests but a case can be made for implementing certain small, short-term improvements. In this situation, the sales representative has a vetted and established relationship with the potential customer so there’s less risk. Still, not every sales request is worth acting on. Product and sales should make a list of the top 5-10 highest priority requests each quarter.

Listen to the needs of your heaviest users instead

Prioritize features based on who is asking for them not how frequently they are asked for. Current customers can provide more relevant feedback than potential customers as they are already using the product and are better equipt to understand its limitations than someone who has never used it. The heaviest users of your product will give the best feedback. These are the users who have found the product’s edges. They know what works well and what doesn’t. They have felt the joy of having something just work and the frustration of trying to troubleshoot for hours, maybe even days, with no solution in sight. The heaviest users are the ones who have most likely submitted issues and pull requests proposing code modifications that might solve the problem they are experiencing. The ability to contribute back to the product is one of the greatest benefits of open core products.

After filtering up the best feedback from the heaviest users, weigh feature requests according to effort versus value. Low-effort, high-value improvements are prioritized over high-effort, high-value features. Stability comes from growth so the quicker you can ship improvements, the better.

Ask your community to help

To be efficient with capital, build with the community. Once you’ve decided which feature requests to act on, plant seeds by shipping a small minimally viable change (MVC) and asking the community to help mature it. This is one way to operationalize user feedback and test the feasibility and overall impact of the change without diverting internal engineers from the product roadmap set by the company.

Shipping functionality that is incomplete to expand the scope sometimes goes against instincts. However, planting those seeds even in an incomplete state allows others to see the path and contribute. With others contributing, iterations happen faster. You can have a long tail of categories that are at a minimal maturity that don’t get investment until they show traction.

While MVCs come with a low level of shame they allow the wider community to contribute and people to express interest. It is much more common for people to contribute to categories that already exist rather than suggest something entirely new. People who care the most are using it and just want it to work better. They rarely add scope.

You control your product roadmap

Ultimately, the product roadmap is created by the company, not the users. It’s the product team’s job to determine the product scope and which features fit into that scope. The entire product scope is defined by the product team and roughly 90% of the features will come from them as well. The other 10% will come from customers, potential customers, or sales requests.

The product scope defines the end result: what will this product do? The product scope is made up of features and functionality. A company may have a single product scope defined but there are many ways to implement the features and functionality. Product scope is developed through research and testing, primarily done by the product team. Ideas for features and functionality can come from a wide variety of sources. Users, contributors, and potential customers shouldn’t be adding scope.

Final thoughts

Feedback is critical to product development but not all feedback is equal. Heavy users will give you the best feedback and you should invest a lot of time in understanding how they use the product and what limitations they are running into. Potential customers are not that familiar with your product—the quality of their feedback is bound to be lower than users. Potential customers who are using a missing feature as a reason for not buying are probably not a great fit. Don’t listen to the last objection.

You should think of paid advertising like pouring gasoline on a fire. If you’re starting with real heat, it amplifies what’s already working. Pour it on damp wood, and it will flare up and burn out.

YC’s canonical advice is to “do things that don’t scale,” like manually finding and talking to users. Paid marketing is the opposite of this. It focuses on scale, the mechanics of ad buys, and funnel optimization instead of actually understanding who your users are. But people tend to gravitate toward the path of least resistance, and for founders, this is usually building software, not talking to users. Executing ads feels like building. Manually engaging users is outside the comfort zone.

The result is founders often reach for paid ads before it can be helpful. A product needs to deliver real value, retain users, and prove that the core works before it can scale. Paid is not a substitute for that work. It’s a multiplier on top of it. If you scale before proving the foundation, you actually make it harder to determine what retains users or makes them churn.

Paid acquisition is a science built on understanding your cost per acquisition (CPA), customer lifetime value (LTV), and payback period. If you don’t know LTV, you’re making bets without knowing the odds.

At the early stage, you can’t know LTV because it takes time to measure. If your assumptions about conversion, retention, and gross margin are too far off, it could have massive implications for the viability of paid marketing as an acquisition channel.

Take what happened with meal prep services in the early 2010s, for example. Blue Apron, HelloFresh, HomeChef—venture money poured into these businesses, and most of it went into paid acquisition. They had their CAC, LTV, and payback periods modeled out, and it looked solid. But the math was built on false assumptions. People were signing up for free trials and not sticking around. They just moved on to the next service’s free trial or found the cheapest alternative. At the end of the day, meal prep delivery is a commodity service. All those venture dollars essentially subsidized consumers’ meals and ad platforms.

The same thing is happening with inference today. Commodity agent platforms (AI SDRs, AI recruiters, etc.) can acquire a ton of new users via paid channels, and weekly active users will increase as they keep pouring into the top of the funnel. But at the end of the trial period, users move on to the next platform offering a free trial. Some try to solve this by requiring a credit card on file to start the trial, only to learn that 1/3 of these cards are declined when the trial is supposed to convert. Many times, founders don’t realize the credit card failed because some payment systems (i.e., Stripe) still recognize these as “converted trial users” and count it as MRR. Once founders figure this out, they have a ton of overdue receivables they have no way to collect.

If you cut paid completely, WAU drops, which is the leading indicator of churn. Without a constant stream of new paid acquisition cohorts masking churn, the retention problem surfaces. If your oldest cohort is only a few months old, you haven’t seen enough churn yet to know what retention actually looks like at 6, 9, or 12 months. Expanding new users can paper over a churn problem that was always there, just not visible yet in a young cohort.

Another thing many founders fail to appreciate is that maintaining a constant growth rate requires exponentially increasing spend. That’s a pretty counterintuitive concept. In other words, if you want to continue growing at, say, 20% per month, you have to spend increasingly more money every month.

So if you’re acquiring users who cost you money (because you run at negative gross margin given inference costs, for example), this has a compounding deleterious effect. Increasing spend to maintain a consistent growth rate of costly users is a death spiral.

If you don’t know LTV, retention, and churn with confidence, and you don’t know why users are retained or churn, paid marketing will make it harder and more expensive to figure it out.

Paid marketing isn’t the enemy, but premature paid marketing is. Used at the right moment, it’s a powerful accelerant. Used too early, it’s a way to burn runway learning things you could have learned for free by talking to your first hundred users. Prove value, prove retention, prove unit economics, and then scale. Performance marketing has diminishing returns, and potentially compounding negative returns. Organic acquisition compounds positively. Build that first.

OCV’s new Open Core Ventures Source Available License (OCVSAL) is a source available license designed specifically to cover the proprietary components of software. It’s a simple license that clearly requires a commercial agreement for production use while providing access to the codebase. Here’s how it works:

1. View and modify: Users can view, modify, test, and publish modifications to the code.

2. Commercial agreement required: Using the software in production requires a valid commercial agreement (subscription or contract) with the license holder.

3. Modifications stay with the licensee: The license holder retains rights to all modifications, reducing legal complexity around contributions.

OCVSAL is more restrictive than many source available licenses but more permissive than traditional proprietary alternatives. It is complementary to open source and not meant to replace it. The open source parts of the codebase should remain licensed as open source.

Why not use an existing source available license?

Commons Clause adds restrictions on top of existing open source licenses, which creates confusion about what’s actually permitted. It’s a modifier, not a standalone license.

Business Source License (BUSL) limits commercial use for a set period, then converts to open source after a number of years. That model works for some companies, but it doesn’t fit when you need permanent protection for proprietary features. If you’re building an open core business where certain capabilities are always commercial, BUSL’s time-based conversion doesn’t align with that model.

Other licenses are encumbered by long, complicated licensing text. People are more likely to adopt a license when it’s easy to understand. The OCVSAL is intentionally short, readable, and clear.

Why source available over other license types?

Source available is the most complementary non-open-source license to open source itself. It preserves what matters most: transparency.

When the Commons Clause was released eight years ago, open source advocates warned that source available licenses would destroy open source. That hasn’t happened. Instead, source available has become increasingly accepted because people understand the tradeoff: companies need to monetize their work to sustain development.

The vocal minority who object to any non-open-source license will always exist. But most customers and developers understand the deal: building software costs money, and companies need a way to sustain that investment. Source available licensing provides that vehicle without locking code away entirely.

The alternative to source available isn’t open source—it’s fully proprietary licensing with no code access at all. For enterprise software, providing source code is now table stakes. The days of source code escrow are over. Customers expect access. If you won’t provide it, they’ll find someone who will.

Source available gives companies a sustainable path: share your code, protect your business, and meet market expectations.

OCVSAL v1 is available for use

The full license text is available on GitHub. If you’re building an open core company and need a straightforward license for your proprietary components, OCVSAL v1 is open for use.

We welcome feedback. If you have questions or suggestions, you can find us on X @sytses and @HeatherMeeker4, or get in touch with Heather at www.heathermeeker.com.

Fundraising puts you in front of tons of investors who have heard hundreds, if not thousands, of company pitches. Ideally, you’re talking with experienced partners who have invested in multiple successful companies and know a thing or two about how to build a successful startup. So when they give you feedback on why they passed, intuitively, you want to listen. But don’t. Take the no, and ignore the why.

It can be hard to wave off the feedback from investors when you have a perception that they know better than you. Founders often carry this perception because VCs allocate capital, which gives them a significant degree of power. But it’s important to keep in mind that money and power do not equal correctness.

Potential investors are playing a long game

Many VC partners will talk to hundreds of companies in a year and invest in fewer than five. Just because an investor took a call or two does not mean they were ever seriously interested in you or your company. In reality, if they pass, they just don’t believe in you yet. Most likely, your pitch needs improvement. For example, if an investor is confused about your market, you probably didn’t explain it very well. Don’t mistake that confusion as a reason to reassess your market. The worst thing you can do is think you should pivot your business based on something an investor who didn’t invest recommended.

Investors are playing a long-term game. Even if they pass now, they may want the opportunity to invest in the future, so they are going to be very careful about how they manage interactions with founders. The majority of people struggle to take constructive criticism without having an emotional reaction. If an investor is blunt with their feedback, they run the risk of tarnishing their relationship with the founder and may be passed over for future investment opportunities. If they anger a founder, that person may go talk to other founders and share their negative experience, and suddenly, the investor is being shut out of multiple investment opportunities.

Instead of giving real feedback, most investors will share non-controversial, generally accepted feedback to play it safe—something that the majority of people would agree with. For example, they may say something like “the market is too small” or “the market may not pan out how you think.” This may or may not reflect their true opinions. Even more specific feedback like “if the product would do XYZ instead” or “if you targeted this other market instead” should be ignored. The VC has no incentive to give you real feedback and is trying to come up with the least provocative reason to pass. Following advice in this situation could lead to a path that is completely wrong for your business.

Other excuses VCs tend to give are “it’s not you, it’s us” or “the business is too early or too late for us to invest right now.” These excuses are rarely true. The “it’s not you, it’s us” excuse is an age-old way to let someone down easily while avoiding sharing any details. Similarly, investors know the stage of your company when taking the call. Yet, blaming the stage of your company is the number one excuse they use, simply because it gives them an easy out.

“If you rename what it is called,” he wrote, “you help to remove the ‘bait and switch’ controversy by openly recognizing it as an emerging standard business model with specific attributes associated to it (i.e. GPL core, with commercial extensions).” Adam also explains that the emergence of a standard business model for open source was welcome and necessary. However, he acknowledges that these perspectives often result in a “religious open source war” and it was only a couple years later that the Open Source Initiative (OSI) shared its definitive stance on “open core.”

Objections to open core

According to the OSI’s statement on open core, the fundamental problem is that open core is just a nickname for proprietary software and shares no advantages with the user. The blog post lists six scathing declarations on open core: “’Open core’ has NOTHING to do with ‘Open Source’. At this point, nearly every proprietary software product has various degrees of open source-licensed source code in its core.” The statement declares that open core puts the software user at a disadvantage in the same way that all proprietary software does, and calls open core companies that claim the advantages of open source deceitful.

I agree that open core ≠ open source, and that open source software is eating the world. The difference between open core and proprietary software is that open core produces a substantial amount of open source software, whereas solely proprietary software produces none. They both offer open source maintainers a way to get paid for their work, but open core contributes back to open source. Source available carries more advantages to the user than closed source. Most open core companies put a lot of effort into maintaining the core. Therefore, open core is better than proprietary software for all of these reasons. The argument isn’t open core over open source, it’s open core instead of proprietary.

A framework for feature segmentation

The perception of open core as faux open source is perpetuated when companies aren’t transparent about pricing models. While most open core companies will have a statement of intent regarding their relationship to the open source project, they usually don’t disclose how they place features and functionality. When open core companies aren’t explicit about their pricing model, it causes confusion and mistrust.

One of the questions I get asked most frequently about starting a new open core business is, “What features do I make open source, and which should be proprietary?” Yet, Adam Lampitt gave us the framework in 2008: “Some say that this dual license strategy is OK, but as long as you follow the spirit of segmenting by user base, not features.” I call this buyer-based open core and have been using this model to build GitLab since 2015. It’s the model we strongly encourage at OCV.

Buyer-based open core is a framework for determining which features are made to be open source and which are proprietary, based on who cares most about the feature. Features that appeal most to an individual contributor are open source and free. Features that appeal most to management or executives are proprietary and not free. 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.

For example, the merge request feature in GitLab is free and open source, but the merge request approvals function is not. The rationale is that managers are more likely to care about approvals than individual contributors. While it’s not a completely objective framework, it provides a baseline that any company can adopt. It positions the question of open source or proprietary around which type of user gets the most value and begins to negate the bait-and-switch arguments.

Deciding which features to monetize can make or break a business: The worst-case scenario is giving too much away for free, and the business can’t sustain itself. The second-worst-case scenario is to build a company on top of an open source project and never contribute back. This is a balancing act, and companies are bound to get it wrong sometimes. Resist the urge to move features from the open source version into the licensed version. Doing this completely erodes trust. Use feedback from the community and users to refine where you place features as you build.

The buyer-based model provides guard rails for companies so they don’t overcorrect in either direction. It’s a monetization strategy that enables business growth while furthering the open source movement.

Good for business ≠ bad for open source

An open core business that builds on an open source project unlocks resources for the project that it may not get access to otherwise, allowing the project to grow and innovate more quickly. Meanwhile, the busines gets a return on investment in the core project, with the benefits of a community and their contributions that improve the core. Where they make money is by charging users who are also using the project for financial gain.

Founder and CTO of Authentik Security, Jens Langhammer, commented in the announcement about forming the company built on his open source project: “There are many things I wanted to do but couldn’t because I didn’t have the time. I’m excited about the opportunity for people to work full-time on the project. Both the future enterprise and open source versions will benefit.”

While open core may produce proprietary code, it does so alongside a fully operational and maintained open source core. It sustains open source and the contributors who pour their time and effort into creating it.

We’ve seen this play out across OCV’s portfolio. Mermaid‘s OSS gravity made it the default diagramming framework for AI tools. Its syntax-saturated developer training data got embedded in GitHub, GitLab, and every major doc platform, and became the lingua franca for “diagram as code.” It is now the fastest-growing code-based format in the world, and has driven Mermaid’s exceptional commercial growth.

But the relationship runs both ways. AI is also a cheat code for OSS. AI enables people who are not professional developers to contribute to OSS for the first time. As of early 2025, there were around 35 million professional developers and another 10 million amateurs. Until now, well under 1% of the global population is responsible for all software being built and maintained in athe world. But that is rapidly changing. Over 36 million new developers joined GitHub between September 2024 and September 2025, the fastest absolute growth in the platform’s history, and monthly active OSS contributors doubled from 84K to 175K, driven largely by AI adoption.

This trend reached a fever pitch in March 2026 with OpenClaw, which became the fastest-growing open source project in history. Its contributor guidelines explicitly welcome “AI/vibe-coded PRs,” and the community reflects it: the vast majority of contributors are not classically trained developers. At NVIDIA’s GTC, Jensen Huang called it “the operating system of agentic computers,” comparing it to Linux, HTTP, and Kubernetes. Five years ago, the idea of non-developers contributing to foundational computing infrastructure would have been unthinkable.

The most durable OSS projects are what Jean Lafleur, co-founder of Airbyte, calls federation-style: where the user persona and the contributor persona are the same. That’s why the most successful open source projects have historically been devtools and infrastructure; the feedback loop between using and building is tight, and the product compounds with every contribution. The alternative is stadium-style OSS, where a small core team builds while the community watches. This is why OSS has historically struggled at the application layer: even if users are smart and opinionated, the bar to contribute has been out of reach.

There’s a growing consensus that building application-layer software is a dangerous proposition, as the cost of software development trends toward zero, so why not build a custom application every time? “AI will kill vertical SaaS” is the new refrain. I’d sharpen that: AI + COSS (Commercial Open Source Software) will kill closed-source vertical SaaS.

Consider Electronic Health Records (EHR), the OG vertical software. An EHR manages patient medical records and the administrative workflows of a medical practice, including scheduling, billing, and clinical documentation. Any EHR vendor will tell you no two practices are alike. They are deeply opinionated and require significant customization to support their particular workflows and requirements.

Epic owns ~40% of the U.S. hospital market and generates $5B+ in annual revenue, a substantial portion of which comes from implementation and customization services. Ask any practitioner how they feel about Epic, and the answer underscores the persistent gap between the people building the software and the people who live in it every day.

Epic will be around for a long time. But I believe it will gradually be displaced by an open core solution. Healthcare organizations won’t vibe-code their EHRs, but they will build and customize workflows within a framework that understands the regulatory environment, the clinical context, and the data model. An open core EMR is a platform for AI-powered customization, workflow automation, and agent orchestration, grounded in the patient and provider data that it protects.

OSS has always been a knowledge-compounding machine: contributors improve the software, which attracts more users, which improves the software. When domain experts who were previously locked out can finally join that loop, the flywheel spins faster and reaches further. This dynamic is true across verticals, but especially powerful in healthcare, where knowledge-sharing is hardwired into the professional ethos.

This is the thesis behind our investment in OpenCoreEMR, which is commercializing the most popular open source EHR in the world—a project built by and for healthcare providers. For most of its history, contributing to OpenEMR required clearing a technical bar that most physicians couldn’t reach. AI is rapidly changing that, and the project is growing exponentially.

OpenCoreEMR is one example, but the pattern will repeat across every industry where domain experts have been locked out of the software they depend on. “AI will kill vertical SaaS” is right in that those experts are now empowered to build. But they won’t build from scratch. They’ll build on open core platforms that already understand the regulatory environment and domain-specific requirements of their field.

Our stack starts with Gobii AI, an OCV portfolio company that lets anyone spin up virtual coworkers. Gobii tackles some of our core operational and data processes—no code, workflow mapping, or APIs needed. We simply create AI agents that are onboarded the same way a new remote hire would, by communicating with words. We give them access to the same internal systems and accounts a real employee would use, and teach them the workflows conversationally. If you can explain it in plain language, you can build it.

One hard requirement for anything in our Ops stack is self-hosting capability. We run Gobii on our own infrastructure, which means the data our agents consume and store stays fully within our control.

Portfolio data auditing with Gobii

The first Gobii agent we created automates our portfolio data audit process. While it’s not quite a full operations analyst yet (more like a really good intern), the results have been promising.

Pulse is OCV’s internal VC ecosystem that houses key information on our portfolio (investments, financial metrics, founder teams, etc.), including profiles for each of our portfolio companies. Keeping those profiles up-to-date and complete is critical to our ability to manage operations. Manually auditing our growing list of companies is tedious and time-consuming. So we gave it to a Gobii agent, aptly named Pulsey Jackson.

Before Pulsey could get started, it needed access to Pulse. Instead of using an API or giving it access to an existing user, I created a dedicated login for Pulsey and gave it the only permissions it needed to do its job, just like we would for any new employee.

Once Pulsey was connected, I asked it to log in, review every portfolio company profile, and flag any data fields that appeared incomplete. Pulsey compared each company profile against a fully filled-out model profile that I audited myself. Once it was finished, it sent me a PDF report, which alerted me that the monthly projected burn rate was missing from a significant number of companies, alongside the list of all missing fields and the corresponding profiles they were missing from.

A task that would have taken roughly two hours a week to manually review was handled in a single automated run. Nice job, Pulsey.

As our portfolio continues to grow, this kind of data hygiene would only get harder to maintain without automation. The next step is to train Pulse on the nuances of our portfolio. Ultimately, we expect it to audit, edit, input, and broadly manage the data integrity of Pulse with only the minimal required human oversight. After that, we can integrate more Gobii agents to work with Pulsey to monitor the portfolio, dissect financial information, and expand our dataset.

Founder and CTO Philippe Lafoucrière brings over two decades of entrepreneurial and engineering experience to the smart home automation space. A serial founder since university, Philippe started Gemnasium in 2011—a pioneering dependency scanning company in the software supply chain industry—which was later acquired by GitLab in 2018. As a Distinguished Engineer at GitLab for seven years, Philippe worked closely with OCV’s founder and general partner, Sid Sijbrandij, an experience that profoundly shaped his approach to building transparent and vision-driven open core companies.

Philippe envisions a future where Selora Homes is the standard for home and building automation. “Software is eating the world, and that includes homes, too. Every home will be a smart home in the future—it’s not a question of if, but when,” said Philippe. “My vision is that Selora becomes the automation and monitoring go-to solution for not just homes, but for all buildings—institutional, commercial, and industrial.”

Bucking proprietary lock-in

Smart home solutions like Control4, Crestron, or Savant force you to choose between reliability and flexibility. They provide a professional installation experience, but trap users in their ecosystem with expensive hardware, limited integrations, and dependency on certified dealers for every change. Mainstream platforms like Apple Home, Alexa, and Google Home offer a middle ground—easier setup than professional systems and better integration than before—but still lock users into their respective ecosystems with limited device compatibility, basic automation capabilities, and reliance on cloud services.

These closed platforms can hold customers hostage with restrictive licensing and costly maintenance requirements. Even consumer-friendly options like Apple Home require HomeKit-certified devices and offer only simple automations, while Google Home pushes users toward Google’s ecosystem with similarly constrained automation rules. Neither platform gives users meaningful access to their own historical data or the ability to create complex, multi-condition automations.

Meanwhile, free and open source solutions like Home Assistant offer flexibility and support for over 2,000 integrations across every smart home protocol imaginable. There’s little incentive for customers to stay locked in with a single ecosystem when more smart device companies are providing open firmwares and embracing the “Works with Home Assistant” label, according to Philippe. “The power of Home Assistant is that it works with almost everything,” said Philippe. “This means homeowners can use a single application to manage all of their devices instead of scattered apps for each device brand.”

However, setting up DIY solutions like Home Assistant requires significant technical expertise. “When something stops working, homeowners have a steep curve to fix their problem,” said Philippe. “People don’t work on their home automation systems every day. It’s easy to quickly forget how and what you did, making troubleshooting later a headache.” While technical troubleshooting Home Assistant is part of the appeal for the technically inclined, it’s a huge hurdle for the average homeowner trying to make home automation simpler—a problem that worsens with scale.

Building the future of connected spaces

Selora Homes’ open core approach brings professional installation and support to Home Assistant’s robust open source foundation. “We want to make smart simple,” said Philippe.

For homeowners, the platform will deliver professional peace of mind through 24/7 monitoring, expert technical support, and guaranteed response times. Features like secure remote support, continuous security monitoring, and automated security updates ensure reliability. Automatic backups with quick recovery and optional High Availability configurations will ensure zero downtime.

For professional installers, Selora Homes will provide a comprehensive business management suite including centralized customer dashboards, team collaboration tools with role-based access, professional ticketing systems with SLA tracking, and direct Home Assistant technical support. The platform offers secure remote access through just-in-time tools like Tailscale for troubleshooting, proactive monitoring, and alerting for all installations, and managed updates with rollback capabilities. These features enable installers to scale their operations while maintaining high service levels.

Beyond operational tools, installers can join the Selora Homes Network, a marketplace where homeowners can discover and connect with certified professionals in their area. This means installers not only streamline their existing business but also gain access to new customer leads, expanding their reach without additional marketing costs. As part of our installer network, professionals benefit from increased visibility while homeowners get vetted, qualified experts who understand the platform.

Strengthening the open source foundation

Building on open source Home Assistant ensures customers avoid vendor lock-in and can reliably use a wide variety of devices. “Home Assistant’s open source automation framework is changing this smart home market,” said Philippe. “There’s already more than two thousand integrations, and you can create an integration for pretty much anything that you might think of. If your device has a network connection or is available through an API, you can integrate that with Home Assistant.”

Philippe’s approach to building Selora Homes reflects a deep commitment to strengthening rather than fragmenting the Home Assistant ecosystem. “That means contributing back to Home Assistant whenever we can. “It’s the foundation of our offering, and we want to be good players in the market and make sure that Home Assistant is getting all the benefits from the changes that we’re going to make,” he said.

This philosophy stems from Philippe’s belief that open source represents a fundamentally better way to build technology. “Our goal is to make Home Assistant usable to customers who know nothing about Home Assistant,” said Philippe. “The foundation is free and open source, but we’re building an out-of-the-box solution for people who probably wouldn’t use Home Assistant on their own.”

Join the waitlist

Selora Homes is now inviting early adopters to join the waitlist. We’re looking for homeowners who want professional-grade smart home automation without the complexity, and installers ready to grow their business with our platform. Selected participants will get early access to the platform, direct input on feature development, and exclusive pricing when we launch. Whether you’re frustrated with your current smart home limitations or you’re an installer looking to scale your operations, we want to hear from you. Register for early access and help us shape the future of connected homes. Space is limited as we carefully onboard users to ensure the highest quality experience.