This article originally appeared on SearchOpenSource.com.
The open source stack is moving to the core of data centers -- to a place where it's responsible for handling critical parts of business operations. Support for these applications
is paramount for IT departments and absolutely essential to the enterprises that use them, according to a report from The 451 Group, based in New York.
When it came time to support these applications, enterprise users looked to their application providers or operating system vendors for an assurance of support, the report said. The conclusions in the report arrived in spite of the fact that many stack providers today offer a single point of software support, often referred to as the "single throat to choke."
But, as the dynamic changes, how will savvy open source IT managers stay afloat? The 451 Group analyst Raven Zachary, author of Stack and Deliver: An analysis of open source stack providers, with recommendations for vendors and their customers, offered suggestions during a recent interview with SearchOpenSource.com. Zachary followed up with suggestions for keeping ahead of the open source technology curve.
SearchOpenSource.com: The number of vendors in the stack space is increasing. Who is expanding the market, and what are some ways IT pros can successfully vet them?
Raven Zachary: It is true that there is increased vendor competition -- the number of vendors that are competing in the open source stack provider market is growing. This is the real challenge for end users. Competition, while a benefit for users, can also make it challenging for them, especially if their organization is new to open source software and they are trying to evaluate the reliability. It is not as simple any more as it was a year or two ago, when it was pretty clear where to get product-level support. Now you have operating system vendors like Novell, Red Hat and Sun competing for business as they perceive stacks as an extension of the operating system.
Applications companies that are starting to bundle everything from hardware to the stack to applications oftentimes support the whole set to the customer. And then there are the systems integrators, which see the stack as a building block for customized development initiatives.
Where is the customer to go? It all depends on an organization's characteristics. There is a greater level of ownership or single org. If it's a single org, stack providers are squeezed from many sides. If it is a user that has already deployed Red Hat in its data center, all it will take to add on to that is a phone call to a sales rep and a bigger check in the mail to Red Hat. Typically, the first open source software in the door of an organization has the advantage of selling additional services.
Open source software demands talented developers, which you mention in the report. Where is this talent coming from? What should IT managers look for?
Zachary: Vendors wanting to provide open source services -- and enterprise users who are implementing open source software -- increasingly see value in acquiring expertise through the hiring of core developers. This is the challenge of supply and demand. The demand for open source expertise amongst core developer projects -- popular projects -- has far exceeded the availability of talent.
When I worked for La Quinta, we hired Tomcat developers because we had a great dependency on Tomcat for our online reservation system. That model is also being followed by other organizations today, and now we are seeing highly successful open source projects that are not backed by a primary vendor. A great example is PostgreSQL. But the talent demands for that model are pretty high right now. So don't look for talent, look to vendor relationships.
Your report also talks about a 'federated support model' where vendors of OSS software and project communities ally to provide support to end users. Could you give a real world example of this?
Zachary: There are a couple. One example is what we are seeing with OpenLogic. With that, they are going directly to the developer community to recruit experts to augment their own expertise. One other example is when a company reaches out to individual experts to augment the knowledge base. Unisys partnering with JBoss is a real world example of this.
For an enterprise, with its complex enterprise IT infrastructure, essentially one has to -- through a set of vendor relationships -- build federated support models. With open source we see a similar model whereby individuals within IT organizations are seen as point people for open source. They are responsible for building a support model for their organization through combinations of internal extensions, vendor relationships and deployments.
So are you saying that every IT organization using open source should have open source liaisons that are hands-on with the technology at all times?
Zachary: Yes. Resources should be designated as the primary points of contact for each open source component within the user organization. While an organization may not have internal 'experts,' there is value in taking ownership of this process, as opposed to deferring entirely to a provider.
It would be a mistake for an organization to fully outsource support for open source. Instead, consider it an augmentation of internal expertise. In that case, if an organization needs help with Apache Web server, it can go to a vendor like Covalent, which provides 24/7 support for Web services. If you have no internal leads on managing and supporting open source deployments today, then an organization must educate itself in this regard or it will not gain the ability to have flexibility and vendor independence down the road.
You cite the importance of distinguishing between open source software components used in development and those used in production. Just how important is this distinction?
Zachary: Well, for example, programmers may develop an application on JBoss but deploy it on BEA Systems' WebLogic. Such an organization would require a different level of support from its open source stack provider than a pure JBoss environment would. It is an issue of options. An organization must ask: Do we get the support contract during the evaluation phase? In the evaluation phase, the value of support contract is more on developer education. I think the enterprise should consider having various levels of support based on the criticality of the open source application in question.
What would happen if a user did not understand the difference?
Zachary: If you were to skew to the conservative side, you will spend a lot of money on production-level support that goes mostly unused. If you skew the other way, then you risk having an outage in a critical system with no expert to turn to.