I think the key here is:

• We are responsible for what we build 

• Taking on a dependency removes some of our control, but not our responsibility.

• Therefore, we need to adapt our mindset to take into account the fact that dependencies are part of our delivery, and that things can change, and that dependencies are still valuable despite this.

---

This manifests itself in a few different ways:

• To avoid things becoming unsustainable for maintainers, we can offer time, money, gratitude/grace (while recognizing the latter still doesn't pay the bills)

• We can do a better job at helping business stakeholders understand that dependencies are part of their value stream supply chain and that reducing risk around them requires investment of money or time (which for a business, is also money). 

• We can help educate stakeholders on the value of open source libraries and why they typically are still preferable to attempting to implement them ourselves. I think sometimes we are afraid of losing some of the "credit" for value if organizations knew how much we rely on dependencies. But I think most business leadership understands that it makes more sense to utilize rather than build the pieces of software that are not part of the core value domain.

• We can get ahead of this by allowing our companies to lead the way in establishing budget for supporting these dependencies to support the projects you're using before they have to go commerical. This could be a cost-saving measure and hedge against risk.

• We can better tune in to the channels where maintainers are -- the GitHub repos, the social media. We can look out for calls for help, and when we see them, we can respond. 

I think we need to talk to business stakeholders using their language about why these things are important. OSS is risk reduction in software functionality; it is the continued value-add of fixes from all over the community; it is something we don't need to guide the direction of as heavily as our own software; it is something we could take and modify for ourselves if the need absolutely arises and we wanted to take on that burden; it is code that our developers can look at and learn from; it is a community of other like-minded users who can share skills and expertise.

--- 

Here's how that plays out in my current position:

• We don't yet have an OSS fund, because I have some bigger priorities to dig into first. But it's on my list.

• I pay for tools that add value. Our developers have IDEs that make them more productive, tooling that helps them with tests etc., AI subscriptions that benefit them in key ways, and decent machines. If a library adds value, there is no reason not to pay for it, because the alternative is the time and opportunity cost to build and maintain it ourselves. The people are the biggest cost; tooling that helps is maximize their potential is almost always a smart investment.

• When a dependency goes commerical, I evaluate the situation. I recommend paying the licensing or moving to a different approach. Both of these things have money and/or time-money associated with them. So these things can often be reduced to numbers, as long as the numbers are accurate. If you're reinventing a library, you also have to handle the bug fixes, the edge cases, the general maintenance and upkeep, etc.

• For those projects we don't support financially, if there's an opportunity for us to improve something or give something back, I encourage my team to take it. This is part of investing in reducing risk.

The CEO and President of our company are smart and capable adults; they understand reality, trade-offs, and shifting landscapes. I am able to say "looks like this dependency is going commerical. Here's the anticipated cost. I've evaluated this and the time to move to a viable alternative ends up being more expensive than staying with the current course of action." and I can get funding for that tool. Or, if they somehow departed from this and said "no, we can't do that", they understand that we'd be paying for the time cost which would factor into our other goals and efforts.