“In information systems design and theory, single source of truth (SSOT), is the practice of structuring information models and associated data
schema such that every data element is stored exactly once. Any possible linkages to this data element (possibly in other areas of the relational schema or
even in distant federated databases) are by reference only. Because all other locations of the data just refer back to the primary “source of truth” location,
updates to the data element in the primary location propagate to the entire system without the possibility of a duplicate value somewhere being forgotten.” (from Wikipedia)

Why did we find SSOT appealing regarding our code base?

Virtual Minds is an association of technology companies that develop online marketing products. A multitude of technologies are used in each individual company.
Like every other modern, tech savvy company we build applications by combining the features of open source components with our own custom components
to create applications for a specific use case. Components can be packages, libraries, binaries, containers, done on our own or with open source. They can be written in Java,
Javascript, PHP or in a dozen of other programming languages. The component-based software development and the availabilty of millions of available helper libraries
helps us to speed up our development process.

When having different teams or even different companies with their teams working on similar things, there might be an increased chance to run into some ineffectiveness
like building up a fragmented tech environment, creating duplicate code, downloading and managing the same components in different versions or solving problems which
are already solved elsewhere.

So we asked ourselves: How could we improve organizing our development processes?

• Can we create synergies or collaborate better?
• Do we really do duplicate work, in different teams and also across partner companies?
• Can we save time in development and release management?
• Could we save bandwidth from downloading and updating the same components again and again?
• Can we decrease our dependencies from remote repositories? What happens when a component is removed, or the repository is down?

And in regards of all this we asked us finally: Will we benefit from one large independent, central repository? Do we need a repository manager?

Since the quick answer was YES, we wanted to go into more detail. So we created a quick overview of our technical landscape.

• Which programming languages are used by each team across our partner companies?
• What package formats are used across every team and organization?
• What languages and package types do we probably want to add later?
• What’s the number of applications per team?

We found out that we used more different development technologies than we were aware of. We use packages like jar, apt, apk, npm, docker and programming languages like
php, java, javascript, c++ to name a few. We also use half a dozen of repositories like maven central and npmJS as well. We even found out that we use
different components to solve the same problem.

That made us think…Hm, it might be a good idea to start using a repository manager, let’s check out Nexus…

So we did, and learned more about what a repositiory manager in general and Nexus in particular does.

It’s like a warehouse for parts, for software parts, a warehouse the software development world calls repository manager. A repository manager is a dedicated server application
used to manage all the repositories the development teams across companies use throughout the course of development. At its core, a repository manager does the following:

• Centralizes all needed software parts on one server
• Proxies remote repositories and caches contents
• Hosts internal repositories
• Groups repositories into a single repository

How do we benefit from using Nexus?

• We enable and gain a greater collaboration focus between developers.
• We got an increased build performance setup, due to a wider distribution of software and locally available parts.
• We reduce network bandwidth and dependency on remote repositories.
• We insulate our companies from outages in the internet, outages of public repositories (Maven Central, npm, etc.), or even removal of an open source components.
• We avoid or lower our technical debt and unplanned work.

The possibility to completely control access to, and deployment of, every component in our organization from a single location is another benefit of a repository manager.
It allows us to control what gets into our products from remote sources as well as examine, and keep track of, what is produced by our build systems.
A repository manager also allows us to secure a connection to remote repositories, ensuring that usage is not publicly exposed.

More technical benefits:

• Manage binary software code through the software development life cycle.
• Search and browse software components.
• Control code releases with rules and add automated notifications.
• Integrate with external security systems, such as LDAP or Atlassian Crowd.
• View component metadata.
• Host internal items not available in remote repositories.
• Control access by authenticating and authorizing specific sets or groups of users.