Advocating For Corporate Open Source Contributions
Should a company building proprietary software, but using free software, contribute changes to free software projects it is using? Seems like a no-brainer for us engineers, but the business side of the company is often hesitant. The goal of this essay is to highlight benefits a company gets from upstreaming its changes to open source projects.
Cost vs benefit
The basic argument is this. Why is a company using free software in the first place? Because it is faster and cheaper to use already available software than to write it from scratch. The reason changes to free software should be contributed upstream is because not contributing them would cost the company more.
Most software is being actively maintained. It is, therefore, constantly changing. Suppose a developer makes a change to some free software library. Initially the cost of this change is the time the developer took to make it. But there is a long term maintenance cost as well - if the library changes, the initial version of the change may stop working. Then the company would have to dedicate more developer time to updating the change to work with the new version of the library. Alternatively, the company may decide to abandon their change, thus foregoing the benefits that the change presumably brought.
The stated benefit of hoarding the change is that the competitors will not be able to profit from it. But consider how much effort a competitor would need to invest to duplicate the change: roughly as much as the company did. Many changes, especially bug fixes, are fairly small. Thus the presumed effort that a competitor would avoid is insignificant.
What about larger changes? Just because a change is large does not mean it is relatively large. Look at Ruby on Rails - this framework is a result of hundreds if not thousands of person-years of work. Even a major change, say, one that is worthy being mentioned in a release announcement, is still a drop in the bucket compared to how much benefit Rails provides overall.
The Rails example is interesting for another reason: conceptually, Rails has not changed since its introduction. Phrased differently, anything that can be done today with Rails 4 could also have been done 5 years ago with Rails 1.1. It would have taken longer, but a company that used Rails did not get beaten in the market because their competitor also used Rails and furthermore used some feature of Rails that the first company did not.
Rails is nearly always changing incrementally. There are exceptions, like making activerecord write only modified fields on save rather than all of them, but they are few and far between. Especially between consecutive versions the differences are rather small. The benefits of hoarding a Rails change are highly questionable.
Another concern with larger proprietary changes is they are more likely to conflict with ongoing development of the free software libraries and frameworks. The larger a change, the more often it will need to be revised and the more work each revision will require. The cost to the company of hoarding larger changes is correspondingly larger.
Once a company sends its changes upstream, the upstream developers of the software take over maintenance of these changes. In most cases the company no longer needs to spend any developer time on change maintenance.
The business people should understand the cost/benefit tradeoffs, but there are softer factors in play as well.
Quid pro quo
Free software exists because some people are altruistic by their nature, and because some companies realize that by releasing their proprietary software as free software they will overall come out ahead. This last principle is similar to taking venture capital funding or expanding a market: a smaller portion of a much bigger pie is still larger than an entirety of a small pie.
In order for free software to exist, companies need to contribute to it. When companies refuse to contribute "just because", the company effectively takes a poisonous attitude toward the community. Some developers may not work for companies that do not respect communities they operate in.
Especially in companies without officially sanctioned free software contribution policies, it is up to individual developers to contribute to free software. By doing so said developers establish a name for themselves in the community. A company that prevents its developers from making free software contributions effectively restricts the growth of its developers, with the resulting developer unhappiness.
Companies that do encourage free software contributions may gain free advertising if their employees openly state that they work for company X. Of course, a company which is hostile to free software contributions is unlikely to have developers advertising it in this way.
Especially non-technical management sometimes considers all software that their company develops its "proprietary IP (intellectual property)". While that is technically true, most changes to open source libraries and frameworks that a company is using are not related to its core function, especially when these changes are bug fixes. Founders probably will not use "we fixed X bugs in Rails" as a reason to request a higher company valuation during fundraising. For major features that could register higher on the "proprietary IP" scale I would point out that contributing those features back to the community is a recruitment tool and probably outweighs any valuation increase in that capacity.