The Business of OpenSource Software
Richard Stallman the founder of the Free Software Foundation and inventor of the GNU General Public Licence (also known as CopyLeft) defined the 4 freedoms of free (where usually free is classified as "free as in speech" rather than "free as in beer") software as:
A little economic theory goes a long way here: If a market provides high profit margins it will attract competitors who drive prices down until only marginal profits are earned (also known as Perfect Competition). One set of factors (there are others) that prevents perfect competition are known as Barriers to Entry. For software they are installed base (the network effect) and the huge investment needed to create new applications (also known as sunk cost). Looking at the profit margins of software companies, it becomes obvious that they run very attractive profit margins (the marginal cost for the second license of a developed software are practical 0 - not to confuse with "cost of doing business"), which point to high barriers of entry.
OpenSource lowers the sunk cost barrier by allowing to spread the market entry cost over many participants, so it becomes possible to compete. It is also a way to starve competitors off revenue in their key market to make it more difficult to compete in your own markets (history tells: if the war chests are empty agression subsides). OpenSource can be attractive for customers as well. I've not come across any larger customer where software didn't get heavily customised. The cycle looks mostly like this:
A vendor releases a software (e.g. SAP, Oracle, IBM or Microsoft) and customers engage professional service to adopt the product to their needs. This service can be rendered by the vendor's consultants, independent system integrators like Accenture, Wipro, TCS etc or by inhouse expertise. Problems or wishes in the core product are fed back to the vendor with the hope (and political pressure) for creation for the next version. Corporations pay maintenance but have little influence on the product manager's decision what will be next. Once the new version comes out the cycle of applying customisation starts anew.
In an OpenSource model the mechanism (ideally) would look different. Corporations would not pay for software licences but for know-how, implementation and help desk. By letting their staff or the staff of the chosen implementer (who could be the OpenSource project principal) become contributors they can yield a much bigger influence over the features and direction of the product:
Money is spend tied to the implementation of specified features. Customisation would flow back into the core product, so once the next release is out these don't need to be reapplied. If a large scale customer disagrees with the general product direction they could fund a fork of the project and go their own way. As the example Debian/Ubuntu shows that separation doesn't need to be 100% but could be to still reap benefits from a shared code base. Also companies would gain the freedom to choose whom to ask to fix a bug (or implement a feature) out of a release cycle. This way they can reduce the total bill (Part of the profit margin stays in the corporation). The lower licensing cost will probably require higher consulting fees. It would be interesting to "run the numbers" and include productivity gains by better tailored software. One big OpenSource platform that is driven by customers (and academia) is OW2 Consortium with an impressive list of infrastructure software. The big wildcard in this scenario are the system integrators. So far I haven't seen them pushing the model: "Let us provide service and support and customisation for your OpenSource". It could be that one one side they don't want to endanger their supplier relations with the large software houses and on the other side the idea, that a company simply could give back their customisation to the core product (and thus potentially to the competition), seems rather alien for business people. Another reason could be that OpenSource is perceived as "risky". Anyway the big vendors have understood this threat, hence the fierce drive to move everything into the (propriety) cloud. We live in interesting times.
- The freedom to run the program, for any purpose
- The freedom to study how the program works, and change it to make it do what you wish. Access to the source code is a precondition for this
- The freedom to redistribute copies so you can help your neighbour
- The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this
A little economic theory goes a long way here: If a market provides high profit margins it will attract competitors who drive prices down until only marginal profits are earned (also known as Perfect Competition). One set of factors (there are others) that prevents perfect competition are known as Barriers to Entry. For software they are installed base (the network effect) and the huge investment needed to create new applications (also known as sunk cost). Looking at the profit margins of software companies, it becomes obvious that they run very attractive profit margins (the marginal cost for the second license of a developed software are practical 0 - not to confuse with "cost of doing business"), which point to high barriers of entry.
OpenSource lowers the sunk cost barrier by allowing to spread the market entry cost over many participants, so it becomes possible to compete. It is also a way to starve competitors off revenue in their key market to make it more difficult to compete in your own markets (history tells: if the war chests are empty agression subsides). OpenSource can be attractive for customers as well. I've not come across any larger customer where software didn't get heavily customised. The cycle looks mostly like this:
A vendor releases a software (e.g. SAP, Oracle, IBM or Microsoft) and customers engage professional service to adopt the product to their needs. This service can be rendered by the vendor's consultants, independent system integrators like Accenture, Wipro, TCS etc or by inhouse expertise. Problems or wishes in the core product are fed back to the vendor with the hope (and political pressure) for creation for the next version. Corporations pay maintenance but have little influence on the product manager's decision what will be next. Once the new version comes out the cycle of applying customisation starts anew.
In an OpenSource model the mechanism (ideally) would look different. Corporations would not pay for software licences but for know-how, implementation and help desk. By letting their staff or the staff of the chosen implementer (who could be the OpenSource project principal) become contributors they can yield a much bigger influence over the features and direction of the product:
Money is spend tied to the implementation of specified features. Customisation would flow back into the core product, so once the next release is out these don't need to be reapplied. If a large scale customer disagrees with the general product direction they could fund a fork of the project and go their own way. As the example Debian/Ubuntu shows that separation doesn't need to be 100% but could be to still reap benefits from a shared code base. Also companies would gain the freedom to choose whom to ask to fix a bug (or implement a feature) out of a release cycle. This way they can reduce the total bill (Part of the profit margin stays in the corporation). The lower licensing cost will probably require higher consulting fees. It would be interesting to "run the numbers" and include productivity gains by better tailored software. One big OpenSource platform that is driven by customers (and academia) is OW2 Consortium with an impressive list of infrastructure software. The big wildcard in this scenario are the system integrators. So far I haven't seen them pushing the model: "Let us provide service and support and customisation for your OpenSource". It could be that one one side they don't want to endanger their supplier relations with the large software houses and on the other side the idea, that a company simply could give back their customisation to the core product (and thus potentially to the competition), seems rather alien for business people. Another reason could be that OpenSource is perceived as "risky". Anyway the big vendors have understood this threat, hence the fierce drive to move everything into the (propriety) cloud. We live in interesting times.
Posted by Stephan H Wissel on 06 December 2010 | Comments (1) | categories: Business Software