Recently, there has been much discussion about the need to serve gems in a private network. This need arose not only from the security problems experienced by RubyGems.org but also due to the fact that some gems aren’t hosted on RubyGems.org such as Vagrant, which no longer supports RubyGems, or gems that are not open source or not public and that may nevertheless be shared as gems rather than sources.
Source control tools may be a relevant alternative in some cases, but clearly not in all cases and not for all purposes since gems are binaries and not sources. There are several strong reasons why Version Control Systems are not always relevant for binaries:
Version Control Systems (VCS) are not gem repositories. They do not calculate indexes on the server, they do not support dynamic REST API (such as the dependency resolution API used by Bundler, which offers faster resolution).
Versioning mismatch issues may occur due to the fact that binaries are usually versioned by their name which sources are versioned by content (and VCSs differentiate them according to changes).
Some VCSs (for example, Subversion) cannot obliterate files, meaning that any uploaded file stays in the repository. One of the reasons this may prove a problem for binary files is their large size (relatively to the source files with which the VCSs are supposed to work).
The search options of VCSs are relevant for sources, not binaries. For example, VCSs search by content and not by what is relevant for binaries: file metadata, location, structure of file name and (in case of an archived artifact) the contents of the archive.
Versioning sources use a permissions scheme not fit for binaries. For example, permission to override - overriding sources is common practice yet overriding released binaries is to be avoided.
Size management issues may arise when using distributed VCSs with large binary files. Distributed VCSs bring the entire history when creating a local clone, a practice not relevant for any large file.
The need for a dedicated RubyGems server is not fulfilled by Gem in a Box (a Sinatra-based gems server) since it has no built-in authentication, no authorization, no repositories separation and no other servers (for example, RubyGems.org) proxy. It is also not fulfilled by GemFury (a subscription-based, cloud-hosted gems server) which provides a private repository protected by an obscure URL and has no proxy for RubyGems.org (or any other repo), no authenticaion model for collaborators and no virtual aggregation of repositories in case you have more than one.
While it is true that Ruby is more often about source (usually open source), it is also true that the Ruby community can borrow a page from the Java Enterprise book - the proper binary repository.
Artifactory , with RubyGems support, is the fulfillment of the need for it has the relevant features which include (among others) a proxy for remote RubyGems repositories (including, obviously, RubyGems.org and also any instance of GemFury, Gem in a Box and other such remote repositories). Additionally, Artifactory serves as a deployment target for your gems - whatever you do not want to put on RubyGems.org (for whatever reason) and that is not offered by other local repositories.
Furthermore, Artifactory offers the following features:
Virtual repositories to aggregate any number of remote, local and virtual repositories under a single URL.
Authentication and authorization schemes which allow controlling permissions on repositories per user and/or per group, including integration with external authorization services.
Searching and browsing for hosted and remote gems.
REST API with Info, Search, Dependencies List and Yank commands.
A powerful user plugin framework.