JFrog provides a bunch of products and services around DevOps, i.e. taking your software and deploying it to the world. Their most popular lines deal with package and dependency management.
- Software is mostly developed locally (on a personal computer), and then later deployed remotely to a group of powerful servers to run in “production”
- The process of deploying that software - especially as teams use more and more open source packages - can get pretty complex
- JFrog provides products that take your local software and get it ready for deployment, manage those packages, scan for security vulnerabilities, and other nice things
Adoption is comically high, with literally 82% [1] From JFrog's most recent 10-K filing: As of December 31, 2024, we had a global customer base of approximately 7,300 organizations across all industries and sizes, including approximately 82% of Fortune 100 organizations. of the Fortune 100 as customers (seems suspicious tbh). JFrog IPOd in 2020, and in 2024 they generated $428.5 million in revenue, growing 22% year-over-year [2] From JFrog's most recent 10-K filing: We generated revenue of $428.5 million and $349.9 million for the years ended December 31, 2024 and 2023, respectively, representing year-over-year growth rate of 22%.. So they're definitely on to something.
Refresher: deploying software and packages#
Why does JFrog exist, and what problems do they solve? The key is to understand the “DevOps” buzzword, which is what I’m here for. Quoting from the What’s DevOps post:
To understand why DevOps as a concept has gotten really popular recently, you need to understand software delivery and how that’s changed over time. → What it means to deliver softwareWhen a team of engineers builds an application, it’s just a bunch of code. And that code needs to run somewhere for users to access it and get value out of it. During development, developers tend to run that code on their personal computers, but that’s obviously not scalable - so when they’re ready to share the software with the world, they’ll put that code on big powerful servers, and let people access it via a domain name like https://technically.dev. So in general, delivering software means taking the application you’ve built and figuring out how to distribute it widely to whoever wants to use it.→ How things have changed, a lotJust 10-15 short years ago, a lot of delivering software meant literally delivering software - Microsoft Office used to ship to you on a CD that you’d install directly to your computer. And it wasn’t web-based, so you didn’t need internet access to use Excel or Powerpoint. The public cloud (AWS and co.) didn’t exist, so if you needed to run software on a server or two, you’d need to literally build that infrastructure yourself, which used to cost millions of dollars up front. So naturally, software delivery was bespoke and on the slower side.But then people started consuming software via the internet, and public clouds like AWS made it cheap and easy to use a server without having to build a data center. That fundamentally changed 3 things:The scale of software increased - software is generally used by a lot more people than in the past. You could realistically need to support millions of users for your applicationInfrastructure got more complicated - we’re moving towards increasingly specialized managed infrastructure for different parts of the stack. Generally, you don’t just throw your code onto a box and forget about it anymoreTeams started releasing a lot more often - changes in philosophy mean teams are now shipping code changes to users as often as multiple times a day, which means many many more opportunities to break thingsWith these fundamental shifts happening, teams needed to start building processes for managing this stuff, and making sure their apps didn’t constantly break and disappoint their users. And that’s basically what DevOps is - making sure your app works at scale.
There’s one more thing you’ll need to know to understand JFrog - packages. Today, pretty much all software you use is built on top of existing “packages” of code written by other people, most of which are open source. A few popular examples:
- React, a library for building interactive user interfaces
- Passport, a library for building authentication into Node.js apps
- Tensorflow, a library for building machine learning models
If (more like when) you’re using packages like these in your applications, they save you a lot of time and headache - but they also add complexity:
- Versioning - the folks working on React are constantly updating and improving it. Which version did you build your software with? Will newer versions of React break your software? How do you deal with upgrades?
- Packaging - how do you include the underlying code for React in your application itself? Do you pull it from the web, or store it on your own servers?
- Security - are the packages you’re using secure? If vulnerabilities are discovered, how do you patch them?
You’ll also see these packages referred to as dependencies, because your software is dependent on them to run.