If only Newton were Apache....

Whilst I'm on a roll...

I continue to get asked by all sorts of parities, "Why is Newton using a GPL (actually AGPL) open source license? Why isn't it Apache?" Less frequently, the same question in another guise - "Why did Paremus set up codeCauldron rather than join Apache or Eclipse?"

This question usual emanates from one of three sources:

• Individual Developer: Usually very excited about Newton and its capabilities; typically a Samurai - (Paremus like Samurai!). The conversation goes - "If only Newton were Apache, I could deploy it in production without sign-off". The Samurai sees the value in the product, sees the vision - and believes (but cannot ensure) the organization will do the right thing; the right thing being to pay for support and consultancy services from the company that developed the product. Unfortunately I've seen exactly the opposite behavior from a number of Organisations! Many VC's believe without questioning - the diffusion model; i.e. "Give it away and the revenue will roll in" - yes, those very words have been used. My response - I continue to watch SpringSource and MuleSource with much interest! But I predict that the VC's in question are in for a shock!
  
• The Small SI: Usually want Newton capabilities upon which they can build business specific services - but do not want to pay for the privilege. Newton is unique in its capabilities at present - so either the SI must make their own derivative code GPL, or develop the equivalent of Newton capabilities themselves, or enter a commercial relationship with Paremus. If only Newton were Apache!
• Tier 1 Technology Vendors: Complain - "We (who shall remain nameless) cannot officially look at Newton code because it's GPL. Implication being: We are not interested in a commercial relationship with you, rather we want to see what you Paremus folks have, try and guess where you are going, and then do it ourselves. If only Newton were Apache!
  

So whilst capable of generating a large footprint, the Apache license model is, I believe, a significant barrier for small innovative companies wanting to build a financial successful business, as:

• Its easy to give something away. Trying to charge for usage a-priori - much more difficult! Again, I continue to watch SpringSource and MuleSource with much interest!
• The giants of the Software Industry, after the Linux/JBOSS experience have become quite effective at controlling open source communities, and neutralizing potential threats to the status quo; just my paranoid observations.

Perhaps Microsoft were correct all along?

That said, companies with closed source / proprietary software products seem to make the same mistake. The market is tough, developers opt for "free open source" solutions, our ROI isn't obvious? So give away the product based on some criteria - to customers with revenue below a certain level, or limited functionality / scale of the free product. Later - when the customer exceeds this boundary - we have them by the balls! (queue evil laugh). A viable long-term business strategy?

Again, I have my doubts.

Impaled on the Horns of an OPEX Dilemma

The finance industry are clearly having a tough time at present. As losses mount, CEO's & CIO's are increasingly scrutinizing the costs of doing business. One interesting metric, the cost of running a single production application; $1,000,000 per annum! Take the many thousands of applications typically used in a large finance house, and operational costs rapidly exceeds the billion dollar per annum mark.

Why is this?

Surely, over the last few years the Finance industry has increasingly driven down the price of enterprise software, to the point that an application server may now be charged at a few hundred dollars per node. Likewise, basic networking, server and storage are cheaper than at any time in the past.

The problem isn't the cost of the raw materials, rather the fact that these organizations have built increasingly complex environments which must be maintained by an army of IT staff.

I'm probably not far off the mark suggesting 80% of the annual cost for each application relates to support and development staff that are required to maintain and keep the application running.

And the choices available to the CxO?

• Use Cheaper Resource: Ship operations out to China, India or Mexico! While on-paper attractive as a quick fix; there is a catch. Wages tend to normalize as time progress, with the cost of initially cost effective workforces rising to the point that the Market will bear. Indeed - it has a name; "Free Market Dynamics". Hence within a reasonable timeframe (~5 yrs) - the cost advantage will evaporated; meanwhile the company is still left with a complex manually intensive operational environment. Traditional - third party outsourcing - of which there are several failed examples exist in the late 1999 / early 2000 period - fall into this category. This approach does nothing to address the the root cause of the spiraling operational costs – complexity! In short - a strategy guaranteed to fail in the medium / long term.
  
• Reduce the Number of Applications: If the cost relates to the number of applications - simply forcing down the number of applications in use will initially reduce OPEX costs. Whilst a reasonable strategy for some, the Financial Service industry is highly adaptive and constantly needing the evolve applications and services. Hence, a "no new" applications policy merely results in bolt-ons of additional functionality to existing systems - increasing complexity and associated costs of the remaining applications.
  
• Use Technology to Reduce headcount: The IT industry have collectively failed to provide real solutions to this! Despite a flood of Automated Run-Book, Monitoring, Configuration Management, Package / OS Deployment and Virtualization Management products, humans are still very much still "in-the-loop"; directly concerned with all aspects of every software service in the runtime environment. Environments are more complex than ever!
  

So what is stopping the IT industry developing the right products? Simply, industry continues to fail to realize that automation of the existing is not sufficient. A fundamental/radical change in perspective with respect to how distributed systems are built and maintained is needed to address the Complexity Crisis organizations now face. Funnily enough, this is what Infiniflow has been developed to address.

And the users of the technology?

• The fear of change!
  
• The linear relationship between status and managed headcount.
• And most importantly, a severe shortage of sufficiently talented engineers and architects that have the vision and determination to drive such changes through their organizations - (Paremus referring to these rather special individuals as Samurai).

So if you are a frustrated Samurai, contact us at Paremus, we can introduce you to many like minded individuals :)

Meanwhile, if you are a CEO / CIO with the desire to tackle the root causes of your organizations IT complexity - why not drop me an e-mail, and we'll explain how we might be able to help; specifically you may find the dramatic impact that Infiniflow has on operational cost of great interest.