Welcome to the August 2021 edition of the Tidelift product update, or Pupdate for short! The Pupdate is our monthly rundown of new features and enhancements in the Tidelift product, and there’s a picture of a dog at the end.
A core feature of the Tidelift Subscription is the ability to create catalogs of approved and denied open source package releases. These catalogs help developers move fast and centralize the decision-making related to open source package releases.
The central administrators can complete tasks related to their catalog. A task might be reviewing requests for a new package from a development team or making decisions about new security vulnerabilities or license issues—both made easier with Tidelift recommendations and guidance.
We recently made some major improvements to how catalog administrators review tasks. For this month’s product update, I spoke with product manager Joan Liu about the changes that our subscribers can expect.
Well, surprisingly, there is a lot new that’s not about completing tasks. We make scanning a list of tasks easier so that catalog administrators can quickly view the task list and only dig into the ones that are important. The table view allows users to see more tasks at a time, so they can skim the list. If they want to learn more, a click quickly reveals a preview of the information.
Once you are ready to dig into a task, we make the next step very clear: you should make a decision about what you’d ideally like developers to do.
Customers felt like they couldn’t make decisions on catalog tasks without fixing everything in their code. This isn’t how we want customers to feel. Instead, we want to empower them to make decisions about whether or not their team should use a particular release.
For example, for a security task, we used to ask, “How do you want to handle this vulnerability?” We have changed that to match our real question, which is, “Do you want your development teams to use this release?”
We provide you with the information you need to determine if you are affected, such as which projects use it, how you would have to be using it to be exploited, and recommendations if you don’t want them to use the release anymore.
So far the feedback has been awesome. As part of this view, we removed some of the data we previously displayed and so we got some feedback that some of that information was needed to make a decision. We’re working to incorporate that feedback in our next iteration. The quick-view drawer was favorably received, as it allowed the catalog administrator to rapidly look through a lot of tasks without having to be taken away from the entire list. The colors help make it more scannable for the type of issues they need to address.
One of the things that makes Tidelift different from a traditional scanning tools is that we partner directly with maintainers and can ask them for clarifying information and recommendations. We surface that information and anything else we have found to help you make your decision. For example, we may provide context from a maintainer that an identified security vulnerability is only relevant under certain conditions.
We want to evolve these tasks into a place where siloed teams in an organization can discuss priorities and proposed solutions. For example, one customer has found that a task isn’t important to them right now because they’re about to do a major revamp of their application, potentially addressing the task. Another team might be interested in the work done by that team to inform how they proceed. We think this discussion and explicit decision to deprioritize this task is extremely important and we are working to enable that, but it didn’t make it into this new version...yet.
All the different scenarios we had to think about and accommodate! What should happen when multiple vulnerabilities affect the same package? What should happen when both a security vulnerability and a license issue are found on the same package? What should we show when we are partnered with the package maintainer? What should we show when we have a recommendation? There were dozens of decisions like this to make every week.
Catalogs are still a relatively new concept, so we’ve been improving the way they work based on what we hear from our customers. Because of that, we have some complex logic in the backend to calculate what should be displayed to the catalog administrator to make it simple for them to find out what projects aren’t aligning to their company policies, and clear recommendations when Tidelift (or our partnered maintainers) have a recommendation. We’re really working on streamlining the logic wherever possible and trying to avoid duplicating code that calculates which tasks are presented to the catalog administrator. Additionally, we’ve learned about different metrics companies use to measure health, so we want our tasks to be flexible enough to accommodate future changes.
In addition to becoming a place for streamlining internal discussion, we’ve received some feedback on reducing technical lag on open source usage, so we’re working to incorporate some of that into helping companies improve their open source. Technical lag means different things to different organizations, so we expect to iterate some on this upcoming feature.
We’re continuing to improve our recommendations so that we sort through the noise for our customers and they don’t have to spend a lot of time trying to decide if they should use a particular release or how to remediate it.
I’m more of a cat person, but I do love my mother-in-law’s schnoodle, my schnoodle-in-law, Stella.