To make it short: I believe the most direct reason why companies contribute to open source projects is to lower their cost of consumption of that very project. Specifically, contributing to a project builds competence in that project, and employing committers builds additional foresight and influence. General compentence makes the company use the software more effectively, avoiding costly bugs and rework. Foresight and influence helps the company avoid misalignment of their products with the evolving open source software they depend on. Such misalignment can also lead to costly rework and missed market opportunities.

I’m not aware of any RoI model that helps an engineering manager determine how much to contribute to achieve how much lower consumption costs and risks. Because of the step function from contributor to committer status for the involved employees, the investment return is not a linear function, that much we can say. The rest remains imperfect science for now.

Related

One Reply to “Why Companies Don’t Always Free-ride on Open Source Projects”

Agree that cost is the main driver here. I see in practice that configuration management plays a role as well: By contributing a feature (or bug fix) to the public source ensures that further changes (done by other people) won’t break that contribution, and that it will be present in future releases of the open source software.