Product roadmap snapshot as of January 2019

Happy new year!

The last few months have been full of sales calls and feedback, and we’ve learned a lot. Based on that, we’ve put together some draft thoughts on where we’re taking the product from a subscriber perspective. Trying to get to the next level of specific & concrete, evolve things to the next step, etc.

Why does subscriber-facing product direction matter to you?

  • apropos of Ned’s question this morning, we’re looking to revamp how we explain things on, in banners on project sites, etc. - and provide more helpful collateral and “next steps” for getting subscribers on board.
  • it affects the exact work we’ll be asking lifters to do & some additional income opportunities we might be able to offer. (But this current draft doesn’t change the core model.)

If you’re interested, we’d love to get your observations here or even get on the phone. We have a big company meeting next week to work on planning the next couple months, so input this week is extra-useful but anytime is great! Nothing is ever “done.”

Another useful thing: if you’re ever talking to potential subscribers or peers about this stuff, and get feedback, pass it along! “You know, what I’d really like is…” “It would make more sense to me if…” that’s stuff we want to hear.

Product management tactics

To give ourselves a little structure, we’re using a mad-libs template from which goes like this:

Today, when [customer/user segment]
want to [desirable activity/outcome]
they have to [current solution(s)]
This is unacceptable, because [shortcomings of current solutions]
We envision a world where [shortcomings are resolved]
We’re bringing this world about through [broad technology/approach]

Another bit of structure is from this post where the punchline is:

So in this post we’ll describe what the “skateboard”, “bicycle”, and “car” might look like. Apologies to those of us who feel bicycles or public transit are better than cars, but I don’t want to redo that graphic :slight_smile:

The problem we’re trying to solve for subscribers

(draft framing)

Today, when engineering leaders want to maintain the open source they’re reliant on, they have to use homegrown or costly tooling that surfaces lists of problems … and then dedicate engineering time to tackling the endless lists of problems. They also have to research and monitor package status (quality, roadmap, licensing, releases) themselves, package-by-package.

This is unacceptable, because it’s too time-consuming to be practical. In practice, teams do not keep their dependencies adequately maintained, creating risks, fire drills, and sub-par quality. They often come to view dependencies as a liability to be minimized, rather than taking full advantage of open source.

We envision a world where maintenance problems are addressed proactively by our service, and teams only have to review and apply our fixes, rather than researching and solving the issues themselves. When solutions are more complex than a new release, teams have easy access to help.


If a dev team uses many dependencies, in the aggregate they are sort of a mess:

  • maintainers vanish all the time
  • unsolve-able dependency graphs when they try to update to fix a problem
  • no easy way to learn about all material information (vulnerabilities, API breaks) in one place
  • random quirky licensing situations

There’s a thriving market for open source audit/compliant/security tools to try to notice when things are a mess, but the most common way teams handle this is head-in-sand. “I’m sure Facebook is fixing it”

There’s no reason every software team on the planet should be slowing down their velocity trying to clean up their open source dependencies on their own, when they could instead focus on higher-value work. Right now, they don’t have a real alternative to doing it themselves.

Note: the customer we’re primarily speaking to is an engineering leader, probably at a large-ish company in most cases.

The skateboard solution (already shipping)

(draft framing)

We envision a world where teams have a smarter list of what problems to tackle, are better equipped to resolve problems faster so they can use their time most effectively, and begin to support the maintainers of their exact dependencies to reduce maintainer turnover and neglect

We’re bringing this world about by:

  • continuously scanning the open source packages teams are already using,
  • analyzing dependencies informed by high-quality data provided directly by upstream maintainers,
  • giving teams prioritized insights into actual or potential problems, and
  • bringing information and solutions to them in one place to fix problems faster.

We are supporting a wide range of open source ecosystems, and including all of security, licensing, and maintenance issues, to give teams a simple all-in-one list of problems to consider.


The skateboard is rolling already, though it isn’t the fanciest skateboard yet. Where we are now is that we’re supporting maintainers, we’re giving subscribers insights, but the link between the two isn’t as strong as we want it to be - that’s a direction we’re proposing to push further in as we go on to a bicycle or a car.

A bicycle solution

(draft framing)

We envision a world where maintenance problems are addressed proactively by our service, and teams only have to review and apply our fixes, rather than researching and solving the issues themselves. When solutions are more complex than a new release, teams have easy access to help.

We could bring this world about by, for example:

  • showing problems to ourselves and our lifters first, ensuring on our side that there’s an actionable suggestion, and only then surfacing those problems to subscribers for them to review and apply.
  • expanding our business processes to support some degree of problem-solving on 100% of customer dependencies, not only those with upstream maintainer participation
  • for more complex issues, providing a way for teams to request support or consulting in small, low-overhead increments


This is getting into more speculative/future territory, but note some of the possible directions:

  • more directly help subscribers on their exact issues, potentially making a release to address it. For example, if a package is pulling in a transitive dep that has no license or isn’t maintained or is broken, we might collectively (some blend of Tidelift+package maintainer) come up with a pathway for subscribers to solve that. Note that this isn’t a support queue–it’s solving auto-detectable problems that affect N subscribers, not answering arbitrary questions.
  • we want to figure out what we do with packages where the upstream maintainers aren’t interested in being part of Tidelift.
  • how could we simplify getting personalized help, consulting, or traditional “help desk” type of support–we don’t want this to be a mandatory part of lifter tasks, but we think we can make it a lot easier to pay someone for an hour of advice–and easier to get paid, too.

A car solution

(draft framing)

We envision a world where maintenance problems arise far less often, because of strong maintenance and release engineering practices applied consistently across open source libraries and subscriber applications.

We’re bringing this world about by paying maintainers to caretake each package, while creating a community of funded maintainers who collaborate with us, with subscribers, and among themselves to define best practices and deliver complete, high-quality dependency stacks to subscribers.

We expect this community with our help will tackle root causes and scalable approaches for release-engineering open source dependency graphs as a whole, for example:

  • CI tests that new releases of each package work with the overall graph and don’t break customer applications
  • Signature checks that all packages come from a known source
  • Good release practices and documented LTS timelines

Participating subscribers are effectively part of a global QA & integrity process that results in dependencies that Just Work for their specific applications.


Clearly this is the most speculative / most long-term part of this post.

How could we, with the tools & business model to support it, set up some really great collaboration and feedback loops between subscribers and upstream projects?

How could we apply some of the benefits of Linux distributions to all of open source, using the native package managers for each ecosystem?

Why this sequence?

The evolution over time boils down to: identify the problems, then do a better and better job fixing them earlier in the software development lifecycle or in a more root-cause way. One of the ultimate root cause issues, of course, is lack of maintainer time–created in part by a lack of maintainer funding.

In practice it certainly won’t be delivered as three tidy milestones, and the details and examples simply will change, but hopefully these illustrate the direction we’re thinking about. Needless to say, we’ll keep learning.

If you took the time to read through this then thank you very much!


“we think we can make it a lot easier to pay someone for an hour of advice”
I would certainly welcome that, as setting up the necessary payment/invoice/tax infrastructure is hard. You would need to distinguish between consulting and help desk though, given most maintainers available time.

“we want to figure out what we do with packages where the upstream maintainers aren’t interested in being part of Tidelift.”
Interesting. From my perspective, I think there is potential to assist with other packages not directly owned by me.


1 Like

Thanks for sharing this. I’m also intrigued by "make it a lot easier to pay someone for an hour of advice”. That’s a common hurdle for maintainers, and something that a centralized broker like Tidelift could solve.

1 Like

I’m glad that resonated with both of you :grinning: I’d be curious to hear how you’d differentiate between the consulting framing of “an hour of advice” and the help desk framing of the same thing. Specifically, we’ve heard the consulting angle as being closer to, “review this PR or add this feature for a corporate user,” so that’s obviously something we want to be careful of. How does that compare to your thinking?

I think a maintainer is offering an hour of their time for a fee, and has to be able to deal with a variety of things in that time. But the difference is that they aren’t expected to be configuring or debugging other environments. Its more likely to be a discussion around product direction. Paying to review a PR? Tricky as the maintainer will feel awkward if they disagree and want to reject.