Consider scale, open governance, and culture

We’re excited to see more companies embracing open source software and operating principles. Open source adoption in the enterprise is great for open source ecosystems that thrive on the strength and diversity of the community. More enterprise developers working in the open produces more secure, innovative technology for all.

So, how do you create an enterprise that embraces open source? When becoming an open enterprise, you need to consider risks, scale, open governance, and culture.

Consider the risks. Open source adoption doesn’t come without some risks. You need to have a strategy in place for where you will invest and how that technology will affect your current technology stack.

Think about scale. When creating or investing in open source projects, you need to consider how you scale those projects within your enterprise. When we engage in a project, we focus on those aspects that matter most to the enterprise: interoperability, portability, security, scalability, and accessibility.

Push for open governance. Open governance ensures the long-term success and viability of open projects. We engage in communities that embrace open governance, donating our code for the benefit of the community while also using the resulting code in our own products.

Create an open culture. Becoming an open enterprise requires a shift in your company’s culture. It isn’t going to naturally happen, but there are some things you can do to encourage an open culture. We go into more detail below.

Learn about our approach to open technology  

Speed innovation with open source support

Enterprises need help unlocking the full potential of large-scale open source software adoption. A new market study from Forrester shows how IBM Open Source Support can improve developer productivity and help clients deploy new apps faster.

18% Higher developer productivity
30% Lower 3-year Infrastructure cost of operations
44% Faster to resolve downtime

Essentials of an open source program

At IBM, we have six core elements in our open source program to help us achieve this culture of open. Consider using or adapting these elements to build your own open enterprise.

Dive into each element and discover how you can create an open.

  • Before working with open source — either on company or personal time, employees must take our annual training. This training ensures everyone has a solid understanding of open source and its benefits and risks.

    Because we are constantly refining our open source process, IBMers must complete the training annually for as long as they are actively engaged in development or other activities involving open source. Over 60,000 IBMers complete this training every year.

    Essential elements of open source training

    Some of the key elements we cover in our training include:

    • Definition of open source: Any employee working with open source needs to understand what it is and also what it is not. Once a clear definition is established, it’s easier to talk about how to use it effectively.
    • Benefits of open source: We highlight the benefits of open source to encourage employees to contribute.
    • Potential risks: Our training talks about the common risks associated with open source. We want employees to be able to spot the risks, but our approval process is also in place to uncover and reduce the potential risks early in the development cycle.
    • Open source licenses: It’s critical everyone understands permissions granted by licenses, license obligations, and how to properly handle open source packages according to the license. This understanding ensures our intellectual property is protected, that terms of the license are honored, which all helps to protect our reputation as good open source community citizens.
    • Ways of working with open source: Training includes our policy on working with open source on personal time, consuming open source internally, consuming open source in products and services, handling open source from a vendor or client, and contributing to open source.
    • Open source and corporate strategy: Understanding what role open source plays in our corporate strategy provides context to help developers understand how their open source contributions benefit our entire company.
    • Open source management process: We explain the steps, tools, and stakeholders involved in our process.

    Both our process and our training material is revised regularly as we get feedback on what is working well and what we can do better.

  • Recognize and reward contributors

    We want all of our developers to be engaged in open source. Each year, we recognize IBM employees who contribute to open source with cash awards, and individually publicize each awardee across the company.

    Our award categories include project creators, significant contributors, and project leaders in key open source communities.

    This program has coaxed developers that may be new to open source to make that first contribution and become ongoing contributors. In addition to our incentive program, we also have open source mentors available to sit down and help developers make their first contribution.

  • Scale with tooling and automation

    Because our open source usage across our products and services increases 30% year over year, we have to automate solutions to keep up. We developed in-house tooling which can be dropped into DevOps tool chains to automate open source management.

    When assembling a tool chain to manage open source, there are multiple angles to consider. Focus your tooling and automation on the following vital areas:

    • Open source identification: What open source is in the build, including all dependencies?
    • License identification: What open source licenses are in the build? Sometime there is more than one license in an open source package. If there is more than one license, are the licenses compatible? Does the license contain any unique terms?
    • Open source scanning: We scan the source code of open source packages to identify potential IP issues such as other third party licenses in the code (including commercial software), potential patent issues, and any prohibitions for commercial use. We also scan for depth- to identify dependencies which could have licenses that may not be compatible with the parent package.
    • A centralized data store: We have a centralized repository for internal analysis of open source packages, so teams can share scan results and not duplicate effort. We have over 60,000 unique scans available.
    • Automated analysis of new versions: If a new version is not significantly different than a previously scanned version of an open source package, we don’t require a new code scan.
    • Workflow automation, metrics, and tracking: Our tooling supports customization of approval workflows based on risk and business unit requirements. We support all sorts of use cases – some where no approvals are required to others where legal and business executives must approve. We use the workflow to track what open source technology is used in which products and services across our entire portfolio.
    • Contribution tracking: Often our contributors will have personal GitHub ID and an IBM GitHub ID. We use tooling to track contributions under both IDs to ensure everyone gets credit towards our recognition program. We respect our developers’ need to be individuals, and their open source code contributed under a personal ID represents them and their resume.
  • Create a dedicated management organization

    Our open source management process brings together business, legal, and technical stakeholders. Organizationally, a central open source team manages the process and consults with development teams to answer questions and make sure the process runs smoothly. Our dedicated team has decades of open source knowledge and experience, and provides education, consulting, and policy and process management for IBM teams.

    The open source team works closely with our DevOps teams responsible for tooling and automation to expand and improve our open source management and review process. Our customized tooling includes identification and scan tools, review workflow for product usage and contribution requests, and databases and portals to effectively share information and guidelines across all of our business units.

    Having an accurate picture of all open source across our portfolio is the foundation for open source vulnerability management. Our internal open source process tools can track vulnerabilities so that product teams can quickly address them.

  • Define a process for consuming open source

    It’s important to set clear processes for how to consume open source technology—both the open source that is built in-house and other projects you adopt from outside your company. Here are our general guidelines.

    Consuming open source inside IBM

    For open source that only IBMers use — experiments, development tools, productivity tools, internal builds — our rule is that as long as the open source has a license that is on our internal list of approved licenses and the package is not on our very short list of packages prohibited for internal use, then the open source needs no formal approval.

    Note that if there is an End User License Agreement (EULA) or other terms required to download the software, it is not open source and those terms would have to be reviewed further.

    Consuming open source outside IBM

    When we talk about open source used outside IBM, we mean code that is included in a software or services offering, whether deployed in our cloud or a customer’s on-premise systems. Common examples include software and hardware products, Software as a Service (SaaS), and cloud solutions. When we use open source technology in a product or service, we follow a formal process that ensures that we honor license obligations and track what open source is used in each of our products and services. This is also important to ensure we can identify and address security vulnerabilities.

    Our process is as transparent to developers as possible. Most teams use a continuous delivery model, sometimes delivering multiple times a day. This process enables teams to submit changes to their open source Bill of Materials on a monthly cadence, so the approval process is not an obstacle to delivery.

    Here are the steps:

    • New open source added to a build is identified by tooling. The reporting capabilities in the tool identify the package name, version, associated license(s), and whether the source code for that package has been scanned previously.
    • For any open source that has not previously been scanned or is not closely related to a version previously scanned, a code scan is performed and saved for other teams to reference.
    • The release manager submits the request, which can include several hundred or even several thousand open source packages.
    • The workflow tool automatically calculates the number of approvers required and routes the form after each signature. Over 90% of the time, requests are approved by a first line manager and the open source management lead for the business unit. In some cases, for example when a license requires separately licensed code, both legal and business executive approvers are required.
    • This process is repeated for new open source technology added to the offering. Once the open source has been approved for a given offering, it needs no additional approval for future releases.

    Along the way, our open source management leads are available to answer questions and advise teams in our internal Slack channel.

  • Be responsible open source contributors

    We believe that contributing to open source projects is not only good manners, but part of our responsibility as an open source leader.

    We invest in community code for strategic technologies and ensure that fixes and new features are up-streamed rather than forking community code and creating our own version of a project. For instance, the Cloud Foundry that we integrate into IBM Cloud is the same code that is released by the Cloud Foundry Foundation, and the same that is used by HPE, Pivotal, and SAP. Similarly, the Docker included in IBM Container Service is the same Docker that that community releases.

    When we want to add extensibility that can use IBM’s particular capabilities, we work within the community to create the necessary API or SPI. We also invest in making sure that those extension points are not abused to create a potential for lock-in.

    We continue to evolve our process to encourage our developers to engage and contribute to open source communities. Our focus areas for contribution include:

    • Contributing to a featured community. IBM leads many open source projects that are strategic to our business and development interests. We encourage all developers to do bug fixes or small enhancements; an internal steering committee for a particular community reviews all major changes or enhancements.
    • Posting snippets and sample apps. With a manager’s approval, we encourage posting code snippets on developer sites and contributing sample applications and product usage examples.
    • Bug fixes and small enhancements to existing projects. Fixes and enhancements are encouraged across a wide variety of open source communities and in most cases require no formal approval.

    Proposing new projects. Reviews are held for new projects ranging from code patterns on IBM Developer, IBM @ GitHub, to starting broad community initiatives such as Hyperledger and Apache OpenWhisk.

Find a partner in open source

You probably don’t have time to comb through open source communities looking for answers or trying to understand dependencies across technology stacks. To get the most from your open source investments, you need to engage a support partner to help you mitigate any risks related to the open source in your enterprise. With our support services, you have a single place to go to support your entire open source ecosystem.

Engage our support services