様々な理由でオープンソースのソフトウェアプロジェクトに携わってきました。

(1) その機能が必要だったので / 自社の利益のために必要だったから

自分たちの都合のためにオープンソースソフトウェアに修正を行い、自分たちの利益を最大化するために共有して、結果的に貢献したことになる場合があります。

まず前提として、オープンソースソフトウェアに欲しい機能が欠けていたりバグにより困っている場合には、プロプライエタリなソフトウェアにはない解決方法があります。
プロプライエタリなソフトウェアと同様に他のソフトウェアに乗り換えたり、要望を出しておいていつか対応されることを願ったり、資金を提供して優先的に実装して貰うように交渉を試みたりもできますが、オープンソースの場合にはこれに加えて自分でソースを弄って実装するという選択肢があるのです。

そして、多くの場合はこの修正を自分だけで独占せずに大元の開発者を通じて皆に共有するのが合理的な選択です。というのは、この修正を共有せずにいようとするとコストが嵩むからです。利用している間セキュリティ上の問題がないかどうか自分たちだけで確認し続けなければなりませんし、元のソースが更新されたことにより修正内容が素直に適用できなくなって手間を取られることもあります。一方、自分が書いたものを他人に共有したところで自分が損をするわけではないので、総合的に見て共有した方が得なのです。

こうして、結果的にオープンソースに貢献することになります。

なお、追加しようとする機能が独特の一般的でない事情による要求から来るものであって、共有する意味がなかったり開発元に統合を拒否されたりすることもあります。こうした場合には大抵「独自の機能を追加できるプラグイン機能」を開発することになります。
また、稀にその機能が自社の競争力の根幹に関わるものなので共有したくないという場合もあります(こういうケースは想像以上に稀です)。この場合も同様に、独自の機能拡張をできる機能を追加することになります。

(2) 面白いから

世の中には様々な面白いオープンソースプロジェクトがあり、そこに参加するのは楽しいです。この楽しさには様々な種類があって、大規模なプロジェクトならではの興味深い問題があってそれを解くのが楽しかったり、業務以外で別の人たちと共同で開発作業をするのが楽しかったり、自分が惚れ込んだ製品がよりよいものになっていくのが楽しかったりします。

別に既存のプロジェクトに参加することなく、自分でオープンソースでないプロジェクトを立ち上げて同じことをやっても良いのかもしれません。
ただ、多くの人に使って貰い大規模なプロジェクトに育てるのも一緒に開発する仲間を集めるのも惚れ込めるだけの良い製品にするのも難しいことですし、今のようにオープンソースが一般化した状況でそれを実現するためにはプロジェクトをオープンソース化したほうが楽ですから、結局「オープンソースに貢献する」ことになるでしょう。

(3) ポートフォリオ構築のため

オープンソースであればプロジェクトにおける自分の実績を誰かに見せるのは容易ですから、転職や報酬交渉の際にうってつけの交渉材料になります。特に、それが著名なオープンソースプロジェクトであればなおさらです。

これに対して業務でプロプライエタリな製品を開発している場合には、自分が具体的にどのような貢献をしてどのような結果が得られたのかを外部に示すのが一般的に難しくなります。業務システムや開発基盤のような社内のユーザー向けのソフトウェアを開発している場合、そのプロジェクトの存在自体が一般的に知られておらず、実績を理解して貰いづらいこともあります。

(4) 業務上の戦略に従った結果

ソフトウェア企業は様々な理由から自社の製品の一部または全部をオープンソースライセンスで公開することがあります。この場合、業務としてこのプロジェクトに携わっていれば結果的にオープンソースに貢献することになります。