Explore our proven methods for open source success. Reap the benefits, avoid the pitfalls, and learn how to do open source the right way.
IBM does open source at scale. Our open source management process balances development and compliance, and is the result of our experience since the beginning- when the definition of open source was formalized nearly 20 years ago. We’re sharing what we know with you to help you successfully embrace open source development.
IBM is unmatched in building enterprise technology, and our open source efforts and investments reflect that fact. When we engage in a project, we focus on those aspects that matter most to the enterprise, which are the things we know how to do well:
IBM invests in communities and helps shape programs that can deliver characteristics that matter to our clients and partners. We value open governance because it ensures the long-term success and viability of those projects that form the foundation of our enterprise offerings and solutions.
For example, IBM donated 44,000 lines of code to the Linux Foundation’s Hyperledger Project while providing new blockchain-as-a-service offerings on the IBM Cloud. IBM worked with other industry leaders in the Hyperledger Project because we recognize the long-term value of open collaboration and a cross-industry open standard for distributed ledgers.
We’re also investing in more and more open source from within IBM development and research labs; you’ll find all kinds of innovative open source projects within our IBM Code initiative.
We drive interoperability, portability, and other features that matter most to the enterprise. We also focus on contributing IBM innovation upstream rather than maintaining closed source when it pertains to strategic projects such as Hyperledger. There is IBM value-add in our offerings, but we don’t invest in interoperability and portability only to ignore these attributes when we deliver our own offerings based on those open technologies. Our strategy is based on leveraging a solid foundation of open technology and ensuring that the interfaces (APIs and SPIs) defined by these technologies are fully exposed and not hidden or inaccessible behind a proprietary veneer of value-add.
We strive to not fork the community code by creating an “IBM Hyperledger” or “IBM Cloud Foundry.” 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.
We invest in the community code for these strategic technologies. We work to ensure that fixes and new features are up-streamed rather than adding extra complexity and effort on IBM’s part to maintain an independent, differentiating version. Where we desire to add extensibility that can leverage IBM (or others’) 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 focus our open source efforts around six core elements that together make up the “IBM open source way”:
Dive in to each element and discover how you and do open source right.
All IBM employees must take our annual training before working with open source either on company or personal time. This training, which is tied to our Business Conduct Guidelines, ensures everyone starts off with 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 services activities involving open source. Over 62,000 IBMers complete this training every year.
Elements of our open source training include:
We want all of our developers to be engaged in open source. Each year we recognize several hundred IBMers 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.
Over our nearly two decades of involvement in open source, we have developed in-house tooling which can be dropped into DevOps tool chains to automate open source management. Necessity drives automation–we see 30% year-over-year increases in open source usage across our products and services, and our process has to scale accordingly. Approximately 150,000 open source package requests are projected to be cleared through our process in this year alone. 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 Core Team (OSCT) manages the process and consults with development teams to answer questions and make sure the process runs smoothly. The OSCT has decades of open source knowledge and experience, and provides education, consulting, and policy and process management for IBM teams.
The OSCT works closely with our DevOps teams responsible for tooling and automation to expand and improve our open source management and review process. Enhanced automation and connections to development/build tools has allowed us to support our ever-growing usage and contributions to open source. 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 the diverse set of IBM business units.
An accurate picture of all open source across our portfolio is the foundation for open source vulnerability management. Our enterprise secure engineering leverages our internal open source process tools to track vulnerabilities for remediation by product teams.
All IBMers are required to complete our annual open source training and get their manager’s approval for open source related work. Our process for consuming open source is different depending on whether we’re using it inside IBM or outside IBM in a product or service.
Open source used within IBM means only IBMers are using it. Common 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.
Open source used outside IBM means inclusion 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, and Software as a Service (SaaS), cloud solutions. Consuming open source in a product or service uses a formal process to ensure we honor license obligations and also 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 designed to be 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.
Beyond making things better for our end-users, Watson Workspace has redefined how we build, test and deliver software in IBM. We started from the premise that the cloud-first principles which revolutionized the consumer software market can and should apply just as well when building enterprise collaboration tools: Horizontal scalability to support millions of users, true continuous delivery with builds deployed to production within hours of code being committed, security at the foundation of everything we do and a delivery model where every step of the process, from testing to deployment is automated.
Our automated process clears over 90% of our open source with no human intervention required.
IBM does not look to fork community code. We do not want to create an “IBM Hyperledger” or “IBM Cloud Foundry”–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.
We invest in the community code for these strategic technologies and ensure that fixes and new features are up-streamed rather than adding extra complexity and effort on IBM’s part to maintain an independent, differentiating version. Where we desire to add extensibility that can leverage IBM (or others’) 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.
IBM believes that contributing to open source projects is good manners, part of our responsibility as an open source leader, and the essence of “the IBM way.” We continue to evolve our process to encourage our developers to engage and contribute to open source communities. Our focus areas for contribution include:
IBM has over 1500 repos across GitHub, thanks to ongoing contributions of new projects from IBMers. We’ve learned a thing or two about how to contribute to open source projects.
If you’re implementing open source in your organization — and you should! — be sure to remember these best practices. They’ll help you become a trusted, in-demand collaborator and innovator.
Back to top