While a significant portion of development on FOSS projects is undertaken by volunteers hacking on their free time, the majority, at least on high profile projects like the Linux Kernel is undertaken by organisations to further their own agendas.

Why do organisations contribute to FOSS projects?

Any organisation may make use of a FOSS project, provided they comply with the licence terms. This is appealing for organisations as there is often a FOSS project that does approximately, if not completely, what is required.

Organisations may make changes to make the software suit their purposes better, and they do so freely, providing that they comply with the licence terms.

No FOSS licence requires that organisations contribute their changes directly back to the upstream project, and if an organisation is only making a one-off product and there are no ongoing updates required, then there is no compelling need to contribute the changes upstream.

However, this is an unlikely situation; the success of one product can imply a future product line, and all our gadgets are increasingly connected, so security updates are an essential feature.

Both the case of new products and the case of updating existing products for security or functionality reasons imply the need to use a newer version of any FOSS project used in the product. Since projects change over time to adapt to the needs of their users, and it is a relatively safe assumption that there's an overlap between the needs of the users of the FOSS project, and the users of any given product.

If an organisation chooses to use a new version of a FOSS project than previously used, they will need to port any locally held changes to the new version. This becomes harder the more that the 'upstream' FOSS project has changed relative to the last time the organisation updated. So it becomes more sensible, both from a cost and an efficiency point of view, to 'upstream' any changes so that they are included in the FOSS project, so that there is no need to port the changes or make equivalent changes all over again.

As an added benefit, working as early as possible with the 'upstream' on a change ensures that those responsible for the FOSS project can say whether it is a reasonable approach, as they likely have expert knowledge of the domain.