Mike Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 45 with Tracy Ragan, Founder and CEO of DeployHub. Tracy is exactly the kind of entrepreneur we’re looking to interview. She is deeply experienced in open source. For example, she served on the board of the Eclipse Foundation. She’s a serial entrepreneur, and she has a plan to succeed that will adapt to whatever the market throws at her.
If you want to learn more about Tracy, she was a guest on two episodes of The Daily Drive. I try not to repeat too much of the content from those podcasts. I’ll put links on the episode page so you can check them out. The Daily Drive is hosted by Ken Knorr to provide entrepreneurs, marketers and sales people with news, information, inspiration and tools to drive success – it’s a fun show. Well, enough of my blabbering, let’s get on with the interview. Here we go.
Tracy, thank you so much for joining the podcast today.
Tracy Ragan: Hello, and it’s my pleasure.
What Is Continuous Deployment?
Mike Schwartz: This isn’t really a tech podcast, but sometimes the background is helpful. So, I’m wondering if, in a nutshell, you could help us understand what is the Continuous Deployment Market, and what are some of the adjacent markets, like, how would you compare to a Puppet or a Chef?
Tracy Ragan: I think the best way to describe it first is to define it around Continuous Delivery. Continuous delivery is the engineering process that says, “Hey, let’s get new innovation out to end-users as quickly as possible.” And that means a change has to go through sort of an assembly line from tracking the change request, to creating the binary, to testing the binary and installing it at different locations, from dev to test or production. That’s what Continuous Deployment is.
So, when you think about companies like Chef and Puppet, they are at a lower level, they are worried more about the configuration and the deployment of the infrastructure itself, so, do I have a cloud image or a physical machine that I am ready to deploy to. So, they are at the lower level. So, Continuous Delivery and Continuous Deployment generally sits at a higher level and worries about the application level.
How Is DeployHub Democratizing Continuous Deployment?
Mike Schwartz: In a previous interview, you mentioned that DeployHub is democratizing Application-Release Automation – what exactly does that mean?
Tracy Ragan: I have been in this business for quite a long time, and I get frustrated when I see so many companies still relying on scripts to do the heavy lifting of the Continuous Deployment piece. It can be a real showstopper for a lot of companies because they can’t do updates as frequently as they would like to.
Now, they can go out and buy a product, but some of these products are really expensive. Some of them are based on endpoint. So, if you’re going out to a few thousand servers, you’ve got to buy an agent for every server.
And when we built out DeployHub, I really, really wanted to provide an open-source solution to many companies and developers who didn’t have what I call Budget Authority, so that they could move away from this scripted process, and instead, do something that’s truly automated, and do it from an open-source standpoint. And that’s what I always mean when I say we’ve democratized it.
Because it’s not just the person at the CTO-level or a director-level, making a decision that everybody in the company is going to use this particular solution, and it’s going to cost hundreds of thousands of dollars. Instead, the developer, who’s already building out that CD pipeline, can say, “This is a good practice for us to use, and I can afford to take advantage of it.”
Mike Schwartz: You mentioned that in your market, competitors are selling expensive enterprise software platforms, how is DeployHub different, not just from a price perspective, but what are your other differentiators?
Tracy Ragan: When we built out DeployHub – and our open-source solution we call Ortelius, by the way. Abraham Ortelius was the first map-maker, he created the first world atlas – we saw the problem from a microservices standpoint, there’s several really solid ARA, Application-Release Automation tools on the market. But they are monolithic-driven, they don’t think about an application in terms of its pieces and parts.
When we built out DeployHub, we put it back inversion engine on it – just like you would inversion source code – so that we could independently deploy the pieces and parts of an application as opposed to an entire monolithic.
Now, that’s critical in the microservices world. And it’s basically a mapping exercise. What we’re really doing is what I often call Automated Configuration Management from microservices. And as you push the microservices across the continuous delivery pipeline, we’re tracking the changes and building a map.
So, if you think about, if you ever go, “This is a fun exercise.”, if you ever go and Google search on the Netflix Death Star, you’ll begin seeing the kind of world that we’re putting together with microservice, and it’s massive. I think Netflix runs around 4,000 plus microservices. So, what we’re doing is part of the deployment is versioning the Death Star.
Now, in the beginning, we have companies who come to us, and they start hitting a bottleneck at six or seven microservices. That may not sound a lot, but if you put that, and then you add versions, even a version for DEV, TEST and PROD, and then the next version coming, or the version three months from now, you end up with a lot of microservice really, really quickly.
So, what we focus on is creating that map, and that’s what the open source project is all about. Because, in order to be successful with a Kubernetes microservice implementation, you must have a way to organize the microservices in the same way that you had to organize APIs when we first started doing API management.
Mike Schwartz: So, as I understand it, the monetization strategy for DeployHub is Software-as-a-Service. And I’m wondering, is there a community collaborating to build the software that you run as a service?
Tracy Ragan: We’ve been working on that. When we first started Ortelius, we had a few really important folks show up to help us out. One individual’s name is Doug Orr. He actually designed Kubernetes for Google, he was one of the directing engineers that built Kubernetes out.
We also had a local company called Descartes Labs step in and start looking at what we were doing with mapping and give us some real strong direction on where they thought the product should go.
And now, that’s been a year ago, when we first released the product, and we first brought the community in. We now have Netflix and Google, who have joined our Technology Oversight Committee. And we’d have those board meetings about — we try to do them three times a year, to really build out the roadmap.
So, we’re pretty excited to have some really strong players in the market that’s helping us what our roadmap will look like for the mapping of microservices in a cluster.
Has Open Source Materially Benefitted the Business?
Michael Schwartz: Would you say that open-sourcing the software has materially helped the business?
Tracy Ragan: Not yet. It hasn’t. There are simple reasons why you would open-source. For example, there’s always this term that a lot of companies use, and you’ve probably heard it before, “vendor lock-in”, and there’s also this thing called patents.
We open-sourced it originally under the Affero License, which it currently exists under, and what that does is, it exposes the code to all of our customers, so they don’t have this concerned about vendor lock-in. If they want to enhance it for their own environment, they can, but nobody at this point can take it and monetize it.
Now, on the patent front, it’s a real problem to try to patent software. Everybody says, “You know, if you want to get investment, you should go do that.” When you release something under the Affero License, you’re patenting it. Because anybody who goes to use it, has to use it under that license. They could reuse it internally again, but they can’t monetize it.
Now, as we have grown, we are inviting more folks in, like Netflix and Google, because we need now their expertise. And their expertise comes from having these massive Kubernetes clustered environment. We can’t get that without an open-source tool.
So as we move along, we’re hoping that we will move that Affero License and change it to something that’s a little more liberal license, so that we can include that as part of the CD Foundation, and then other companies can monetize on the mapping.
It’s yet to be determined if we’re going to get a financial gain out of it, but we certainly have become thought leaders because of it. There’s not too many companies talking about this microservice configuration management issue. The more we can be out there as a thought leader and the more input we can get from these big companies, the stronger our tool will be. And the only way to do that is through an open-source project.
How Do You Decide What Is Open Source?
Mike Schwartz: So, you probably don’t open-source absolutely everything, and there’s always this balance between what do you open-source and how do you prioritize R&D, and open-source, or, let’s say, your proprietary. And I’m wondering how do you handle that conflict?
Tracy Ragan: Yes. So, we looked at the product, and we talked to the folks who were using it from an Enterprise perspective, and we asked them what’s the most important part of the tool that they really, really, really love. A lot of that had to do with what we call our Domains.
So, in microservices, you really need to establish what’s called a Domain-Driven Design. I like to equate it to, you know, everybody has a junk drawer at home, and if you don’t know where something goes, you kind of throw it in the junk drawer. And then, if something’s missing, you kind of dig through the junk drawer to hope it’s in there. Oftentimes, right now, microservices are being kind of treated that way.
They’re checked into a repository, but that doesn’t mean there is a domain-driven, logical hierarchy of where to find these microservices and to share them. So, when we looked at the Pro version, what we call our pro version, we have what we call Divisional Domains. And that’s important to an Enterprise, but it may not be important to a project team. And then, on top of that, what’s important to the Enterprise is – the feedback they gave us – is the ability to put security around those domains.
So, if you have a group of API developers, they want to be able to share their microservices, but they don’t want anybody to edit or change the way they’re deployed, and some of that information is what we versioned. We, in the open-source version, we took all of that, the Divisional Domain, and all of the security out of it. And that’s generally what the Enterprise wants, but it’s not critical for a project team.
So, a project team can go ahead and move forward with it. And if they really needed to put security around it, they can do so around their CICD. So, CircleCI, for example, has approvals that move authority it built inside of it. They can actually build security around it without using ours.
Is SaaS The Main Monetization Strategy?
Mike Schwartz: Did I get the monetization strategy right? I was under the impression that you were a SaaS, or that there was a SaaS version of the open source. But other revenue streams besides the SaaS?
Tracy Ragan: No, that’s it. Well, of course, we have our consulting arm, so we help companies with implementing these microservice structures and organization. We do what we can to help anyone who comes to us and says, “We’re struggling with managing our domains – how can we do it?” But there is a – just as a point of clarification – there are some companies who don’t want to use the SaaS. We have a registered container at RedHat, and we’ll be adding one to the AWS marketplace that they can create an on-prem version.
Mike Schwartz: Deployment is a very horizontal market, do you segment the market vertically, or any other way, when you’re thinking about the marketing strategy?
Tracy Ragan: We actually do. If you take the financial market for example, they have a very different perception of deployments than somebody that might be in Telecom for example. The financial market is really super highly-regulated. They have serious audit requirements. Now, Telecom does as well, but not at the level that the financial markets would. They take separation of duty still very serious.
When we’re talking to somebody in the financial market, we may be having a conversation that’s stronger around audit, as opposed to somebody who may be in another industry, where it’s stronger around Continuous Deployment. I know it sounds crazy that the financial market may not want the Continuous Deployment. They want Continuous Deployment with a strong audit trail.
The other markets may want to solve microservices. So, we do have a message specific to some of these industries, medical’s the same way. And then, there’s embedded — you talk to embedded folks, and that’s a whole different story for them because they have a whole different set of challenges.
Mike Schwartz: What does the sales process look like for DeployHub? I know for a lot of SaaS, there’s this philosophy of try by fly. You are a little different, it’s a complicated product sold to Enterprises, and I’m just wondering, like, what does the sales process look like?
Tracy Ragan: We’re still figuring that out. We still believe some of our best sales has come through a self-service model. So, what we did is we took the open-source version Ortelius, and we built it into a SaaS offering so we could call it freemium. It’s free to use, and we have about 150 users out there using a product, many of them are small project teams.
What we find are these bigger companies who want to be able to do a POC and never talk to a customer. We have been successful in closing deals based on that model. So, while they use the free version, they understand some of the problems with implementing of the free version into an Enterprise because of the security, the lack of security on the free version, so then, they reach out to us.
We’re focusing now that we’re kind of low here with the current economy, and we’re focusing right now all of our efforts in making the front end of the product as easy to use as possible. It is a complicated set of problems to solve, it’s our job to make it an easy problem to solve.
So, the sales model is going to rely on our ability to provide a self-service SaaS product. The teams can get excited about and start implementing on a very, very short schedule. We’re talking two or three days at the most.
Mike Schwartz: Your business is still sort of new. I think you were formed maybe two years back. But one of the questions I like to dig into a little bit is pricing, which I find is really hard. And the difficulty is really underestimated by a lot of entrepreneurs. Do you have any advice for how do you find the right gates, how do you find the right price, and how has your thinking evolved maybe since you first got started?
Tracy Ragan: When we first launched DeployHub, the company, I reached out to a few CPAs and said, “I need to make these decisions on real data.” And I put together a monster of an Excel spreadsheet. A monster that said, “This is what we want to do. This is the number of freemium customers that we want. This is what we want to do to convert them. This is where we need to get to, and this is what it’s going to cost.”
And from there, I backed in the price. So, looking at how much money we wanted to make off of it, we this time – and pricing is really tricky – we said, “This is what we would have to price the product at in order to get to a certain growth in dollar amounts, and to be able to support the product, and do the development that we need to, and do all the selling that we need to do around it.”
So, that’s how we did it this time. We did it much more scientifically than hunch. You know, I got a hunch that this will work. So, the way we priced it is, we have something we call a “project”. So, if you’re a bank, you have a teller application, that would be a single project. And we price it at $2,500 per year per project, or it comes out to, I think, $300 a month per project, which is a really low price point, but it is a project by project implementation, as opposed to going out and saying, “We want to sell you an Enterprise deal at a 100K with a 30,000 a year maintenance contract.
And the way we’ve done it, a project team can make the decision to say, “I’m going to go ahead and buy the Pro version. And I’m going to go ahead and implement it because we control our continuous delivery pipeline, and I don’t have to get everybody involved to make this decision.”
To say we’re really practical about it, I spent the first six months – when we first started DeployHub – with my head in financials and talking to CPAs and really working out the model.
How To Manage Customer Interactions At Low Price Point?
Mike Schwartz: So, your price point, I think managing customer relationships correctly is really critical to scale. So, what are the different channels that you have in place to communicate with customers?
Tracy Ragan: We try to keep in touch with most of our customers by reaching out and calling. And we have a sales rep, I guess you could call him a sales rep, but he really is a customer service person who reaches out on a regular basis. And we have regular training that we reach out, to help them move from one step of the product to the next and make sure they understand all the features.
But, you know, GitHub is a great resource for that, because, we have on the open source side, we have a GitHub repository, where people go and open up issues. And that creates a really nice conversation, not just amongst us internally, but as well our other customers who are seeing some of the same problems.
So, we have a GitHub repository for the open source, and then we have one that’s private for what we call the Pro and Enterprise versions, but for most part, most of the tickets are opened up under the open source, which creates a really great platform for that.
Mike Schwartz: As we mentioned, the business is still kind of young, but I’d like to ask questions about partnerships. What kind of partnerships does DeployHub have today, and what types of partnerships are you looking to develop in the future?
Tracy Ragan: I would say two of our best partners is CircleCI, they have really embraced what we do around deployments, especially around the management of microservices. We also work pretty closely with the CloudBees folks. They have what I would call a competing tool, but they still want to provide their customers options. So, CloudBees and CircleCI have been great to work with.
Now, we also are working with Plutora. Plutora is a company that manages what we often call Value Stream. And not a lot of companies are thinking about Value Stream Management for microservices. So, we’re doing some integration as some joint customers with Plutora.
When it comes to a broader community, I’m on the board of the Continuous Delivery Foundation, and so I’ve built quite a few relationships with those folks. And I’m currently working on building out a partnership with Gitlab.
Advice For Open Source Entrepreneurs
Mike Schwartz: I ask this question to all the guests – do you have any advice for entrepreneurs who are launching a business around an open-source software product?
Tracy Ragan: You know, I think one of the smartest things I ever did was work on that, build out that Excel spreadsheet. It was painful, it was not fun, it hurt, it really did hurt. Some days, I just feel, like, I just have to go, you know, strap on a drool cup and watch TV for a while.
It’s not an easy practice, to sit down, and visualize, and think through your company for a five-year projection. But, if you take the time to do it, I believe that you will see if your company is viable or not. And you can get the pricing down, and you can really understand what you need to do to achieve success.
That was one of the best things that I that I ever did because I know now, I have marching orders that I have to live by. And it’s in that Excel spreadsheet. I know what I have to achieve on a quarterly basis, and I know when I need to increase the price of the product. So, that was really important.
The other thing that I did that was right was, I got involved in the bigger open-source community. Getting involved in the Linux foundation, even if you’re a young company, that’s a fairly inexpensive entry point, to join the Linux foundation, and then join one of those sub-foundations like the CNCF or the CDF, because it really does give you a broader community to talk to and develop partnership within your community.
So, I probably wouldn’t have the friendships that I have now with folks that are at Gitlab or CircleCi, or CloudBees, for that matter without it. So, those are the two things I believe I did right. I worked on that spreadsheet really, really hard. I worked on building getting my name out there, making sure people knew me from a community perspective.
I’d already worked out to get Eclipse Foundation, so I understood how important that was. And when we started DeployHub, I went back into doing a lot of volunteer work for the community that I love. And anybody who’s starting a company, an entrepreneur of any type should do that. You have to give back even if it’s hard.
Advice For Building The Team?
Mike Schwartz: I just looked through my notes, and I realized I missed a question. And I want to make sure I ask this one. In one of your previous interviews I listened to, you talked about recruiting new team members, and how sometimes, you don’t necessarily look for deep technical know-how, you’re looking for a certain type of person. And could you go into that a little bit deeper, like, how do you know who to recruit?
Tracy Ragan: I learned this when I was running OpenMake Software in the early days. You know, we were small, we needed to expand our ability to recruit without having to pay a lot of money, to be quite honest. And one day, I was sitting at a coffee shop – it was like Caribou Coffee shop – and I was watching this guy work, and he was able to do like — I don’t know, he was making four coffees at the same time, running the register, he just was able to do multitask.
So, I started talking to him, and he had graduated from Boston University, and he was a filmmaker, and I asked him, “Have you ever thought about doing anything with technology?” And he said, “Oh, I’ve done some programming.”, and I continued questioning him, and I ended up hiring him about three days later.
He was one of our most valuable employees at the time. He not only could put a story together for us, he really understood how to build a broader picture, and he could code. Had I not been thinking to kind of open up my mind to how to recruit folks, I probably would have never sat there and looked for somebody who was like, “Wow, he’s multitasking really well – I wonder what else he’s talented at?”
The other thing is, there are a lot of older folks that have a lot to bring to the table, may want to change jobs. We hired an individual most recently who had done some testing, and he had done some deployment work. He was older and he had gone to our community college and taken programming. And we brought him on, and he was fabulous, really, really hard-working. I could rely on him for – and I still do – rely on him for anything that I need. But had I been just looking in the normal channels, I probably wouldn’t have found him.
Advice for Women Entrepreneurs
Mike Schwartz: If you look at our podcast, you’ll see that the male to female ratio for our guest is like 50:1, although we’re trying to improve that this year. Given the fewer number of chances I get to talk to them, and I want to ask you one specific question about, do you have any advice specific for women entrepreneurs?
Tracy Ragan: This is hard for women entrepreneurs. You know, 2% of the funding goes to women. 2%. So, I don’t have a lot of advice except reach out to me, reach out to other women entrepreneurs, get involved in women in technology, consider going to some of these women in technology conferences, because we need to build our network.
When I first got into computers, there were a lot of women. And they’re not a lot now, and there’s even fewer at the top. And that is a problem, it’s a very big problem. And I’ve spoken in high schools and encouraged young women to go into the business of STEM, in particular Computer Science. And I reminded all those boys out there that if they don’t encourage their friends, who are female, to get involved, they’re going to have a really boring life because they’re just going to work with men all the time.
So, we really need to build our own network, and I do everything I can to reach down, when I see somebody really talented, to help them in any way. I do have a couple of ladies that I’ve mentored through the process. And that’s what other women, who have already gone through and have some understanding of how to move from step A to step B, we need to help each other. That’s the best thing I can say.
And I’m hoping that there’s going to be more women, who are investors, who want to start reaching out and bringing women up to the top. I know we have to look at, like, LaunchDarkly, she was great at being an example of what a woman entrepreneur can do. She worked her butt off to get funding now. It’s not easy, and it’s just the reality.
Mike Schwartz: Congratulations on all your success. And thank you so much for making a couple of minutes to talk with us today, and best of luck in the future.
Tracy Ragan: Mike, thank you so much. It was a pleasure, and I look forward to hearing it.
Mike Schwartz: Special thanks to the DeployHub team for making Tracy available for the interview.
Editing by Ines Cetenji. Transcription by Marina Andjelkovic. You know all those cool graphics on the website? Special thanks to Kamal Bhattacharjee for making them. He’s done a great job for 45 episodes, so, thanks, Kamal.
Music from Broke For Free, Chris Zabriskie and Lee Rosevere. The podcast Twitter handle is @fosspodcast. Next episode, we talk to Joe Duffy from Pulumy. Stay safe, everyone. Until next time, thanks for listening.