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.
What is the Tidelift Subscription? Why do we have this?
What are catalogs?
A catalog is custom for your organization and includes all of the package releases that are approved for use within your organization.
How does this help me as a developer?
- 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.
- 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 administrator, before they ever get to you.
- You can see what others at your organization are already using, which may make it easier to decide what to use yourself.
- 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:
- 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.
- 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?
The Tidelift Subscription 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.