I have been asked to write an article for the first Allevo newsletter of 2016. Then I got a wealth of friendly advice on how to do it – comply KISS (Keep It Simple Sorin – to just paraphrase their saying), be positive, don’t address uncomfortable themes, and lot more. Here I go and hope to be sufficiently alive to publish the extension of this post – discussing the risks related to OSS.
Allevo’s FinTP software application suite is available under GPL V3 licensing frame in two distributions: 1. community free unconstrained full featured and 2. Allevo guaranteed one. FinTP is a real-time middleware for financial instruments, standards and regulations compliant, bridging the communication between external channels, protocols and services, and an institution’s resources, operations and business systems.
Lately I’ve been hearing the following question: is FinTP a disruptive software application development project?
Considering the widely agreed criteria to discern Disruptive Innovation* cases, it should:
- Be Cheaper – from customer perspective
- Be More accessible – from usability and distribution perspective
- Have a business model with structural cost advantages – as compared to existing solutions
* As summarized by Maxwell Wessel (a venture capitalist at Sapphire Ventures) in his article “How Big Data is Changing Disruptive Innovation”, published in Harvard Business Review, January 27,2016
I would venture to say FinTP meets all these criteria: it is a disruptive project and a disruptive software application. All that remains is for the market to confirm it.
The natural next question to address is if disruptive and innovative features of FinTP make a real difference to adopters?
- If adopters are customers (enterprises embracing FinTP for productive use), the ones with deeper pockets will most probably value having the technology the low market players will use to compete beforehand (worth to remind in context the ‘knowledge is power’ cliché). The low market players (SMEs) will accede an affordable solution to perform same operations high end players use to fulfil their business.
- If adopters are system integrators, solution providers, ISVs, or service providers (like PSPs for instance), they will all benefit of practice proven technology, cheap – straightforward components to proof concepts, and to further architect and upscale their projects.
I’ll build the rest of this post on this premise – a disruptive innovative FinTP – and will approach the uncomfortable comments collected in the recent past. For instance, how does the value delivered by an open source software application distributed under company’s guarantees compare to a controlled IP distributed one?
- Assuming a same set of functionalities, the open source application delivers to the customer the source code, thus removing the need of the ‘escrow agent’ service and empowering it to internalize full control on the application continuous maintenance and development.
- If so, why should I opt for the guaranteed distribution? Because it can free internal business, operations and IT resources from the servitude of ensuring recurring maintenance, and allow their allocation towards business developments facing the adopter’s customers – an area of higher competition.
- If so, how will my staff internal developments be supported by the provider of he guaranteed distribution? As long as the internal developments are share-back to the community, or at least with the provider, the recurring maintenance will include the needed support.
- How do I choose the SLA provider – since we reference an open source community? The only criteria are trust and proven quality of the provided SLA. A way around this dilemma is to replace the customer to provider relationship, with fully defined partnership – obviously different liabilities are to be taken into account.
- As CIO, how am I going to justify the need of an external provider, while I have at hand a wealth of information? The simplest way is to draft budgets for each scenario and compare those both quantitatively and qualitatively. It can be that the saving opportunity is less significant than improving resource allocation.
- If the application is mission critical for performing financial business, how safe is it to rely on open sourced code? There is a twofold answer to this quiz:
- The guaranteed distribution provides an SLA which indisputably covers the security requirements to be fulfilled according to each customer specific implementation. That’s fully equivalent to the guarantees extended by constrained IP application distributors.
- The community distribution, which in itself does not provide legal binding warranties, benefits of the expert contributions of the participant professionals, while the commitment rules enforce the needed discipline of promoting contributions to the project’s core.
Bottom-line is that it’s a matter of balancing between the two models of distribution, based mostly by the organizational given culture and the cultural trend envisioned.
- 3. The availability, robustness, stability, compliance to standards and regulation of software applications are highly required features. Will open source software meet these requirements?
Most certainly it will, in both available distributions. While for the company’s guaranteed distribution the SLA is a pretty good control of deliverables (source code and ancillary services) consistency and quality, for the community distribution the contribution commitment constraints play the quality assurance watchdog role. It obviously remains a matter of consideration the degree to which the community becomes self-sustainable. The community self-sustainability directly depends on product traction, which hopefully will evolve along consolidating the market awareness of the product.
- 4. Well established providers ensure knowhow transfer – if we only ponder the best practice enforced by the application implementation. Will open source application deliver a comparable value?
I would say that open source applications deliver even more than that, because they embed explicit and complete application concept documentation, the source code itself, the explanation on how additional customized financial instruments or operational and business flows can be added, how specific data mapping can be handled, how new intelligent reporting can be generated etc. Summarizing, the open source distribution provides explicit self-sufficient documentation, along the optional services to assist the customer to define and implement new specifications.
- 5. Software vendors consolidate their user group community – customers and partners; what could the equivalent of a user group community be in an open source setting?
Open source software in itself is based on tight and transparent collaboration (during the entire software lifecycle) between the adopters (demand side) and the providers (supply side). All these parties play a role in the community, they witness and contribute to product enrichment and consolidation (new specifications, new design, improved coding and testing, better support processes, better and more clear documentation), while direct and virtual gatherings fuel more effective experience sharing.
To conclude, I am executing the ‘sit’ command (the single one my dog unmistakably associates with sweet treats): I stop writing; I await my reward – which if convenient, will make me come back with open source software risk related comments. To all those who will hate me receiving candies, my advice is to pray that I’ll wait in vain for my reward.
Author: Sorin Guiman, Allevo Co-Founder