JFrog Ltd. (FROG) Earnings Call Transcript & Summary

Good afternoon, everyone. Thanks for joining us for this next session of our CSI Conference. Next up is JFrog. With us today, Shlomi Ben Haim, Founder and CEO of the company; and Jacob Shulman, CFO; as well as JoAnn Horne on the IR side. Thanks all for joining us.

Thanks, Brad, for having us.

Thank you for having us, Brad.

Shlomi, maybe we'll start with you, given that you're the Founder and the company's a fairly recent IPO, for those uninitiated in the DevOps world, maybe you can help us understand what was the issue that you saw that you wanted to solve with JFrog and what you guys are doing today to solve that problem?

Yes, Brad, what a great opening. But we -- when we founded JFrog back in 2008, actually, we were developers ourselves, that we saw a problem in how you build software and what the world demands. This gap was something that we thought that will be solved by automating your full software delivery, build-to-delivery process. We decided that the way to do it is going after the one asset that's called binary, the software packages. And we built the platform to manage your binary life cycle, all the way from caching it and storing it, to testing it, securing it and distributing it. So today, JFrog is the company that stands behind the hybrid universal DevOps platform to manage your binary life cycle and to make sure that your organization is faster and secure when you release software.

So we hear the word "binary" a lot. I'm by no means an expert. It took me a while to sort of get the courage to ask what a binary is. So maybe you could start with what is a binary and then sort of talk about that whole sort of developer life -- co-development life cycle and where you fit in, in that.

Yes, well, I'm smiling because we hear the same question from the moment we created JFrog. And I'm honored and I can humbly say that we were part of the companies that made the change. But software packages also, known as binaries or artifacts or images, it's all a term that is looking at the asset in the world of software creation to deployment, that you either bring from outside, you either bring software packages from somewhere else, someone else's hub or repository and bring it into your organization or you build it yourself from your own source code. And from that moment, from the moment you created the binary or the software packages, this is what you start to build with, rebuild with, secure, test and promote, all the way to the edge devices. So if you want to think about why binaries became the first-level citizen and the primary asset in the world of DevOps, it's mainly because of the fact that, number one, you can be faster because you use someone else's code. You can automate it. It's 0 and 1. This is the machine language. It's not source code. It's not human language. That's the machine language so you can automate it and it can be faster. But it's also, Brad, the incremental update that you want to deploy on runtime on your deployment environment. So instead of replacing everything, if you can just replace the specific software packages, you are faster than your competitor, and therefore, binaries became a primary asset, the first-level citizen in the world of DevOps and DevSecOps.

So if we were to think about the software development life cycle, everyone knows GitHub, that would be sort of the beginning of the process where you're writing code in your native tongue and in whatever development language you want. And then, at some point, it gets compiled into these 1s and 0s. And that, that collection of 1s and 0s is going to sit in JFrog, and you're going to manage that.

You got it right. GitHub is where the developer will start. Every developer will start with a Git repository, whether with GitHub or another provider, with a CI today to automate the process. But the moment you use CI on top of Git's source code, you create binaries. From that point on, and you know the infinity loop of DevOp, from that point on, it's all about binaries, all the way to runtime.

Got it. Now you mentioned, and I'm going to dive into the weeds here fairly quickly, you mentioned I can write my code or I can bring in code from a third party. Well, in the world we live in today, bringing in code from a third party seems pretty dangerous. So how do you help me keep from getting in trouble?

Well, it is dangerous. And this is almost an impossible dilemma for the developer, right? On one hand, the CIO is pushing you to be faster and to automate the process and to kind of use open source and other libraries that were already written and tested at scale. On the other hand, the CISO is telling you, no, no, no. You cannot do it anymore because you cannot just be fast and dirty, you also have to be secure. So what we have built on top of Artifactory is a product we call Xray. Now Artifactory is your importer. This is the proxy. This is the automated way to go out and bring binaries and host it locally. This is the repository. This is the database of DevOps, a universal solution that supports all field software packages. On top of it, we built Xray, which is a DevSecOps solution that natively sits on your repository and scans all your binaries. Now why this is crucial for the organization because it's not just running a scan and securing your repository in terms of vulnerability, it's opening those binaries for you, shows you the dependencies between them. This is not source code. This is binaries. It's come with all the metadata and integrate with your CI/CD. So even if the developers brought something that Xray deducts, Xray will break the build for you and prevent the organization from being exposed to any kind of vulnerability or open source license compliance to avoid anything that reminds of a SolarWinds.

Got it. So maybe let's take a step back, okay? And maybe you could talk to us about how you go to market. You have a big community out there. You have a free tier. You're very efficient. So how have you achieved all of that?

Brad, we built JFrog with the community. When we started JFrog, it was based on an open source project that Yoav Landman, our CTO and Co-Founder, started just to find a solution and a pain solver for a developer. And then we started to build the commercial and the enterprise solution on top of it. So our commercial solution actually is a set of add-ons that sits on top of this open source foundation that we created more than 12 years ago. On the philosophy that -- on the philosophy level, what we believe is that you should provide developers with the freedom of choice. Therefore, I'm not going to tell you whether you should work so fast in the cloud. I'm actually going to support you wherever you want to work. So one of the things that we provide is a hybrid solution, a real hybrid solution. What you get as self-hosted is also what you get from me as a service. The second thing is universality. We didn't reach out just to the Java developers or Docker users or .NET developers. We actually -- we were named the Switzerland of DevOps because we support almost 30 different technologies in a very in-depth support. So going to all the communities with a hybrid solution, that was step 1. And then the third thing is the integration with your ecosystem. I'm not here to tell you I'm doing everything from A to Z. I'm doing everything that is related to binaries, and therefore, you are coming to me because I'm the binary company. And everything else can be supported by other tools, but I would bring the best native, seamless integration that you can ever think of so you will have a joyful ride when you use the DevOps platform. So they're too integrated to fail, philosophy number one; hybrid solution, number two; and then universality, number three, both the community, to us. And we built the business from the bottom-up, and basically, that's one of the things that make JFrog very efficient.

Maybe you can talk to, and I don't know if it's you or Jacob, but the different SKUs, the different pricing levels. And then, obviously, you have a different pricing model for a self-managed customer versus a SaaS customer.

Yes...

And maybe I'll start, Shlomi, and you will chime in. So we built our subscription based on -- to mirror the customer journey and how the customer journey evolves from the moment they become our users and customers. It all starts with our Artifactory Pro, which is a subscription for Artifactory. Then it's a natural step for our customers to add security on top of that. So they would -- eventually, they would naturally convert it to the Pro X package, which is Artifactory with Xray and support. Then you'll see these 2 packages will typically be adopted by different teams within enterprise. And then when there are several teams already using that, it makes sense for the enterprise to transition to the next level, which is enterprise package, which adds those benefits for the enterprise because benefits for a developer is different from the benefits for enterprise. What's important for developers is ease of use, integration, ease of implementation, full UI, full features. What's important for enterprise is DRP, security, user management, et cetera, et cetera, hybrid, multicloud. So an enterprise package would allow enterprises also to fulfill that need. And then when -- customers we see typically expand with a number of servers throughout the enterprise. And when they standardize on the Artifactory or secure their repository with Xray, then the next natural step for them is to distribute binaries to the edge devices. And that's when they would typically transition to our full platform. And Distribution is the #1 driver for our customers to go to the platform. And our platform consists of 6 products, all products that JFrog has to offer. It's Artifactory, Xray, Distribution, but also automated by Pipeline, which is our CI/CD tool. And on top of that, we have 2 products, Mission Control and Insight, which is basically an administrative console as well as an analytics tool. So this is the same subscription structure for both on-prem and cloud. For on-prem, we charge by number of servers. So we sell -- a customer can expand either by number of servers or by value per server based on the subscription. And in the cloud, we charge by usage, which is measured in terms of data transfer and storage.

The cloud business has been growing very rapidly. But I think, if I remember correctly, you're agnostic to how your customers consume, or maybe said another way, you don't incent your sales force to sell cloud over self-managed. So one, is that correct? And number two, if that is the case, why do you think customers are adopting the cloud product so aggressively?

I can take that. The first thing, the question you asked is very much true. We never pitch to a customer whether they should go on-prem or cloud. And by the way, we are one of those very unique companies that can do that because the product is identical. You mentioned a company before that the cloud solution and on-prem solution is not the same. In JFrog, it's the same, which gives us a great avenue for growth because we can also provide you with a very authentic hybrid solution. And we -- what we see in the market is that every company that starts today or started in the last decade started in the cloud. So it's clear to me that when we look 20 years ahead of us, companies will not maintain their own servers and data centers. They will use compute that will be provided by other vendors like the cloud. So obviously, we see a growth there. When you look at the Global 2000 of today's world, the majority of them are still very much on-prem. So they are transitioning to the cloud. With a hybrid solution coming from JFrog, that's a very, very important factor for them. But it's not just that. All of them are also very much aware of the vendor lock-in that they might get into. And therefore, multicloud is another benefit that JFrog provides. You can work with all 3 clouds, all major clouds. You can work in different regions. And you can have your self process. So the flexibility and the help that we give them to avoid any vendor lock-in is the #1 decision on the management level. Then the developers know how to take it to partners.

Got it. I have a couple of questions that have come in over the console. I'll start with probably the most specific one first. The question sort of relates to one of your, I'll call it, legacy competitors, Nexus, out there, right? What do you do -- what are a handful of things that you feel you do a lot better than they do and why you win?

Well, obviously, I'm biased, but I would say that, in 2008, we founded JFrog. We introduced the world with the first binary repository manager, and a few months after, Nexus came and they built a very nice tool. They supported the Java community. They came from the Maven foundation. And we know the product and the team very well. I think that, in 2012, what happened with Sonatype is that they started to be focused on security, and the repository was a solution that was included but not a primary asset, not the flagship product. JFrog Artifactory is our camelot. This is our bread and butter. We do binaries, we eat binaries, we dream binaries. So it's not a security company that also does a repository. Now if you think about what happened since then, Brad, in 2013, we released the first high-availability solution for a binary repository, and Nexus fell behind. And then when we released the security on top of your binaries, the Distribution on top of binaries, when we acquired 5 different companies, that was all about managing your binary life cycle management. And I think that this is where we built a better product to manage your binary.

And along those same lines, Shlomi, obviously, this is a space that continues to rapidly evolve. When you look at your sort of 6,000-plus customers today, they've probably done something to manage binaries, maybe Excel spreadsheets, to a packaged app. When you win new deals, is it predominantly replacing a homegrown solution or a third-party legacy app?

Yes. Yes, that's a very good question. Actually, this is something that we are monitoring ourselves because when you provide the platform to the world, it starts to be a bit more complicated question. I'll explain. With the repository, it starts to be the standard. We see everywhere in the world that nobody is trying to build their own file server and manage binaries. The amount of binaries that your organization produced today, even if you are just 5 developers, is unbelievable. It's exploding, and you cannot just have your own solution for that. So a binary repository manager, and may I say, Artifactory is a standard, usually replaces other tools or something that -- or a company that adopts now DevOps as methodology in the organization. Regarding our security solution, actually is not trying to be a better security for your Git repository, actually comes with the concept that was not introduced to the world before JFrog. Composition analysis of your binaries is something that we know how to do better because we know what it means to manage metadata, to build an integration with your CI/CD based on dependencies, and not source code vulnerabilities is something that we know how to do better. And therefore, Xray is still the native solution, the best native solution on top of Artifactory, which is your database. When it comes to Distribution, Brad, this is quite new for us. We launched the first version of our Distribution just a year ago. And recently, at swampUP, our user conference, we announced the enhanced solution of Distribution, PDN, for binary. It's the only solution in the world. So obviously, we are replacing the homegrown solution and in-house development. If you build something to push your binaries 20 years ago, you probably used your own team on top of a CDN. And now you can do it end-to-end with JFrog. So with Artifactory, we were the first to replace what you had in the organization. It was homegrown and now it became standard. With Xray, the same thing, and now it became standard. And hopefully, we will see the same success with Distribution.

Got it. Jacob, maybe one for you. Obviously, early in 2Q, you guys put through a price increase. I know it was long contemplated and sort of a priority in your guidance, but maybe you can walk us through what that price increase was all about, who it impacted and how it rolls through the numbers over the next probably few years on renewals.

Yes, absolutely. So it's not just about price increase, it's -- some also subscription changes that we made effective April 1. So first of all, it applies only to on-prem and not to all subscriptions. It does not apply to our cloud. It does not apply to on-prem Enterprise+ subscription. For enterprise subscription, prior to the change, we had Xray as optional. So about half of the customers decided to go with Xray from the get-go, and the other half decided to go without Xray. Given the innovation that we injected into Xray and the importance of it, recently, given the SolarWinds hack and others, the raise of DevSecOps, we made the decision to make Xray a mandatory part of the subscription. So customers who had Xray from the get-go, no change for them as well. Those who did not have Xray, they will get Xray when they renew the contract and will pay a higher price. So for enterprise, it's really just a subscription change. We did increase price for our Pro X subscription, from $1,400 -- $14,400 to roughly $19,000, about a 40% increase. And we did increase the price in our Pro subscription, from $2,950 to $3,200. The reason for the price changes, first of all, we don't have methodology of annual price increases. We constantly evaluate the value that we provide to our customers, the competitive dynamics and the price that we charge, and we want to align those. Last time we've made changes to our Pro subscription was about 5 years ago. So 8% increase in 5 years is really -- it's not an issue at all for our customers. We increased price for Pro X subscription at a higher level because of the significant innovation that we added to the Xray subscription and also the importance of DevSecOps and also to align and streamline the upsell notion between our subscriptions. So overall, the change is valued to slightly less than 40% of the business. And if we take weighted averages of the changes that we made, we expect, in the long term, that to contribute about 10% to our revenues. Given the fact that some of our customers renewed their agreements early, we started this process back in Q4. So in Q1, in advance of this change, customers had an opportunity to renew their contracts. And about 40% of our bookings in Q1 related to those early renewals. Definitely made more sense for those customers who are scheduled to renew in Q2 to pull it in into Q1 and then Q3, less -- to the lesser extent, even lesser extent to Q4. So we'll see this change rolling into P&L gradually, with acceleration more towards the end of the year. But it will not become effective for those who renewed in Q1 until Q1 2022 and if they entered in the multiyear agreement even Q1 2023. So that's why we expect this gradual impact on P&L. As I said, 10% in the longer term, low to mid-single digits in 2021.

Got it. That's a great, complete answer. I think that clears up a lot of the confusion that was out there. Shlomi, maybe back to you. Obviously, 2020 COVID year impacted new customer acquisition to some extent. Maybe tell us where you are in that process on the reacceleration. I know you were pretty optimistic about it on the last earnings call. What you're seeing out there from a pull perspective versus a push perspective on your side?

Yes. Well, first of all, Brad, we're back to business in Israel. Our team is back to the office. Next week, we are celebrating our reunion in Sunnyvale, with all the American team back to the office, still green tier. For us, green tiers mean more than just COVID, it's green. So we are very excited. But the community is not yet back. And we don't yet see the conferences and the engagement that we used to have with the developers. Remember, we built the business from the bottom up. This relationship with the community, with the developers, with the user, is extremely important. Even this conference, we are now having it virtually. So we expect H2 to be better. We see ourselves providing more innovation, changing a lot of what the organization used to practice when they say DevOps. But we know that it will take time. What's happening now in JFrog is that we are paving the way, we are building the highway and driving it at the same time. And we did it 3 times. We did it with Artifactory, then we did it with Xray, now we are doing it with Distribution. And I know that we create a world of liquid software for continuous software updates. We see increasing number of developers using our free tier in the cloud. We see the demand coming from the market. We see the numbers, and this keeps me optimistic. But we are still -- we are not yet on the show -- kind of on a safe show telling you that the pandemic is behind us, not yet.

And on the cloud side, are there things that you think you can do to further accelerate adoption there? We've seen it with other DevOps companies with the cloud tier, see healthy acceleration there, while the self-managed business takes a little longer to catch up.

Yes. So the free tier is something that we introduced to the world in Q3 of the previous year. It's always getting optimized. Every quarter, we add more features, and we have a better onboarding experience. We are adding more and more free solutions to the -- this entry point. But you also have to understand where it lands in the life cycle of the developer. It comes -- usually, when the developers start to manage binaries, need to manage releases, need to automate it, need to secure it, and therefore, we have patience until this evolves with the organization. It's not a simple developer tool. It's an infrastructure that facilitate the DevOps in your organization. So obviously, that's an amazing entry point. Thousands of users, as I said, are joining us every quarter. And we start to see the conversion growing. So the free tier is promising. It's multicloud. It's providing you with a solution that covers the old platform. But still, we see demand on the self-hosted in parallel. We will build it as we go and as we add more innovation into it.

Got it. And maybe wrapping up here, the last couple of questions or 1 or 2. Earlier in the conversation, Shlomi, you talked about, I think, doing 6 acquisitions over the life of the company. I'm not going to ask you what you're going to buy next or what the focus is. But maybe more broadly, what are the guardrails insomuch as we won't do this, but we want to do that?

Well, you can ask me, I will not answer, but I will tell you one thing. When we thought about JFrog going public last year, we had a very clear goal in mind. We are very focused. You know us. You see us in action. 12 years, we are doing what we are saying. There is no waiting with the hands and then doing something else. One thing that we have realized is that JFrog can be the company behind all the software updates in the world because we are managing the binaries. We are managing this asset that you want to update on your iPhone or your [ laptop ]. And we also acknowledge the fact that we are left. When people are saying shift left, we are left. And now, we have to build the boulders that you need to have as you shift right as you go to the device. A world of liquid software and JFrog as the liquid software company requires a continuous software update. It means that you will see us focusing on SecOps to make sure that you are not just securing your DevOps infinity loop, but going all the way to the embedded software and making sure that what the developer created can be deployed securely. And the second thing that you will see us looking at is more capabilities to the Distribution, to the delivery process, continuous delivery and continuous updates.

Excellent. Well, we're just about out of time. This has been a wonderful 30 minutes. I really appreciate you all making the effort for us.

Thank you, Brad.

Thank you very much, and you're welcome to the swamp starting next week. Take care, Brad.

See you soon.

Bye-bye.

Thank you. Bye-bye.