The IBM open source way

At IBM, open source is much more than just a license, it’s part of our culture. We’ve done open source since the beginning and we’re sharing our knowledge with you!

Explore our proven methods for open source success. Reap the benefits, avoid the pitfalls, and learn how to do open source the right way.

Open source at scale

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.

What makes IBM good at scaling open source?

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:

  • Interoperability
  • Portability
  • Security
  • Scalability
  • Accessibility

Why is open governance important?

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.

Is IBM open source really open?

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.

What is the “IBM open source way”?

We focus our open source efforts around six core elements that together make up the “IBM open source way”:

  • Training Training enables a common starting point across the organization for understanding process and encouraging participation in open source.
  • Recognition A recognition program rewards those who participate in open source and also connects potential open source mentors to those who are new to open source.
  • Tooling It is difficult if not impossible to scale a manual process. Tooling and automation is key.
  • Organization Our central Open Source Core Team includes experts available to answer questions and advise teams on consuming and contributing to open source.
  • Consuming We have a formal process around consuming open source, tailored to use just enough process for the situation.
  • Contributing We don’t require a formal approval for most contributions.

Dive in to each element and discover how you and do open source right.

It starts with training

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.

What are the essential elements of open source training?

Elements of our open source training include:

  • Definition of open source It’s important everyone working with open source in the organization understands what it is and also what it is not. For example, other types of third party software such as freeware are often confused with open source.
  • Benefits of open source From driving emerging technologies and leveraging open standards to contributing to projects to add qualities important to your customers, our training covers common benefits.
  • Potential risks Open source does come with risk- our training includes common risks associated with open source, and our approval process is designed to uncover and reduce 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 to ensure our intellectual property is protected and terms of the license are honored. This protects 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 We explain why open source is key to our corporate strategy, and why it’s important for all our developers to consume and contribute to open source.
  • Open source management process We explain the steps, tools, and stakeholders involved in our process.
  • Tracking and metrics 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.
  • Feedback 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.

Recognizing our open source heroes

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.

  • Leadership This award category includes active leaders of the Project Management Committee or similar leadership team who are clearly one of the driving forces behind the project in the review period.
  • Significant contributor Significant contributions to project code, documentation, major testing, and/or substantial outreach for a significant portion of the review period.
  • Project creator Creator of a new open source project hosted on the IBM Code/open page in the review period.

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.

We scale with tooling and automation

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.

What tooling and automation areas should I focus on?

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, then no new code scan is required.
  • Workflow automation, metrics, and tracking Our tooling supports customization of approval workflows based on risk and business unit requirements. We can support use cases where no approvals are necessary to cases where legal and business executives must approve. The workflow is also used to track what open source is used in which products and services across our entire portfolio.
  • Contribution tracking Often an IBMer will have a different personal GitHub ID and IBM GitHub ID. We use tooling to track contributions under either ID 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.

Our open source management organization

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.

Consuming open source

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.

Consuming open source inside IBM

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.

Consuming open source outside IBM

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:

  • 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 or not.
  • For any open source identified that is not previously 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 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.

Consuming open source at scale: Meet the Watson Workspace team!

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.

Learn more »

Placeholder image

Contributing to open source

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:

  • Contributing to a featured community IBM leads many open source projects that are strategic to our business and development interests. Bug fixes are encouraged from all developers while proposing major changes or enhancements are reviewed by an internal technical steering committee for that community.
  • Posting snippets and sample apps With manager ok, we encourage posting code snippets on developer sites and contributing sample applications and product usage examples.
  • Bug fixes and small enhancements to existing projects From functional or security to performance or supporting IBM solutions and platforms, 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 developer kits on IBM Code Open, IBM @ GitHub, to starting broad community initiatives such as Hyperledger and Apache OpenWhisk.

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.

What are the open source etiquette “golden rules”?

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.

Be nice and courteous

If the community views you as rude or arrogant they will go out of their way to ignore you.

Don’t be a talker- be a doer and a good observer first

Open source communities respect your ability to contribute code and documentation improvements.

Don’t flaunt your title or education

All the community cares about is your ability to be a hands-on contributor.

Get a mentor in the community. Let them put you to work

The experienced contributor will be more willing to answer your questions and do code reviews of your work if you help them out.

Don’t be a drive-by committer

Communities expect a significant, ongoing commitment. Don’t dump in code for a feature you want and leave.

Start small, build trust

You need to contribute small changes for a long time before you will be trusted to make large changes.

Don’t forget tests

Expect to submit unit tests with your code patch and understand the testing frameworks used in the community.

Code as the foundation of your reputation

When you contribute, the clear expectation is that you have the rights to contribute the code and that it is an original work, unless properly attributed to the author.

Know the license and stick to the rules

IBM prefers to contribute under permissive licenses such as the Apache v2, MIT, EPL, and BSD licenses. GPL, AGPL and other restrictive licenses can cause risks and require special consideration.

Be authentic

Being authentic means sharing the code and responsibility. All your code development from commits, to issues, to automated test cases — will happen in the open.