Where Open Source Meets Community with Sam Weaver

Sam Weaver describes Plural as an orchestrator of open-source software. Even when those apps are free, they demand considerable time and effort to bring all the pieces together. Along with Cofounder Michael Guarino, a FAANG engineer who spent years doing just that at Facebook, Amazon, Twitter, and Frame.io, he’s giving developer teams an easier and more cohesive way to build, maintain, and scale infrastructure on Kubernetes.

Unlike many of the other subjects of these open-source founder interviews, Sam is someone I’ve invested in and built alongside. I have to say, his fast progression in this space is really exciting—for example his recent release of Plural Stacks to speed open-source deployment—and I learn so much from him every day. Here’s what I learned today:

Share a little bit about your professional journey and what has led you to be so excited about Plural?

My background is in computer science. I came out of college and straightaway did engineering work at IBM on mainframes. I wasn’t there long—for a number of reasons. One was that mainframes did not seem to be headed in a progressive direction. It was about the same time when everybody was moving to decentralized compute or at least some form of private cloud. I didn't want to be pigeonholed into what I felt was dying, and there was a really cool emerging company in the open source space at the time called Red Hat—this is 15 years ago. And so I jumped over to Red Hat and I spent four years there, two as an engineer, two as an architect.

This was when Red Hat became the first billion-dollar open-source company, which paved the way for today's open-source unicorns.

I really liked the community aspect of open source. It felt like everybody was much tighter, everybody enjoyed working on products together, you got great feedback from your community users, and people were way more engaged.

Four years in, Red Hat was at about a thousand people. I learned a lot and I decided I wanted to do open source again, but at a smaller scale. So I joined MongoDB pretty early, at 50 or so employees back around 2011. The London office was just about 10 people, so we were just doing everything. So whilst I joined as an architect, I spent days where I was a consultant or a marketing person or a community person.

It was there I realized I really enjoyed talking to users about the product. Back then, enterprise B2B product management was certainly a lot less prevalent than it is today, but that's effectively what I was doing. I was talking to users about MongoDB, figuring out why they couldn't use it, and then giving that feedback to the engineering team. In the end, I moved to New York in 2014 and started the product management team through to the IPO in 2017.

But again, after we went public, I realized I like building things and going from 0 or 1 to scale. So I joined an even smaller company called Unqork, which was a no-code platform with ten employees. It was the first time in a long time I'd been at a closed-source company. What I really missed was the amount of rapid product development you can get out of open source versus closed source. Our innovation was just naturally slower in a closed-source ecosystem because we could only develop with our engineers with no community contributions. We were getting product feedback from paying customers only—no one on the peripherals, no one in the community.

We'd gone through this consideration on taking the product to the next level, limited by our architecture being based all on cloud-managed services and some legacy frameworks. And so we said if we were doing this properly, we would bring those services in-house rather than cloud-managed. We'd still deploy on the cloud, in compute, but at this point we would deploy on Kubernetes, with great cost savings and improve our margins for going public in a couple of years.

And so that's what we started to build. We called it the platform control plane. And it was tough, it was really hard. We had to find the engineering team to do it: specialized DevOps engineers who understood Kubernetes. We had to do a migration. We had to get all the customers from the old architecture onto the new architecture. And it took probably over a year, maybe two years.

By then I had met Michael, my cofounder, who had the same problems at Frame.io and Twitter. And it was like, well, how do we commoditize that in a platform that everybody can use? And so that was the genesis for how we started to work together. And we joined up forces officially about a year ago.

Unbelievable context for what you're doing right now. Three different unicorns, two open source, one, seeing the struggle of having to move on to Kubernetes. How's it going right now with Plural?

In January, we raised $6 million dollars in seed funding. We did not anticipate the rockiness in the macro venture markets throughout this year, so the seed funding gave us the flexibility to be a bit more relaxed and not have to worry about immediately looking to go out for further fundraising. We've built an incredible team based on who is doing the best work in each area, and the product has gotten to the point where it's easy to get up and running.

So you're early in the journey at the seed stage of the company. What is keeping you up at night?

Being pulled in directions we hadn't originally anticipated—that’s what keeps us up at night. When we started Plural, we thought it would be an amazing tool for DevOps teams. And that's true; we see DevOps teams having a lot of success with Plural. But we're also seeing a lot of interest from data engineering teams. So we must consider how much deviation goes into the product from what we had originally imagined.

How are you thinking about building community?

The community aspect is interesting because any major open-source company today has started with a really engaged community. That community is giving product feedback and is growing into accounts that will later become our biggest accounts. In general, you can think about community as a good place to start monetizing.

There’s the anti-product perspective where you knock on doors until you get somebody willing to listen to your pitch, and hopefully, you convert it into a sale. But we operate from product-led growth, which means the product sells itself. Customers already realize that the product is solving a problem.

So part of building community is figuring out what people need, what they can afford, and if it’s possible for them to be successful. Revenue is secondary to us.

How do you measure community involvement?

There are a couple of ways. We use a pretty well-known community measurement tool called Orbit.love, which plots the concentric rings of our community. The first ring is composed of the really engaged users. These are people that are going to be commenting on your Slack channels and submitting requests. Then there are the people in the outer rings who are less and less engaged moving outward. We built analytics to tell us if somebody gets to a certain ring of engagement. The goal is to bring everyone into the first ring of the orbit.

You've been CEO for under a year. How do you like it?

When I was offered the role, I was the Head of Product at Unqork. I thought, “I don't know if I'm a CEO–I'm a product guy!” But I gave it a try, and now, ten months in, I don't know if I could ever do anything else. Being able to solve all different problems across multiple areas is really interesting. It turns out I'm not a product guy, I'm a problem solver.

The arc of your journey is really fascinating, and you get to see some incredible companies in their early stages and be a part of building them. When you think about Plural IPOing in the future, what went right?

I could see Plural’s IPO being almost identical to the MongoDB journey. Many things happened with MongoDB early on that worked really well, and some that didn’t. MongoDB had a great community, and that community was pushing the company into interesting places. But a few things were blocking the adoption of MongoDB. First, they had a database with no management tools. Then the biggest competition was our own open source product, it's free, so why would anyone pay for it? But when you see Mongo today, it's such a victory. This makes me think of the quote: "First, they ignore you. Then they laugh at you. Then they fight you. Then you win."

Mongo became buzzy with developers. Why was that?

It was this ease of use and speed to deploy. So with traditional SQL, you have to define a schema; if you want to change anything, you alter the table, which takes a long time. MongoDB didn't have any of that. If you needed to insert a new attribute, you could do it. They made it so storing things on JSON became standard. We had a lot of things going in our favor. We crossed the chasm when we figured out how to start pulling the right levers for monetization. That was around operations where we gave users the tools to deploy and manage the platform more easily.

How are you thinking about Plural right now regarding free versus paid?

We're trying to create a standard for how people are deploying software. We're deploying open-source software at scale, a standard that doesn't exist today. Putting up artificial pricing barriers right now will slow community sharing and growth.

Do you have people right now who are bought in to the Plural vision?

Yes. When we talk about this vision to people, they get really excited—particularly a lot of our early users and early investors truly believe this is an opportunity we can conquer. That said, this is a 10-year vision.

It’s a long way to go to get to this vision. And nobody started without conquering a niche. And so you could imagine Plural for data infrastructure, great. What about Plural for security infrastructure? Plural for monitoring infrastructure, Plural for CICD infrastructure. And you really end up building a giant marketplace where people are creating combinations of infrastructure to solve use cases and problems and it's a single click to deploy. And so that's how you start getting people coming as the standard is, I'm going to Plural and this is the problem I'm solving.

One thing that strikes me is that people believe a seed-stage CEO needs to be on top of the product. How are you maintaining a level of customer centricity?

The nuance here is it really depends on how well you understand product management. A lot of product management is the nitty gritty of organizing the engineering team. But the primary part of building a product is talking to users about the actual experience of the product. I spend most of my day talking to as many people as possible. The product manager reports to me, and we work very closely in tandem.

One thing that I really appreciate about your leadership is how inclusive you are. This feels like it parallels some of the things that drew you to open source. As a last thought, can you speak to this idea?

My superpower is identifying who has strength in what areas. They know way more than I know, so my job is to empower them to feel supported to make creative decisions. Because if you don’t try, then we'll never know. And failing is actually good because then you still know more than you did before. People sometimes ask me why I don't build the product and be the Product Manager. The answer is that my product is the company.