A few observations on how technology companies can strategically use open-source from my time working on open-source at Google.
- Hiring: It's easier to hire for roles that involve open-source projects. Ideally, you can hire developers who are already familiar with the technology, reducing the ramp-up time for new developers. See Open Source and Firm-specific Training for a more economic explanation.
- Marketing: A GitHub repository readme is the equivalent of a marketing page. Not only do developers trust technical documentation more, but GitHub meets developers where they are.
- Go-to-market (complement): Open-source products that are often used together with your paid product and drive users to your paid product by default selection. Google is the master of this method (Android/search, Chrome/search, etc.). Commoditizing your complement in the cloud era. Facebook (data center tech) and Microsoft (VSCode, TypeScript, etc.) are good examples. I would also lump in open-source/complement pairs like RedHat/services and AWS/hardware in this bucket.
- Go-to-market (free tier): Companies are hesitant to adopt core infrastructure that isn't open-source (however, this isn't always true for best-of-breed companies, e.g., Snowflake). Allows enterprises to integrate software on their own before procurement and vendor security requirements (bottoms-up, lead-gen). Stronger pull than a free tier (sometimes) but continues to create some switching costs through APIs, data schemas, and skilling. Many enterprise infrastructure companies ("open core") are in this bucket (GitLab, Confluent, Elastic, Redis, MongoDB, etc.).
- Reduce competitor's moat: You can sometimes open-source a product that is another company's competitive advantage to compete with them. This can be done by reducing switching costs (Kubernetes/AWS) or AWS OpenSearch/ElasticSearch. Facebook created PyTorch to compete with TensorFlow, Microsoft, and other companies funding Rust development (vs. Google's Go).
- Goodwill: In the same vein of marketing, companies might contribute to open-source out of goodwill without a concrete strategy in mind. It could potentially yield interesting R&D, developer marketing, or even increase the talent pool of developers (through educational opportunities, e.g., Google Summer of Code).
- Standards Lobbying: Companies might contribute to an existing open-source project that is core to their business in order to ensure that the roadmap is aligned with their product. Incompatibility can create real costs for businesses: extra development time from maintaining a forked version or implementing internal workarounds. Sometimes companies will even put forward a vision of the future that's compatible with their internal work (e.g., Facebook/React).