How to evaluate AI startups that depend on open-source models, libraries and infrastructure across licenses, maintainers, security, forks and differentiation.

Open source can be an advantage

Using open models and libraries can reduce vendor lock-in, accelerate development and give startups more deployment control. It is not automatically a weakness. The diligence question is whether the company understands and manages its dependencies while building differentiation above them.

Map critical dependencies

List foundation models, inference servers, vector databases, orchestration frameworks and libraries that are essential to the product. Identify which can be replaced quickly and which would require major reengineering.

Review licenses

Model weights, code and datasets can have different licenses. Commercial rights, redistribution rules and attribution obligations matter. A startup should maintain a software and model bill of materials rather than discovering restrictions during a financing or acquisition.

Maintainer and project health

Look at release cadence, governance and the number of active maintainers. A popular project can still become risky if one organization controls key decisions. Evaluate whether the startup can maintain a fork if necessary.

Security response

Open-source components need patching and vulnerability monitoring. Ask how the company tracks advisories and tests updates. Fast-moving AI infrastructure can change interfaces frequently, so upgrade discipline is part of operational quality.

Model replacement

If a core open model stops improving, can the product switch to another? Finndy’s earlier article on AI startup moats is relevant: defensibility should live in data, workflow, distribution, identity or economics rather than dependence on one freely available model.

Cost and hosting

Self-hosting open models shifts spending from API fees to GPU infrastructure and engineering. Compare total serving cost at realistic utilization. Open weights do not mean free inference.

Conclusion

A strong startup can be deeply open-source and still defensible. The key is to know which layers are commodities, which are controlled, and what remains valuable if the underlying model changes. Dependency risk should be explicit and tested.

Review checklist

• Reconcile the headline metric to source data.
• Separate recurring behavior from one-time effects.
• Test concentration and dependency risks.
• Include infrastructure economics.
• Document assumptions so they can be updated.