Another Business Model for Software Companies?

I attended a meeting last week with Peter Bostrom, BEA’s Federal CTO. During a discussion of open source in the DoD, he made the valid point that integrators aren’t the best suited for developing large scale software products. They don’t have the product management capability, standards body interaction, versioning expertise and all of the other product-oriented DNA that is necessary to effectively develop software products.

I’ve posted before that I think widely used infrastructure projects like the Army’s SOSCOE (the software underpinnings of Future Combat System) should be developed under a “funded open source model.” In the future I would like to see contracts written that still expect delivery of functionality within a particular time frame; however, with additional deliverables that require the contractor develop and host an open source community around the product.

Today traditional software product companies like BEA participate in DoD software projects rather passively. As subcontractors they do little more than provide software licenses (and perhaps some focused integration expertise) to the integrators. Would it be reasonable to believe that they could alter their business model to un-bundle their software development expertise from their products and in the future sub to the integrators not as a mere license provider, but as the funded open source developer? In other words, could a company like BEA be hired to be the JBOSS for SOSCOE or other infrastructural products?

I really can’t say whether this model is workable (especially for firms like BEA who would have to change culturally to be successful in open source development). But I think the continued erosion of sales of proprietary middleware is inevitable and a defensive posture just isn’t going to work in the long run. Better to go on the offensive and try things that leverage the core strengths of the firm than sit back building a Maginot Line (unless the prospect of Vichy politics suit you).


  1. Kit Plummer - August 27, 2007 @ 5:35 pm

    It is really interesting that you picked SOSCOE as your example, for what SHOULD be done openly. The funny thing is that the COE is really BS. There is no such thing as common. I’d be willing to bet that most don’t know that Boeing’s SOSCOE isn’t the only COE available. For example Raytheon’s COE is a prime example of integrators doing whatever the hell they feel like.

    I think the point that we all must arrive at sooner than later, is that Common and Standards are not the same thing. Just because Microsoft’s Document format is the most common by de facto, does not make it the standard.

    I’m still not convinced that Openly developed solutions are the answer. I can already imagine the quagmire of politics that would ruin a truly Open Source software project target at a governmental customer with big bucks. I believe the more important piece of this puzzle is the open standard/specification that defines/mandates interoperability. Although I realize this is just a prone to stalemates – however, this doesn’t really change the integrators business model for them (something they are incapable of).

    Anyway…I’m not sure BEA would be the integrators first choice – logically. There are many Open Source “parents” out there like RedHat(JBoss) and IONA(ServiceMix/ActiveMQ) who are ready and willing to work the way you are describing – and do.

  2. Kit Plummer - August 27, 2007 @ 5:38 pm

    BTW, keep this stuff coming! Great thinking – that must happen. ; }

  3. Jim S - August 27, 2007 @ 8:50 pm

    Hey Kit,

    I agree with you, BEA probably wouldn’t be my first choice to replace an integrator to do this kind of thing. What I guess I was trying to answer was “what other business models might be available in the DoD space for a software company like BEA; a business model that takes advantage of its product development capabilities?” It is my view that their current business model has limited life left in it (and fake Steve agrees:

    Regarding SOSCOE as a COE… I’ve been arguing for a while that SOSCOE shouldn’t be an integrator’s “product,” but should basically be a distro. Like Ubuntu it is mostly OPS already (other people’s stuff): lynxOS, JXTA, ICE, and a whole bunch of POSIX interfaces…

    If we thought of it as a distro, where all the glue was OSS too, I think there would be a bunch of advantages of transparency; plus it would probably get used for all kinds of purposes outside of FCS.

  4. Kit Plummer - August 28, 2007 @ 12:45 am

    I completely agree. What I forgot to mention was that Raytheon has internally Opened their COE. It is a step…cross-program (color of money) development is a very squishy subject right now. As much as we would like to believe that the acquisition problem is being improved, it really isn’t. One customer does not want to fund another customer’s solution…even they are the same customer. ; }

    I agree as well, BEA is terminal unless they can rebrand in a hurry. I’d also say that company’s like IONA are toast, if they forsake what it really means to add value to an already very good Open solution.

    The CORBA train has left the station. Realtime Java (and subsequently, realtime middleware) is just waiting to blow up. If, and when this happens companies like WindRiver will also get consumed (if it takes that long – rumors are swirling that IBM is a hefty suitor).

    LynuxWorks is an interesting breed…a good mix of both proprietary and innovation – but, not Open Source.

    All that said – you are still right in thinking that SOSCOE should be Open. If nothing else it would probably guarantee interoperability – rather than prevent it.

  5. Andy - October 25, 2007 @ 8:47 am

    Lets face, Open Source is also not suited to developing large scale software products. They don’t have the product management capability, standards body interaction, versioning expertise and all of the other product-oriented DNA that is necessary to effectively develop software products.

    There are very few examples of open source developers stating a goal and actually achieving it a controlled timeline. And even if they do get to a release the subsequent changed needed to maintain standards support etc. seem to fade away over time.

  6. Jim S - October 25, 2007 @ 12:57 pm

    @ Andy, I appreciate the gist of what you are saying, but I think you look just a little bit you’ll find plenty of examples that contradict your point.

Leave a Reply

Your email address will not be published / Required fields are marked *