Why Self-Enlightened Contribution to Open Source Projects is Difficult

Posted on

Self-enlightened contributions to open source projects are (code) contributions that come about because a company chooses to contribute. The opposite is forced open sourcing, which typically happens when a reciprocal license like the GPLv2 forces a company to lay open some source code.

Self-enlightened contribution is hard!

Here are three examples that might make a company stop a developer dead in their tracks when trying to contribute to an open source project:

  1. The contribution lays open the future product road-map of the company. Providing competitors and customers with this information can put the company at a disadvantage in its business strategy and contract negotiations.
  2. The contribution exposes the company to the risk of patent infringement litigation. Depending on the open source license, a company may be at a disadvantage now re: cross licensing agreements or become the target of patent trolls.
  3. The contribution makes a competitively differentiating feature non-differentiating in the market place. Open sourcing a feature makes it available to competitors and if this feature was a reason to purchase, the company just lost it.

Contributing (code) to an open source project is a business decision. To the developer it may just look like they are doing the right thing, but to a product manager it may look like the developer just gave away the farm (well, maybe part of the harvest).

Note to research sponsors: I’m still looking for someone to sponsor research into how product management interacts with open source; how to determine what’s a competitively differentiating feature and what is not; and how to determine it is time to let go of a competitively differentiating feature before your competitors do. If you find these research questions interesting, please get in touch.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.