Problem solve Get help with specific problems with your technologies, process and projects.

Preparing the enterprise for an open source software stack

Interested in making open source software an integral part of your core enterprise software stack? Allow analyst Raven Zachary to guide your efforts with these tips for a successful enterprise-level deployment.

Operating system vendors are "moving up the stack" and including common open source components in their releases, said Raven Zachary, an analyst with The 451 Group, based in New York. Zachary is also co-author of a new research report that outlines the trends in the stack arena.

More on the OSS stack
PostgreSQL vs. SQL Server: PostgreSQL is right for the Microsoft stack

Golden's Rules: Beyond the LAMP stack - A guide to open source Nagios, Xen & Asterisk

"Open source vendors are also making those components available as separate but complementary offerings," he said.

What that means for IT managers is that more infrastructure software components are being treated as part of the core operating system that end users expect to be present. Meanwhile, Zachary said, application vendors are increasingly looking to deliver a complete package to their customers by bundling required third-party components in with their offerings.

"Consequently, we believe the market for pure-play open source stack providers looking to support enterprise customers directly is limited," he said.

With those limits as the backdrop, Zachary listed the following trends that IT managers should watch for and some advice they should follow as they bring more open source software into their core enterprise operations:

  • Supplier commoditization. Where popular open source components are not backed by a single vendor, multiple vendors offer the same services and risk becoming commoditized. Because of this, customers have regular opportunities to reevaluate their relationships with suppliers and seek alternative suppliers.
  • Understand relationships. Relationships aren't just about dating. IT managers need to understand the relationship between open source stack providers as well as the open source project communities themselves. This includes well known open source vendors like MySQL and JBoss. "Eighty to 100% of the core developers for those projects are employees of those firms," Zachary said. "Do due diligence with the company that is actually providing you with support [for the stack]. If all a vendor is doing is acting as an intermediary between you and the community, maybe it is more cost-effective to engage the community directly."
  • Explore stack certifiers. Organizations new to open source or with limited internal IT resources should consider employing the services of an open source stack certifier like SpikeSource Inc. Building a best-of-breed stack with multiple providers -- from scratch --- requires a learning curve and internal resources. Zachary said that customers do benefit from a single point of accountability in this case, but he added that there needs to be an understanding that this approach is a transitional area.
  • Make sacrifices for expertise. In light of the last point, Zachary cautioned that the downside of working with a single vendor is that customers may sacrifice depth of expertise, direct access to core code changes and coverage of the less common components. This is especially true if customers are dependent on a large number of open source components. However, the more focused the set of components required, the more likely it is that a single vendor will have the expertise to provide the necessary support.
  • Designate your primary point of contact. 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 it entirely to a provider.
  • Document your support and know your contacts. The levels of support for each open source component in use should be fully documented, including a contact for the support of each component. For some components, this may be an open source stack provider while for others it may be a community of users and developers. Consider an escalation plan in cases where there is no vendor support for an open source component.
  • Open source with closed source standards. The same support standards should be applied to proprietary and open source software. If an open source component is used in production, it should meet the same standards applied to proprietary or custom software. Although the open source market is still maturing, these providers are competing with the alternative -- a non-open platform -- and to be competitive, they must provide levels of service comparable to proprietary vendors.
  • Know your role and your dependencies. A key aspect of identifying suitable vendors is understanding dependencies. If an organization is highly dependent on specific open source software components, it will want to seek out the best expertise possible. The various open source stack providers offer various degrees of expertise in specific open source software components. Users should match dependencies to providers' offerings.
  • Communities versus providers. These relationships will affect the level of service that customers can expect from providers, especially in the case of bug fixes and feature requests. The greater the level of collaboration that exists between the teams that create the software and the vendors that support it, the more likely it will be that issues will be escalated to the appropriate parties for resolution. While a commercial relationship with an open source stack vendor doesn't provide preferential treatment for open source project issue resolution or feature requests, it may provide advocacy for customers.

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.