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.

Strangely enough, I don't actually expect Oracle to recognize the varied dimensions of open source on account of having too much vested in the proprietary model, industry leaders can be funny that way. As Matthew Aslett over at the 451 Group points out, "It is no wonder Oracle hasn’t seen customers asking for open source databases - it has been busy looking the other way." On the other hand, I'm sure the folks at Sun might disagree with the contention that there isn't a notable demand for open source databases.

Still, you would think that in an age marked by global conglomerates, rapid consolidation and break-neck competition, there is sufficient motivation to recognize how to fully leverage open source. And just as much room to express how to do just that. However, stock barrel line on open source remains, more or less,

1. Cheaper
2. No vendor lock-in
3. Better???

The first of which is being diluted by the dynamics native to any marketplace, see: the availability of products like Oracle Express. Number two still holds true, although to those already chained to a proprietary vendor/platform the talk of freedom of choice mostly comes across as just that, talk. Which is precisely why I'm of the perspective that there's room for what might be termed as progressive open source. Yes, this terminology drips with political overtones, but pragmatically I think open source success, over the long haul, will be achieved by tending towards more progressive characteristics.

Thus far it has been well-established that open source is indeed different. What's needed now is to demonstrate how these multiple degrees of difference can help meet customer needs, solve complex business problems and power innovation. Up to this point, this brand of understanding has resembled esoteric knowledge more than it has mainstream thought. And that's exactly what needs to change. More need to be informed what is to be gained from open source and why it matters to them. Instead of open source = cheaper and more open, it should be: Yes you will save money, yes you won't be locked in, but here's how involvement with an open community is profitable as well.

The root of progressive is progress, which can't be achieved without a break from the stat quo. However, to overcome the inertia that can stifle progress an alternative mode must become real. Its benefits can't be vague and hazy. The reasons to embrace a shift from established avenues can't be known only to an inner circle of the "enlightened" but should be expressed to the collective whole. This takes time, but the passing of time itself shouldn't be mistaken for gaining ground...its progressive action  applied over time time that breeds a desirable end result.

In more than one sense, partnerships must transcend the press release/announcement that heralds their existence. Within any successful solution-centric ecosystem each relationship is a win-win. Otherwise a partnership defaults as a well-intentioned PR play. The same holds for open source software ecosystems where the primary focus of each partnership must be on building product/service strategy in line with go-to-market plans. This is driven by the following:

• Agreeing on the shared market opportunities. Once the appropriate customer/prospect needs, product whitespaces and the appropriate potential partners have been identified, it is possible to build a healthy stable of solution scenarios based on the features, advantages and benefits suited to customer needs. For the vast majority of open source players, feature-driven decisions been at the crux of partnership actions. And understandably so, since most proprietary competitors are more feature complete...still this must change. Since in order to grow and compete effectively in a more consolidated environment it will be necessary to segment markets by size of companies, user roles, geographies and industries.
• Make open intellectual property (IP) work. Compulsory within the context of a partnership is identifying and each participants IP. Determining the nature of IP licensing and protections is an important step in the process of building successful relationships. However the dynamics introduced by open source provides an additional angle for establishing vibrant innovation networks and a balanced continuum of IP ownership. This touches on the very nature of IP, everything from how it's built to who builds what. This is the foremost differentiator for open source software ecosystems in that they are equipped to challenge the dynamics of the dominant mode of solution production with an entirely new and more efficient [open] approach.
• Fill the gaps. In a marketplace that prizes the concept of solutions to business problems over that of raw technology it's critical to identify when a competitor might be a potential partner, the need for geographic coverage and the viability of vertical offerings. Each partner should be assigned a risk profile that details its credibility based on the strength of existing relationships and/or references.
• Solution quality assurance. Product integration is paramount since the success of a joint solution can justifiably (and unjustifiably) affect overall brand value. Therefore, a transparent certification process at every tier of a partnership must be outlined and agreed to. This often drives the entire partner relationship management process as it spells out the parameters by which solutions (and those involved with its integration) will be measured.

Each participant must be appropriately integrated into the overall support community. This involves defining a customer support model that allocates responsibilities and cross-vendor point of contacts. The support community must span multiple touchpoints across multiple roles and address:

• Support, service and revenue sharing. This is often a deal breaker since maintenance streams represent a cash cow for vendors and partners of all sizes, this is especially the case for the commercial open source vendors. Regardless, skill set requirements should be at the heart of formalizing priority-based support and the according maintenance fees.
• The creation of support infrastructure. With solutions spanning a gamut of customer needs the service infrastructure behind its delivery must also shore the gaps between partner responsibilities. Interconnected channels within an ecosystem must be well defined and transparent to customers. This is an area that continues to plague the emergence of open source solution ecosystems since it requires pockets of internal experts and specific competencies capable of providing training and certification.
• Extend open source communities to supplement support activities. This entails translating the latent user-focused ideals of open source community into a wider landscape of customers and partners. An open source ecosystem should encapsulate the notion of community such that customers and partners are smoothly integrated into one and the same. In this way maximum value can be derived from an open atmosphere where comments, criticisms and feedback are welcomed. Otherwise, a big part of the open source value proposition is lost.

As the complexity of tech partnerships continues to grow, new roles and organizations will emerge to bridge the gap between business development, channel management and partnership management. In much the same way that commercial open source vendors have come to realize the value that community governance and directorship has from a business perspective resulted in a rash of community management positions, the same will occur as more come to realize that strong ecosystems represent the door to sustained growth and competitiveness. In fact, I look for the open source community management role to, at some point down the line, merge into executive level duties of creating and nurturing partner ecosystems.   

This has left a great deal of leading prognosticators in the dark about the path upon which FOSS finds itself. A sterling example of this fact is the Forbes piece titled, "Cash Me Out," which afforded mainstream pub to open source but was laced with a number of far-reaching, lazily placed generalities. That being said, I understand that bold, striking statements is what the online editors at Forbes require from writers but an honest examination of shifting cultural dynamics of open source must be undertaken with the following facts in mind:

• Commercial outfits built around the open source software model are businesses first and foremost. The profit-generating mechanisms that they are, businesses are amoral. Therefore, drawing associations between the decisions of those running open source companies with the larger FOSS movement is a delicate matter. That being said, there are real people behind these companies who understand (and even appreciate) the values underlying FOSS, only they are compelled to act primarily in the interest of an individual company.
• There is no idealogical rift between FOSS and adjacent commercial activities. Why? Because, they are separate spheres of activity...that's why. The sale of x open source companies does not imply that FOSS is being co-opted by proprietary forces. As a matter of fact, it has more to do with the timing, dynamics and marketplace conditions surrounding the purchases than the overall state of FOSS. If a movement could be controlled solely through commercial channels, Microsoft would have taken to snapping up open source companies a long time ago. And that's the thing, even if every single open source company is acquired, FOSS will remain in tact. The converse is also true: the growth of commercial activity surrounding open source does not signal the decline of FOSS.
• There is no dominant mode of existence within the open source domain. I consider it a good thing when companies adopt FOSS principles and integrate them into forms of hybrid/eclectic approaches to the business of software. I look at this as part of an ongoing evolutionary cycle. So from my perspective, debate regarding the "purity" of FOSS is more ideological than anything else. One other note on this subject: In my eyes, it was the FOSS movement that paved the way for open source (in its commercial, hybrid and more "pure" forms). And for every direct relationship between the expanding, and increasingly commercialized, open source landscape there are numerous indirect, less-obvious ones help create a complex dynamic between FOSS principles and commercial open source.
  
• The values underpinning the FOSS movement and those that drive open source business models aren't necessarily interchangeable. I alluded to this above, but my point is that there isn't a unifying set of goals, values and/or directives that can be used to evaluate any and everything open source. There ARE certain characteristics that are absolute, but that's about it. After all, FOSS principles were never meant to serve as the moral authority for usage of the term open source. Meaning a commercial entity should feel free to choose from the FOSS palette during the process of painting a picture of success and profitability.

I'd love to hear what anyone else has to say on this matter...

• Very little "new blood." No new proprietary vendors have rolled out ESBs over the past two years. "New" products have been the result of existing vendors extending the capabilities of older enterprise application integration offerings to include ESB-esque features like Web service support and business service orchestration.
• Signigicant market consolidation. The trend of larger platform vendors acquiring niche ESB vendors have reduced the number of players and available choices. The Oracle BEA acquisition is a prominent example and last year's acquisition of webMethods by Software AG, another.
• Commoditization of the ESB. No longer a leading/cutting-edge technology, ESB is now a substantially cheaper, infrastructure commodity. As it stands, more growth potential exists in emergent upper layers of the infrastructure stack, e.g. Business Process Management (BPM). The ESB is going the way of the application server, that of a sort of bundled prerequisite for new products.

However, despite the opportunities for open source disruption, the ESB market is unique in the sense that its core capabilities are still evolving. An example of this evolution is the fact that over the past four years the ESB, as well as other integration-centric categories, continues to take shape. Circa 2004, the conceptual understanding of an ESB included Web services, event triggering, routing and messaging. By 2006, this expanded to include a large number of capabilities that were previously classed in the EAI domain such as, data transformation; process orchestration; application adapters; process modeling and process monitoring. Today, the ESB stack now includes event-centric capabilities like Complex Event Processing (CEP), event management, simulation and human workflow. Where both EAI and ESB capabilities can be grouped under the integration-centric business process management umbrella.

Survival for open source vendors in this market is directly related to: how clearly the business model is defined and communicated, how quickly and capably mass adoption is established; the efficiency of technology and service delivery models. The presence of serious, commercially viable companies to support middleware deployments is critical for enterprise customers. However, while the lack of compulsory upfront license fees characteristic of proprietary products aids adoption, it removes a chunk of revenue stream. A reality which can't be discounted since smaller open source companies are faced with the prospect of fewer resources available to invest in building a business. These same vendors will not be able to rely upon traditional strategic approaches to growth and capturing market share if they intend to thrive. They must work alternative forms of monetization into their business models in the face of lower average deal sizes.

This entails stimulating strong ecosystems of consultants and system integrators through a practitioner focused outlook, one that encourages speed and flexibility of customization (two valuable differentiators). These third party channels are key to fully understanding the role of an open source ESB not only as a product but as a solution. There is also room to explore how to leverage relationships with the Apache and Eclipse communities, through the incorporation of technologies from the former and the development of a family of plug-ins for the latter. Doing so, provides some branding momentum since those two remain the most trusted and recognizable names in the open source community.

Interestingly enough, the trajectory of the Deutsche Post spin-off SOPERA will provide a glimpse at the path that lies ahead for ESB challengers. Currently it needs to extend its capabilities with more feature completeness most notably an adapter framework. This could take shape as a commercial add-on or as a partnership with an open source BPM effort (perhaps Intalio). However, SOPERA must be careful to clearly communicate a strategy and execute along a focused path that serves as a buffer from the pressures of a highly competitive ESB market...ditto for any other open source ESB effort that has its sights set on challenging larger incumbents.

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.

Keeping the above in mind, it pays to remember that support is more than maintenance and operation. In most cases, the real value lies in providing integration and/or solutions. Most commercial open source providers already offer a unique set of service offerings tied to a software package, which is fully expected. And, with business models tied to subscription revenues, it makes sense that these companies would sport a deep dive expertise in maintenance and support of their particular software package. However, some of the biggest challenges with open source are found in integration with the rest of an increasingly heterogeneous software stack. Unfortunately, this mostly falls mostly outside the scope of many support agreements.

To the rescue: the third-party provider. These serve as a source of reliable open source support. The competent ones have a proven track record of supporting and maintaining complex software (open and closed) configurations over an extended period of time. This is critical since after the initial install and configure period, once software is integrated with other platforms or a change (versioning, replacement, etc.) takes place to components in the stack -- the real work begins. And it takes a considerable level of experience managing complex, integrated enterprise quality software in order to even consider doing so. Therefore, the following capability checklist should be consulted before choosing a provider.

• Experience across multiple products and platforms. This is especially important as open source is being deployed in multiple configurations. The combinations of open and closed source software escalates the chances of cross-platform interoperability issues across the moving parts of a stack. Here is where experience supporting related configurations (open and closed source) enables a higher quality of service to be rendered.
• Direct connections to open source "product" resources. Buyers should always take the effort to inquire whether a service provider is involved with the open source communities associated with the products/packages for which they claim support. Providers with actual experience will almost always have some tie to the community if only because they benefit from staying close to its productive flames. The number of programmers and support personnel dedicated to support  of an open source resource should be reflected in a commensurate involvement with the community. If not, a provider should be able to produce their training and certifications demonstrating a sense of significant experience.
• Industry-standard SLAs. This might be somewhat of a no-brainer, still expectations for open source service and support should be no different from expectations for proprietary counterparts. Robust SLA's, formal processes geared towards problem resolution, time-hardened tools and methodologies; and SLA accountability in the form of pre-determined consequences for non-performance.
• An understanding of the open source value proposition. In the same way that enterprises benefit from drawing a complete picture of the open source value proposition, IT services firms will as well. Even though software is software, qualified support and service providers must understand how to pass the value of open source to their customers. A firm grasp on the concept of open source value proposition will allow a provider to keep costs low, guarantee higher service quality and reduce problem resolution time in the face of an issue. This step is a precursor to creating and bundling any notion of a standard stack of open source components.
• Client references. Providers who have a demonstrable, multi-year track record of open source maintenance and support are preferable. Longer contracts tend to entail the support of more than one complex projects that serve as a test harness for quality of service and the strength of the client/provider relationship. This isn't always the case, but more often than not provides a reliable indicator of the level of capability for a provider.

Step 1: An active portfolio of OpenSocial applications
Seeing how th forge model has come into vogue as of late, an OpenSocial forge for applications wouldn't might not be a bad concept (no hosting, just plain-text linking). And with the API in its early stages where there is more wonder about what OpenSocial is capable of, highlighting what is being done will do nothing but expand the boundary of thought and innovation. A consolidated directory that represents what's being accomplished and who is doing it would put a face on a potentially enormous OpenSocial development community. Plus, it serves as a great way to prevent apps from floating in cyberspace, shrouded in anonymity.

Step 2: Validate viability of changes
In order for OpenSocial to emerge as a stable bridge/gateway to the heretofore closed nebulous that is the contemporary social networking platform, it must evolve rapidly without endangering the core principles of successful API's. Therefore, a premium must be put on the changes that complicate the prospect of developers writing to OpenSocial with a minimum level of effort. The best way to accomplish this is to validate the viability of proposed changes in a proactive manner.

This is especially critical in the case of OpenSocial since it is a third-party API, i.e. Google doesn't hold sway over the underlying platforms to which it is providing access. The bottom line is that the entire social networking space will undergo vast changes over both the near and long term. OpenSocial must be able to adjust to a level of change that's proportional to the overall maturity of participating platforms, all without sabotaging its original aims. It should be a buffer between the developers and the shifting landscape to which they seek to connect.

Step 3: Aggressive incubation
There are several concepts that will prove key to OpenSocial's transformation from promising early stage effort into industry mainstay. These will need to be tightly integrated into the current growth process moving forward -

• Transparent decision-making. Yes Google is driving the good ship OpenSocial, but back-room decisions will bring little more than confusion as the specification matures. A decision made out of plain sight, especially if it turns out to complicate matters for those writing to or implementing OpenSocial, will be met with sheer derision. As a result, Google must work to instill transparency into the fabric of its entire decision making process.
• Patterned collaboration. The patterns of interaction potentially made real by OpenSocial, i.e. innovative types of relationships between applications/services/platforms, will be driven in advance by collaboration. Google will find itself on the hook to play the role of facilitator. It won't be enough to meet the needs of platform partners (MySpace, LinkedIn, and Bebo) and the development community in isolation of each other, instead channels that funnel an active sense of participation and collaboration must become the norm.
• Engaging the non-selected.

Step 4: Demonstrate secure interoperability
Last December's Orkut worm is a prime example of the security risks that need to be addressed before OpenSocial can move forward. Whether through security provisions made available natively through the API or external entities. OpenSocial is supposed to grant more granular control to developers making security attacks more difficult. That remains to be seen, and in the meantime the threat of attacks making use of OpenSocial as a distribution mechanism is far more harmful. This is especially important since sustained momentum will only bring new waves of applications written to the API. I can't see Google neglecting to consider this fact, only it remains to be seen how well it will be addressed/considered. 

Step 5: Monitor the processOpenSocial's trajectory will be determined by how well sustainable innovation is cultivated in relation to an underlying current of openness. Just as new forms of measurable value should emanate from OpenSocial, so should the associated metrics with which it will be gauged. Other types of open source have come to rely upon downloads and unique users although I don't think this will scale in the case of OpenSocial. Whatever the case, a realistic and representative form of measurement will have to arise in the process of quantifying progress.

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.

Nonetheless, Roy's contention over Sun's approach to open source governance/decision-making doesn't just highlight key issues and challenges tied to the open source software model. Namely the fact that the open in open source should not be confused for a generic identifier that guarantees a finite set of characteristics. As the model matures, it makes sense to expect that the number of differences between disparate open source efforts will only increase positively over time. However, the reality that different evolutionary paths will materialize from the unique forces (internal and external) exerted on individual project communities seems to go unnoticed. In the same light, some of the words commonly used in conjunction with open source will continue to become too broad to leave to interpretation. As an example, Roy pointed out the following:

"What is the point of creating the OpenSolaris Community governance if the community isn’t even allowed to decide what is called OpenSolaris? This isn’t an abstract discussion of trademarks. It is the fundamental basis for making technical decisions of any kind for the project."

It remains difficult to effectively criticize Sun (or anyone else) for choosing the path it has with OpenSolaris so long as the commitment to transparency is a priority. However, from the looks of things a key member of the OpenSolaris Community Advisory Board (CAB) didn't have the same understanding of what open entailed. More than anything else, Roy's departure is symptomatic of critical gaps in communication, whatever the specifics. Such a gap isn't unique to open source and is more often the rule as opposed to the exception when it comes to larger organizations. Unfortunately, open source thrives when external and internal communication is clear and driven by the variety of flattened hierarchies that are typically extinct within those same large corporate organisms...all of which seemed to fall under the CAB charter. 

So it's mildly surprising to learn that the individual tagged as a representative of the general open source community was never made aware that his concept of open decision making differed from Sun's understanding of the same term. If the Sun team never had any intention of granting substantial input into the technical decision making process, that's their choice. Only the company should have taken care to cleanly express the desire to retain control (in general or in regards to specific matters), since the CAB was founded with a perceived air of, not just representation, but also participation in the governance process. There should have been absolutely no motivation to project anything other than the actual outlook on these matters...the definition of transparency.

My perspective is that the open source umbrella has unfolded enough to cover a healthy variety of flavors, colors and combinations (and I don't have any reason to assume this won't continue). So while there is still lively debate about whether certain licenses can be considered open source, other elements associated with a community aren't subject to this type of either/or judgment. Personally, I have no problem applying the open source label to a project that makes its proposition (what it is/isn't as an open source effort) crystal clear and sticks to it. Roy's position seems to be that this is exactly what didn't happen with OpenSolaris.

Obviously the community isn't going to fall apart anytime soon. All the same, it does provide cause to wonder how much of openness is being spun for the purposes of perception management. Hopefully this fallout will incite Sun to assert a cohesive position on how the OpenSolaris community will proceed as a decision making body and continue to demonstrate a commitment to that angle.

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.

To be realistic, one major caveat in publicizing this brand of far-reaching goal (time-wise) is the fact that, by 2012 very few will remember, let alone hold Red Hat to it. On one hand the quarterly focused, bottom line Wall-Street types could care less what Red Hat says it's going to achieve 94 months from now...short-term profitability, stock price and market share count for more (plus, this safe harbor provides a good deal of legal shelter). On the other hand, any and all viable players in the middleware market will be setting their sights high for 2015...it's a competitive necessity.

Regardless, a closer look gives reason to consider that the enthusiasm exhibited by Red Hat senior leadership and associated week's ambitious goals regarding JEM, might be more than PR wire fluff. Recent activity surrounding JBoss technology indicates that it is, indeed, at the core of a rapidly maturing middleware business for the company. There is also a noticeable fit with the expressed strategic focus associated with the Enterprise Acceleration initiative, serving as early evidence that company direction is indeed aligned with stated objectives in the near-term.

Over the past 6 days, announcements of partnerships with companies like iWay Software, Hyperic and SeeWhy have hit the wire. Obviously the timing was far from coincidental, but it sufficiently backed the commitment to expanding a partner ecosystem that will need to grow by a factor of two or three in the process of meeting the aforementioned Red Hat objectives. Both the iWay and Hyperic partnerships addressed an area that will be critical for the JBoss Enterprise SOA platform moving forward: the budding overlap of enterprise Java and the Web 2.0 generation.

The indelible effect that rich internet applications have had on web-driven application development is practically undeniable. That being said, SOA will encapsulate these realities as it evolves, meaning any and all platforms which claim to tackle this space must do the same. The iWay partnership, in addition to enabling integration with more than 400 databases and applications, strengthens the capability with regards to building rich, Web 2.0-esque apps. The jointly developed management platform project, dubbed RHQ, went live last Thursday led by Red Hat and Hyperic. RHQ will serve as the foundation for JBoss Operations Network v2.0, due in late Spring 2008 and is directed at ensuring that features like inventory, data collection, configuration management control and strong alerting and provisioning is available towards meeting the needs of an increasing array of web-driven enterprises.

Red Hat will benefit tremendously if JEM can mature into one of the key players in the middleware/SOA market, especially in light of the fact that Red Hat Enterprise Linux (RHEL) continues to make headway of its own. As it stands now, Red Hat hasn't been able to effectively cross-sell JEM to as many RHEL customers as was expected by outsiders when JBoss was acquired, despite the fact that those same customers are in the midst of building reference architectures to deliver the applications and services their businesses need. If the gap between JEM and RHEL can be closed without slowing down the latter, the open source enterprise computing stack envisioned by some will be all that much closer to reality. 

The above is particularly interesting since Red Hat's progress as it relates to the above will have a significant impact on how its success story will [continue to??] play out. While the investment community is well already aware that the company has recently experienced a decline in share value, the stock is trading around $18.06 and in highly volatile times, like those today, more than a few will be undervalued. Knowing this, investors will be searching for "bottom feeder" investment opportunities characterized by consistent performance from companies that tend to fly under the radar. If Red Hat can make good by bringing forth the fruits of executing its Enterprise Acceleration strategy the company will develop into an investment opportunity during bearish times. This would arm the company with the ammunition and momentum necessary to seize a leadership position in the tech industry.

On the open source/Linux front, stated commitments to the Android platform, from parties like Verizon and LG, have followed a ballyhooed inception to the world  and emboldened speculation that Google has more than a passing eye on the mobile advertisement space. The LiMo Foundation, a consortium of 32 companies, also made noise yesterday by showing off 18 handsets powered by its platform following chip makers Texas Instruments and Qualcomm participating in demos for handset prototypes on Monday. Of the aforementioned 18, 15 are commercial while two are reference designs and one is a prototype. The companies involved with LiMo weren't fully comfortable with the ownership structure of the Nokia Series 60 and/or Windows mobile platform(s). The fact that LiMo produces real code and gives companies the opportunity to get involved has served as a key selling point.

Despite its status as a relative newcomer, Android has demonstrated that it intends to be more than Google branded vaporware. Texas Instruments official Ramesh Iyer demonstrated a prototype with Android running atop its flagship, OMAP3430 multimedia applications processor. The claim was that IT was able to p8ut Android on top if its processor in less than a week. Qualcomm validated Android's associated ease of application development by showing off a game developed by engineers in a couple of hours. The hope is that Android will spark a wave of mobile applications from the development community and lead to the next generation of smartphone that combines Web-enabled applications with standard voice features by freeing the power of processors. All by empowering developers to customize applications rapidly.

Thus far, Google has positioned Android as a completed operating system. Whereas the LiMo foundation has been active incorporating components from its member companies in an effort to provide a platform made up of existing, proven components. In this way LiMo is sharing the costs and risks involved with creating a cost-effective platform for all involved parties. Initially both efforts will have to sink or swim in an already fragmented market where primacy depends on device penetration (getting onto a majority of devices)...at the very same conference, Vodafone CEO Arun Sarin called for consolidation in the number of operating systems available.

Meaning while there is definitely room for the Linux category as a whole, Android and the LiMo platform may struggle to exist side-by-side over the long-term, especially since the initiatives overlap  in many ways (see: the number of companies participating in both, including LG Electronics, Motorola and Samsung). As a result, the yet-to-be crowned early leader will be able to push the other effort towards the margins of relevance more quickly than is otherwise the norm. A quick swing in momentum for either side might tip the tides of consolidation for the Linux market in that direction. Therefore, it's critical that both retain as much progress and traction out of the gate as possible.

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.

As of the current 1.1.1 release, Synapse is positioned as Paul Fremantle, Vice President of Technical Sales at WSO2 Inc. put it "a high performance, easy-to-use, Open Source Enterprise Service Bus (ESB)," an upgrade from the lightweight XML and Web service mediation framework that it was earlier in its existence when it provided three main functions: managing virtualized connections, service management and message transformation. Previously, it was useful for exchanges made through SOAP-based Web services where management of the exchanges were available through the WS-* protocols. Now support has been extended to numerous open standards such as HTTP, SOAP, FTP, SMTP, XML, XSLT, XPath, JMS, Web Services Security (WSS), Web Services Reliable Messaging (WS-RM), and more.

The above helps Synapse cover the key segments of service oriented architectures, namely:

• Execution and integration services provided through interfaces.
• Message routing, transaction, and related services/interfaces used by services.
• Service assembly foundation.
• Management, governance and control capabilities.

Plus, as an ESB the above is offered in a familiar manner that more amenable than the aforementioned mediation framework identity. It was a tad bit strange when the initial explanations of what Synapse brings to the table went, it looks like an ESB, works like one...but isn't quite an ESB. I never figured out whether that was supposed to keep the Yet-Another-ESB tag at arms length while its identity was formalized (through incubation stage) or what? I'll go out on a limb and assume that perhaps ASF noted this distinction to prevent the which one is it...Synapse or ServiceMix conversation from flaming out of control. Yet from what I understand about both, ServiceMix is built atop JBI while Synapse is designed as a simple, high performance ESB that prizes low overhead and scalability minus the JBI foundation.

Either way, now that it's clear that Synapse is in fact an ESB, the challenge for Apache is to cut through this cloud of lingering confusion and carve out space in enterprise application development tool sets. WSO2 stepped forward some eight months ago and ran its own Synapse based ESB against ServiceMix and Mule ESB in two rounds of performance testing, which provided an idea of what Synapse powered platforms can do. Perhaps this should be repeated with direct participation of members from each party (ServiceMix, Mule, Synapse) plus some of the guys from Open ESB? Providing hard evidence that a well-tuned Synapse can stack up to its open source peers tuned similarly for performance might serve as a nice coming out party/current state of affairs for the project.   

Regardless, the driving force behind the Synapse value proposition remains the ASF software development process itself since it's no secret that the ASF is a leading example of leveraging open source in the creation of complex infrastructure. I'm looking ahead for the newly promoted Synapse project to capture more contribution from a wider range of enterprises, vendors and SIs. Even if given the ASF's operating model and the inherently complex nature of a category like SOA, sustained momentum won't hinge on the availability of customer-supportable products. To fill in the gaps, I expect that ISVs and SIs will handle the complex and time consuming tasks associated with integration work. The net result: an Apache Synapse that's well positioned at the forefront of what remains the early stages of SOA technology maturity.

As the article points out, the current generation of Java containers is not well suited to support a fully modular SOA pattern. As a result, the prospect of designing and implementing enterprise systems without introducing issues with cross-dependencies, dynamic loading and lifecycle management is certainly complicated. The emergence of an OSGi container is dead set on changing that reality by enabling universal middleware, an ambitious term to say the least, but one that aligns with the expansion of use of the OSGi specification beyond embedded devices. More than just a catchy phrase, the prospect of universal middleware is made real by an intersection between open standards and open source. And if it can build momentum within the context of an increasingly SOA driven world, look for open source middleware to benefit tremendously as a result.

In essence, OSGi is a step towards agile systems of application modules grouped by business functionality available through interface contracts between services. OSGi provides the component-oriented, container framework that is capable of hosting dynamic services that do not have to be registered programmatically while providing the means to track and react to changes in the lifecyle of a service. In anticipation of the realities rooted in dynamic lifecycle problem, the OSGi/Spring combination has emerged as a solution with Spring providing dependency injection and aspect-oriented programming (AOP). Formerly known as Spring OSGi but renamed Spring Dynamic Modules for OSGi, the pattern of extensibility and freeing developer hands/heads to tackle more complex issues that has characterized the growth of Spring since its early days, has taken root in similar ways. Enterprise developers seeking to further simplify application development have taken to this combination, contributing to the significant industry momentum behind OSGi over alternatives like JSR 277.

In a broad sense, OSGi is at the forefront of a movement towards platform agnostic services that are inherently modular in nature. The result? Container independent services that sit above underlying implementations of OSGi. This is another of level of abstraction meant to enable the service based architectures of tomorrow but also an opportunity for the current wave of open source enterprise technologies, i.e. J2EE application servers and ESB frameworks to establish more traction. If OSGi can standardize one approach to SOA from a Java perspective, the doorway for heterogeneous SOA arsenals over single vendor suites will open even more.

Once players like Oracle/BEA and IBM step to the forefront with OSGi containers, the prospect of creating services supported by a standardized, dynamic deployment framework across the nexus of closed and open source offerings will receive a drastic boost. At this point, developers will be afforded the option of writing with the framework instead of against a product-specific approach to enabling SOA...a tantalizingly real opportunity to take a step forward in the Java enterprise application development arena.

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 hisanalyst 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.

As the article points out, the current generation of Java containers is not well suited to support a fully modular SOA pattern. As a result, the prospect of designing and implementing enterprise systems without introducing issues with cross-dependencies, dynamic loading and lifecycle management is certainly complicated. The emergence of an OSGi container is dead set on changing that reality by enabling universal middleware, an ambitious term to say the least, but one that aligns with the expansion of use of the OSGi specification beyond embedded devices. More than just a catchy phrase, the prospect of universal middleware is made real by an intersection between open standards and open source. And if it can build momentum within the context of an increasingly SOA driven world, look for open source middleware to benefit tremendously as a result.

In essence, OSGi is a step towards agile systems of application modules grouped by business functionality available through interface contracts between services. OSGi provides the component-oriented, container framework that is capable of hosting dynamic services that do not have to be registered programmatically while providing the means to track and react to changes in the lifecyle of a service. In anticipation of the realities rooted in dynamic lifecycle problem, the OSGi/Spring combination has emerged as a solution with Spring providing dependency injection and aspect-oriented programming (AOP). Formerly known as Spring OSGi but renamed Spring Dynamic Modules for OSGi, the pattern of extensibility and freeing developer hands/heads to tackle more complex issues that has characterized the growth of Spring since its early days, has taken root in similar ways. Enterprise developers seeking to further simplify application development have taken to this combination, contributing to the significant industry momentum behind OSGi over alternatives like JSR 277.

In a broad sense, OSGi is at the forefront of a movement towards platform agnostic services that are inherently modular in nature. The result? Container independent services that sit above underlying implementations of OSGi. This is another of level of abstraction meant to enable the service based architectures of tomorrow but also an opportunity for the current wave of open source enterprise technologies, i.e. J2EE application servers and ESB frameworks to establish more traction. If OSGi can standardize one approach to SOA from a Java perspective, the doorway for heterogeneous SOA arsenals over single vendor suites will open even more.

Once players like Oracle/BEA and IBM step to the forefront with OSGi containers, the prospect of creating services supported by a standardized, dynamic deployment framework across the nexus of closed and open source offerings will receive a drastic boost. At this point, developers will be afforded the option of writing with the framework instead of against a product-specific approach to enabling SOA...a tantalizingly real opportunity to take a step forward in the Java enterprise application development arena.

Still, as the Covalent business model bares witness to, Tomcat has also found a home in more than a handful of data centers. Nonetheless, Tomcat is consistently classed for it isn't as opposed to what it is. Thrown into the same category as a JBoss or even a Geronimo (WAS Community Edition), Tomcat is mostly overlooked as a smaller, not feature-poor open source application server, when in reality it was never developed to be an fully-fledged app server. Yet for those, who continue to associate enterprise application infrastructure solely with the traditional application server, Tomcat isn't ready to approach the holy grail of "enterprise-readiness." In light of the presumption that scalability and uptime is gained through hoofing the app server route, it's interesting how easily accepted that reality that Apache httpd powers countless scalable LAMP apps while Tomcat's ability to do the same for Java apps is barely granted a passing murmur. In actuality, Tomcat continues to be used behind a fair share of non-trivial web application. Maybe not to the extent that its ASF brother has, but certainly proportional within the boundaries of the Java web development.

Still companies with products positioned around the Java web container have taken note of how a significant chunk of their service and support business involves Tomcat-driven applications and infrastructures. Enterprise penetration was certainly high enough to warrant the acquisition of the leading support and service provider for Tomcat to be snapped up, not by a threatened giant, but an emerging open source player, like SpringSource. Perhaps this move will pave the way for a more complete top-to-bottom lightweight stack for Java development similar in composition to LAMP...who knows?

So as SpringSource and Covalent  work towards merging operations under one roof, it will be interesting to note the growth curve for Tomcat as a commercially viable commodity...especially with regards to Spring powered applications. I fully expect an ascertainable jump in decisions to standardize on Spring-Tomcat now that services and support subscriptions are available from a single source. Which might not constitute a direct threat to an Oracle or an IBM per se, but is certainly the source of cohesive commercial momentum for open source in the enterprise.