Learn more >
At IBM, we take open source seriously. We train our employees in the best practices for engaging in open source communities and the importance of open governance, and we empower them to create open source projects that solve their business and personal problems.
We’ve learned a few things over the past three decades of contributing to open source, and we’re passionate about helping other enterprises create, adopt, and scale open source in their own companies. When becoming an open enterprise, you need to consider scale, open governance, and culture.
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, which are:
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.
To create an open culture, it’s critical that your employees understand the importance of open source, how to responsibly consume and contribute to open source, and the tools needed to engage with open projects.
At IBM, we have 6 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 in to each element and discover how you can do open source right.
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.
Some of the key elements we cover in our training include:
Participation in our training program is tracked, and annual training certification is a prerequisite to submit open source requests. Training is tied to our Business Conduct Guidelines, so it is not optional.
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.
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.
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:
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.
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.
Open source used within IBM means only IBMers use it. Examples include experiments, development tools, productivity tools, internal builds, and trying out the latest technology. 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, 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.
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:
Along the way, our open source management leads are available to answer questions and advise teams in our internal Slack channel.
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:
Back to top