Nearly twenty years after Richard Stallman wrote the first draft of the GNU General Public License, open source has really started to come of age in the enterprise. Industries which do the largest amount of custom development, notably financial services and healthcare, have either adopted open source software stacks outright or have used them as cornerstones of their internal operating environment. Today, participation in an open source project often wins a job seeker major brownie points for smarts and initiative when interviewing at a company. Yet, after that job seeker gets hired, eyebrows may be raised when they wish to continue contributing to open source projects on company time.

Is it a good idea to have enterprise software developers contribute to open source projects on the company dime? Several technology vendors have invested developer resources in OSS projects as a strategic move; we, however, are only going to consider this question for companies who use technology heavily as a means to their own business ends. We believe contributing to OSS can be a strategic investment for any company that does a large amount of custom development. Nevertheless, there are several good arguments to be made against contributing to OSS projects. Let us consider a few arguments a company may want to examine before investing development resources in an OSS project.

Why not contribute? A company may not want to contribute to an open source project almost instinctively. Resource conservation is a simple reason — why allocate developers to projects whose objectives don’t align with the profit-maximizing aims of the company? Legal and compliance pressures, especially in heavily regulated sectors like financial services and healthcare, may hold back companies from potentially exposing themselves to liabilities by contributing to open source projects. For these companies, there may simply be too much at stake in terms of fiduciary or privacy issues to realistically consider ongoing contributions to OSS project. Even if there is a will to contribute to OSS, there are often logistical problems–there aren’t enough people who understand the intricacies of both technology and compliance to bring about a culture of contributing to OSS. Moreover, players in businesses like financial services, where having the right technology at the right time for as long as possible can mean handsome profits, rarely want to contribute to open source projects because they effectively see it as ceding any competitive advantage derived from technology to the public domain. Finally, there’s the issue of code quality. In-house software development often produces code that works well to solve a particular business problem. Making the code general enough to free it of domain constraints may often prove difficult, if not impossible.

Why contribute? Despite all the above questions, which we think are valid when entire business models are at stake, companies that do a lot of custom development have not shied away from including open source into their operating environments. A lot of the time, these companies take an open source codebase and augment it with changes specific to their own needs. If these changes are not contributed back to the parent OSS project, the company undertakes the task of maintaining a codebase that may not directly relate to its revenue-generating activities. What’s more,  these changes have to be forward ported to future versions of the parent OSS project as well. Contributing proprietary changes back to the parent OSS project relieves a company of at least some hassles associated with maintaining its own fork of an open source codebase.

When weighing whether contributing to OSS projects using company resources is a good idea, it is worth considering emergent positive and negative network effects. As often as companies in a sector like to play the lone wolf in search of competitive advantage, they are often up against the same technical problems as their competitors. If contribution to OSS becomes more prevalent among competing companies, it can very often lead to an increase in the shared understanding of a problem domain. On the flip side, we believe that companies taking code from OSS projects but not giving back might jeopardize the sustainability of what led those companies to OSS in the first place. If, say, a large enterprise continues to use the products of an OSS project without giving back to the project, and all its competitors do the same, then nobody with a true understanding of how certain problems are solved in a large enterprise would be contributing to the project. This cannot be a good thing for a project or for its large enterprise adopters; the project might end up merely being a proof of concept solution, which enterprises have to tweak heavily to fit their business needs.

It’s evident that there is no easy answer to the question of whether it is a good idea to allocate some development resources to OSS projects. Even if companies hope to take advantage of network effects arising from contributions to OSS from themselves and their competitors, there is still the prisoner’s dilemma of who will bell the cat. Today’s developer workforce is not just comfortable with using open source; in many cases, these open source projects have become indispensable to the technology value chain within an organization. As new leaders emerge from this OSS-enabled generation of developers, we hope for a long term sustainable solution to what otherwise seems like a enterprise-scale game of chicken.