About Mapping Open Source into Your Business Model
The Building an Effective Commercial Open Source Strategy workshop was a great opportunity to share ideas and talk about business case examples with industry leaders and experts from all around the (mobile) world.
- Open source economics;
- Collaborative open source development;
- Whole product solutions;
- Open source business models;
- The importance of Time;
- Customers’ and vendors’ perspectives.
Since open source software is just software, numbers like the average number of lines of code written by a programmer in a day, either the average number of bugs per 1000 lines of code, don’t change. In a slogan: Write less, reuse more. But in order to reuse open source projects, you need to spend time and effort to select them – what I call “the cost of free” – and also to support them. In fact, considering the general lack of enterprise support and the “open source mediation conundrum” – i.e. any given customer has a component distribution that falls everywhere on the open source long tail – internal open source support and development is a must.
Collaborative open source development maybe an option, an option many actors in the mobile open source world are looking into at the moment, maybe even to many as discussed over lunch with representatives of the mobile industry. A lot of food for thoughts here, many one-to-one conversations were just about how to start and foster an open source sponsored community around your own project. Sandro during his speech on successful open source marketing strategies, said that adopting the communicate early, communicate often approach pays, and can help to make your community ready-to-go as soon as possible. Talking about open source communities I mentioned group forming networks and why they matter, also quoting David Reed saying that gateway partnerships among communities of value may be the most efficient ways to create value (read inter-projects collaboration and super-communities).
Talking about delivering a “whole product solution” – Geoffrey Moore docet – helped to highlight the importance of distinguishing the core of a product from all its complements. Stephen Walli wrote few thoughtful slides (from 7 to 9) on how “Whole solution” business tools can greatly help a software business. Complements like add-ons, certification programs and consulting services should be carefully considered as a source of revenues and a medium to foster your ecosystem. Last but not least open source components can be used to rapidly develop products to fulfill over-served markets (e.g. Alfresco and the ECM space). I eventually talked about core competencies – defined by Moore as any process that contributes directly to the sustainable differentiation leading to competitive advantage in target markets – and how different they are from core value propositions, by definition customer facing. Understanding the difference between what people will pay for and which competencies can help you to get paid, is key to define and deploy your business model.
Open source business models are based on open source projects, either sponsored by your organization, third parties or “organic“. Your core competencies not only define your core value proposition, but they determine also your cost structure. Creating your own project or building it up using building blocks is one of the many business decisions having an impact on your business model. Adopting existing open source components could speed up your time-to-market, while requiring to participate or to sponsor those projects.
Time is also really important. Customers are willing to pay as long as they recognize a value in what they buy, and tipically they value things different over time.The classical software vendor strategy, keep adding new and new features, brings the vendor to over deliver sooner or later. Open source challengers then can enter in the market with low-end disruption strategies, as it happens with OpenOffice.org, even if still poorly delivered in the enterprise segment. Timing was also important for MySQL, at least twice. MySQL was indeed the first over move in the open source DBMS space. Later MySQL took great advantage of the dual licensing, a business strategy less relevant today – likely because a better general understanding of open source licenses’ obligations is shrinking the demand for the commercial license. Nevertheless MySQL happily shifted to sell subscriptions instead.
Customers’ and vendors’ perspectives towards the future of open source are different, I tried to summarize some of the most significant differences in the following table.
|Make a wish..||..granted?|
|Savings on licensing||Now. And than?|
|Avoid vendors’ lock-in||Multiple providers?|
|Enterprise support||Open source ecosystems?|
|Hw/Sw integration||“Stacks” assurance|
|All they want is..||it demands for:|
|Joining technological clubs||Participation|
|Shared R&D||Community building|
All customers want to save money, but they have to weight cost reduction initiatives against long run viability of software choices. Methods and metrics ranging from the GRAM/GRAS lists and the Qualification and Selection of Open Source software methodology here can be of help. Costs of exits might be lower with open source packages compared with their proprietary counterparts, still customers show little inclination to change unless effectively supported by open source vendors.
Avoiding lock-in is still an hot topic, but in order to mitigate those risks customers need to choose from a variety of different vendors, an option not always available, though.
Considering the general lack of enterprise support, even if big companies want to buy only from big solution providers, itis true that most of open source packages are backed by small vendors, with no or little ecosystem and poorly connected with bigger players.
Vendors enjoy open source innovation, think of the linux-embedded case, or the many initiatives in the mobile arena. Sequential innovation within technological clubs demands participation, and membership is not for free.
Open source software potentially saves industry over 36% in software R&D, and it is no surprise that vendors like the idea. Influencing or leading an open source project is about adopting a symbiotic approach and this is not for free too.
A strong brand comes with a business, but considering that appropriating returns from commons is not trivial many open source companies tend to to spend little money to build their brand. Protecting open source IP is important, and alliances and acquisitions can play a role here.
Vendors to have full visibility into the code base need to track contributions, trying to balance company’s interests with communities’ ones, not always an easy goal to achieve.
Loosely joined open source components require some effort to be integrated, few open source vendors spend time integrating their products with many other ones, leaving some space for open source stack businesses.
I want to credit and thank Stephen Walli for his great contribution, and all attendees to make the workshop conference such an interesting experience.