JFROG -- a few quick thoughts

In the “last bus” thread, BrokeStocker (LOVE the handle!) found the topic reminiscent of JFROG. I’m a bit behind in my Bert reading, and I recently read his December 3, 2020 article on JFROG. Seeing how the stock price had declined, I got excited and thought that now might be the ideal time to bring JFROG back to this board. After taking a look at fourth quarter and full year results, I decided against it. Gross margins would be to this board’s satisfaction. Revenue growth – at over 30% but under 40% – makes this a second-tier offering. Probably worth watching for signs of improvement, but it ain’t going to supplant many board participants’ lowest conviction holding. I feel the same way about VEEV and GH; great companies and great stocks, but second-tier from this board’s perspective. Spoiled rotten, and glad to be adding those tools to my perspective!

Fool on!
Thanks and best wishes,
TMFDatabaseBob (long: GH, VEEV)
See my holdings here: http://my.fool.com/profile/TMFDatabasebob/info.aspx
Peace on Earth

Please note: I am not a member of any newsletter team. My opinions are my own and do not necessarily reflect those of the TMF advisers. I am not an investment professional, merely an investor.


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.



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

Thanks Paul, It’s always really useful to get a view from the field, from people actually working with those things, for us non-techies. We all appreciate it. I decided against JFrog because it was a tool for developers to use to make their work easier in some cases, as I understood it, which gave it a limited market compared to something like Snowflake, whose market is data which grows exponentially forever. Also because it was growing lots slower than our best choices.





You’re exactly right. The biggest problem with “tools for developers” is that developers are a really finicky bunch, and you will never get “all developers” or even “most developers” to agree on any given tool. On top of that, tools for developers are themselves developed by developers. Which means all it takes to unseat the latest greatest “tool for developers” is a few other people as smart or smarter than the previous ones to think up something better. Software developers develop software tools all the time, it’s literally their job to do so.

There’s no moat there. Slack isn’t much better. They started out as a “tool for developers” as a marketing tactic, but all along their strategy was capture the hearts and minds of entire companies through the developers. As a result, they’ve done quite well and have somewhat of a moat. But still not strong enough for me to invest in them.

I felt the same way about Zoom initially. “It’s just another video conferencing app!”. But they built themselves a moat by just hammering on ease-of-use, flexibility, and integrations. Slack is trying to do that too. Zoom did it better and faster and executed much better at the outset of the pandemic. Slack should have capitalized on that similarly to Zoom, but failed to do so for some reason. Possibly because “chat apps” are a dime-a-dozen and most will suffice in a pinch without costing too much. Video apps became much more of a necessity, and the smaller, faster, easier-to-use Zoom outpaced even their toughest more established competition.



Good discussion. My thoughts, coming from the software industry. In the enterprise market, one has to have good product and excellent distribution. Slack had an really good product but a subpar distribution. It lost the plot to Microsoft, which had on OK product (Microsoft Teams) but excellent distribution. This is why Slack sold itself to Salesforce to tap into their distribution prowess. It might be too late for them compared to Microsoft’s juggernaut.

JFrog, it solves a very small problem (if at all) that some other technology will solve much better and free. I do know JFrog Artifactory is being used by big companies in Silicon Valley. But, don’t see a moat here.


Thank you for your insights from the field Paul.

However, when I hear people so easily dismiss significant revenue-generating products that have created multi-billion dollar companies as something that “anyone can do”, I naturally have to question the thoroughness of the assessment. There must be something valuable about a product when customers are buying it at increasingly high rates.

Slack is a $25B company with almost $1B in revenue that was recently acquired by one of the leading companies in the world (Salesforce), which is led by one of the most effective/visionary CEOs in any industry (Marc Benioff). If, as you say, “literally anyone can do what they’ve done”, then why would Salesforce even bother acquiring Slack? They certainly have the resources and software expertise to build their own “chat app based around IRC.” There must be something that you are missing about the usefulness of their product, no?

Similarly, there has to be more to JFrog than meets the eye. Admittedly, I am not a software developer and do not have the expertise to speak about their product. So, as with any company, I had to see what people more knowledgeable than me have said about JFrog. Luckily, I immediately found a deep dive article by one of my favorite tech writers, Bert Hochfeld, that seems to counter your claim that JFrog offers a generic product and has no moat. (https://seekingalpha.com/article/4392778-jfrog-small-company…)

I’d encourage everyone to read the whole article, but here are some of the more relevant quotes about JFrog for this discussion:

– Frog has essentially created a category called “liquid software” and indeed it’s founders have written that book… literally.

– The concept of liquid software is to automate the release process of software and eliminate numbered versions within a standard and trusted security paradigm. The entire process is automated and the technology authenticates and validates the software as it is released and flows through the pipes on a continuous basis.

– As might be imagined, there are many artifact repositories these days. That is not where JFrog’s differentiation lies. Simply put, the differentiation involves using an artifact repository to implement a liquid software paradigm. For this company, its unique selling principle is to be able to develop and enhance software without software versions and with software updated seamlessly and securely without the hassle of update processes and downtime. The company calls this a continuous software release management (CSRM) and that is what the business is all about.

– The company offers multiple products in order to provide users an end to end platform. Other than Artifactory, the company offers several other significant SKU’s which include XRAY, Distribution, Edge, Insight, Pipelines, Mission Control and Access.

– One key to Frog’s differentiation is that developers can use more than 20 types of packages and it is this choice that has proven to be a substantial competitive advantage for the company.

– JFrog appears to be on the right side of many of the hot trends in the DevOps space, and it is run by a team whose antecedents and resumes suggest that this will continue to be the case for the foreseeable future.

– For readers trying to make a decision on acquiring the shares for their portfolios, my belief is that the company has created a wide and deep competitive moat and I believe that the management of this company is likely to ensure that the technologies offered by the company will be those that developers find the most useful in automating and standardizing the completion of their projects.

Regarding TAM (which I think speaks to the need/potential for their products)…

– The JFrog S-1 had two measures for TAM. One of those from IDC is for a space of $18 billion; the other estimate compiled by the company and based on average spend/size comes to $22 billion.

What do you think? I’d be interested to hear your feedback on Bert’s deep dive. Again, I am not a developer and do not use JFrog so I am basing my understanding of this company solely on what I have read online (including the positive user reviews of the product). Also, full disclosure, I do not own shares in Slack, Salesforce, or JFrog (though after reading the article I plan to start doing more due diligence on JFrog). I bring up these points because it felt like we were only hearing one side of the story and I think we should always try to consider the other side of a thesis, whether bullish or bearish, in order to make better investment decisions.

  • Ceez

The concept of liquid software is to automate the release process of software and eliminate numbered versions within a standard and trusted security paradigm.

Just to illustrate that what seems new often isn’t, I was doing continuous update of my ERP package in 1990.

1 Like


How does the JFrog offering reduce manual decision making and inputs in favor of a system selected refresh?

If versioning and revision is now automatic, optimized and opportunistic, what advantage does the user gain (other than people being freed up to do something more productive with their time/attention?)

Apologies if this question is out of your area of familiarity with JFrog.

GDavenport, I can’t speak to how JFrog works … I was merely pointing out that continuous releases themselves are not a new concept. My presumption is that JFrog makes it considerably simpler than when I was doing many years ago, when I had nothing but my own tools to assist the process. I will say, however, that I believe even the crude system I had was net less work and disruption than traditional numbered releases because the change was minor in each piece.

1 Like