Though Artifactory is currently still listed as being OSS on their site ( https://jfrog.com/open-source/ ) they stopped publishing the source code after the 7.0 release of Artifactory (somewhere beginning this year). I guess this could be the reason. Having an OSS product is not something investors get thrilled about...
Rightly so, considering the next step for a lot of such OSS projects is AWS offering it as paid hosted service with zero benefit to the maintainers. So then they have to couple it with a restrictive license which devalues the "open" part.
ElasticSearch or Redis seem like a good example of the challenges with that approach. Managing contracts is tedious and there's a substantial convenience factor for the difference between “click and it's running on your existing bill” and “go somewhere else, get setup with a license, take over O&M for your own servers”.
If it's really critical, you'll do that but a company has to be really dependent on a piece of software (or unusually cognizant of the open source maintainership problem) to go the second route. Built-in defaults carry a lot of weight.
Partially - the AWS Marketplace can avoid a procurement (which can be huge) but then you’re running EC2 servers. The popularity of services like RDS suggests there’s a good percentage of the market which will choose managed options, which is great for them but doesn’t help the upstream developers unless a cloud provider supports that development.
I think the real problem is that in a lot of companies, there’s a huge institutional inertia towards adding a new supplier vs. paying an existing supplier slightly more.
I guess I've not worked in big enough corporates to use this.
Can any user here provide some context what JFrog does? The website doesn't really say much, the example pipeline files for JFrog pipelines seem more complex than GitLab CI.
For me JFrog is synonymous with Artifactory -- I think that was their earliest / bread & butter product? That may just be my interaction. It's an on-premise/cloud hybrid source artifact repository. The nice thing about it is that it is one product that can act as a maven/npm/pip/etc. repo. If you're in a polyglot org (big enterprise) and you have security needs/historical baggage to host on-premise (big enterprise) then you can do a lot worse picking a solution. Also has nice API & CLI components for integration, it is far from my least favorite of the enterprise-y sorts of things you can run into at a big company :)
A library. If you're familiar with pip or npm or the like, you've probably used public repositories. npmjs.org hosts all the free and open source node libraries. But a big org might have a loads of closed and proprietary libraries they need to share and version among multiple development teams or partners. A product like artefactory hosts those kind of libraries for multiple languages and is compatible with the popular package managers.
It's also like a local cache of public repos. That means faster builds, some level of quality control (ie black or white list of safe libraries) as well as protection against things like the leftpad fiasco or 2016.
I would define it as a file that is distributed for use among many decoupled hosts and which is generated from some sort of source input.
Packages/libraries such as those used by NPM and Pip are some examples. It may also be an entire program, an OS package, a virtual machine, a Docker image, even things like PNG images.
Artifactory has tooling to make it easy to integrate into typical build pipelines.
I think the big part that everyoen missed, is that other than artifact storage (artifacts are usually what your code becomes, like the usable end product, and also stores info to reproduce and audit, etc etc) is that JFrog is also putting lots of efforts into full fledged software distribution pipelines, which is what these big enterprises need.
There is also the whole DevSecOps sections of their product, and though OSS is not as big, they are giving out plenty back to the community by hosting ChartCenter (Helm), GoCenter (Go-lang), JCenter (Java), and Conan (C/C++)
Artifactory is a strong tool. I work for a large multinational with somewhat regressive IT policies, so you can't really use the internet - Artifactory is both a package cache and package manager, working across pretty much every language. I have used PyPi, JS, Java, & Docker artifacts contained in it, so that's pretty cool
The company I work for uses it for the same reasons as yours. We also have to use it to cache things like NPM and RPM packages. Without that caching, we would be putting a strain on public mirrors. We additionally have a layer of security because we have a system for approving which packages and package versions go into our cache.
They also have an XRay offering for scanning things like Docker containers for vulnerabilities, although for various reasons we do not use it. I wish we did! It would keep things integrated.
The main reason why we use Artifactory, though, is because it allows us to share artifacts across different regions and environments.
The one thing I don't like is how stingy jfrog is with their licenses. It makes automatic deployments of Artifactory a bit difficult for us. Their Mission Control offering isn't enough for the way we deploy Artifactory.
def more known for Artifactory (and community spin-offs like Conan and JFrog Container Registry), but CI/CD has become the core growth as the artifact storage is pretty robust at this point
For those of you looking for an open source alternative to the otherwise fantastic Artifactory product, have a look at Pulp, a Red Hat project that has been rapidly maturing and gaining features over the past two years: https://pulpproject.org/
Three S-1's in one day, and the AirBNB prep last week. Is there just light shining, or are these companies worried about the future prospects of the IPO market?
In addition to what others have said, I think Amazon's Elastic Container Registry is a huge threat to JFrog's prospects. Perhaps they need to IPO now to gain access to the deep pools of capital they'll require to face down the threat from Amazon. Or maybe this is one of those IPOs like SendGrid that is fairly quickly followed by an acquisition.
The people and places i know of see them are complementary. If you’re installing a custom rpm in your docker image, you store the rpm in artifactory and the final image in ecr. The pricing on bandwidth was crazy to use it as a docker repo last I looked, which was a while ago. There’s a ton of value in hosting all the private repo types.
Both ECR and CodeArtifact are competition from AWS. If you're already using AWS it's difficult to justify the switch to Artifactory, considering you also lose integrations with things like instance roles when you switch.
The IPO market was already being prepped but got delayed due to COVID. Since then much of tech stocks not only rebound but are at all time highs. Wall st is seething wanting to buy more stocks that they know can pop and those that have popped are arguably overvalued. (see Zoom)
You don’t want to be without a chair when the music stops. The evidence points to now being an ideal time to get public market liquidity at a high valuation. Even bankrupt companies (Hertz) saw...exuberance from investors.
Has anyone else had nothing but trouble with Artifactory? We are furiously migrating away from it to Github packages for our internal NPM repository. Their uptime has been abysmal.
Artifactory provides NuGet feeds. We even get the public packages (https://nuget.org/) from an Artifactory feed. (Our build servers don't have internet access.)
NuGet is "one" of the packages that Artifactory can host (in addition to NPM, RPM, Python, etc etc etc)
You can also have unlimited private repos, and unlimited cache repositories for proxying public repos
"Our business and operations have experienced rapid growth, and if we do not appropriately manage future growth, if any, or are unable to improve our systems, processes and controls, our business, financial condition, results of operations, and prospects will be adversely affected."
"Our recent rapid growth may not be indicative of our future growth, and we may not be able to sustain our revenue growth rate in the future. Our rapid growth also makes it difficult to evaluate our future prospects and may increase the risk that we will not be successful."
"We have a history of losses and may not be able to achieve profitability on a consistent basis. If we cannot achieve profitability, our business, financial condition, and results of operations may suffer."
"The markets for our products are new, unproven, and evolving and may develop more slowly or differently than we expect. Our future success depends on the growth and expansion of these markets and our ability to adapt and respond effectively to evolving markets."
"Our results of operations are likely to fluctuate from quarter to quarter, which could adversely affect the trading price of our ordinary shares."
"If we are not able to keep pace with technological and competitive developments or fail to integrate our products with a variety of technologies that are developed by others, our products may become less marketable, less competitive, or obsolete, and our results of operations may be adversely affected."
"A limited-functionality version of JFrog Artifactory is licensed under an open source license, which could negatively affect our ability to monetize our products and protect our intellectual property rights."
"The market for our products is nascent and highly fragmented, and we may not be able to compete successfully against current and future competitors, some of whom have greater financial, technical, and other resources than we do. If we do not compete successfully our business, financial condition, and results of operations could be harmed."
"JFrog Artifactory is at the core of our business and any decline in demand for JFrog Artifactory occasioned by malfunction, inferior performance, increased competition or otherwise, will impact our business, results of operations and financial condition."
"If we are unable to increase sales of our subscriptions to new customers, sell additional subscriptions to our existing customers, or expand the value of our existing customers’ subscriptions, our future revenue and results of operations will be harmed."
this is very standard language. the goal with this section is just to cover your tracks so no investor can sue you for omitting something, regardless of the likelihood any of these risks ever come true.
With Helm, there is no need for Artifactory. You get Harbor, Verdaccio, etc. It is silly to pay a company 100k+ when all this stuff is easily managed using official or far more powerful tools.
That's not necessarily true. Helm is a way to install things, it is not a replacement for an artifact store. Binaries are still required. Besides, not everything can be containerized. In the finance industry that I work in, we do push k8s a lot, but regardless, there are still many things that simply cannot just be pushed to containers without serious re-writes. Artifactory is a lifesaver for us, especially when it comes to handling proxy servers for library repos (npm, nuget, rubygems, etc).
Can I upload my Maven binaries to Helm? Does Helm store them? If I have a jar or war, can Helm store them? Does Helm resolve Maven dependencies if I connect to it and run mvn clean install locally?
I know some HashiCorp customers who are actively maintaining their own wheels (built on top of Consul, no less) that duplicate HashiCorp functionality, badly. I don't know if I will ever understand why people work so hard to accomplish so little.
"To err is human. To really foul things up requires a computer."
Helm has a much narrower use case. Artifactory can host a wide range of artifacts. For example Artifactory can host and proxy maven, NPM and similar programming language library repositories.
Nothing I see allows Helm to "do Maven". They have a Maven plugin that allows Maven to package Helm charts.
But that's assuming you use Kubernetes.
Helm is not a replacement for Artifactory, I don't know what you're going on about. They have a bit of overlap but the main use case of Artifactory is as a binary artifact repository for any environment, including non-Kubernetes ones. And there are a lot of non-Kubernetes environments out there. I'd argue that Kubernetes environments are a drop in the ocean compared to everything else.
Usually JFrog is pretty responsive on StackOverflow though for this particular question they seem a bit evasive ( https://stackoverflow.com/questions/43481238/where-is-the-ar... ).