The model of the future is based on social, mobile, cloud and big data, and IT is realizing that to succeed it must have the right processes, tools and culture. This is where open source is a major benefit.
Once you've decided to make open source a key feature of your enterprise IT infrastructure, here are steps you should take:
* Identify critical dependencies: It's important to determine which components of an open source deployment represent critical dependencies. These are the ones you need to be fully certain about in terms of community size, robustness, feature suggestions and more. When it comes to components that represent dependencies, it's important to ensure you don't get locked into something that isn't the perfect fit.
ACTION: Survey your open source use and determine which projects/products you're using. Separate into useful, important, and critical. Ensure you have on-staff or commercial support for all critical and any important projects that are used in mission-critical or customer-facing projects. A commercial product like Black Duck can help to identify which open source products/projects you're using.
* Build open source skills: Unlike proprietary vendors' products, open source doesn't come with a help desk. Self-reliance is a necessity, and to fully engage in open source there must exist a willingness to learn and develop open source skills.
ACTION: Given the project/product survey executed for the previous step, identify important skills needed to succeed with critical and important projects and begin a program to infuse those skills. For current recruiting, add open source skills to candidate evaluation. For current staff, survey for skills and begin a training regimen to educate staff. Develop future staffing plan to recruit new talent with uncovered skills.
* Determine what to contribute and what to keep internal: With any code you write, decide where to place it. Always remember that if you contribute it to the product, your code will become part of the product and be present in future releases.
ACTION: Identify all code written to extend or integrate open source projects/products. For all extending code (i.e., code that resides inside the project/product and implements additional functionality) take a default position that it should be contributed to the upstream code base. For integration code, evaluate how much, if any, could be contributed to the upstream code base of a project/product and do so. For any integration code that must be kept in-house, ensure you have a long-term maintenance approach and budget to support. If you do not currently have an open source policy and process that supports code contributions, develop one stat.
* Understand that open source isn't a one-size fits all approach: Although open source deployments offer a number of advantages, that doesn't mean it should be used for every application. There will be instances where a proprietary product is a better fit. It's important to recognize and understand which components of your project are better suited to open source, and which aren't.
Sign up for CIO Asia eNewsletters.