In recent years, the role of open source software in promoting the digital transformation of enterprises has become more and more obvious. The country has written the construction and improvement of the open source ecosystem into the “14th Five-Year Plan”. At the same time, topics such as open source governance and secure supply chain have become a hot topic in the industry. As open source users or as open source subjects, how should we understand open source, how to understand the community, and how to participate in open source better and more safely. This article will discuss with you the meaning of open source, business models, risks and challenges, choices and governance.
What Open Source Means for Business
Let us first think about the meaning of open source and individuality from the perspective of an individual. We can summarize “selfishness and altruism” in one sentence. Using open source projects or products can help individuals quickly solve problems and challenges at work, and individuals can also gain innovative ideas and experience from open source projects or products. These are all selfish. When an individual is not satisfied with just being an open source user, and begins to participate in the contribution of an open source project, or even set up an open source project himself, it becomes altruistic, and other users will benefit from his contribution or project.
The same goes for businesses. When enterprises focus on their own digital transformation, it means that enterprises will pursue a more open organizational spirit. The core of digital transformation is to use digital technology and capabilities to reengineer enterprise processes, thereby driving business model innovation, enhancing enterprise competitiveness, and even changing an industry, just like “DiDi”. This requires the enterprise’s IT infrastructure and technology to not only support the rapid changes and development of the business, but also drive business innovation. Enterprises must quickly establish business, quickly iterate business, and quickly obtain business feedback. Therefore, having an IT architecture and technology that can flexibly support short-term and long-term business development is the key. Enterprises must adopt open and collaborative new technologies to continuously improve and enhance the iterative capability of technical architecture. These all mean being “fast” enough and “innovative” enough. Open source technology just responds to the needs of enterprises, because open source technology pursues the spirit of openness, collaboration and contribution. Enterprises adopting open source technology can obtain contributions from outstanding talents from all over the world, and can rapidly improve and enhance the competitiveness of enterprises through the contributions of talents from all over the world. The open ecosystem created by open source brings this value to all parties involved.
Take the smart car industry as an example. Traditionally, car manufacturers have relied on a large number of third-party suppliers and technologies. However, when companies enter the new smart car track, car companies need to continuously innovate vehicle functions, improve user experience, and quickly occupy the market. If car companies still adopt the traditional supplier model, they will be constrained by those closed suppliers and will not be able to innovate products and quickly occupy the market. By adopting open source technologies, such as AGL (Automotive Grade Linux), it is possible to eliminate the need to develop the basic operating system of the vehicle, and instead invest valuable R&D technology on more competitive innovations.
Enterprises with an open spirit will not only stop at adopting open source technologies, but will also contribute to open source. Large enterprises can help enterprises realize market strategies, occupy the market or change the game rules of the market by open-sourcing their own products or technologies, such as Google’s Android system. Innovative small enterprises can accumulate huge community users, increase their influence, and expand their own valuations through open source.
It can be seen that the significance of open source to the digital transformation of enterprises is obvious. On the one hand, open source is conducive to stimulating technological innovation of enterprises. Compared with the use of closed source software, open source technology makes users more creative and innovative; on the other hand, the use of open source technology can help enterprises save costs, so that more IT investments are used to deploy new technologies and accelerate digital transformation. This finding is echoed in a survey of global IT leaders on the state of open source in the enterprise 2020, with 95% of respondents saying open source is strategically important to their overall software strategy. In China, some leading Internet companies have also established special corporate open source committees to help companies achieve better open source strategies. The country has written the construction and improvement of the open source ecosystem into the “14th Five-Year Plan”.
Open source is sometimes given the concept of “trusted and controllable”. It is true that open source cannot be directly equated with “trustworthy and controllable”. Only when an enterprise has the ability and resources to thoroughly understand and master it through learning can it be truly trusted and controllable. However, open source, in the form of open source code, allows users to be reassured and solve problems in operation and maintenance by studying open source code when necessary.
F5 operates open source NGINX in China and deeply understands the demands of Chinese users. The reliability and ease of development of NGINX technology ensure that enterprises can have a better and more reliable IT infrastructure, which is of great significance to the digital transformation of enterprises. Whether in distributed or microservice architecture, NGINX technology has been proven by users all over the world, and its reliability ensures the stability of IT infrastructure. In China, we can see that a large number of users use NGINX technology in production, whether it is an Internet company or a financial enterprise, such as the open banking of Agricultural Bank, the business access scheduling of Xinwang Bank, and so on. The ease of development of NGINX makes these technological innovations possible. It can be said that many customers have realized the autonomous control of soft loads with the help of NGINX. Further, by localizing open source NGINX and providing open source subscription services in China, it means that Chinese users can achieve more reliable product use through local services. This service includes basic technical support and advanced expert services. Creation, development, etc.
Open source business model
There are many business models for open source. According to the origin, background, appeal, and subject of the project, it can generally be divided into: advertising mode, which can obtain certain benefits by placing sponsored advertisements on the website, installation process, documents, etc. Games and search projects are generally easy to take this approach.
Selling services is a typical open source business model. The service provider itself does not provide code sales, but services, and users pay for better and more professional technical support services. The sale of services can be the original subject of the open source project or other subjects. Of course, it is generally difficult to support the development of a company by simply selling services. Generally speaking, companies will adopt a mixed business model, such as Redhat.
Software redistribution , enterprises expand and enrich upstream open source projects through their own development, and form commercial products for redistribution and sales. This is a relatively common approach, such as there is a large number of commercial distributions or reintegration of enterprise products around kubernetes.
Direct code sale , the definition of open source allows you to sell source code directly. In the early days of the Internet, revenue was made by collecting, distributing code or binary software and making it on CD-ROM. Relying on direct sales codes is obviously not easy to succeed today.
Dual license/open core , the main body of the open source project has a commercial license version of the software while publishing the source code. Generally speaking, there will be some functional differences between the two. Open source products will have the main core functionality, but some additional functionality needed for production-level enterprise deployments will be sold in commercial versions. Such companies often also sell additional services at the same time. NGINX Open Source and NGINX Plus are a dual license. NGINX Plus is completely based on open source OSS, but has added many enterprise-level features, so that users can better deploy and run in the production environment.
SaaS , deploying open source software as a SaaS service model on the cloud, is also a popular way at present. It is also a model in which open source products are more likely to achieve commercial success in the cloud era. MongoDB’s SaaS service is this model. Of course, some open source controversies have arisen because of cloud services, which will be discussed later in the Risks and Challenges section.
Eco-partnership , commercialization in the form of an eco-partner is a hybrid business approach. Some companies have full-time employees involved in some very well-known and popular open source projects, such as Istio, Kubernetes, etc. Contribute to these upstream projects and enter the technical committees, SIGs, etc. of these upstream projects, forming a high influence in the community and field. The company itself will sell related professional service support, value-added products, etc. This is a more advanced form of business, generally found in large companies or very innovative start-ups. Companies such as Solo and Tetrate. F5 NGINX’s contribution to the community k8s Ingress Controller is also in this pattern.
There are many open source business models, such as donations, crowdfunding, and peripheral brands. Either way, from the user’s perspective, the product must have value in order to be paid for. For companies that rely on open source for commercial services, they must provide valuable products and services with good experience, and return to the origin of the product to achieve open source commercialization more easily. It is difficult to achieve sustainable open source commercialization only by relying on the market.
Open Source Risks and Challenges
Open source has many benefits for businesses or users. However, in the actual use process, there will still be certain risks and challenges. From the risk point of view , there are the following four aspects: License risk , which may be the first consideration in the use of open source. Generally speaking, free software licenses are in copyleft mode. Such licenses are generally stricter and will force downstream users to keep open source. Therefore, be careful whether you will violate the license requirements after modifying the code. For example, the GPL License of HAproxy should be handled carefully. This is a typical copyleft license. When distributing the modified and compiled binary, you must attach the modified source code. Packaged products with delivery capabilities implemented using HAproxy also need a short copyright statement at the delivery prompt. Although some open source software licenses today no longer require users to open source the modified code, it is still necessary to be careful about the license scenarios and restrictive requirements. For example, whether open source code is used in prohibited usage scenarios, Redis’s RSAL restricts usage scenarios such as search engines and stream processing engines. When using open source software to build cloud service capabilities, you must be careful about open source products using the Affero GPL or SSPL protocol. He requires the relevant source code to be disclosed, which is very unfriendly to many companies similar to public clouds, so Google strictly refuses it internally. Use AGPL’s software on the public cloud.
Project continuity risk , due to the uneven main body of open source, some projects are the results of some enterprise KPI-oriented, and some are the results of individuals based on hobbies or work stages (it can be called: open source smoothly). These items may not be durable and have a short life cycle. If an enterprise chooses such a project, it must fully understand such risks, and the enterprise needs to be able to develop and maintain it continuously. Persistent risks may also be manifested in some geopolitical issues. Although the Open Source Initiative (OSI) mentions “non-discrimination against individuals or groups” in its 10 definitions of open source, such concerns may still be encountered under certain circumstances. Sometimes these concerns are based on personal emotions or based on personal perception. For example, some time ago, F5’s statement on stopping the work of F5’s Russian office staff made it emotionally unacceptable to a small number of people, misunderstanding that NGINX originated in Russia, but F5 stopped Russians’ contributions to NGINX. In fact, this is just a decision made by F5 based on the regional war for the safety of F5’s internal staff. The source code of NGINX has been hosted on github and mercurial multiple service systems, and contributions, access, and downloads from Internet users around the world have not been affected.
Project quality risk , open source projects pursue openness, and developers’ experience levels are not completely consistent, which may lead to insufficient code testing, code security risks, and incomplete use cases. Some large and popular open source projects often improve software quality by standardizing developer contributions, setting up special testers, documentation personnel, and security teams. But not all projects have such resources and capabilities. Enterprises should do sufficient research and testing when introducing open source projects.
Open source nesting risks , such risks need to be considered from two perspectives. One is the license. When citing other open source projects in your own project, you should pay attention to the relationship between the reference method and the license, and pay attention to whether there is a compatibility risk between the license of your own project and the license of the referenced project. The second is to pay attention to the loss of quality control caused by serial nesting. When project A cites B, and B cites C and other multi-level references, it is necessary to comprehensively judge all the above-mentioned risks.
From a challenge perspective , its coverage is much broader. Generally speaking, the digital transformation of enterprises involves three aspects: culture, technology and process. Likewise, the challenges of enterprise use of open source can also be considered from these three perspectives. Culturally, the lack of motivation for companies to build an open source culture is a challenge. Enterprises often emphasize the stability of operation. Whether it is a process or KPI assessment, stability is often pursued for IT systems. From the bidding, testing, launching, and operation and maintenance of the project, stability is the first. In such a culture, the technical system and personnel ideas tend to become rigid: the almost static and stable IT system limits the IT system’s support for business innovation, resulting in slow business launch; technical personnel will rely on the technical support of commercial products, resulting in a lack of innovation Spirit. On the other hand, the lack of motivation for open source culture is that enterprises lack the spirit of open source contribution. They only ask for use, do not contribute to the upstream of open source, and are even more afraid to share their innovations with the community.
On the technical side , there are two interrelated challenges: the ability to master open source technology, and the talent to master the technology. Open source products are often not ready to use out of the box. Enterprises need to re-develop according to their own conditions. At the same time, in order to achieve business capabilities, they often need to adopt a variety of open source technologies. This requires enterprises to have more development talents and more innovative talents, who need these talents to analyze and study these open source products, understand and master core technologies. This is often a big challenge for companies that adopt outsourcing models, and such companies lack enough talents to master these technologies. Even for enterprises with a certain development scale, how to transform talents, establish a good talent promotion channel, and retain high-end talents who master key open source technologies and understand open source technologies are actually very big challenges.
In terms of processes , companies need to adapt existing processes to open source, which is often difficult. Using open source technology means that processes oriented towards closed source software need to be transformed and adapted to the changes brought about by open source technology, whether it is business processes, asset management, technical support, governance processes, etc. We have seen that some enterprises still encounter some problems in the process of purchasing open source-related technical support services after using open source.
Open Source Selection and Governance
Open source subjects and open source users think about open source selection and governance in two different categories. Because it’s a question of two directions, even though the roles of the two sometimes intersect.
Open source choice, for open source subjects , the first thing to do is to make a decision on whether or not to open source their projects. The person in charge of the project or company needs to think about it based on the cognitive understanding of open source, combined with the characteristics of the industry, the analysis of competition in the field, and its own actual situation, and comprehensively analyze the impact of open source or not open source. When you decide to open source, you also need to decide whether to open source internally or externally. Intra-enterprise open source is a practice of some leading Internet or technology-leading large enterprises. Generally speaking, the internal open source of an enterprise will go through the spontaneous stage of individuals or groups, and then to the stage of unified open source management and coordination at the global level of the enterprise by setting up an internal open source management department in the enterprise.
When the official decision to open source is made, then it is necessary to turn to thinking about open source governance. For open source entities, open source governance includes two aspects, one is the governance of project engineering, and the other is community governance.
(1) Project engineering governance. In any case, an open source project is ultimately a software engineering, but it is based on a larger scope of collaboration, trust and contribution. Therefore, the management of project engineering quality and code is also applicable to open source projects. It is necessary to consider the scope management, schedule management, quality management, change control, etc. of the project, and ensure the quality, progress, and safety of the code through these managements. We can see that some open source projects will give developer guidance, Code of conduct, etc., which are used to ensure code quality. At the same time, it is also necessary to build a good DevOps automation pipeline to make the contribution process of developers smoother, to ensure that the submitted code undergoes relevant reviews, automated inspections, automated tests, etc., and the results are fed back to contributors in a timely manner. In addition, risk management needs to be done well. We can see that many mature open source projects require developers to sign a Developer Contribution Agreement (CLA) before submitting PR. These are to prevent copyright, non-original and other risks. Risk management also includes license compliance management for other open source components used in the project to avoid introducing risks. Tools like FOSSA are often used for this management.
(2) Project community governance. The biggest feature of open source projects is decentralization and diverse personnel. They come from all over the world, with different backgrounds and cultures. Therefore, the governance of the community is essentially the management of “stakeholders”, and the management of people is the biggest challenge in open source projects. It can be said that the quality of community governance is a very critical factor for the success of the project, so the Apache Foundation particularly emphasizes the concept of “Community over code”. A community should have clear rules and a tone from the start, which ensures that the community always brings together those who share the same understanding. The governance of the community will involve choosing which governance model, such as foundation custody or self-management. Generally speaking, joining the foundation is beneficial to the operation of the project, because these professional open source foundations can help guide the operation of the project, and can also help the project go global quickly, help build the project ecology, and form a relationship between different projects through the power of the foundation. cross support. Of course, the foundation also runs many activities, which can help the project to increase its visibility, attract more developers to become users, and eventually become contributors. Self-management requires the project owner or the organization behind it to have strong community management capabilities. For example, NGINX is self-managed, and F5 manages the community through a professional community operation team. No matter what kind of governance method, the core is to help the project walk on the right track and direction, ensure the sustainable development of the project, and solve various stakeholder problems in the process of the project. The work required for community governance can include product evangelism, event operation, developer relationship maintenance, Issues/PR management, license management, community contract and rule management, document management, ecological construction, legal affairs, etc.
Open source selection. For open source users , especially for enterprise users, the first rule of open source selection is to establish access control. Enterprises can consider establishing a whitelist of open source software assets to prevent developers from randomly introducing open source software or projects. The software provided by the purchased service provider is also subject to relevant whitelist checks. Although this increases the cost to a certain extent, it is indeed very necessary for the enterprise’s security risk control. Enterprises should conduct sufficient research and analysis on open source projects to understand the status, activity, supporting force behind the project, operation mode, user base, contributor popularity, license restrictions, technical roadshows, software architecture, code quality, etc., and do a good job Adequate pre-introduction testing. Open source projects should also be introduced objectively to avoid the introduction of “relational open source projects” due to the technical feelings or inclinations of a small number of people.
Let’s look at open source governance . As with the challenges of using open source above, enterprises can conduct open source governance in terms of culture, technology, and process.
(1) In terms of culture, enterprises should establish a culture of advocating and respecting open source. While actively encouraging the adoption of open source technologies, strengthen employee awareness of open source. Such as respecting copyright and avoiding legal risks. Knowing open source does not mean free, and using open source does not mean cheating. Knowing open source doesn’t mean you can be autonomous and controllable. Open source does not mean customization, and any modifications and enhancements that are beneficial to the product should be fed back to the upstream. Enterprises should objectively evaluate their current ability to control open source according to their own actual situation, and should not rashly advance. For example, enterprises may need to shape open source cultural genes step by step. At this time, it is more suitable for enterprises to adopt open source software usage models with professional support services. By introducing the support of third parties or open source service providers to help enterprises avoid technical risks and achieve pragmatic independent availability control. Taking soft load products as an example, enterprises can try open source practices by introducing NGINX support services. For departments that have just undergone open source practice transformation, such as operation and maintenance departments, they can consider adopting commercial products + manufacturers’ open source expansion solutions to ensure that they gradually enter open source operation and maintenance under the premise of controllable risks.
(2) In terms of technology, establish a good development construction and testing platform and security testing platform in the development link, and conduct code scanning and inspection on relevant open source codes. Identify dependencies of related libraries and discover potential vulnerabilities in the code itself and associated dependencies. Check for possible license compliance issues and cross-problems through open source license management software. During delivery and operation, use additional security devices or strategies to strengthen the environment in which open source components run reinforcement. Strengthen the technical team’s learning and skill improvement of open source technology, and establish a professional open source technology component support team.
(3) In terms of process, enterprises can consider establishing a whole process mechanism from introduction, development, delivery, operation and maintenance to exit for open source management. From the aspects of organizational mechanism and management system, the open source software introduction specification, development specification, deployment specification, operation and maintenance specification, exit management and other specifications are formed. The introduction of specifications can be combined with the above-mentioned open source selection part to identify open source access, establish access conditions, and make the first pass of the entrance. The development specification can consider defining the use language, paradigm, boundary, modification process, documentation process, etc. of open source software code. Deployment specifications can be considered around delivery, dependency management, security hardening, and standardized environments. Operation and maintenance specifications can consider the operation and maintenance tools, troubleshooting processes, best practices and other aspects of open source software. In addition, enterprises should also form a closed-loop management system, and establish an identification and inspection mechanism for the use and operation of open source. For example, identify open source software and related projects that are already running, and evaluate them, make corrections in terms of culture, process, and technology for the problems found, and exit open source software that is not running well in time to ensure that the governance of open source is always Stay on track to avoid open source sprawl and runaway.
Summarize
It can be seen that, whether it is an open source subject or an open source user, the understanding, choice, risk, challenge, and governance of open source are all systematic projects and capabilities. In recent years, under the strategic background of the country’s vigorous promotion of open source, the concept of “trusted open source” has been proposed in China, and its main goal is still how to better play the role of open source and avoid possible risks in open source. In any case, if an open source project can always adhere to its original intention and insist on being user-centered, it can eliminate users’ concerns and risks in open source in many aspects. As Zhang Yiqiang, general manager of F5 China, said at the “2022 F5 Multi-Cloud Application Service Technology Summit”: Focus on user needs and build an open source ecosystem around product features and community platforms. This is the core that ensures that NGINX can go a long way in China, the core that F5 provides value to users, and the core that users trust F5. I think the same applies to our understanding of other open source.