The topic of support as it relates to open source software is one that typically centers around that which is purchased from a commercial vendor. However, a concept worth exploring involves enterprises developing in-house capabilities to support the use of open source within their own IT departments. This in house support could be aligned with existing IT service delivery mechanisms and would be designed to meet the parameters of company-wide open source software policy.
James McGovern has been a leader in calling for the industry analyst community to actively address this subject area and he is dead-on in doing so. Organizations, especially those at the larger end of the spectrum, are entirely capable of developing sufficient levels of competencies in terms of supporting open technologies. The transparency of everything from the software assets themselves to the surrounding community make the prospect of developing expertise with and understanding of the technology at hand a viable option.
The need for external vendor support is most appropriate in situations where a software asset is running within a mission critical 24x7 environment. However, this isn't the reality for the majority of situations. Perhaps for infrastructure software (operating systems, databases, application servers, web containers, clustering software) or business applications (CRM, ERP, HR), but other categories of open source don't tend to meet this criteria as strictly. In these cases it behooves the enterprise to consider developing a strategy for ramping up and delivering support for open source software.
This strategy should be agnostic with regard to the type of asset for which the support is being provided and should focus on the follow areas:
- Creating a catalogue of open source assets already in use.
- Assembling the concept of toolsets, or groups of open source software which can be used in conjunction with each other.
- Assures best practices are documented, maintained and updated barring any changes.
- Makes visibility up the reporting chain a priority.
- Alignment with open source software governance.
The overall goal is to encourage the cultivation of knowledge and understanding related to a variety of open source software that might be in use. Far from expecting, an already overworked IT staff to memorize the intricacies of the Linux kernel, it would be closer to making sure that individual(s) who are best qualified to initiate a knowledgeable investigation of how to support the use of open source software, do so. In turn the appropriate persons should be recognized and charged with prioritized responsibility to take the lead in the felicitous areas.
A hypothetical example might be if a company's webmaster introduces Drupal as a content management solution for a small set of intranet sites. He/she should be able to catalogue its use (information about its intended purpose, license, version, etc.) as well as name him/herself as a point of contact for it. After doing so, any delegated point of contact(s) should be given room to proceed with documentation in the specified format. If Drupal is implemented in affiliation with other open source software both should be marked as belonging to a common toolset. Any succeeding issues or questions related to an asset in the catalogue can then be directed to the best available point of contact(s).
Reviews of the catalogue should be done at no less than a quarterly clip and needs to entail issues filed against an asset and their state within an assigned issue tracking process, much the same way they are in open source communities. By facilitating the development of internal knowledge bases which can be tapped at will as a source of support, organizations are able to take full advantage of the independence afforded by the open source model. At the least it's a concept worth investigating as the use of open source continues to spread into newer domains.
Leave a comment