Posted on

To open source or not….

Ashok was perturbed. In Jan 2006, an eastern European company had taken his source code, made minor changes and started selling it under an alternate brand name at a reduced price. Ashok’s company Chartengo was a pioneer in Adobe Flash based charting software that helped users create charts for data visualization. Its charts were perceptibly superior to any available on the market. The company had five employees and revenues of $500,000 in 2006. It used to offer source code with its USD 99 developer version of the product. A growing business like Chartengo was sandwiched between free libraries on the Internet and large data visualization vendors (revenues > $100 million) on the other. In between it also had to content with few hundreds of competitors. The possibility of a vendor infringing on Chartengo IP in some distant corner of the globe was high.

Chartengo did not have a legal team so they contacted a firm that specialised in copyright infringements. The firm quoted $250,000 to file a suit but there would be additional fees for court appearances. besides the unaffordable legal fees, Ashok was apprehensive about the stance an eastern European court would take in this matter. He decided to forego the legal route. He talked to development team and few experts outside. A surprise suggestion with overwhelming majority was – make your product code open source. They said open source code will make it difficult for infringers to compete. Why should customers pay for a code that is open source from the original vendor? Ashok’s team of developers was thrilled with the idea of open sourcing their code. It would accelerate innovation and save them time developing everything themselves. They felt perhaps the customers would also be happy. They could also see an opportunity for higher revenues. The open source would probably draw more customers, especially those who were sceptic of dealing with a small company like Chartengo.

Ashok had so far found it the best strategy to protect its intellectual property. He believed innovation would only happen if it could be exploited for exclusive financial benefits of the innovator. How could he even think of handing over his crown jewels to the infringers in the marketplace? The thought of handing over his IP to these hackers and letting them enter their random untested code into it thus contaminating its pure quality was appalling to Ashok. He clearly saw his competitive advantage evaporating with opening his source code. Yet, at that time, open source was rising like a tsunami? Apart from individuals hacking into your code, well-funded companies were also doing so. There was passion about open source. Even customers were enamoured by open source culture. It was turning into a religion.

The question is – what should Ashok should do?

Posted on

Pricing dilemma

A year back I was involved with a leading mobile apps company on an issue related to product pricing. The company developed customized mobile apps for business. At the time it had a staff of 20 programmers and reasonably successful – having on its customer list several top global corporations like cola companies, few leading banks, advertising giants and others. It had revenues close to USD 1 million. The company had identified 20+ software functions (routines) that were commonly used in most mobile apps. They had put these together into a single library that programmers could access from a central repository when working on a mobile app project. Examples of such routines included memory management, real-time authentication, camera control, text messaging within the app and so on. Use of this central repository of frequently used routines had resulted in 30% saving in programmer time, standardization and uniform quality across projects, shorter time to market and finally the monetary benefit.

The company saw a window of opportunity externally. They knew the mobile app business was growing at a fast clip with app vendors mushrooming all over. They were also aware of the trend of end customers developing mission critical apps internally. Both these customer segments would see a value proposition in the library if the company offered it. The company was at a critical point – thinking how to breach the psychological revenue barrier of USD 1 million. It faced fierce competition that had brought down margins from 80% to 25% in just two years. They thought the library was a ticket to new profit stream and improved competitive position. They were debating how to price and market the product.

However this meant a sea-change in the way the company thought and worked. So far, they delivered single project as per known customer requirements to a single known customer at fixed price. They did their best to deliver within time and budget. They priced their services at cost plus margin. Any delay ate into their margin. Selling the tool externally would involve selling a generic product to external customers whose size and number was unknown and uncertain. They had a hunch but did not know for sure the external customers would really see value in the offering. For example a tribe of software programmers take pride in and get thrill from solving tough problems. They would not care for such a product. A few team members even felt that their competitors would also acquire the library thus diluting company’s competitive advantage in the market.

The company sought answers to several questions:

1. Should they sell the library externally at all?
2. Should they price it on cost plus basis or some other method e.g., value based pricing?
3. What should be the list price of the product?
4. What should be the license structure i.e., kind of licenses they should offer?

The company made a set of decisions. I will share those in the next post. Meanwhile, I invite you to share your suggestions on the questions facing the company.