[barisozmen]

Completely agree. It's one of the most important skills to know which dependency is good and which is bad.

My two cents. If a dependency is paid, than it is usually bad. Because the company providing that dependency has an incentive to lock you in.

As another point, "dependency minimalism" is a nice name for it. https://x.com/VitalikButerin/status/1880324753170256005

[ehnto]

As well, paid dependencies usually only have one source of support, and when the company goes under or stops supporting the product you are in rough seas.

Given very few companies last forever, you have to assess if the trajectory of your project would be impacted by being coupled to their ability to support you.

[Cthulhu_]

For sure, this goes into the terrain of acquisition though, for which there are long-running procedures and assessment criteria. Long-term support / company longevity is one of them.

But likewise, these companies have the incentive to look like they have long-running success and can be relied upon for years / decades to come.

[swiftcoder]

> when the company goes under or stops supporting the product

Or, even worse, gets acquired by someone like Salesforce

[barisozmen]

Exactly. That's another point

[jmcgough]

I've experienced some bad paid dependencies forced on us by a non-engineering team. I've had a few good experiences with "open core" kinds of dependencies that are widely used by the community, e.g. sidekiq, and therefore less likely to suddenly vanish one day as they would almost certainly get forked and maintained by others in the same boat.

The upside of paying for something is that, assuming the owner or company is stable, I don't have to worry about some unpaid solo maintainer burning out and never logging back in.

[RossBencina]

> assuming the owner or company is stable

and continues to be stable for the lifetime of your product.

[AdieuToLogic]

> My two cents. If a dependency is paid, than it is usually bad. Because the company providing that dependency has an incentive to lock you in.

Vendor lock-in is a risk for both purchased components and FOSS ones where the organization is unwilling to assume maintenance. The onus is on the team incorporating third-party component(s) to manage their risk, identify alternatives as appropriate, and modularize their solutions.

[nlitened]

Developers would say this and then deploy to AWS Lambda or Vercel with a straight face

[7402]

If a dependency is paid and it is bad, then maybe you just aren't paying enough for it.

If my code has a dependency then I want there to be people whose feel it is their job to support it.

Either there have to be enough people who are paid to support it, or there have to be enough people whose self-worth and identity is so wrapped up in the code that they take it as a point of honor to support it.

I don't need a company that's likely to abandon a code product and leave me hanging. I also don't need a free software author who says "bugs are not my problem - you have the source, go fix it yourself." If those are my choices, I'd rather write it myself.

[chii]

> I want there to be people whose feel it is their job to support it.

their "feeling" will not change reality, which might conflict. For example, a specialized database vendor would prefer that you cannot move away, and even if they feel like they want to support you, there are other economic factors to consider which could override this.

[f4c39012]

https://opensourcemaintenancefee.org/ uses payments as an incentive to keep projects going, so dependencies can be updated. .NET Rocks! interviewed them https://www.dotnetrocks.com/details/1948

[chii]

I think the idea is that if you are paying, the dependency needs to implement some sort of open standard/interface to which there are at least one other implementation you could move to. The vendor cannot lock you in with this requirement, since you always would have the option to move (despite it being a bit expensive, it's just there as a threat).