Want to better understand your current dependencies? Here's how.

Today we're launching the Tidelift Subscription, a service that gives professional assurances to commercial users of open source while funding maintainers to offer those assurances.

We're also launching a free dependency analysis service. This post is a tour of what it has to offer. If you have code hosted on GitHub.com, you can try the analysis service right away.

Dependency analysis has at least two roles at Tidelift:

• It helps both subscribers and open source maintainers understand their dependencies along with their security, licensing, and maintenance properties.
• It routes subscription revenue to the right packages; we pay lifters according to how often their packages are used.

Modularity and collaboration are among the powerful impulses behind the growth of open source. We believe the future of software involves more modularity and collaboration, not less. But business models and processes aren't keeping up. The Tidelift Subscription is part of a business model that we believe will scale to many thousands of packages. To make this work, we'll need to automate.

How is the Tidelift analysis different?

We're running our analysis service from the Libraries.io dataset. Libraries.io is an open source project to index all open source packages and repositories—read more about Libraries.io in this previous post.

With the Tidelift analysis service, we're going wide first and deep second.

• We support 24 package managers and counting, while most services are the other way around (they're limited to a single or a short list of language ecosystems).
• We look at multiple attributes of each package, including whether it's still maintained, whether it's deprecated, whether any security vulnerabilities affect it, how it's licensed, and whether it's up to date.

Signing up

Step 1 to try out the analysis: create an account and log in. You can do this in one step by logging in with GitHub.

When you connect Tidelift to GitHub, we'll request permission to access your repositories in order to understand their dependencies.

(If your code isn't on GitHub.com, you might want to create an account anyway because we have some demo repositories you can use to explore the analysis service. We don't have a self-serve way to scan your non-GitHub.com dependencies yet, but get in touch and we'll help.)

Insights for whole organizations

Once you log in, it will take some time for the Tidelift service to scan all of your repositories. When the scan is complete, visit the Insights page to get some summary statistics. In the top right, you can select the GitHub organization to analyze:

If you've never run an analysis like this, you may be amazed how many packages you depend on, in total—especially for languages where the Tidelift analyzer understands dependencies-of-dependencies (also known as transitive dependencies… these come from package-lock.json or Gemfile.lock, for example).

Digging in to specific repositories

For more details, try the Your Repositories page to see the list of all repositories we've loaded from GitHub.

Find the repository you're interested in, and click through to view detailed analysis results for that repository.

If you don't see a private repository you were expecting to find, there are two possible issues.

First, click "Add private repos" to allow the Tidelift service to access private repos through the GitHub API:

Second, you may need to authorize Tidelift to access each individual organization in GitHub settings. You'll only be able to see this if you're the owner of the GitHub org.

You can find these settings through the GitHub site, or click here:

Once you're in the repository you want to analyze, we'll show you the dependencies we found and any issues we think they have.

What are my dependencies, anyway?

Here you can explore the list, for many but not all languages including transitive dependencies.

What sort of problems can Tidelift detect?

The analysis service can flag several categories of possible issues with your dependencies.

Missing license information:

Deprecated packages:

Unmaintained packages:

Security vulnerabilities:

Outdated packages:

You'll probably have a bunch of outdated packages almost all the time, so we treat that as a warning rather than a hard error.

Prevent regressions with PR checks

Once you fix any errors on your master branch, you can avoid introducing new problems by setting up checks on GitHub pull requests.

Click this button on the repository page:

Then you'll get an indicator like this on your pull requests:

It's also possible to quickly enable many PR checks at once on the Your Repositories page:

What if I can't fix an error?

Some errors are problems to solve in your own repository. For example, if you've specified an old version of a package that has a security vulnerability, you might upgrade to a newer version.

Other errors can be deep in the transitive dependency chain… what if a dependency of a dependency of a dependency has been deprecated?

It's possible to add a .tidelift.yml file to ignore certain errors and continue with your pull request.

But wouldn't it be better to get that deprecated package fixed? Tidelift subscribers have the option to escalate problems with their dependencies to Tidelift, where we'll work with the upstream maintainers to find a solution.

Much more to come

We hope you find this dependency analysis service useful! Understanding your dependencies is a first step, but we're focused on taking it to the next level: helping subscribers improve their dependencies, by supporting open source maintainers who bring those improvements.

To know what's new as it happens, subscribe to updates from Tidelift or follow us on Twitter.