With the release of RiverMuse open source ‘core’ product a number of people have been asking me about the pros and cons of open source. It’s new to our industry, so the implication and benefits (to customers and vendors) are not well understood.
above. thanks to http://www.flickr.com/photos/daviderickson/ / CC BY-SA 2.0
Herewith, my take on it…
Is open source really new to the OSS/BSS industry?
Well, ok, no. It depends how you look at it. Many large telcos have had open source policies for many years. British Telecom, for example, had a two-pronged approach to IT platforms (including OSS and BSS platforms) that preferred one commercial stack and one linux-based stack. The benefit being:
- They could buy in, and support, open source platforms a bit cheaper than commercial platforms.
- They could use Point 1 to drive down the prices charged by their commercial product vendors.
Use of open source platforms, as in the operating system and some key components like Apache web server, is pretty well established in the wider IT world. It’s a low risk strategy.
Open source telco applications are much rarer. Business critical, 24/7, applications even more so.
Many of the big-vendor OSS products were ported to run on Linux a few years ago. Few get open-source-ified above the operating system level. Other open source components, like MySQL databases and jBoss application servers, have no support outside of small, tactical, solutions (until now).
Bits of open source underpinning OSS/BSS solutions are not uncommon; A complete stack of open source, supporting a major OSS process, is something new.
Will the quality be up to business-critical standards?
I expect so. If it’s not, that is nothing to do with it being open source.
The fear of open source tends to be:
- It’s written by kids in their bedroom, with insufficient control over design and implementation.
- The kids aren’t even using their own code. They’re ripping off IBM/Microsoft/SCO/Whoever. No one’s checking the origins. You’re going to end up on the wrong end of a lawsuit for using unlicensed code.
This argument has been doing the circuit for many years, mainly being aimed at big targets like Linux and Apache. Both have stood up to the test remarkably well. Quality is at least comparable with commercial products. The big IPR lawsuits have pretty much failed.
Any responsible CIO or IT team should consider these issues, but that should be equally true for software from commercial organizations as well.
A key consideration here is the nature of the OSS/BSS industry, and RiverMuse is a fine example: Bedroom coders aren’t writing OSS applications. Professionals, managed within proper businesses, are writing the code.
Outside of the high-profile ones, most long term open source projects are almost entirely coded by a team within, or sponsored by, one commercial organization.
How will RiverMuse make any money?
There’s a few different open source business models, two of which are:
- Release a fully-featured open source product and generate revenue from services and support only.
- Release an open-source product with core functionality, sell services and support, but also sell closed-source complimentary products.
Model 1 is most peoples idea of open-source, but it’s Model 2 is where the larger open-source companies expect to see revenue. For open-source platforms, like Red Hat Linux, and both MySQL and Ingres databases, the core product is free while the ‘enterprise’ or ‘server’ versions are chargeable.
I would expect RiverMuse to be releasing only the core product as free, open-source. In fact, in some recent coverage the term ‘core’ has been used to refer to the community release.
Announcing an open-source product is also a good marketing move. It generates buzz; I’ve seen far more blog coverage of RiverMuse than any other recent product launch.
In some cases it may also mean RiverMuse gets a foot in the door. Some OSS deployments exist by evolution rather than creationism. If a few companies start to deploy RiverMuse as a cheap, possibly short-term solution, then they have a stronger starting point for commercial negotiations.
That said, I don’t expect many big, tier-1, customers to be won this way. Selling to large organizations is no easier with open-source than it is with commercial, closed-source products.
Should established vendors go open-source?
Sure, why not? Or, if not open-source, then perhaps free core products with at least useful APIs. Some sort of ‘community’ release.
Apart from it being a useful sales and marketing strategy (see previous answer) it offers other benefits to the vendor:
Allows them to focus on building value propositions for new solutions (catalog, BPEL, service management, data federation, and so on) rather than having to justify the cost of a big bag of pricey products. For example, free inventory but you pay for automation and activation.
It can build a community of companies enhancing the core product or offering value-add functionality. Encouraging more development, such as the Sincera SASI product, would be A Good Thing, extending the OSS vendor’s functionality at little cost to them.
Actually, I’m not fussed as to whether a free or open-source version of the vendor’s products are released. I believe that open-source offers limited benefit over free (but closed-source) software in our industry, simply because there isn’t actually a community of independent developers wanting to tweak existing products. The need is more about allowing third-parties to configure, integrate and compliment core OSS capabilities. It’s more about allowing add-ons, adapters, interfaces, and cool GUIs to be developed, most of which would be through normal customization methods rather than hacking core code.