Why CII best practices gold badges are important

“A CII Best Practices badge, especially a gold badge, shows that an OSS project has implemented a large number of good practices to keep the project sustainable, counter vulnerabilities from entering their software, and address vulnerabilities when found.” – David A. Wheeler, Director of Open Source Supply Chain Security

Open source software (OSS) is now widely used by many organizations. But with that popularity, that means the security of OSS is now more important than ever. The CII Best Practices badge project — including its top-ranked “gold” badge — helps improve that security.

In June 2020, two different projects managed to earn a gold badge: the Linux kernel and curl. Both are widely depended on, and yet in many other ways, they are radically different. The Linux kernel has a large number of developers, and as a kernel, it must directly interact with a variety of hardware. Curl has a far smaller set of developers and is a user-level application. They join other projects with gold badges, including the Zephyr kernel and the CII Best Practices badge application itself. Such radically different projects managed to earn a gold badge and thus demonstrated their commitment to security. It also shows that these criteria can be applied even to such fundamentally different programs.

But what are these badges? A Linux Foundation (LF) Core Infrastructure Initiative (CII) Best Practices badge is a way for Open Source Software (OSS) projects to show that they follow best practices. The badges let others quickly assess which projects are following best practices and are more likely to produce higher-quality secure software. It also helps OSS projects find areas where they can improve. Over 3,000 projects participate in the badging project, a number that grows daily.

There are three badge levels: passing, silver, and gold. Each level requires that the OSS project meet a set of criteria; for silver and gold that includes meeting the previous level. Each level requires effort from an OSS project, but the result is reduced risks from vulnerabilities for both projects and the organizations that use that project’s software.

The “passing” level captures what well-run OSS projects typically already do, and has 66 criteria grouped into six categories. For example, the passing level requires that the project publicly state how to report vulnerabilities to the project, that tests are added as functionality is added, and that static analysis is used to analyze software for potential problems. Getting a “passing” badge is an achievement, because while any particular criterion is met by many projects, meeting all the requirements often requires some improvements to any specific project. As of June 14, 2020, there were 3195 participating projects, and 443 had earned a passing badge.

The silver and gold level badges are intentionally more demanding. The silver badge is designed to be harder but possible for one-person projects. Here are examples of silver badge requirements (in addition to the passing requirements):

  • The project MUST have FLOSS automated test suite(s) that provide at least 80% statement coverage if there is at least one FLOSS tool that can measure this criterion in the selected language.
  • The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (a whitelist) and reject invalid inputs if there are any restrictions on the data.

The gold badge adds additional requirements. Here are examples of gold badge requirements (in addition to the silver requirements):

  • The project MUST have a “bus factor” of 2 or more (a “bus factor” is the minimum number of project members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel).
  • The project MUST have at least 50% of all proposed modifications reviewed before release by a person other than the author.
  • The project MUST have a reproducible build. 
  • The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values.

Historically the LF has focused on getting projects to the passing level because projects not even at the passing level have a higher risk. But many projects are widely depended on or are especially important for security, and we love to see them earning higher-level badges.

Of course, a gold badge doesn’t mean that there are no vulnerabilities in the existing code, or that it’s impossible to improve their development processes. Perfection is rare in this life. But a CII Best Practices badge, especially a gold badge, shows that an OSS project has  implemented a large number of good practices to keep the project sustainable, counter vulnerabilities from entering their software, and address vulnerabilities when found. Projects take many such steps to earn a gold badge, and it’s a good thing to see.

We hope other projects will be inspired to pursue — and earn — a gold badge. Of course, the real goal isn’t a badge — the real goal is to make our software much more secure. But good practices can help make our software more secure, and we want to praise and encourage projects to have good practices.

For more background information on the best practices badge, see the presentation “Core Infrastructure Initiative (CII) Best Practices Badge in 2019”.

OSS projects can go to the CII Best Practices badge website to begin the process of earning a badge. If you’re considering the use of some OSS, we encourage you to check that website to see which projects have earned a badge.

Those who wish to learn more are welcome to contact David A. Wheeler, Director of Open Source Supply Chain Security at The Linux Foundation, at dwheeler AT linuxfoundation DOT org.

Building a successful open source community

Why do you need program management as part of your open source project? We asked a few of the Linux Foundation’s program managers to tell us how they each approach the task.

How does coordination and facilitation help improve my project? 

We tend to think of the primary goals of the Linux Foundation’s projects as producing open software, open hardware, open standards, or open data artifacts — the domain of participating programmers & engineers, system architects, and other technical contributors. 

However, successful projects engaging a broader ecosystem of commercial organizations, particularly when raising funds, benefit from active leadership besides pure technical contributions. Contributors often have work outside the project that often puts demands on their time. It takes real time to build and coordinate a commercial ecosystem, ensure stakeholders are engaged, recruiting and onboarding members, create a neutral governance culture (often amid competitors competing), and to keep various aspects of the ecosystem aligned such as when end users begin to participate.

Many Linux Foundation projects fundraise to provide resources for their community. This is an excellent benefit for the technical community when the business ecosystem comes together to invest and help the community obtain resources to build a thriving community and ecosystem. A typical fundraising model in our community is to offer an annual membership structure that provides a yearly fund for the project. 

The Linux Foundation’s approach to governance separates decisions about funds and business affairs from the technical project’s governance. The companies contributing money to a project’s fund can decide how those funds are spent and any related business decisions. The technical community can operate independently with open source best practices and continue to make decisions about what code to accept, how to build releases, etc. based on the technical merit of decisions in front of them and not based on what companies contributed funding.

We will always have representation from the technical community involved in the budget and business decisions to ensure funding decisions are well informed. This is how the Linux Foundation model preserves the development best practices of open source while enabling a community to benefit from the commercial ecosystem dependent on their work.

Guidance for your community

Within a technical project, there are roles for organizing how releases are built. Often some committers decide which code is accepted, and maintainers decide what to put into a release.  When scaling the project to create an ecosystem around it, there are other key roles and responsibilities that a project needs to stay on track and to continue to scale. These functions include:

    • Planning and Building.  Building a cohesive strategy is critical to the success of a project and requires investments in outcomes the core stakeholders want to see happen, and prioritize
    • Measuring KPIs. Tracking a project’s mission, goals, and objectives while moving those through the swim lanes is key to iterating on things that work and addressing things that don’t.
    • Facilitating. To be successful at facilitating, a coordinator must understand the landscape, and remain neutral. This can be difficult and is often the most challenging part of the job, NOT weighing in unless asked. 
    • Advising. Coordinators are a sounding board for these things with some expertise. To mature an organization, you must craft mechanisms for self-governance and sustainability.
    • Iterating and Reflecting. What happens along the way is that stakeholders in the community want to get things done — but when that happens without reflection, you lose sight of what and where you’re going. It’s essential to see the forest AND the trees, especially from an above-the-canopy view.

In the past, we have had a few communities with respected, neutral leaders who have provided these roles. The Xen Project is one example of a member of the community who has offered to perform this role for many years. There is a significant time investment from the community’s leadership to make it work, which is an excellent benefit for the community to have someone able and willing to spend their work time on this function. 

Many other projects are not able to find someone in the community to help. This is often where the Linux Foundation builds a support program to assist the projects we host that need help to obtain neutral coordination and facilitation professionals. We call the people who provide this support Program Manager (PM). PMs are often the first point of contact for community participants and potential members, and are usually involved in the following activities:

    • Program Managers help the governing and technical boards shape the project’s directions and goals. 
    • Program Managers will work with a project’s technical leadership to understand their technical goals. 
    • They work with the members to fill positions such as Chair and Treasurer and are involved with the voting process.
    • They ensure that both the governing and technical boards act within the agreed-upon guidelines of the project’s charter. 
    • They help onboard new members into the project community. 
    • They will engage resources from the Foundation’s Marketing, PR, Events, and Training teams to coordinate the support programs delivered for a project.  
    • Program Managers also oversee the delivery of other support programs provided by the Foundation and any services provided by vendors or contractors.
    • Program managers will pull in the Foundation’s IT service team members for a consultative discussion on the right development infrastructure, tools, and managed IT support programs based on the project community’s needs and roadmap. 
    • Program managers actively engage in community management and help the project’s leaders coordinate meetups, developer hackfests, and participation at events.

Setting strategic goals for your community

Identifying and articulating a project’s mission is essential with an open source project as it is with any business activity. Setting concrete goals enables the participants in a project to discuss and align around a single narrative that can guide their activities and inform decisions. 

Program Managers work with the project’s membership and technical leadership to define a strategy with goals, milestones, and metrics for the project. They coordinate discussions to assist the governing board in coming to a consensus on a budget that supports the technical community’s needs and aligns with the project strategy. 

For open source, very often, the goals include maximizing a project’s footprint in order to help the most people. Goals are often articulated to a fine granular level — enabling contributors to engage more easily, growing the membership from a particular sector of the ecosystem, or increase contributions from end users. 

The CHAOSS project is a community focused on defining community metrics around engagement, risks, etc. that are often helpful to project leaders in setting and establishing goals for measurably improving their ecosystem. 

Implementing a project lifecycle for your community

Open source projects often have subprojects and various efforts to innovate on new ideas that may not be ready to be included in an official release or as their independent release. We often refer to these communities as using an “umbrella” model with several coordinated sub-projects within the community. Within an umbrella community, the projects will typically follow a lifecycle. The lifecycle generally follows a path from imagination to planning to initial execution, expansion, and eventually maintenance and eventual retirement. 

Program managers often work with the technical leadership to codify this lifecycle according to milestones so that participants in the project can immediately understand where a project stands in terms of maturity and resources. CNCF, for example, has project phases that include Sandbox, Incubation, and Graduation. OpenJS Foundation has project phases that include Incubation, At-Large, Growth, Impact, and Emeritus, which map to the needs of their community.

A project lifecycle is an essential tool for a foundation to signal the maturity of multiple projects and identify for the community what the path towards a fully mature project requires. It is both a pathway and a signal, noting that projects grow and change, and what the community thinks a project should rely on to guide itself. 

In most projects, there is an entry-level, a mid-level, and a graduate level. The entry-level projects indicate a promising start for an emerging project and something to be considered. Mid Level projects show growth and development for an audience that might consider using this project, and graduated projects indicate full maturity and a project that many in the ecosystem rely upon.

“Within the Cloud Native Computing Foundation, the various project stages have been beneficial for encouraging projects to grow, not only from a development standpoint but from a community standpoint. A project looking to graduate has to demonstrate both a strong codebase and a strong community.”

Amye Scavarda Perrin, CNCF Program Manager

Linux Foundation Networking (LFN) Program Manager Trishan De Lanerolle notes how the Technical Advisory Council plays an active role in a project’s lifecycle management:

“Linux Foundation Networking project (LFN) technical leadership (Technical Advisory Council) developed and published a model that lays out criteria and checkpoints for projects in various stages of maturity, including an LFN Entry review and evaluation for new candidate projects to the LFN umbrella. The entry process provides a mechanism to amicably and fairly assess upcoming projects. In LFN, that entails asking whether a proposed project: falls within the LFN scope, provides a snapshot into the status or health of the community, and ensures the project’s documented governance is clear, complete, and easily accessible.”

Through facilitating the work of the Strategy Subcommittee, whose primary goal is to assist the Governing Board with developing and implementing Continuous Delivery Foundation (CDF) strategic planning, Program Manager Dan Lopez was able to guide CDF toward sustainable, long-lasting strategic goals. 

“The immense value of a Program Manager lies in their ability to foster a space for progress to happen. It’s not their role to necessarily make the tough decisions, but rather be the ‘glue’ of a program, ask the tough questions, and spark inspiration and critical thinking within their stakeholder group to create, in this case, sustainable goals that will create long term value for the CDF,”

Dan was able to approach strategic planning, as a neutral party who understood the landscape of the CDF, and assist the Governing Board in creating well-aligned goals that mapped to key performance indicators that can be measured and managed over time. 

The importance of open governance in your community

The Program Manager is also a vital member of the leadership team, working collaboratively to facilitate and operationalize the wants, needs, and priorities of the governing bodies. Each Linux Foundation Program Manager works with each project community to establish a transparent, open governance model for the technical community.

In open governance, a project is managed by a group of people representing the stakeholders in a project — generally project members and leaders of the project’s technical efforts. The concept of conducting a major technical effort using an open form of governance, in which all stakeholders’ needs must be addressed, and people are required to cooperate to get work done, is founded on the basic concept of democracy. It differs from closed or proprietary governance due to the transparency and coordination required to reach consensus.

Open governance provides a balance that can never be found in a proprietary, restrictive environment — the dynamics of that activity drive creativity and innovation, and significantly increase the speed of development. Program managers and community managers often guide these processes and help keep governance bodies on track with each other.

DPDK’s Program Manager Trishan de Lanerolle discusses how his project is divided into two bodies of equal responsibility:

“DPDK is one model of open governance, with co-equal governing bodies; the Governing Board has ownership and oversight, over budget, marketing, lab resources, administrative, legal, and licensing issues, and a Technical Board with ownership and oversight on technical issues including approval of new sub-projects, deprecating old sub-projects, the project’s technical roadmap, recruiting maintainers, defining the processes for contributing, testing, and managing security. The Technical Board comprises individuals from various organizations, that are not necessarily corporate members of the project, recognized for their technical contributions. The governing board comprises representatives from member organizations, who financially support the project, working hand in hand to make the project mission a reality.” 

Other projects, such as LF Energy, take a somewhat different path towards how their governance is structured. 

LF Energy represents an example of open, representative governance within a rapidly growing open source foundation. LF Energy has a board of directors, like most foundations, made up of Premier members, and includes a representative from the General members and a representative from the Technical Advisory Council (TAC), which is made up of technical project leaders. No single company has more than one representative on the board, which provides corporate as well as cultural diversity and voices from all over the industry, not just focused on one niche. 

The Linux Foundation’s neutral program management support program can help

Active program management and program management support is one of the main reasons why open source projects join an organization like the Linux Foundation. Our program management professionals provide a unique set of operational skills and capabilities that nearly all of our projects take advantage of — which is to offload operational and facilitation work from the community. 

In summary, a successful project should have community coordination and program managers that can plan and build, that can measure a project’s performance, that can act as prime facilitators and advise, and can help project stakeholders iterate and reflect to learn from their experiences in order to move a project forward.

“Managing Open source projects can be compared to nurturing a young sapling as it grows into a mature, healthy tree — or in this case, a community. Our job is to supply it with the right balance of nutrients and conditions for successful growth. Following proven governance models with strategic program management, helps increase the odds of nurturing a healthy community. Program Managers help clear the path, allowing communities to focus on the code and achieving technical goals. We are horticulturalists, toiling away in the background, and if we are doing our job correctly, you shouldn’t notice us.” 

Trishan de Lanerolle, Technical Program Manager & Community Architect, LF Networking

In 2020, we want to learn from best practices in how companies create effective open source strategies, how their open source programs are structured, and how they measure success.

The TODO Group is a set of companies that collaborate on practices, tools, and other ways to run successful and productive open source projects and programs.

Open source program offices help set open source strategy and improve an organization’s software development practices. Every year, the TODO Group performs a survey to assess the state of open source programs across the industry, and today we are happy to launch the 2020 edition.

Last year, over 2,700 people participated in the survey. As a result, we were able to learn: 

  • Adoption of open source programs and initiatives is widespread and goes beyond early adopters and; 
  • Hiring of open source developers is a prominent concern, and; 
  • Companies value their open source foundations

In 2020, we want to learn from best practices in how companies create effective open source strategies, how their open source programs are structured, and how they measure success.

We are also asking how macroeconomic conditions and COVID-19 are affecting open source. Survey closed.

The Security of the Open Source Software Digital Supply Chain: Lessons Learned and Tools for Remediation

Introduction

It has been estimated that Free and Open Source Software (FOSS) constitutes 70-90% of any given piece of modern software solutions. FOSS is an increasingly vital resource in nearly all industries, in the public and private sectors, among tech and non-tech companies alike. Therefore, ensuring the health and security of FOSS is critical to the future of nearly all industries in the modern economy.

In February of 2020, The Linux Foundation’s Core Infrastructure Initiative (CII), in partnership with the Laboratory for Innovation Science at Harvard (LISH), released the preliminary results of an ongoing study ‘Vulnerabilities in the Core,’ a Preliminary Report and Census II of Open Source Software.` This report represents the first steps towards understanding and addressing structural and security complexities in the modern-day supply chain where open source is pervasive, but not always understood.

The initial report from the Census II study identifies the most commonly used free and open source software (FOSS) components in production applications. It begins to examine the components’ open source communities, which can inform actions to sustain the long-term security and health of FOSS. The stated objectives were:

  1. Identify the most commonly used free and open source software components in production applications.
  2. Examine for potential vulnerabilities in these projects due to:
    • Widespread use of outdated versions;
    • Understaffed projects; and,
    • Known security vulnerabilities, among others.
  1. Use this information to prioritize investments/resources to support the security and health of FOSS

What did the Linux Foundation and Harvard learn from the Census II study?

The study was the first of its kind to analyze the security risks of open source software used in production applications. It is in contrast to the earlier Census I study that primarily relied on Debian’s public repository package data and factors that would identify the profile of each package as a potential security risk.

In order to gain a better understanding of the commonality, distribution, and usage of open source software used within large organizations, the study used software composition analysis (SCA) metadata supplied by Snyk and Synopsys. SCA is the process of automating visibility into any software, and these tools are often used for risk management, security, and license compliance.

With this metadata, the study was able to create a baseline and unique identifiers for common packages and software components used by large organizations, which was then tied to a specific project. This baselining effort allowed the study to identify which packages and components were the most widely deployed.

The top-scoring, most widely deployed projects were the ones that came under additional scrutiny and became the prime focus of the preliminary study, which were examined for the total lines of code, total number of contributors, and frequency of commits during the 2018 calendar year.

Observations and analysis of these specific metrics led the study to come to certain preliminary conclusions. These were:

Software components need to be named in a standardized fashion for security strategies to be effective. The study determined that a lack of naming conventions used by packages and components across repositories was highly inconsistent. Thus any ongoing effort to create strategies for software security and transparency without industry participation would have limited effect and slow such efforts.

Developer accounts must be secured. The analysis of the software packages with the highest dependents found that the majority were hosted with individual (personal) developer accounts. Lax developer security practices have considerable implications for large organizations that use these software packages because they have fewer protections and less granularity of permissions that are associated with them. For example, organizational accounts frequently employ the use of multi-factor authentication (MFA), which individual developers might not, potentially exposing larger organizations to attack.

Project atrophy and contributor abandonment is a known issue with legacy open source software. The number of developer contributors who work on projects to ensure updates for feature improvements, security, and stability decreases over time as they prioritize other software development work in their professional lives or decide to leave the project for any number of reasons. Therefore, as time goes by, it is much more likely that these communities may face challenges without sufficient developers to act as maintainers.

Legacy open source is pervasive in commercial solutions. Many production applications are being deployed that incorporate legacy open source packages. This prevalence of legacy packages is an issue as they are often no longer supported or maintained by the developers, or they have known security vulnerabilities. They often lack updates for known security issues both in their codebase or in the codebase of dependencies they require to operate. Legacy packages present a vulnerability to the companies deploying them in their environments. In essence, it means they will need to know what open source packages they have used and where so that they can maintain and update these codebases over time.

What tools exist to understand better and mitigate potential problem areas in open source software development?

The Linux Foundation’s community and other open source projects initiatives offer important standards, tooling, and guidance that will help organizations and the overall open source community gain better insight into and directly address potential issues in their software supply chain.

Understand the vulnerability vectors of your software supply chain

Concurrent with the publication of the findings of the Census II study is the Open Source Supply Chain Security Whitepaper. This publication explores vulnerabilities in the open source software ecosystem through historical examples of weaknesses in known infrastructure components (such as lax developer security practices and end-user behavior, poorly secured dependency package repositories, package managers, and incomplete vulnerability databases) and provides a set of recommendations for organizations to navigate potential problem areas.

Focus on building security best practices into your open source projects

For open source software developers, the Linux Foundation develops and hosts the Core Infrastructure Initiative’s Best Practices. This initiative was one of the first outputs produced as a result of the Census I, completed in 2015. Since that time, over 3,000 open source software projects have engaged, started, or completed the process of obtaining a CII Best Practices Badge.

Projects that conform to CII best practices can display a badge on their GitHub page, or their web pages and other material. In contrast, consumers of the badge can quickly assess which FLOSS projects are following best practices and, as a result, are more likely to produce higher-quality and secure software. Additionally, a Badge API exists that allows developers and organizations to query the state of CII best practice score of a specific project, such as Silver, Gold, and Passing. This means any organization can do an API check in their workflow to check against the open source packages they’re using and see if that project’s community has obtained a badge.

More information on the CII Best Practices Badging program, including background and criteria, is available on GitHub. Project statistics and criteria statistics are available. The projects page shows participating projects and supports queries (such as a list of projects that have a passing badge).

Gain better insights into the community developing your open source software

We encourage organizations and projects to join the CHAOSS community, whose work on tooling and risk metrics was leveraged in the Census II study. CHAOSS is a Linux Foundation project which is focused on creating analytics and metrics to help define the health of the software community. The community is working on open source tools, including:

Augur, which is a python library and REST server that is used to mine metrics from git transactions, such as the number of committers and commits over a historical period.

Grimore Lab is an open development analytics platform that allows for automatic and incremental data gathering from almost any tool related to contributing to open source development, such as for source code management, issue tracking systems, forums, mailing lists, and others. It also provides a data visualization dashboard that allows for filtering by time range, project, repository, and contributor.

Equally as important, the CHAOSS community has brought academics and corporate practitioners of open source best practices to develop common CHAOSS Metrics that any organization can adopt and begin using. The Metrics project includes metrics focused on Risk (including Security), the Evolution of a project, and many more useful metrics leading open source organizations to monitor their open source software supply chain.

Gain better insight into the open source software being used in your organization

The second major initiative by the Linux Foundation is Automating Compliance Tooling (ACT), which was launched in 2019 and comprises five major projects, which as of today include:

FOSSology an open source license compliance software system and toolkit, allowing users to run license, copyright, and export control scans from the command line. A database and web UI are also provided to provide a compliance workflow. License, copyright, and export scanners are tools available to help with compliance activities.

OSS Review Toolkit (ORT) enables highly automated and customizable Open Source compliance checks the source code and dependencies of a project by scanning it, downloading its sources, reporting any errors and violations against user-defined rules, and by creating third-party attribution documentation. ORT is designed for the CI/CD world and supports a wide variety of package managers, including Gradle, Go modules, Maven, npm, and SBT.

QMSTR, Also known as “Quartermaster”, this tool creates an integrated open source toolchain that implements industry best practices of license compliance management. QMSTR integrates into the build systems to learn about the software products, their sources, and dependencies. Developers can run QMSTR locally to verify outcomes, review problems, and produce compliance reports. By integrating into DevOps CI/CD cycles, license compliance can become a quality metric for software development.

Software Package Data Exchange (SPDX) is an open standard for communicating software bill of material information (SBOM) that supports accurate identification of software components, explicit mapping of relationships between components, and the association of security and licensing information with each component.

Tern is an inspection tool to find the metadata of the packages installed in a container image. It provides a deeper understanding of a container’s bill of materials, so better decisions can be made about container-based infrastructure, integration, and deployment strategies.

The ACT projects are also working with initiatives within other open source communities to support accurate identification and sharing of software metadata in the ecosystem. Of particular note are:

Clearly Defined, which is part of the Open Source Initiative (of which the Linux Foundation is an Associate member), is a shared repository of licensing provenance information through a common database that helps organizations understand the risks associated with using open source software.

Software Heritage, which is being developed in collaboration with UNESCO, is committed to collect, index, preserve and make readily available the source code of the software that lies at the heart of our culture. As with the Internet Archive (“Wayback Machine), which seeks to preserve the history of the Internet and its content, Software Heritage is a historical preservation of open source software and packages that anyone can search and browse through.

Conclusion

The preliminary findings of the Census II study strongly indicate that open source projects require supporting toolsets, infrastructure, staffing, and proper governance to act as a stable and healthy upstream project for your organization.

The Census II study shows that even the most widely deployed open source software packages can have issues with security practices, developer engagement, contributor exodus, and code abandonment.

Addressing these challenges is where an organization like the Linux Foundation and other nonprofit organizations can offer significant assistance and support for the project community using a low overhead model. The Linux Foundation is uniquely suited to not just providing tools, but also the governance, fundraising, and support programs that critical open source projects require in order to maintain a stable, secure and reliable release model. These support programs include:

    • Providing funding support through membership models or securing one-off contributions through crowdfunding, leaving the complexities of managing the legal entity, financial oversight, and regulatory filings to professionals that are highly experienced and dedicated to their administration.
    • Providing base policies that offer a known framework for commercial organizations to collaborate, including an antitrust policy, trademark policy, templates for a code of conduct, and more.
    • Providing entity management for maintaining the core administrative support infrastructure that enables communities to interact, including hiring leadership and community support personnel, in order to facilitate and guide projects on an ongoing basis.
    • Supporting community events for face to face opportunities, as well as marketing and communications support to grow a project’s community audience and help people learn about the great things they contribute to.
    • Eliminating the burden of managing software releases through hiring neutral release engineers that support the maintainers.
    • Providing a free platform in the form of CommunityBridge to address common challenges with fundraising, mentoring, security vulnerability scanning, and managing automated Contributor License Agreements (“CLAs”).
    • Providing training and professional certification support that enables building an ecosystem of skilled professionals in order to use, implement, and manage solutions based on a project’s technology.
    • Providing support for license compliance, export control, and security by the routine scanning of project repositories in order to help the community identify license and security problems before an official release proliferates issues to downstream users.

In summary, the Linux Foundation supplies communities with a repeatable, proven governance model as well as value-added support programs to help communities maintain and scale. The ultimate goal is that our communities become healthy upstream projects that your organization can rely on as secure, and well-maintained upstream open source projects in your software supply chain.

It’s not just the Linux operating system

Why have so many of the world’s most important open source efforts come to the Linux Foundation? Because of the ability to scale and provide value-added services to its communities.

Introduction

In April of 1991, while as an undergraduate student at the University of Helsinki, Linus Torvalds began a personal project to create a free operating system. In August of that year, he announced the project to the comp.os.minix newsgroup requesting input on features.

The rest, of course, is history. In the past 30 years, the Linux kernel and its surrounding userspace tools have become the most popular open source operating system in the entire world.

As part of its rise to prominence, increasing complexity, scope, and the number of project contributors, the kernel project required the necessary technology, administrative, and legal infrastructure to scale with the community. As a result, the Linux Foundation was founded in 2000 as the Open Source Development Lab (which subsequently changed its name to the Linux Foundation.)

The nonprofit purpose of the organization is to “support, promote, protect and standardize Linux and other open source software and technologies.” 

Project communities hosted by the Linux Foundation increased dramatically between 2013-2019

Figure 1. Project communities hosted by the Linux Foundation increased dramatically between 2013-2019.

At the time of the Linux Foundation’s formation, the organization was focused on promoting and protecting one project — Linux itself.

Up until roughly 2010, approximately a dozen or so projects related to the Linux operating system were hosted at The Linux Foundation. Those projects were formed to enable Linux’s evolution and entry into new segments and industry verticals, with the objective of making Linux the dominant platform by market share in every category of enterprise computing.

Today, Linux is an undisputed industry leader — but we should remember that was not always the case. At the time of the Foundation’s inception, Linux occupied only a minority market share in high-performance computing. In 2020, it now has complete dominance of the supercomputer market, wholly displacing UNIX, which held 85 percent of all HPC systems just 20 years earlier.

As a result of the efforts of the Linux Foundation’s communities over the past two decades, Linux now occupies a majority share in automotive, embedded systems, mobile devices, and cloud computing, as well.

As Linux continued to take a dominant foothold in all major markets, the Linux Foundation embarked on becoming a “foundation of foundations” to enable developers, communities, and members that wanted to leverage the same model of the LF — but for non-Linux technologies. Over the past seven years, the number of new project communities that the Linux Foundation supports has increased dramatically — which is now 225 and growing. And while that figure may seem small in a world where there are 23 million open repositories on GitHub, the projects at the Linux Foundation are at the heart of multi-billion dollar economies in cloud computing, networking, embedded systems, film, energy, and more.

As we celebrate the 20th anniversary of the formation of the Linux Foundation, it’s a good time to reflect on how the Foundation approaches support for open source innovation.

Scaling to support the world’s most important open source software communities

In the last 20 years, The Linux Foundation has become a critical commons for administration, support, enablement, and protection of open source community assets. This would not have been possible without first building a governance model that communities could trust to work for them, then building value-added support programs to support scale. The design goal has been to build the best upstream community model for downstream commercial solution providers and users.

As of February 2020, the Linux Foundation has become home to approximately 230 distinct project communities, spread among multiple industry verticals. In addition to the core Linux OS, the Linux Foundation communities build open source software technologies for Cloud, Networking, Security, Automotive, Blockchain, the Web, and even motion pictures. Beyond software, the Linux Foundation also supports open hardware communities such as RISC-V, OpenPower, and CHIPS Alliance.

The Linux Foundation’s communities have then gone further, building industry specifications and standards. The Joint Development Foundation (“JDF”) is the home to many of these specifications covering technologies such as GraphQL, video codecs, decentralized identity, and more. JDF is now also approved as an ISO JTC1 PAS Submitter, meaning that the Linux Foundation’s communities can now follow a path to becoming an international standard.

Every single one of these projects has associated community assets.

These include:

  • Over 12,000 Contributor License Agreements (CLAs) signed by contributing organizations for project communities requiring them.
  • Over 700 registered project domains and DNS records
  • Over 700 trademark registrations and applications, as well as hundreds of unregistered marks
  • Over 3,400 source code repositories
  • Approximately 3,000 membership agreements supporting communities

Many of these communities also seek financial support from companies involved in the projects and raise funding to support their efforts. The Linux Foundation has supported projects with a process, templates, and agreements that make it easy for companies to support the project communities they rely on.

In addition to hosting the communities themselves, the Linux Foundation is also host to many open source in-person events, which feature some of the most highly recognizable open source brands, such as KubeCon, KVM Forum, Cloud Foundry Summit, OpenJS World, and the Open Source Summit.

Why projects choose the Linux Foundation

Ultimately, the objective of open source software projects is to produce the best open source software. That sounds fairly obvious and straightforward, but the reality is that managing even a small open source project has a considerable amount of overhead attached to it. The lead maintainers generally have to deal with the burden, and as a community grows, the challenges get more complicated.

It’s easy to set up a new open source project with all the free tooling available today at sites such as GitHub and GitLab. However, beyond having a fundamental repository, if a project community wants to do something more such as building neutral ownership and taking donations from companies, that overhead goes up exponentially. Now the maintainers need to deal with issues they never anticipated:

  • Setting up a legal entity, which can take months of work and legal costs, then the ongoing maintenance of the entity and its associated state or federal filings
  • Setting up a bank account, checks, accounting systems, and payroll systems, as well as benefits administration and hiring staff
  • Getting legal agreements signed by the sponsoring companies
  • Filling out paperwork and forms to be set up as a supplier with a sponsoring company
  • Dealing with invoices, purchase orders, and procurement departments
  • Setting up a financial reporting process, so stakeholders have visibility into where the funds went

Once a project graduates from simple hosting infrastructure, continual paperwork needs to be processed for establishing legal tax status, logos, trademarks, license agreements, as well as addressing other financial, legal, and different administrative needs. The complexity grows, and the project maintainers prefer to focus on what they do best — writing code and shipping the next release. Most maintainers have no desire to become experts at setting up a nonprofit entity, managing accounting, and dealing with procurement departments.

This is where an organization like the Linux Foundation can offer significant assistance and support the developer community using a low overhead model. The Linux Foundation is chosen by major open source initiatives to serve as a home for their projects because of the level of effort, as well as the startup costs for setting up many of these core assets, can be substantial. Additionally, very few reputable organizations with a global presence exist that can provide the level of neutrality required to host these assets in a trustworthy manner that would otherwise be free of influence from an interested corporate entity.

The portfolio of support programs that the Linux Foundation has developed to help its project communities

Figure 2: The portfolio of support programs that the Linux Foundation has developed to help its project communities.

The Linux Foundation can attribute some of the interest from communities to the comprehensive support programs it provides, which include:

  • Providing funding support through membership models or securing one-off contributions through crowdfunding, leaving the complexities of managing the legal entity, financial oversight, and regulatory filings to professionals that are highly experienced and dedicated to their administration.
  • Providing base policies that offer a known framework for organizations to collaborate, including an antitrust policy, trademark policy, templates for a code of conduct, and more.
  • Providing entity management for maintaining the core administrative support infrastructure that enables communities to interact, including hiring leadership and community support personnel, in order to facilitate and guide projects on an ongoing basis.
  • Supporting community events for face to face opportunities, as well as marketing and communications support to grow a project’s community audience and help people learn about the great things they contribute to
  • Eliminating the burden of managing software releases through hiring neutral release engineers that support the maintainers
  • Providing a platform in the form of CommunityBridge to address common challenges with fundraising, mentoring, security vulnerability scanning, and managing CLAs.
  • Providing training and professional certification support that enables building an ecosystem of skilled professionals in order to use, implement, and manage solutions based on a project’s technology.
  • Providing support for license compliance, export control, and security by the routine scanning of project repositories in order to help the community identify license and security problems before an official release proliferates issues to downstream users.

The Linux Foundation model for open communities

The Foundation’s work with open source communities focuses on building a trusted “foundation as a service” model for open collaboration based on five key principles:

  • Organizational Neutrality: No single company or organization can ever “take away” assets from the community that forms around a project. As a neutral owner, the core assets, such as the internet domains, online service accounts, and trademarks, can never be held hostage by an interested commercial entity. The Linux Foundation “owns” the assets, but empowers the community to make decisions about how they want to use them through its governance model.
  • Clear Separation of Funding and Participation: Additionally, any organization’s developer participation in an open source project hosted by the Linux Foundation is entirely independent of their financial support. While an organization may support a community financially, they cannot steer technical direction without contributing to the codebase like everyone else. For example, financial support does not grant any member the ability to name a committer, contribute a project feature, or set project priorities. All of that work is done through an open governance model.
  • Open Governance: Successful open collaboration projects have neutral, well-defined governance models where those who do the work make the decisions. The Linux Foundation strives to provide “do-ocracies” where responsibilities attach to people who do the work rather than elected or selected by some identified decision-maker. Our projects operate transparently, and the community develops its own operational guidelines that serve to create a working technical community.
  • Intellectual Property Clarity: The removal of uncertainty over the licensing of intellectual property makes it easy for developers to contribute and end-users to implement projects supported by the Linux Foundation. The Linux Foundation engages with the key stakeholders to understand and document the intellectual property terms that will form the basis for the collaboration. Contributors retain individual ownership of contributed code under an open source license and/or the terms of a project Contributor License Agreement (CLA).
  • Commercial Support Ecosystem: Developers like to see the projects they’re working on show up in products and solutions — it’s great to have users. The Linux Foundation encourages commercial involvement in our projects, which leads to additional benefits for the community. There are opportunities to get new contributions from developers working at companies, expanding the use cases and features, and helping guide user requirements. Often our communities will see enhanced employment opportunities for project contributors. This commercial support ecosystem can also provide support for the project, helping cover the cost of running an event, paying for development infrastructure, or providing people to help with documentation or other needs.

Conclusion

The Linux Foundation permits its projects to concentrate on the daily business of software development, while also allowing the administrative overhead to be managed by seasoned professionals that can provide the necessary legal and financial oversight at scale.

The growth of the Linux Foundation over the past two decades, and most recently, the last seven years, can be attributed to the diversity of value-added support programs that make it unique among organizations enabling technical collaboration. Whether a collaboration covers software, hardware designs, standards, or open data, the Linux Foundation has developed templates, models, and best practices to support an open community model.

The Linux Foundation’s adherence to core principles of neutrality, transparent governance, intellectual property clarity, and its fostering of a vibrant commercial support ecosystem has enabled it to work with some of the most innovative communities developing technology the entire world depends on every day. That’s an amazing opportunity and responsibility — we hope you will consider working with us on your next open community project.

Today we are announcing the open source beta-release of EasyCLA, one of several services that are part of LFX.

EasyCLA helps maintainers of open source projects to streamline their workflows and reduce the hassles of managing Contributor License Agreements (CLAs) and authorizing contributors.

By automating many of the manual processes, this software-as-a-service hosted by the Linux Foundation reduces delays for developers to get authorized under a CLA.

Companies involved in open source projects benefit from having direct control over and visibility into which of their developers can contribute under their signed Corporate CLA.

The Linux Foundation already manages over 10,000 signed CLAs.  This experience has enabled us to build EasyCLA so it can scale with the largest open source projects, freeing up thousands of hours of time for developers, maintainers, and companies contributing to open source.

What is a CLA?

CLA stands for Contributor License Agreement, essentially a contract between the open source project entity and either an individual developer or the company contributing code.

CLAs are often categorized as either Individual CLAs and Corporate CLAs.

By signing an Individual CLA, an individual developer agrees that they have the right to contribute code and are doing so in accordance to the terms in the CLA.  When an individual signs their Individual CLA, they bind their contributions to the project under the terms of the CLA.

The complexity multiplies, however, when the project requires a Corporate CLA.

Corporate CLAs are often desired to provide direct corporate authority for employees of a company to make contributions with explicit authority for the grants (e.g. a patent grant) in an open source license.

There are other potential uses of Corporate CLAs, but it’s a project’s decision whether to use a CLA or not. In some projects, a CLA may address concerns amongst the contributor and user communities that makes it easier for them to participate in the community.  Other projects may not have the same level of concern and the CLA may, in fact, become a barrier to participation and “drive by” contributions

If the project decides to use a CLA and a contributing developer works for a company, a Corporate CLA needs to be signed by an authorized signatory of the company who employs them. By signing the Corporate CLA and then indicating which developers are authorized to contribute code under that CLA, the company removes ambiguity about who the company has authorized to contribute under the terms of the CLA and license for the project.

The Linux Foundation often recommends a “license-in” == “license-out” model where contributions are made under a project license with a Developer Certificate of Origin DCO “Signed-off-by” statement on each commit.  This means that the developer self-certifies their right to contribute to a project. Projects can easily enforce the DCO “Signed-off-by” requirement in code review tools such as Gerrit, GitHub1 and GitLab for example.

Some projects have considerations that lead to requiring a CLA in addition to using the DCO.

The agreement could include, for example, a statement of the license terms for the contribution to that project; a confirmation that the developer’s employer has authorized the contribution under those terms; or statements confirming that the contributor actually wrote the contribution. Some project communities believe these explicit statements provide greater certainty about rights contributors grant to the project.

In this case, the project maintainers carry the burden of managing the CLAs and the lists of authorized contributors. The burden increases as the number of contributors grows.

Automating the CLA process with EasyCLA alleviates this administrative load on the maintainers.

What Challenges does EasyCLA solve?

For projects that use CLA, one of the biggest problems is that the whole process adds friction to the project maintainer.

The common CLA processes of filing paperwork, following up with an internal signatory, and ensuring commits are made by authorized developers is a huge administrative headache.

Some of those specific pains include:

  • Tracking CLA paperwork, which is often spread across multiple emails or spreadsheets, is time-consuming and brittle
  • Ensuring that the list of company developers authorized to contribute to open source projects is up-to-date requires manual, fragile, time-consuming effort.
  • Collecting developers’ signatures and then waiting for maintainers to manually process CLAs can delay contributions
  • Projects and their maintainers want to ensure that every contribution was made under a CLA

What does EasyCLA do?

EasyCLA removes many of these manual processes by doing the following:

  • Automates the CLA signature and authorization workflows
  • Notifies contributors if they need to sign the CLA, or get authorized under their employer’s CLA from within GitHub or Gerrit
  • Blocks unauthorized contributors until they are authorized under a signed CLA
  • Supports reusing CLAs across projects
  • Enables each company signing a CLA to manage their own list of authorized contributors under their CLA
  • Includes modified template CLAs based on the Apache Software Foundation’s CLAs, as an option for the project’s CLAs

How EasyCLA Works

EasyCLA begins with the Project Manager, who is the project maintainer responsible for selecting the appropriate Individual and Corporate CLA.

Traditionally, the Project Manager has had to enforce whether a contributor was authorized to commit code to their project.  This would become especially cumbersome when getting signatures for Corporate CLAs from companies and updating each company’s whitelist of authorized developers.

With EasyCLA, the Project Manager can apply their CLA to their project and EasyCLA automates and streamlines the rest of the authorization process.

For an Individual developer, the process is straightforward: if they haven’t signed the project’s CLA, their commit will be blocked and they will be given a link that takes them to the CLA.  After providing their e-signature agreeing to the CLA, all their future commits to that project will be allowed.

For a Corporate developer, the process is more complicated. We’ve defined three primary roles for this automated CLA workflow:

  • Contributor: any developer wanting to contribute code to the project
  • CLA Manager: person authorized to manage who can contribute under the company’s Corporate CLA
  • CLA Signatory: the authorized signatory of the project’s CLA for the company

Who can use EasyCLA?

Any project hosted by the Linux Foundation and using either GitHub or Gerrit can use EasyCLA.

Contributors, Project Maintainers, and Companies can all benefit:

  • Contributors submit code with minimal hassle from CLA paperwork.
  • Project Maintainers stop worrying whether accepted pull requests fall under signed CLAs and managing the signed paperwork.
  • Companies get greater comfort from a workflow that enables proper signing authority for Corporate CLAs.

If your project is not a Linux Foundation project, you can sign up here to indicate interest in using EasyCLA for your project.  We are exploring support for non-LF projects on a case-by-case basis.

How to Get Started

For Project Maintainers

If you’re a maintainer of a project already using EasyCLA, you can login with your LF ID here to manage your CLAs.

For Company

If you are the CLA Manager for a company with developers contributing to Linux Foundation projects that are using EasyCLA, sign in with or create your LF ID here.

From there, you can send the agreement to the appropriate signatory.  After the CLA has been signed, you can then can begin whitelisting developers.

Contribute Code to EasyCLA

The code running EasyCLA is open sourced.

While the code is open, there are still several dependencies in the code that would make it difficult right now to run the code on your own infrastructure.

However, if you feel there are features you want to add that will make EasyCLA work better for your, your project, or your company, then please go ahead and create an issue or submit a pull request!

1. https://github.com/apps/dco

The open source project will establish and maintain a common legal and technical foundation for smart legal contracts

London, Accord Project Forum, June 6, 2019 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced the launch of the Accord Project as a Linux Foundation project. The Accord Project is a nonprofit organization that builds open source code and documentation to maintain a common and consistent legal and technical foundation for contract management. The project comprises all the software necessary to author, edit and execute smart legal contracts in a standardized way. Many of the world’s largest global law firms have signed on, as well as leading industry bodies and technology companies such as DocuSign, IBM, IEEE and R3.

Smart contracts are showing promise for simplifying complexities in supply chain management and other contract-heavy areas of technology development, but they also introduce requirements for interoperability and consistency. The Accord Project provides a globally interoperable approach for creating contracts that bind legally enforceable natural language text to executable business logic. With an increased focus on enterprise digitalization, adoption of blockchain technologies and the growth of the API economy, the usage of computable agreements is rapidly increasing. Having a common format for “computable” legal agreements is an important cornerstone for the future of commercial relationships. One of the main purposes of Accord Project is to provide a vendor-neutral “.doc” format for smart legal agreements.

“The Linux Foundation is home to communities that are advancing the world’s most critical software infrastructure,” said Mike Dolan, VP of strategic programs at The Linux Foundation. “The Accord Project represents an opportunity to collaboratively build the framework necessary for the next generation of contracting. Their work is essential in supporting the software that runs our lives.”

Contract templates are composed of three elements: the Template Grammar (the natural language text for the template), the Template Model (the data model that backs the template), and the Logic (the executable business logic for the template). When combined these three elements allow templates to be edited, analyzed, queried and executed. Importantly, the Accord Project’s approach does not lock smart legal contracts into any particular execution environment or vendor applications. Smart legal contract templates can be used with a wide variety of technologies, including different types of distributed ledgers.

The templates are designed to be quick to create from existing legal contracts and easy to execute using the Ergo domain specific language. Ergo aims to help legal tech developers quickly and safely write computable legal contracts. Ergo’s other goals are modularity (reuse of existing contract or clause logic), ensuring safe execution, neutrality with respect to blockchain implementation if one is chosen, and being formally specified so the meaning of contracts is well defined and can be verified and preserved during execution.

Dan Selman, co-director of the Accord Project and Chair of its Technology Working Group, noted that “Our goals for the Accord Project are to promote the use of open legal technology, attract a self-sustaining base of contributors, supported by a rigorous governance structure. Linux Foundation has been an excellent steward to scores of open source projects, large and small, over many years. We believe Linux Foundation is the perfect home for Accord Project and look forward to learning from the collective wisdom of the Linux Foundation community and taking advantage of the various services and programs they offer.”

Developers, attorneys, business and finance professionals and other contract users can access the Accord Project online at accordproject.org and the code at www.github.com/accordproject. For technical documentation please visit: https://docs.accordproject.org/

About The Linux Foundation
Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

In the last few years we have witnessed the unprecedented growth of open source in all industriesfrom the increased adoption of open source software in products and services, to the extensive growth in open source contributions and the releasing of proprietary technologies under an open source license. It has been an incredible experience to be a part of.

As many have stated, Open Source is the New Normal, Open Source is Eating the World, Open Source is Eating Software, etc. all of which are true statements. To that extent, I’d like to add one more maxim: Open Source is Eating the Startup Ecosystem. It is almost impossible to find a technology startup today that does not rely in one shape or form on open source software to boot up its operation and develop its product offering. As a result, we are operating in a space where open source due diligence is now a mandatory exercise in every M&A transaction. These exercises evaluate the open source practices of an organization and scope out all open source software used in product(s)/service(s) and how it interacts with proprietary components—all of which is necessary to assess the value creation of the company in relation to open source software.

Being intimately involved in this space has allowed me observe, learn, and apply many open source best practices. I decided to chronicle these learnings in an ebook as contribution to the OpenChain project: Assessment of Open Source Practices as part of Due Diligence in Merger and Acquisition Transactions. This ebook addresses the basic question of: How does one evaluate open source practices in a given organization that is an acquisition target? We address this question by offering a path to evaluate these practices along with appropriate checklists for reference. Essentially, it explains how the aquirerer and the target company can prepare for this due diligence, offers an explanation of the audit process, and provides general recommended practices for ensuring open source compliance.

If is important to note that not every organization will see a need to implement every practice we recommend. Some organizations will find alternative practices or implementation approaches to achieve the same results. Appropriately, an organization will adapt its open source approach based upon the nature and amount of the open source it uses, the licenses that apply to open source it uses, the kinds of products it distributes or services it offers, and the design of the products or services themselves

If you are involved in assessing the open source and compliance practices of organizations, or involved in an M&A transaction focusing on open source due diligence, or simply want to have a deeper level of understanding of defining, implementing, and improving open source compliance programs within your organizationsthis ebook is a must read. Download the Brief.

Global technology leader supports standardization in open source compliance to improve predictability and efficiency across supply chains

SAN FRANCISCO –  February 6, 2019 — The OpenChain Project, which builds trust in open source by making open source license compliance simpler and more consistent, announced today that Microsoft Corp. has joined as a platinum member. This comes on the heels of several other large companies joining OpenChain last month including Uber, Google and Facebook. The only standard for open source compliance in the supply chain, OpenChain provides a specification as well as overarching processes, policies and training that companies need to be successful in managing open source license compliance so that it becomes more efficient, understandable and predictable for participants of the software supply chain.

Companies consume billions of lines of open source software through their supply chains as they build new products and services. One key challenge as code flows between companies is ensuring the relevant license requirements are met in a timely and effective manner. The OpenChain Project provides companies with a consistent way to address these challenges. It’s hard to overstate the importance of this work given open source is a critical input at every step in the supply chain, both in hardware and software.

By joining OpenChain, Microsoft will help create best practices and define standards for open source software compliance, so that its customers have even greater choice and opportunity to bridge Microsoft and other technologies together in heterogeneous environments. Conformance with the OpenChain Specification shows that an organization follows the key requirements of a quality open source compliance program, and builds trust between organizations in the supply chain. It makes procurement easier for purchasers and preferred status easier for suppliers.

“Trust is key to open source, and compliance with open source licenses is an important part of building that trust,” said David Rudin, Assistant General Counsel, Microsoft. “By joining the OpenChain Project, we look forward to working alongside the community to define compliance standards that help build confidence in the open source ecosystem and supply chain.”

“We’re thrilled that Microsoft has joined the project and welcome their expertise,” said Shane Coughlan, OpenChain General Manager. “Microsoft is a strong addition not only in terms of open source but also in standardization. Their membership provides great balance to our community of enterprise, cloud, automotive and silicon companies, allowing us to ensure the standard is suitable for any size company across any industry.”

As a platinum member, a representative from Microsoft will join the OpenChain Governing Board. Other platinum members of the OpenChain project include Adobe, ARM Holdings, Cisco, Comcast, Facebook, GitHub, Google, Harman International, Hitachi, Qualcomm, Siemens, Sony, Toshiba, Toyota, Uber and Western Digital.

Additional Resources

About the OpenChain Project

The OpenChain Project builds trust in open source by making open source license compliance simpler and more consistent. The OpenChain Specification defines a core set of requirements every quality compliance program must satisfy. The OpenChain Curriculum provides the educational foundation for open source processes and solutions, whilst meeting a key requirement of the OpenChain Specification. OpenChain Conformance allows organizations to display their adherence to these requirements. The result is that open source license compliance becomes more predictable, understandable and efficient for participants of the software supply chain.

About The Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and commercial adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

SAP has established an open source program office to further its open source activities and expand its engagement with the open source communities.

SAP has been working with open source for decades and has now established an open source program office (OSPO) to further formalize the coordination of its open source activities and expand its engagement with the open source communities. “SAP was one of the first industry players to formally define processes for open source consumption and contribution,” says Peter Giese, director of the Open Source Program Office.

Even so, many people do not yet consider SAP to be a company that embraces open source engagement and contributions.

“In the past, we may not have been active enough in sharing our open source activities,” says Giese.

Now, SAP is shining a spotlight on its work in open source. Transparency is an essential part of the new open source mandate, beginning with an explanation of what the company has been up to and where it is headed with open source.

How SAP came to adopt open source

“In 1998, SAP started to port the R/3 system, our market-leading ERP system, to Linux,” says Giese. “That was an important milestone for establishing Linux in the enterprise software market.”

Porting a system to Linux was just a first step, and a successful one. The action spurred an internal discussion and exploration of how and where to adopt Linux going forward.

“We came to the conclusion that Linux would become a major force,” Giese says. “Today that’s obvious, but at the time it was not as obvious to everybody. That’s when we started our endeavors into open source.”

In 2001, SAP formally defined and internally documented its process for open source consumption, and the company committed to using inbound open source projects to build SAP products. There were lots of details to attend to, such as open source licensing, security, and export control restrictions.

By 2004, SAP already had information on the specifications exchange with other companies and was one of the founding members of the Eclipse Foundation. From then onwards, SAP developers actively contributed to several Eclipse projects, including JGit, EGit, Mat, Tycho and Che.

However, it wasn’t until 2008 that SAP started to actively promote open source contributions from SAP employees on a company-wide basis. That was also the year when the company rolled out its outbound open source process. “We had a set of guidelines and rules for what SAP teams had to do in order to share their work with the open source community,” explains Giese.

In 2010, SAP integrated open source tools further into its development processes. “We moved to a higher level of compliance by introducing systematic open source code scanning as part of our standard development processes,” says Giese. “That means we started to systematically scan open source code for license compliance and security issues.”

In 2014, SAP shared with the open source community a tool called CLA assistant which was developed for managing open source contributor license agreements.

Even though these activities and projects were very successful, there was a growing need for more central coordination of SAP’s open source activities.

“We had several teams that took care of specific aspects of open source, such as security scanning, license scanning, and building our own open source tooling. But there was no dedicated function or role with the overall responsibility for everything open source at SAP,” says Giese. “That has changed now, and SAP’s chief technology officer is responsible for open source at SAP.”

SAP and open source today

The new central Open Source Program Office was established in early 2018.

“We wanted to be more active and visible in our interactions with our outside customers and partners, and with open source foundations and other open source communities,” says Giese. “That’s why we also joined the TODO Group last year to share experiences, jointly develop best practices, and work on common tooling.”

Giese points out that the company’s investments and contributions to open source are substantial, yet they still come as a surprise to many people.

“For example, in February 2018, Fil Maj from Adobe published a worldwide ranking of companies, with their total number of their employees actively contributing to open source projects on GitHub, and SAP ranked at number seven”, says Giese. “There are, of course, different ways to create such statistics, but it gives you an idea of SAP’s role as a contributor. Maybe we’re one of open source’s best kept secrets.”

SAP prefers not to be a secret any longer and is stepping up its open source game in more visible ways. “We’re going to participate in more of the open source community conferences, such as Open Source Summit, OSCON, FOSDEM, EclipseCon, KubeCon, and so on” says Giese. SAP’s climb to higher visibility is a sign of its continued commitment to excellence in open source, and the company aims to form more partnerships and spur accelerated innovations.

One recent example of SAP’s innovative open source projects is Gardener, a solution for Kubernetes clusters as a service, as listed in the CNCF Cloud Native Landscape. It enables the management of a large number of Kubernetes clusters and the reuse of Kubernetes primitives in its core architecture.

Another newly open-sourced SAP project is Kyma, a flexible and easy way to connect and extend enterprise applications in a cloud native world.

SAP is actively encouraging companies and other developers to codevelop and cooperate on projects such as Gardener and Kyma.

“This type of co-innovation, for me, is the most compelling aspect about the whole open source movement,” says Giese.

Learn more about prominent SAP projects on their open source page.

How SAP’s open source office works

SAP formed its Open Source Program Office as a virtual team consisting of several teams from different board areas.

“We are working in scrum mode, which is a software development methodology. It has advantages in driving an open source program office,” says Michael Picht, chief development architect in OSPO. “You work in sprints in scrum, and this means you’re forced to break down your tasks into smaller pieces.”

“The scrum methodology propagates cross-functional teams, and that’s what our OSPO is. We have colleagues from across the company in there. Scrum facilitates the work in such a setup. It sounds strange to some people when they hear we work in scrum mode, but in our case, it is working quite well.”

Picht says that “breaking large jobs down into smaller chunks and working in four-week sprints makes challenging and long-running tasks easier to master. It does require some training, however, to make sure all team members are comfortable with the method.”

The office’s mission is to nurture and support the open source approach to software development – inside and outside SAP. Consequently, for employees who want to contribute to open source projects in their spare time outside of the company context, SAP has simplified the clearance process dramatically. “We have provided a few simple rules and as long as you adhere to these you can directly start to work on open source projects in your spare time,” says Giese.

The company is also redesigning its corporate open source contribution process to make it even more efficient. The goal is to shift from policing developers to enabling them through simpler forms, automation of process steps, and support team services.

For the open source community, to advance open source best practices and tooling, SAP recently contributed it’s open source vulnerability assessment tool, which supports any software development organization in assessing security vulnerabilities of open-source components in their application development.

SAP’s open source program office will continue to look for ways to speed up and improve processes, and to support developers, partners, and open source communities.

“This will never end, this will always go on, so we always want to find new ways to improve open source processes and tools further,” says Picht.

Acknowledgements

We would like to thank Peter Giese, director of SAP’s Open Source Program Office and Michael Picht, chief development architect, for their time in contributions to this case study. We would also like to thank Pam Baker for taking the time to conduct interviews at the Open Source Program Office.

SAP is an active member of the Linux Foundation and LF projects including Cloud Foundry Foundation, Cloud Native Computing Foundation (CNCF), Hyperledger, ODPi, OpenAPI Initiative, and TODO Group.