Hi Bob,
I haven’t looked at the metrics for JFrog, but I know the company and the product. JFrog fails to excite me as an investment for the same reason Slack failed to excite me; basically, “it’s nothing special”.
JFrog is a piece of software referred to as an “artifact repository”. And “artifact” in software development is the final package of a bundle of software resulting from a “build process”. If you’re on Windows, .msi files are packages, on Mac it’s .dmg, on Linux, the two most popular are .rpm and .deb. There are lots and lots of different types of artifacts, and really, anything you want can be an artifact.
The point of an artifact repository is to centralize the storage of different types of artifacts for easy (and automated) retrieval for other build processes. For example, take your smart phone. You want to install a new app. The App Store, or Google whatever-it-is, is an artifact repository filled with all sorts of finished apps to install. But these finished apps may in turn depend on other packages as well. So the build process for the app itself points at an artifact repo to retrieve other packages which then get built into the app.
JFrog as merely taken different, already existing, package repository software and simply bundled it into one convenient, and centralized location for its customers. And they’ve added some nice features to it, added on other things they think their customers might want, and then added things “just because” everyone else has it too.
The problem with all this is, there’s nothing special about what JFrog has done. Sure, they’ve taken some of the work out of setting up a artifact repo. But fundamentally, an artifact repo is nothing more than a website. It’s literally just a place to store “stuff” that can be retrieved via HTTP, the standard web protocol. Sure, different repositories have different file system layouts, and some have built their own protocols on top of HTTP for searching and retrieval. But there’s nothing complicated in the technology of setting up the repo. In fact, every one of the repo types that JFrog provides is an open source repository to begin with. And every single one of them comes with decent directions on how to install them, set them up, and use them. And setting them all up in one place, is not difficult nor even time consuming.
What JFrog has done is merely put a nice front-end UI on them and added some extra “features” like their own CI/CD pipelines. Their biggest “feature” though, is simply being “on the internet” in a place where anyone can reach them from anywhere. This is especially important when building things in and for the cloud, like SaaS software. The second big “feature” is that JFrog just does all the repo installation/configuration for you, and has some minor features to help you progress packages through different lifecycle phases.
However, if I’m building SaaS based software, say in AWS, I can simply use an S3 bucket as my artifact repo. I configure all my build processes to spit out their artifacts to a particular bucket, maybe a specific folder in that bucket, and voila. Now I can reach that repository from anywhere in AWS via HTTP if I want to, or just grab it using AWS specific methods (AWS, Google, Azure, etc, all have APIs for programmatically accessing things within their clouds).
Every company and every software development group figures out how to do things for their processes. And what JFrog has done is essentially built a workflow that worked for them, and then sold it to their customers on the assumption that the workflow is universal enough. But (and this is my own opinion) I find their process and documentation clunky and non-specific. It was nice that my company had this service, but honestly, I find it a pain to use and figure out. It could be that I just haven’t dug into their docs enough, but my feeling is, I’ve set repos up lots of times in my career with inadequate documentation and it wasn’t hard. Therefore, if I’m paying for a service, their docs ought to be waaay easier to understand.
But I digress. All this is to say, like Slack, I don’t see that JFrog has any kind of moat. The barrier to entry is extremely low. Literally anyone can create one using S3 buckets. And, a significant number of companies do exactly that! It’s cheap, it’s readily available, and imposes no restrictions or learning curves on your team. Whereas to use JFrog, you need to first figure out what exactly they’ve done to repos, then figure out how to use them, and pay for it.
Slack is no different IMO. It’s a chat app based around IRC. Literally anyone can do what they’ve done (except apparently Microsoft…). Slack and JFrog have no real moats in my opinion, though Slack at least has mindshare across all of high tech to the point where CEOs, Sales & Marketing, and HR teams all use it. JFrog on the other hand, has a TAM limited to software development groups, who tend to be really picky about their tools, and often times, just want to do things their own way and not bother with a packaged “solution”.
Anyway, that’s my non-financial analysis of JFrog, based on almost 30 years of industry experience supporting software engineering groups with these types of tools and solutions.
–
Paul