ITGumbo: spicing IT up

In my last post I attempted to overlap what it would take to establish a middle ground and the concept of open source driven solutions.  I'm not sure how well my point went across, but I am certain that the notion of a new wave of solution that not only includes, but is rooted in openness is one that's here to stay. With that in mind, I think it's relevant to look into what it will take to facilitate the shift towards flexible, truly open solutions. More than anything I think this entails a change in perception regarding what/how sizable a role open source will play in the mostly nebulous world of "solutioning." In effect, what needs to happen in order to kick-start the evolution of open solutions from embryonic towards maturity?

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.

I found Oracle's statements on open source, tendered at the Linux/Open Source on Wall Street conference, intriguing to say the least. I'll begin by making it clear that I don't doubt the veracity of the database giant's experience with its customer base. In fact, I take Monica Kumar's word when she says "We haven't seen our customers asking for open source databases...Not many customers are interested in looking into the code and mucking around with it, and making changes to it." Honestly, the latter half is almost taken as established fact, especially as it relates to infrastructure software like databases, middleware, etc. Unfortunately, pointing this out does more to pawn off the entire open source value proposition solely as visibility into source code.

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.

Players in the tech industry have relied upon partners for solutions, distribution, deployment and support for many years, where a number of highly-publicized (think Apple and HP some years back), but ultimately failed, partnerships come to mind. Ultimately, failed partnerships aren't a good thing. They result in financial losses and more importantly lost opportunities to address new/existing market segments. However, a solution-centric ecosystem composed of a diverse set of partners with clearly defined roles and objectives is capable of supporting an effective reach into target market sectors...a clarity that often proves elusive. Yet for open source software ecosystems, coherency in partnering actions is crucial in promoting strength across the value chain.

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.   

For those who may not be aware, Matthew Aslett (one of my personal favorite blogging analysts) has tendered a strong post titled "Is FOSS heading for an identity crisis?"I thought the points raised therein are well-stated and spot-on, especially the parallels between the gay rights and Green movements. In general, this brand of "where does open source go from here" assertions are coming into vogue as the very definition of open source continues to take shape.

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