Middleware - Beware

     A recent news article has sparked something I have been thinking about for a long time. The dependency a developer now has on middleware providers.
The industry over the last 15 years has switch from developing all parts internally for a program to outsourcing pretty much everything not directly related to the core experience of what they are trying to develop. 
    Middleware is probably not the proper term to be using here as middleware in the SE sense refers to software that connects disparate components together to create a working program. It is more correct to talk about licensed components. 
    These components are thinks like the Quake and Unreal graphics engines, PhysX and Havok physics engines, ProFX texture engines and many others. They generally have a fairly defined task at which the component developer has a large body of experience and has built and optimized toolset for. 

    Component purchasing has been a good thing for the industry in many ways. 3rd Party Components ease develop time and costs in that they reduce internal R&D and debugging. The cost savings have been fairly dramatic for most industries and the reduced R&D time has allowed better critical path management  (R&D can't be scheduled) so programs are finished on time more often than not.  

   An issue not considered until recently is - what happens when a Component supplier is purchased by your competitor. It has happened with Ageia (Nvidia), RenderWare (EA), and is likely to happen to Epic (Microsoft). 
   When that happens do you continue to use the technology you have licensed? Do you seek another Component developer (if they exist)? Or the final safest solution but definitely the most costly... back to the drawing boards and develop from scratch.

   Each of the solutions has it's drawbacks and advantages.

1) Stay with your Component Provider:
Good:
    No rebuilding of code
    No retraining on a new engine
    Critical path protection
    Lower risk of potential error
Bad:
    Possibility of your proprietary code/concept being seen by competitor
    Uncertainty about future of engine (can it be used for sequels)
    Will it be available for your Platform?
2) Change Component Supplier.
Good:
    No R&D Costs
    Protect your concept/code from competitor
Bad:
    Recode segments of your program
    Retraining
3) In House:
Good:
    Protect your concept
    Total dependability related to code ownership
    Can specialize the code more
Bad:
    Costs
    Critical Path Management
    R&D - requires specialized programmers and no set time
    Here's one we don't normally think of but - Potential Liability to original component supplier. Companies like EPIC hand over the entire source code to their engine when you license it. That means anyone that has seen the code and may be influenced by it's design can not be allowed to work on your internal engine.

    The balance act that is created by this is: Time. vs Cost. vs Secrecy. vs Longterm Dependability. vs. Liability. A lot to balance and yet it's something that Publishers/Management do all the time at a high level (most of us developer coder types don't really think about it.) I guess it is time that we do. If our product can be controlled by outside factors beyond our control is it  really our project anymore? Yes... and No. And that answer scares me.
    I wonder if these changes will create another change in the industry - back to the way it was - vertical code integration, accept the higher costs, and lower your risks. I suspect that it won't go that far but that we will be more circumspect about the components we buy and what our contracts entail. It's possible to put no acquisitions clauses into contracts and even stricter privacy rules.... so developers follow the lawyer path fully at last.