If you’ve noticed fewer changes to the Tidelift UX lately, it’s because we’ve been focused on a large new feature called catalogs. We think catalogs will add value for subscribers, while also clarifying the purpose of lifter tasks and potentially adding more income opportunities.
We’re launching Catalogs this week, and we’re excited to share the details!
There are a lot of words here, so if you’re looking for a quick summary:
- We have a new catalogs feature that will make it a lot easier for subscribers to see and benefit from lifter work and manage their open source dependencies.
- We now give subscribers the option to put dependency scanning into a larger context, looking at issues globally for their catalog instead of separately for every pull request
- The catalogs feature was developed based on direct feedback from customers and prospects regarding the pain they are facing when managing their open source.
- This will help Tidelift continue to scale (including individual lifter income!)
- Lifter work and payments aren’t changing at this time, so keep doing what you’re doing!
- If you’d like to learn more, please keep reading, check out this demo video, or sign up for a demo slot (see below for schedule).
Want to learn more?
We have a lot of information to share, and seeing catalogs in action can be very clarifying. So we thought it might be good to set up some sessions where we can walk through everything and answer your questions. We have two demos scheduled for next week:
If neither of these fit your schedule and you’d like to attend a demo, please let us know! We’re happy to schedule additional sessions.
We’ve also put together this demo video!
What’s a catalog?
A catalog is a list of known-good package releases, with tools to collaboratively create and manage the list. Subscribers manage their custom catalogs; Tidelift (with help from lifter tasks) manages pre-built catalogs. We’ll refer to “subscriber-managed” and “Tidelift-managed” catalogs in this post.
We then allow the work done for one catalog to feed into a different catalog. In effect, one catalog can inherit from another one, object-oriented-style. This means that subscriber-managed catalogs can pull-in Tidelift-managed catalogs, and in the process, benefit from lifter work and advice.
Management of a catalog involves setting rules for the catalog, called standards, that come with automated checks. When a standard isn’t met, the catalog generates tasks asking the catalog manager (or where appropriate, a lifter like you!) to remediate the problem.
Simple example: we might have a standard that all packages in the “license researched” catalog must have a license that is Open Source Initiative approved and in SPDX format. When one does not, we generate a task to research and annotate the missing license.
A subscriber’s catalog can then inherit from this “license researched” catalog and avoid reinventing that research. Note that managing a catalog generates a data trail; to approve a package, a catalog manager might research licenses or assess security vulnerabilities. This data becomes part of the catalog, too.
Why are catalogs valuable for subscribers?
We created the concept of a catalog to give all organizations options that until now only the largest companies have been able to afford to build in-house. Namely, we help them:
- stop parsing painful scanner reports full of false positives and open source minutiae
- use Tidelift-maintained lists of known-good open source components that are proactively managed
- start building lists specific to the organization’s policies and stakeholders
- integrate these lists into build tools and integration checks in an easy-to-use but robust way
Right now a lot of organizations are buying scanners that flag dependency issues (similar to Dependabot on GitHub). The problems with this include:
- every developer of every application ends up triaging issues separately, duplicating work
- developers often aren’t the best people to be triaging all issues; take, for example, some arcane license concern
- there’s no tendency to converge toward fewer packages & releases across the organization
- it happens late in the software lifecycle (deploy-time)
- it doesn’t allow for a technical review step to decide which new packages to adopt
- it doesn’t provide a specific incentive for upstream maintainers to create timely fixes for issues that are identified in community packages
The catalog concept centralizes all of this, so developers get a clear yes-or-no answer for a particular package release, and the confidence that there will be a timely new package release when issues do come up. Using our Tidelift-managed catalogs with your advice and recommendations, we can help subscribers quickly approve all the stuff we (Tidelift + lifters) have already analyzed.
How might this clarify Tidelift for lifters and subscribers?
One virtue of the catalog approach is that it unifies the subscriber and lifter sides of Tidelift a bit more. Catalogs are a general tool. Tidelift and lifters can pre-build catalogs together, and subscribers can build custom catalogs that use these Tidelift-managed catalogs. For subscribers wondering what lifters are doing, they can go look at the Tidelift-managed catalogs and even the trail of completed tasks. For lifters wondering what subscribers are buying, they can look at the Tidelift-managed catalogs and see an example. This all uses the same mechanism and will soon share the same (or very similar) UI.
This clarity depends on opening up Tidelift-managed catalogs for lifters (and indeed, casual visitors to the Tidelift website) to check out. We have to write a bit more code before this is possible, but it’s the goal.
How does this relate to Tidelift’s existing lifter tasks?
Tidelift-managed catalogs will contain, in effect, the union of all the version guidance pages that we have today. Because there are multiple catalogs, we’re also giving ourselves (and subscribers) the ability to have multiple collections of “version guidance,” for different purposes.
Right now we ask you to organize releases into streams, and ensure that at least one release in each (still-active) stream is free of issues such as vulnerabilities. If we take all those issue-free “recommended releases” together, that’s what the first Tidelift-managed catalogs will contain.
Why do this? In the past, we’ve had to ask subscribers to imagine a virtual catalog of recommendations and it was a little too abstract to communicate easily. With the new catalogs feature of the Tidelift Subscription, subscribers see a concrete list of recommendations nicely organized.
How does this change lifter tasks?
It doesn’t—everything lifters do now still makes sense. What changes is that we’re working toward a unified view, available to Tidelift, lifters, and subscribers, that will let us all see the pending and resolved tasks for all lifted packages at once.
Each individual lifter will still have a view where they see only tasks on their own package(s). Lifting means owning those tasks that relate to your lifted packages. The tasks themselves are the same kinds of things, but they’re now aggregated into a larger context.
However, we haven’t redone the UI to reflect this yet. Right now the lifter dashboard on Tidelift.com is unchanged, and you won’t see things in a catalog context. We do think that we can organize the lifter UX in a nicer way around catalogs, and we also have a new CLI that we can start to extend to support lifter use-cases as well.
With your help, we’ll continue to iterate on lifter tasks as we better understand what’s valuable and feasible; these iterations are orthogonal to the catalog feature (any lifter task that was possible before still works with catalogs, any lifter task that works with catalogs was also possible before).
What does a subscriber’s customized catalog look like?
Quite a few large organizations we’ve spoken with have an in-house custom-built version of this idea already. They use in-house tools to create an approved list of dependencies, sometimes called a paved path, for their developers.
Before approving a package, subscribers would typically review security, licensing, and technical aspects of that package.
With this catalog feature, we’re productizing what these organizations are already doing, or at least trying to do. It turns out to be quite a hard problem, and maintaining the list of approved package releases isn’t easy.
Most subscribers will start with pretty simple standards on their catalogs:
- releases in the catalog don’t have vulnerabilities
- packages in the catalog have license tags and comply with their license policies
- some sort of technical review process that they define
So they’ll vet any packages they add to their catalog, and will receive tasks for regressions—for example, new vulnerabilities or a change in license policies may generate tasks to review previously-approved releases and take them out of the catalog.
How do we (Tidelift + lifters) use catalogs to give subscribers advice?
If subscribers start from scratch and set out to review thousands of dependencies, it’s a ton of work. So the Tidelift Subscription isn’t only the catalog workflow software, it also includes Tidelift-managed catalogs. Subscribers can use the Tidelift-managed catalogs directly, but it’s more practical to create a custom catalog (with any quirky stuff they use) that inherits from the Tidelift-managed catalogs, object-oriented-style. Subscriber catalogs are effectively a subclass of our catalogs (with multiple inheritance allowed!).
Which Tidelift-managed catalogs do we have today?
Tidelift currently manages three catalogs, based on lifter work.
Our license-annotated catalog has machine-readable, SPDX-format licenses on all packages, enabling subscribers to apply an automated license policy. This catalog lets customers screen out unacceptable licenses without independently researching thousands of false positives—packages often have acceptable licenses that are not properly annotated. These license annotations are powered by your work.
Our security-advised catalog provides advice and remediation around security vulnerabilities. Your work helps us to provide the best advice, in particular avoiding false positives.
- Where possible, the releases in the catalog are updated to ensure that no vulnerabilities apply.
- Where not possible, we document workarounds for each vulnerability.
- For packages with no active maintainer or where the maintainer has been unresponsive to a vulnerability, as a last resort we provide custom patches.
- We work with maintainers to document which release streams receive security updates and end-of-life dates on those streams.
- We work with maintainers to proactively improve project security:
- Maintainers have a confidential security reporting address and follow coordinated disclosure best-practices to reduce subscriber exposure to zero-day vulnerabilities.
- Maintainers set up 2-factor authentication to reduce the risk of trojan horse attacks.
- Maintainers coordinate with Tidelift’s security response team to release security fixes in a timely fashion.
Our indemnified catalog provides IP protection.
- Should a subscriber violate an open source license, you’ve agreed to work with the subscriber to resolve the problem prior to filing a lawsuit. This approach is based on the GPL Cooperation Commitment.
- You’ve certified the authorship of code they write. This approach is based on the Developer Certificate of Origin.
- For the packages you lift, Tidelift indemnifies customers against claims that these packages contain copyright violations, such as copied code or an open source license violation.
- Tidelift may respond to such a claim by (i) replacing the infringing portion of the software, (ii) modifying the software so that its use becomes non-infringing, (iii) obtaining the rights necessary for a customer to continue its use of the software without interruption or (iv) defending the customer (that is, hire and pay for a lawyer) against the claim and paying any resulting damages (up to a certain cap).
- Indemnities are capped based on an organization’s specific needs and subscription level.
What’s coming next in the Tidelift software UX?
For subscribers, we’ve shipped the ability for them to create one custom catalog and pull in prebuilt Tidelift-managed catalogs, based on lifter work.
As a next step, we’re bringing catalogs from 1 to N; subscribers will be able to create multiple catalogs, we’ll have more prebuilt catalogs, and all of them will have a nice page summarizing the intent of the catalog, the standards and tasks that apply to it, and the contents of the catalog.
From there, we’d like to come back and rethink the lifter dashboard UI you’re all familiar with. We think we can make the purpose of each task clearer, make it easier to complete tasks in bulk, and in general simplify significantly.
For this lifter-facing work, we will do all the user testing and take all the feedback on mocks that anyone’s willing to sign up for; and we hope you will!
What’s coming next for Tidelift-managed catalogs?
We believe there’s a powerful opportunity to build catalogs that are guaranteed to contain a useful dependency solve for common application frameworks. For example, everything in the transitive dependency graph of Vue 2.6.
Over time, some of the packages in these graphs will have issues (they’ll be deprecated, on an inactive release stream, unmaintained, or similar). We’d go find the best solution to those issues, working with upstream everywhere possible, and filter out non-actionable false positives in the meantime.
We also believe there’s an opportunity to build catalogs with much stronger enterprise-oriented policies and information, such as documented-and-reasonable security-fix lifetimes on all branches.
How will this help make more money through Tidelift?
This feature designed to address the pain a wide variety of organizations we’ve been engaging with have when it comes to building apps with open source components… We expect that the catalog approach will allow us to solve more problems, and therefore create opportunities for you to help solve them for these organizations. More about that in the coming weeks and months!