To those allergic to buzzwords, the term solution might incite a sneeze. However, upon further examination a great deal of technology is delivered as a solution, that is a bundled, ready-to-use component. The consumer technology market, by itself, is rife with examples (see: the iPod, most home PCs). And while the concept that consumers want to purchase products that fit a specific niche practically out-of-the-box, the notion that the same holds for large companies isn't as evident. To be fair, it's not possible to mass produce ready-made technology for organizations with narrowly defined business requirements and use-case scenarios. And in the case of open source, there are hardcore realities that stand in the way of it playing a larger role in driving greater time-to-value and cost efficiency:

• Integrated designs. One solution size does not fit all and the fit is typically determined by the industry in question. This implies a knowledge of specific segments drawn out in the form of industry solution maps.
• The importance of the sales cycle. Solutions are sold, first and foremost. Open source is still being stealthily transported into a great deal of enterprise environments with the sales process a shortened after thought. If the notion of open source solutions is to take hold, it must be sold and accepted wholeheartedly not smuggled in and permitted to stay afterwards.
• Overlap with industry proven models, best practices and methodologies is key. Acronyms like CBM, IFW and BPM might not be everyday terms but they are industry proven and widely accepted as the basis for solutioning.
• The criticality of a top-down approach that initially prizes business value over technology. I won't pose the bottom-up mentality that has buoyed the open source software movement for some time now, against the seemingly inherent top-down nature of most hierarchies. However, it pays to note that technology selection/procurement is at its core a business decision. And unlike individual products, integrated solutions speak more to the business side of things than anything else.

Finally, if open source solutions are to evolve they must rely on more than being cheaper. Especially since the marketplace tends to base its decision on more factors than just price alone. The market for solutions is driven by participants who exhibit demand for addressing their industry-specific performance drivers, are modular and customizable. Add to the fact that providers which can accelerate time to value, reduce risk and deliver integration are its leaders and it becomes evident that the road to broadly relevant open source solutions is a tough one, indeed.

About the blogger: Alex Fletcher is lead industry analyst at Entiva Group Incorporated, a research and analyst firm which specializes exclusively on the open source software industry. In addition to his analyst coverage activities, he advises organizations of all sizes on establishing governance, strategy and policy surrounding use of open source software as a competitive differentiator. Alex has prior experience as a consultant, software engineer and start-up founder. He can be reached at alex dot fletcher -at- entivagroup dot com.

"What would you add - if anything - about using organizations like the Eclipse Foundation, the ASF, or other standards/code bodies to have a sort of neutral-ground and/or organization "middleware" for all this?"

While the concept of middleware that sits between an increasing array of quality software, produced as output of the open source development model, sounds abstract the growth in demand for open source has created a void for just that. This middle ground is essentially a nether region between software vendors/system integrators and the businesses looking for last mile solutions. Typically, for the larger companies and organizations it's players like IBM GBS and Accenture Global Services that go that last mile to deliver the notion of an integrated solution (excuse my marketing-speak). However, this is done taking a proprietary approach (products, tools and processes). Which proves wildly profitable for both of the aforementioned companies, still what has yet to be seen is who will play the role of coagulating some of the disparate sources of open source, refining it and delivering as consumable pieces that meet a specific business need.

I'm a big proponent that software is bought for what it does instead of what it is. High-end ERP implementations don't ring up 7-8 figures on account of simply being an ERP rollout, rather it's the fact that these systems are often the lifeblood of modern business operations. And there's a growing role for open source within the context of ever narrowing market segments. The Eclipse Foundation has caught wind of this reality and begun to branch out in the direction of specialization. And they're not alone, the OSA has made headway towards giving life to the open solution. These efforts will be instrumental in making open source feasible for segments such as the SMBs, microverticals, service industry verticals and emerging economies.

This is precisely where the middleware analogy is applicable. In the case of organizations like Eclipse and the Apache Software Foundation they are the glue/packaging that enable that sits between the raw productive power of the open source software model and the industry-specific needs of its consumers. Strangely enough, the need for a middle ground goes almost entirely unmentioned. Yet in the absence of an established group of open source behemoths that influence macro-level trends increased prevalence of organizations that serve as a neutral buffer is a positive. Realistically, these organizations don't even have to resemble Eclipse or Apache. And I fully expect that more OSA-style groups will sprout, as profit-turning entities like SIs or vendors begin to realize that it works to their benefit to cooperate towards delivering a collectively neutral approach to "solutioning."

Whether this middleware is spurred by marketplace demand or the proactive foresight of players in industry has yet to be seen. Additionally, increased consolidation amongst open source participants might bring about de-facto platforms fit with ready-made ecosystems that can standalone from one given end to another. However, to wait for impending consolidation is reactionary and strategically sloppy, at best. Especially since in the light of every acquisition (large and small) there is considerable room to pursue the middle ground.