This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
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.
ACTION: Ensure that every software component evaluation looks at both proprietary and open source options. Develop a structured evaluation process and criteria used in evaluations to ensure common approach and impartial decision-making. Of course, be sure to factor in ongoing investment necessary to work with an open source project/product to ensure apples to apples comparisons.
* Be active in communities: What largely makes open source succeed is the fact that people are constantly improving the software. Having users take an active approach is key, and likewise, working with open source project leaders when changing code. Sharing successful strategies also helps strengthen the community – after all, successful adoption of open source is based on the best practices and experiences of others.
ACTION: Attend local and national open source-related meetups and conferences. Identify staff to get involved in important and critical open source projects/products and support their involvement. Consider financial support for important and critical projects/products.
* Last, but certainly not least, beware what we call the “new legacy”: Many IT organizations leverage open source components to build new applications, but overlook the reality that those applications become an ongoing engineering commitment. Many IT organizations have built home-grown DevOps tool chains that string together open source components. The problem is that, down the road, the original engineers have left and the undocumented system is a mess, and then those organizations realize that open source can result in legacy too.
Being free and flexible isn’t a sufficient reason to decide you’re now in the open source-based application business. Every line of code you write becomes an ongoing responsibility.
The nature of enterprise IT is rapidly evolving and with these changes, open source is becoming a much higher percentage of every IT organization’s environment. As more organizations get aboard the open source train, the necessary skills will become critically important – not only for using open source wisely, but for ensuring your enterprise remains competitive in the Third Platform world.
About Bernard Golden: Named by Wired as one of the ten most influential persons in cloud computing, Golden serves as Vice President, Strategy for ActiveState Software. Prior to ActiveState he was Senior Director, Cloud Computing, for Dell Computer. Golden is the author or co-author of four books on virtualization and cloud computing, including his most recent book, Amazon Web Services for Dummies, published in Autumn 2013.
This story, "How to embrace open source tools in the enterprise" was originally published by Network World.