Let’s assume an open source project with a commercial sibling. The commercial sibling is differentiated with additional features, not present in the open source version. In this scenario the maintainer has a conflict of interests due to having two incompatible hats. One hat is being the open source maintainer, keeping a healthy community, motivating developers and presenting a future goal for the product. The other hat is the responsibility for maintaining the differentiation between the open source and the commercial version.
There are examples of this conflict in various open source projects:
- Wine vs. CrossOver – http://www.codeweavers.com/products/differences/
- PDT vs. Zend studio – http://www.zend.com/en/products/studio/compare
What would happen if a contributor would code a feature similar to the one present in the commercial version? It can be rejected, for some obscure reason, and the status quo kept. In the long run, the open source version will be less capable than competitors and the community will react with a branch. See foswiki vs twiki.It can be accepted and the bar between the open source and commercial grows, so the commercial part needs to invest effort to make the product worth the price difference.
Since open source is about sharing, having commercial barriers is almost an anti thesis. But with the right combination of offering (support, training, etc) and the right mix of features, the conflict can be kept to a minimum for the benefit of open source projects.
If you read this far, you should follow me on twitter here.
Related posts:
- Open source vs commercial – support
- Paying for open source
- Open Source makes better programs
- Software debt – another type of rot
Comments on this entry are closed.