How to align Open Source and Enterprise Sales

It's possible to align Open Source and Enterprise Sales, but there are some pitfalls. If done right, it can be a huge success, but you need to be aware of the challenges.

You don't want to cannibalize your Enterprise Sales with Open Source, but you also don't want push away your Open Source users, eliminating the benefits of OSS collaboration and a potential user base for your Enterprise product.

In this blog post, we'll share how we think about Open Source and Enterprise Sales at WunderGraph, what has worked for us and what hasn't. So far, we've seen great success with our approach and we're happy to share our learnings with you.

There are many models to monetize Open Source software, and we don't believe in any of them. Open Core, Dual Licensing, you name it. Don't! Keep it simple.

We've got one repository, a single mono-repo, with a single license. Everything is Open Source, and we don't have an Enterprise version of our product. We don't limit features, we don't limit users, we don't limit anything.

What we do instead is to offer a managed service, and on this service, we limit some features depending on the plan you're on.

You absolutely don't want multiple licenses or versions of your product. It slows down development, it confuses users, and it's a pain to maintain.

Enterprise Sales is not about selling features; it's about selling a solution to a problem.

Some companies are happy to use your Open Source product as is, they don't need anything beyond that.

What we have seen is that we're building very close relationships with our customers. We answer their questions within minutes, we help them with their problems, and we're always there for them. When they have a new requirement, we figure out how to solve it together. What they buy is not about features, it's about the relationship they have with us; it's about access to experts; it's about trust. It's about being able to rely on a partner when there is a problem or bug.

By limiting some features, creating an enterprise version, or introducing multiple licenses, we would only create friction and confusion. We would lose potential users that might help us improve the product, we would lose a potential user base for our managed service, but we wouldn't gain much in return.

Some companies prefer to have their staff spend their time on managing 3rd party software, others prefer to leverage a managed service so that they can focus on their core business.

Both are valid approaches. The first group might be great contributors and advocates for your product, while the second group helps you to grow your business.

Don't even think about using OSS as a sneaky way to get users for your Enterprise product. It's not. The ICP of your Managed Service is different from people who solely rely on your Open Source product.

Open Source is about collaboration; it's about building something together. If you're not interested in collaborating with others to make the product better, you're better off not Open Sourcing it.

We absolutely love the collaboration with our users. Some of them find small bugs, others contribute small fixes, and very few contribute larger features. One huge advantage of Open Source is that bugs are found and fixed very quickly, and the "testing surface" is much larger than what you could ever achieve on your own.

Open Source "might" have a secondary effect on your sales funnel in the sense that the open source product might raise awareness for your managed service, but that's just a side effect. Don't rely on it; don't plan for it. Don't abuse OSS for marketing purposes.

Open Source is also not a business model. It's a way to build software; it's a way to collaborate with others; and it's a way to distribute software.

It doesn't matter whether your solution is Open Source or not, the software itself is not the product. If you don't have a clear value proposition for your Managed Service, your company will fail no matter how good your Open Source product is.

Your Managed Service is your product, and it has nothing to do with your Open Source product.

We've got a separate private repository for our Managed Service. We're SOC2 compliant, and we're working on getting ISO27001 certified. We're experts in our field, and we offer world-class support. We collaborate with our customers, we educate them, and we help them to be successful.

If all we did was to install the Open Source product on a server and charge for it, we wouldn't have a business.

Most importantly, we have the ability to quickly change the product to meet the requirements of our customers. If software wouldn't frequently change, we could just put Cosmo in a box and sell it as hardware. But it's not. Cosmo is a living product; it's constantly evolving, and we're constantly improving it.

The goal of our customers is to innovate, to be faster than their competition, to be more reliable, more secure, more compliant, and more cost-efficient. Our expertise in the field, our ability to quickly adapt the product to meet their new requirements, and our world-class support is what they pay for.

The market leader in our space is Apollo with their GraphOS offering. You cannot self-host the Apollo GraphOS product, you must use their managed service.

That's a great opportunity for us. Some companies operate in highly regulated environments, and they must self-host the software. This could be for legal reasons, for security reasons, or for compliance reasons.

We've got customers who are working on huge government projects, and they must self-host everything in "government clouds" to comply with regulations and pass audits. That's a very interesting market for us.

Even though our product is Open Source, they absolutely want to pay for our expertise, for our support, and most importantly, for SLAs. Security is a major concern for them, and they want to get a fix for a security issue in a timely manner.

This has implications on how to structure and architect your product. From the very beginning, we've designed Cosmo in a way that it can easily be self-hosted in any environment. All you need is a Kubernetes cluster or an environment that can run Docker containers.

You can make your solution Open Source, but if you're relying on proprietary 3rd party services, you're limiting the use cases for your product.

This one might sound counterintuitive. You should invest into documentation and make self-hosting easy. This might sound like a contradiction, because you want to sell your managed service, right?

But again, it's not just about hosting the software. By making self-hosting easy, you have to spend less time on supporting your Open Source users. If they can easily install and run the software themselves, just by looking at the documentation, you can focus on your paying customers. You get value out of the Open Source community, e.g., in the form of bug reports, fixes, and contributions, without having to spend much time on supporting them.

In addition, your Enterprise customers who are required to self-host the software will have it much easier to do so. Just point them to the documentation, and they're good to go. Their Platform Engineers will love you for that, and you will have more resources to invest into improving the product.

If we put licensing, collaboration, and software distribution aside, we're left with building a business.

Customers (hopefully) pay you money to provide value to them. The market for your offerings must be big enough to sustain and grow your business. This should be your primary concern.

It's not about software, it's about solving a problem for your customers. We're not "Open Source Heroes" or anything like that. We believe that Open Source is the ideal way to build and distribute Cosmo. This might or might not be the case for your product.

We believe that in 10 years, the market for Federated GraphQL APIs will rely on Open Source software to a large extent. As of today, we're already seeing collaboration and contributions from FAANG companies. This kicks off a virtuous cycle, where more companies are willing to use the software, which in turn attracts more contributors. No proprietary software can compete with that.

Good Open Source collaboration is about giving and taking. It's not ok to just take. The "Issues" section of a repository is not a free support channel. Demanding features, fixes, timelines or support is not ok. It's ok to politely ask for help, but there's a fine line between asking for help and demanding it.

That said, there are many amazing people out there who understand the value of Open Source, they understand the boundaries, and they collaborate in a respectful way. We're very grateful for these people, and we're happy to have them in our community.

It's important to build a healthy relationship with your community. You need to set boundaries, but you should also not try to exploit your community.

There's a fine line between Open Source collaboration and trying to force people into your Managed Service. If you feel the urge to "upsell" your community, you're doing it wrong. Again, Open Source is about collaborative software development and distribution. If you're playing it right, it can even become a marketing tool and a sales channel eventually, but it's nothing you can (or should) force.

You're probably thinking that this sounds too good to be true. You've seen too many companies that started with Open Source and then switched to a proprietary model, switched to a dual licensing model, or introduced an Enterprise version of their product.

These companies failed to build a business that goes way beyond the software itself. Some software simply should not be Open Source.

If you're losing your moat by Open Sourcing your software, you're better off not Open Sourcing it in the first place. Don't abuse Open Source for marketing purposes; don't abuse it to get users for your Managed Service.

Redis, ElasticSearch, or NGINX are great examples of fantastic Open Source products that lack a clear value proposition for their Managed Service. But not only that, they are also carrying another risk if you're building a business around them.

If your business model relies on compute or storage margins, you're in a very dangerous position. You cannot win against AWS, Google Cloud, and Azure. Even if your solution is better, faster, more secure, more reliable, and more cost-efficient, you cannot compete with the margins of the big cloud providers. And more importantly, you cannot compete with their reach.

Why would I use your managed service if I can get a similar service with much better SLAs, in more regions, with more reliability, and more security from AWS? I already have a contract with AWS, I get support from them, all I need to do is to click a few buttons in the AWS Console. With you, I have to go through months of procurement, legal, and security reviews.

Alternatively, you could sell a control plane that allows your customer to leverage their own AWS account. Instead of competing with AWS, you're "partnering" with them. In general, the big cloud providers will always win against you in terms of infrastructure. You should try to leverage their infrastructure and build services that they cannot provide.

That said, AWS is notoriously bad at combining their own services. Companies like Vercel demonstrate that you can build a very successful business by combining multiple AWS services. Coincidentally, Vercel also leverages Open Source with NextJS—although whether NextJS is truly Open Source is an entirely different discussion that we won't be delving into here.

We believe that core infrastructure software that can be Open Source will be Open Source. If you're not doing it, someone else will. And in the long run, if executed correctly, Open Source will win through network effects. If you bet on the GraphQL Federation ecosystem as a whole, and you're thinking long-term, you should always short-sell proprietary software and bet on Open Source instead.

Another observation we've made is that Open Source can be a very powerful recruiting tool. We've hired some of the best engineers we've ever worked with through our Open Source efforts. People who ask good questions on your community, engage with your product, or even contribute to it, are quite likely to be a good fit for your team.

Why hire blindly from LinkedIn, when you can see already how someone works and interacts through a Pull Request or in discussions on GitHub or Discord?

At the end of the day, it's all about people. The moat of your company is your expertise, which is embodied by the people who work for you. We feel entitled to say that we've already got some of the best people in the industry working for us, but we're always looking to expand our team with more amazing people. We're working on very interesting problems, collaborate with very smart and capable customers, and we're building a product that we believe will have a huge impact on the way we build APIs in the future. Go check out our open positions if this sounds interesting to you.

As noted above, we believe that GraphQL Federation will have a huge impact on the way we build APIs in the future. We also believe that the foundations for this future will be built on Open Source Software. Allowing everyone to use Cosmo however they want, without any limitations, will have huge long-term flywheel effects for all of its users.

We're building the "GitHub for APIs", and we believe that the success of GitHub was only possible because git is Open Source. Core components like a GraphQL Federation Router (Cosmo Router), or the Schema Registry (Cosmo Control Plane) must be Open Source to enable the future as we envision it. We're very excited about the future, and we're happy to have you on board.