The Real Truth About Open Source Software Business
Imagine you are an author and you’ve just finished writing your first full-fledged novel. You’ve sent it over to a couple of publishers, time passes and one morning your favorite publishing house calls you. You’re excited, the first minutes of introduction go really well, and then the guy starts explaining that he likes your work, sees some value but has no intention to pay for it. Why? You ask. Well since you’ve used an open source language… English, of course.
You’re baffled, so you can’t do anything but continue to listen. The publisher has read your story to the end, and he couldn’t find a single word which he didn’t already know! So why would you expect to be paid and receive royalties? Rather he’s calling to offer you a special price for the amount of paper and ink they will need for printing your re-arrangement of something widely known. You still don’t know what to say. He finishes by stating that you will have to contribute your work to the Open MotherLanguage Group (OMG) for ensuring absolute compatibility and allowing people to take it and turn it into their own story. You hang up…
The biggest opponents of this strategy were the operations teams, partially for good reasons. You have terminals from vendor A and amps from vendor B and something goes wrong… who do you call? Despite of all ‘best of breed’ and ‘mix ‘n match’ messages, the most seamless, and supposedly, smoothest way of running networks is to use only a single vendor. No finger pointing, no interworking tests and no (lack of) network management integration… sounds good to operations, but comes with a high price tag and often a limited overall performance (and the insight that there’s no such thing as seamless, but there’s always finger pointing).
In days of shrinking margins despite ever increasing bandwidth requirements, that might be a luxury carriers need to move away from. Luckily, all these ‘open’ network stories have appeared at the right time. Time for a preconception re-check…
The advantages of introducing alien wavelengths are obvious: instead of ripping out a complete network, deploy some new P-OTS’, connect them to the filters, make sure that the new wavelengths don’t overlap with what's already there and you’ve turned your faithful 10G network into a new one, carrying 20 times the bandwidth per lambda via shiny 200G transponders. Even adding guard bands to minimize the risk of interference doesn’t spoil that business case, and old 10G channels can remain in place for as long as necessary. The ability to manage such a network end to end is a number one priority, which can be broken down into visibility of what's going on and the ability to troubleshoot in case something goes wrong. Let’s tackle them one by one…
Hand on your heart… how much does this remind you of what’s going on in telecomsland? The issue is that you just can’t hang up when your customer calls you (even though you sometimes might feel like that)… you want to work with them, build solutions that make them successful and to create a win-win situations. Oh yes, and you want to get paid…
Other than battling the impression that hardware is so commoditized that we should sell it by the pound, the biggest issue of vendors is changing the mindset that everything open-source (or related to open-source) software should be more or less free. The ‘end game’ of open-source is ultimate compatibility, smooth onboarding and limitless interworking. However, a lot of water will flow down the river until this vision will come true. The inherent and ever increasing complexity of solutions will make this path even more difficult. In order to survive and to avoid stagnation, vendors need to build both products and business models that leverage the power of open source but demonstrate the added value a vendor can bring by either refining or hardening the respective solutions or building something on top of them.
A lot is left that needs to be figured out… how would system integrators and resellers benefit from a customer downloading Apps or VNFs from a vendor owned store? Who ensures alignment between the open source code found on the Internet and the “hardened” versions of it? And who will push for it? Is it in the interest of a vendor or a service provider to find the code (they’ve invested in) free of charge on the internet? In case at least large service providers have their own developer teams, where will that leave the vendor community in general? Will the future of telecoms be a bunch of consultants fliting around a few service providers who are developing their own systems?
It feels cool asking those questions… less cool once you realize that questions like these will define the future of your own industry. Also here it looks like the revolution is about to eat its own children… this time by going back to pre-historic models where service providers build their own solutions. But that’s an extreme which only a few will be able or willing to afford, since it completely contradicts the fundamental strategy of keeping companies focused on their core business. Unless some SP’s will start selling their homegrown solutions to other SP’s. Funny thought, you say? Well, isn’t that only one step away from the current ONAP initiatives? What would stop a company that has enough resources for developing code for free, from selling either a better version or some apps build on top of it? Just asking…
But enough of doom and gloom… let’s close with some practical ideas for our community going forward:
- Firstly we need to stop attributing characteristics to open-source software that were not intended … just because its based on open source doesn’t mean it needs to be free.
- It has many benefits and huge potential, but its real advantage might be enabling the creation of an interoperable ecosystem where everybody can benefit from. Either by picking best of breed combinations for certain applications or by finding the right spot to bring in own solutions.
- So let’s stop talking about open source and embrace open interfaces, which are the key to our open future. Many activities of industry bodies like the MEF are about exactly that… making sure that modules are interworking seamlessly. No vendor can afford building closed systems anymore.
- But it should be possible to accept “closed” modules, to ensure that vendors have room for being innovative and for protecting the value of their work. And no one should be bothered if those modules are not always based on open code, as long as their interfaces allow their seamless integration.
- It goes without saying that dreams of remaining just “product sellers” will turn out pretty unrealistic, regardless of how good the products might be. Vendors don’t need to wave product selling goodbye, but have to become experts in customization and integration.
What wasn’t possible on a grand scale for hardware is now becoming a baseline requisition from Service Providers and thus a key differentiator for showing customer orientation and the ability to adapt. “Organizations that will be adaptive are the ones inventing the future”… let’s go out and define our open future.