Open source or proprietary?
Posted on June 20, 2008 | Categorized under Software
Open source software development methodology is based on voluntary contribution from geeks around the globe. Followers of it strongly believe into evolutionary and collaborative progress. It appeals to giving-back nature of people and as participants work on projects they enjoy to work on, naturally gives better quality products. On the other hand, proprietary i.e. closed source software development methodology is more formal in nature. Companies hire people with required skill set and pay them to develop products in required timeframes with specified requirements. Companies themselves have profitability motivations driven by competitive market. Open source seems more predominant in academia while proprietary looks prevalent in industry; which is quite as expected because knowledge sharing is the ultimate focus in academia while money is what counts most in industry.
“History confirms that knowledge sharing has fostered accumulative scientific progress avoiding reinventing-the-wheel phenomenon. If scientists had kept their inventions secret and instead had provided fees based services over those inventions, without revealing the logic behind it, then we would have still been in an era of wondering whether the Earth rotates round the Sun or the Sun rotates round the Earth!”
Open source supporters often argue somewhere along the above lines to promote it as a better software development methodology. And then counter arguments posed by proprietary software followers go into somewhat the direction below …
“Software development is a process which involves creative as well as not-so-creative tasks. Development process based on volunteer contribution from people because of their sheer interest and philanthropic motivations can not ensure execution of all types of tasks upto required extent. A more formal approach can ensure it and that requires building an organization. As code of a software product generates revenue for the organization to sustain, it’s an asset and free distribution of that may not be in the organization’s best interest. That will affect competitive advantage which is a long proven motivation to produce better products or services.”
Well, it is quite fair that these two methodologies have constantly been compared against each other but where it gets wrong is when the comparison tries to prove one better than another in all circumstances. Rather, instead of embracing one of them too tightly, a company can benefit more and can produce better value for its customers by adopting a genius of AND. Products, that differentiate a company from others, certainly be kept proprietary. Though it will take away freedom to know source code from its users, it will ensure company’s competitive advantage. On the other hand, the same company can encourage development of complementary applications around this product using open source methodology — by publishing a well-defined Application Programming Interface (API). By fostering collaborative development of such applications, it can help to create a range of different applications as well as enriching existing applications with a large number of features developed by various developer communities — this kind of scale is nearly impossible to achieve with a completely proprietary development.
As a matter of fact, both the methodologies have their own advantages. Proprietary products can better target mass markets as a company can invest into building a generic product and then marketing it to a large population; whereas, an open source product can target a specialized interest better as it usually relies on network effect to reach people and also people sharing a specific interest can collaborate more likely and more effectively. In case of proprietary products, customers have an official entity to get back to in case of required support. While, an open source project gives an advantage of distributed support system so if a group that initiated development of an open source project fails to sustain, third parties can study source code and offer independent support services.
Given such divergent facts, it makes more sense to evaluate these methodologies specifically against roadmap for a product, than to prove one better than another in a generic sense, doesn’t it?
If you find this article interesting, please make sure that you subscribe to RSS Updates .
ADVERTISEMENT
I vote for info sharing! It definitely fires people up and gets whatever project you are working on moving! Thanks for a great post.
Proprietary for only one reason: open source is easier to hack.