A developer’s survival guide to catalogs

If you are a developer at an organization or on a team that recently started using the Tidelift Subscription and an open source catalog, then this article is for you. The Tidelift Subscription exists so that you no longer have to deal with issues related to open source. That said we also recognize that more tooling can change your workflow, and we want to answer some commonly asked questions.

If your question is not addressed below, please reach out to support@tidelift.com.

What is the Tidelift Subscription? Why do we have this?

Tidelift helps developers spend less time and energy dealing with issues related to open source. We do this by partnering directly with package maintainers of thousands of different Javascript, Python, Java, Ruby, .NET, and PHP open source packages. With them, we’re doing management work to fix security issues, resolve licensing issues and, more generally, ensuring packages match standards that an enterprise customer would expect from any software. All this gets delivered to you in a catalog.

What are catalogs? 

A catalog includes all of the package releases that are approved for use within your team.

If your manager says “We’re using the Tidelift-managed python data science catalog!”, they are effectively saying “We can use any of the package releases that Tidelift has said are okay to use.” And that list will change over time as we are automatically resolving issues on your behalf, adding and removing releases from the catalog.

Your team may be using one or more of the catalogs that we, Tidelift, are managing. And very likely your team will further customize your organization’s catalog. 

They may enforce additional standards, such as those from your legal team, and they may add additional package releases—such as internal packages and other packages for which Tidelift doesn’t provide managed support.

How does this help me as a developer?

Four reasons:

  1. There’s no guessing which open source packages you can use. Your catalog provides a clear “yes” or “no” to whether you’ll be able to include any given package release in your repository.
  2. You don’t need to deal with issues yourself. Issues get sorted out on the catalog-level and get addressed by Tidelift or another catalog manager, before they ever get to you.
  3. You can see what others at your organization are already using, which may make it easier to decide what to use yourself.
  4. There’s a process for requesting to use something new. And it doesn’t require opening a ticket or sending an email.

Help—How do I know what open source is approved for use?

There are a couple of different ways:

  1. From the Tidelift web application,you can browse your organization’s complete catalog. You can see the full list of packages and, for each of those packages, you can see which releases are approved and denied.
  2. From the command line, you can use the Tidelift CLI to check if a repository you’re working in is aligned with the catalog (i.e. all of the repo’s package releases are approved in the catalog). If it’s not, you can see if there are alternative releases that you should use or request for those releases to be included.

Help—Why am I not able to ship to production?

Tidelift is likely integrated in your CI/CD workflow—it is the easiest way to ensure that repositories are only using package releases that are approved within a catalog.

If your build is blocked, you’ll receive feedback indicating which releases are not included in your organization’s catalog and what you can do. This might look like using an alternate release or getting approval from a manager to start using the package.

Help—Why can’t I use an open source package release that I want to use?

If a package release is not approved it could be because:

  • That specific release does not meet standards (maybe a problematic security vulnerability or it’s an old release stream that is no longer maintained)
  • Your organization has an opinion about not using that package or specific release (maybe its license isn’t approved by legal or maybe there’s an alternative package that should be used)
  • No one has requested to use the package yet

In the first two cases, the package is explicitly denied in your catalog. Hopefully there is an alternative release or package that is recommended. Your manager is encouraged to include notes about why a package release was denied, but if there’s nothing there just give them a polite shout.

In the last case, you can request the package release from the Tidelift CLI.

Anything else I should know?

Managing open source on your behalf is only possible because of the relationships we have with maintainers. The subscription fees that your company is paying to Tidelift is being shared with the upstream maintainers of the packages that you use. So thank you for supporting independent maintainers of open source!

If there’s anything we can do to better support you, don’t hesitate to reach out with questions or feedback.


Still need help? Contact Us Contact Us