The list of OSPO maturity models and operation guidelines is used to help implement OSPO or open source plans in an enterprise environment. People can read and download the complete white paper here.
By mapping the dialogue with OPSO leaders and experts to the survey results of OSPO, we developed an OSPO maturity model to describe the typical evolution of OSPO. The model is generic: the size and type of the organization affects the way OSPO matures. In larger organizations, multiple business units may develop different open source methods, each of which has a different technical culture; Pure digital technology companies are more likely to consume and contribute OSS at an early stage, and have more opportunities to access open source technologies and concepts.
Take VMware, an enterprise infrastructure software provider. Their engineers have cooperated with and contributed to many open source communities in network, cloud computing and other key fields for the simple reason that they know that using open source builds will bring better results and stronger interoperability - for communities and VMware customers.
In contrast, Red Hat, the first open source company to be listed. It bases its entire business practice on open source software and compresses its maturity life cycle. In fact, this makes its entire company a bit like an open source software development organization. Today, Red Hat is devoting more resources to early life cycle activities, such as educating internal stakeholders (such as sales teams, marketing personnel, newly hired engineering personnel), and promoting cooperation between upstream communities.
For most other companies in our study, the general phase of the maturity model closely lays out the trajectory of OSS organizations in terms of consumption, contribution, collaboration and participation, and leadership. Some organizations we interviewed have now included open source participation and use in specific indicators.
These indicators include the project participation rate (pull requests comment、commit)、 Attend and participate in open source activities, write blog articles, make speeches, and participate in open source projects. Higher level open source organizations may have metrics for the successful growth of projects initiated by their own engineering teams or partially created by their own engineering teams. Some leading organizations, such as Comcast, VMware, and Red Hat, are already building advanced metrics and measurement tools.
That is, even some complex organizations that track indicators will not explicitly use indicators to track or set OSS goals.
Take Microsoft for example. This organization used to focus almost exclusively on private software, but now it has become a major supporter of open source projects and a wide range of users of its own products. "We focus on making it easier for our developers to work with OSS and encourage them to contribute to the projects they rely on. We track everyone's participation, but the Open Source Project Office does set goals at the individual or team level," said Stormy Peters, former head of Microsoft's Open Source Project Office. "Our developers can voluntarily associate their company ID with their GitHub login, which allows us to measure the degree of participation at the company level. In most cases, the system collects and analyzes indicators in the late stage of adoption, when OSS becomes a key element of the technology roadmap and strategy of enterprises and larger organizations. At the same time, OSPO plans, budgets and personnel are also growing.
Phase 0 adopts open source Ad Hoc
Today, almost all organizations use open source software. They used it in different ways at first. They use open source software as a building block or library of products or tools, or a key part of a supplier's product stack, or to support the supplier's provision of supporting services. Developers can use open source software for rapid prototyping technology or microservices and small applications. Developers also often use open source software development tools, such as integrated development environments (IDEs), or tools built based on open source code such as GitHub and GitLab. Modern cloud native applications almost default to open source systems for container orchestration, observability, data storage, messaging, etc. At the front end of the application, developers rely heavily on open source libraries and frameworks.
Red Hat reports that "90% of IT leaders are using enterprise open source software." Software portfolio analysis vendors like Synopsys determine that more than 75% of the code base contains open source components. In other words, almost every organization is using open source. However, the earliest form of adoption is Ad Hoc, where developers use off the shelf tools and technologies to solve problems. This "ad hoc ad option" usually means that license compliance beyond the default value will be less considered, or the long-term impact of consuming open source and distributing products built with open source components. In most cases, only a few developers are actively seeking open source, while other development organizations may happen to use open source, but do not believe that their activities depend on open source. As a result, these organizations neither focus on open source teams nor have corresponding top-level open source strategies. These are very important, because once adopted, these open source components will become part of the organization's software supply chain by default, which makes the strategic approach more important.
Stage 1: Make full preparations for OSS compliance, directory list and developer training
Generally speaking, when an organization realizes that almost everyone in the project department and development department is using open source products and code, it will form an OSPO. This usage is usually internal, rather than a part of the product or service for customers or users. In fact, any online or application centric organization with considerable IT functions and advanced applications will use open source. Open source technology stacks are everywhere from Linux servers, MySQL database programming languages like NodeJS and Python, and front-end frameworks like React and Vue.js.
At an early stage, the organization used many different names for OSPO. For example, IBM initially called its programmatic open source work "Open Source Steering Committee". In all cases, however, the organizations in Phase 1 recognize that open source software is a key part of their business and technology strategy. They understand that the security practices of open source software projects are different from those of private software companies. For example, disclosure rules for open source software projects are often more stringent than proprietary projects. Therefore, they must determine their compliance and security risks. Strategies to reduce risks include paying attention to license risks, training developers, and identifying accurate OSS lists.
Manage legal risk and licensing
Before the legal team or technical leader of the organization tends to start the first phase of development, OSPO needs to ensure that its employees (as well as contractors, suppliers, etc.) use open source software according to its license terms, and that the organization will not be placed in legal risk after using OSS. They have dozens of open source licenses in use. In the 2020 survey, respondents ranked compliance as the biggest benefit of OSPO for large enterprises and the second largest benefit for medium-sized enterprises. "Enterprises usually have a lot of confusion at the beginning. At present, there is no corresponding licensing strategy, and developers can only do what they think is right," said Dirk Riehle, an open source software professor at Friedrich Alexandria University. He added:
I once walked into a company and a developer said, "We don't have an open source strategy.". Another joked: "We have, and it is: no open source". In response, the third person frowned and said, "What are you talking about? We have contributed to open source projects for some time." It is not uncommon. They will eventually set up an open source project office to deal with the use and contribution of open source.
Although open-source software users have been considering legal compliance, some open-source software contributors have designed new licenses to prevent large cloud providers from creating proprietary services based on open source projects. The most prominent one is the Affero General Public License (AGPL). Enterprises may use open source software to provide proprietary software as a service (SaaS) to their customers and comply with the terms of the license agreement, which further blurs the boundaries between commercial services and internal services.
Developer training
To maintain compliance, organizations in OSPO Maturity Stage 1 have created educational programs to help their developers determine when to use open source software when creating new products or services. "Many developers who have not received open source education believe that they are not involved in licenses because they have not purchased software or signed contracts," said Suzanne Ambiel, director of open source marketing and strategy at VMware. "Open source software may be free and free of charge; however, it may also be expensive if used in an illegal way. Open source software is always accompanied by a license. One of the most important roles of any open source software is to ensure that developers understand the meaning of the license of different choices." Through the training of developers, Senior managers recognize the value and importance of open source software. In these projects, developers can learn:
- The nuances of different types of licenses
- The official approval process for launching new open source software products is the real risk of consuming incompatible open source software, including the use of unlicensed code or OSS products in the project
- Use the Contributor License Agreements (CLAs) to protect developers who contribute to open source in the organization
Sometimes, organizations introduce formal CLA strategies at this stage to provide guidance for judging the health of open source software projects, as part of their decision on which open source software standards to use in the organization's technology stack or infrastructure.
Inventory software
Developers may temporarily call open source software without systematically cataloguing their work. Legal teams and technical leaders tend to require a list of all OSS used in an organization. The list itemizes the organization code base (for example, GitHub, GitLab) and OSS in the system. Stage 1 The organization establishes a specific software inventory process to create an organization wide software bill of materials (SBOM).
With this list, the legal team (usually working with the OSPO team) can continuously monitor the use of OSS and mark legal, security or other project risks. Through detailed SBOM, technical leaders (such as CTO or CIO) can identify and closely monitor the most critical business use to protect the security of the organization.
Phase 2 Promote OSS use and participation in the ecosystem
After organizations realized the value of OSS and the necessity of compliance, education and SBOM, they began to realize the economic benefits of using OSS and sought to expand it. The OSPO in Phase 2 has created such internal mechanisms, such as promoting the use of approved OSS products as ambassadors, good OSS knowledge management education plans, technical training or tuition reimbursement for OSS skill building and certification.
With these plans, organizations can increase and expand their use of OSS. OSS is not only important, but also more desirable than proprietary software products. Employee education includes best practices for interacting with OSS projects, such as how to request features, file error reports, and characteristics of contributing basic code.
At this stage, the organization strengthened its collaboration and experienced the social life of OSS projects and communities. In this regard, OSPO conveys to employees and managers the importance of making contributions rather than just using OSS. This promotion includes advocacy and promotion of event sponsorship, reserving project leaders and maintainers as speakers or team members on public coding forums, and trying to obtain organizational resources (such as talents and funds) for mission critical OSS projects.
For organizations, active and visible participation can produce multiple benefits: higher visibility, better reputation, and more attractive employers. In view of this, many non-technical organizations purchase booths at important OSS events to interact more with these communities and recruit developers who like to work in the OSS ecosystem. Technology companies active in the open source field may expand their education programs to customers who want to interact with the OSS community and suppliers. Deborah Bryant, senior director of open source at Red Hat, said: "We have received many requests from customers, and hope that we can help and guide us in how to participate in open source, contribute to open source, and cooperate with us on projects."
With the advance of Phase 2, the organization began to encourage developers to engage in OSS projects that are critical to the organization's operations, so that developers can become highly active contributors or major maintainers. For technical organizations, it is a valuable investment to hire contributors for important OSS projects: most of their contributors, for example, the Linux kernel (the core component of the operating system and the key interface between computer hardware and software) are full-time employees whose job is to write code for Linux.
Outside of the technology field, few organizations can assign full-time employees to open source work, but they are doing so. For example, Comcast and Bloomberg both have employees working full-time on OSS projects. In the lifecycle phase, OSPO began to explore how to simplify the process of developers using OSS. This developer effectiveness includes simplifying the CLA, adding OSS with acceptable license types to the work order system for rapid approval, promoting the reuse of OSS architecture and existing software (a variant of internal procurement), as well as standardized library selection and open source development tools, so as to integrate OSPO and platform operation responsibilities.
At this stage, the organization will seek guidance from OSPO on how to actively participate in open ecosystems. "You need to make sure that you get as much as you give back. You don't want people to think that you are just making money through open source without contributing to the community." Chris Xie, head of OSPO at Futurewei Technology Co., Ltd., said, "We strongly consider this - more strongly than ever." Companies in regulated industries such as telecommunications must also understand their national export laws and manage political tensions to protect the OSS community and avoid international disputes. "We have always wanted to ensure that our contributions are truly open and can benefit the community and the entire industry," Xie explained.
Generally, in the second stage of OSPO's maturity cycle (or in the first stage if it is a software company or a technology focused company), OSPO begins to make contributions to its developers to simplify and optimize open source. In the early days, the process of requesting and obtaining approval for external participation was often temporary and painful. "When we established OSPO, one of the first things we focused on was the process of contribution," said Michael Picht, chief architect of SAP OSPO. "With Word, Excel and e-mail, this process was not automated at all. When we open OSPO, the first thing we do is to simplify the process and implement end-to-end tool support. We use GitHub to solve different process steps. "
Stage 3 Growing OSS project hosting community
In Phase 3, the organization initiates and hosts or acts as the main initiator of OSS projects. They will designate one or more FTEs for a project and assume the responsibility of cultivating the project community and ensuring its health. They will not confuse this level of organizational commitment with the employees who decide on open source projects. In phase 3, organization leaders support incubating and launching open source projects in the public domain because they understand how these projects benefit their organization. Such projects often provide better performance and economy in key functions, which may not be core to the value proposition of the organization, but are critical to its technical infrastructure.
In addition, organizations that create and launch open source projects have established a wide reputation in the open source community, and the possibility of developing open source technologies has attracted many developers. Most OSPO we interviewed regard recruiting new talents and retaining existing talents as the key driving force for open source work.
In a recent study on the financial services industry by the Linux Foundation, 53% of the contributors said that they contributed to OSS because "it's interesting". Supporting projects with FTE and funds is the true face of the open source competition. The internal resources and processes developed by organizations that cross this threshold and successfully launch multiple open source projects can incubate and ensure the success of these projects after launch. OSPO is not just a gatekeeper and mentor for project formation and launch; They educate project creators on the requirements of cultivating a healthy open source ecosystem, and guide project leaders to prepare them for a more open leadership role required by OSS projects.
As the OSS organization matures, its OSPO develops internal processes, tactical manuals, checklists, tools and other mechanisms to review, organize and operate open source projects, and prepare and guide its leaders. Some OSPOs prefer to launch projects with the assistance of major open source foundations or cooperative organizations (such as TODO Group) to enhance performance or provide infrastructure, tactical assistance and other resources. This preference is less resource intensive, but will give control of the project to the wider community.
Stage 4 Become a strategic decision-making partner
In this mature stage, OSPO becomes a strategic partner in technology decision-making, helping guide the selection and formation of long-term investment projects. In phase 4, the CTO and other technical leaders consult OSPO and its leadership to determine which open source technologies to rely on and which decision criteria to use to judge open source projects. Since the selection of major open source technologies often generates a large number of secondary and tertiary costs, and affects upstream and downstream technologies and recruitment plans, the selection of open source technologies has become a major business decision.
Broadly speaking, OSPO provides three types of strategic guidance in Phase 4. First, OSPO recommends that CTOs and technical leaders adopt or remove open source technologies from the organization's technology stack. Given that there are many OSS options today - most major software categories have dozens of options. As shown in the figure below, OSPO can gain insight into OSS trends, such as popularity of different languages, API design, or functions of different NoSQL databases. In this role, OSPO becomes the CTO's internal technical advisor and internal OSS expert.
In the second type of strategic guidance, OSPO takes the lead in benchmarking the content that constitutes an acceptable OSS project. OSPO often assesses the behavior and performance of the project, especially changes in the types of permits that restrict use, or sudden changes in the project roadmap, to determine whether the project manager takes into account the best interests of the community. Most OSPOs rely on rough indicators to assess project behavior, such as:
- What type of license does it have?
- What is its code of conduct and what are the consequences of violating it?
- What is its governance structure and does it ensure independence?
- How long does it take to respond to a pull request or vulnerability archive?
- How often does the project release new versions?
- Is the project controlled by one party (company or organization) or the whole community?
- How many contributors does the project have? How does this number change over time?
The third kind of guidance is to help organizations understand and control project politics. For example, when multiple influential participants try to guide a project to maintain a neutral position, or clarify the potential political considerations of community members. At a higher level, OSPO can help companies maintain a neutral stance on technological nationalism and bridge political differences by cultivating personal and working relationships that transcend national boundaries and political fields.
As these fields become important neutral spaces in open source, this value gradually extends to the work of foundations and non-profit organizations. Deborah Bryant of Red Hat said that her OSPO had to manage the cost of participating in the work of the Open Source Foundation, including sponsoring and sending employees to take leadership roles. "We found that we need to spend more time on some centralized management and administration of the Software Foundation to ensure that our investment returns, and regularly reassess our participation." In this position, OSPO has a foundation budget of millions of dollars. The strategic importance of participating in the formation and growth of the OSS ecosystem is the same as monetary investment in foundations and non-profit organizations. At this stage, we tend to see the rapid growth of OSPO. Ambiel of VMware said:
Today, one of the main goals of OSPO is to help provide best guidance practices and how to become an excellent open source citizen. When you are in the open source community, you are participating in the opening - everyone can see what you are doing. It is important that an organization do its best. Whether speaking at a conference or contributing a small library to a large project community like Kubernetes, OSPO can help people to do this consistently and confidently.
INFOBOX
1. Using the Open Source Project Office: new research reveals the evolution of OSPO: https://linuxfoundation.org/blog/leveraging-the-open-source-program-office-new-research-unpacks-the-evolution-of-the-ospo-and-a-whole-lot-more/
2. Development of Open Source Project Office (OSPO): https://linuxfoundation.org/tools/the-evolution-of-the-open-source-program-office-ospo/
