Centaurus today is becoming a Linux Foundation Project. The Centaurus Infrastructure Project is a cloud infrastructure platform for building distributed cloud as well as a platform for modern cloud native computing. It supports applications and workloads for 5G, Edge and AI and unifies the orchestration, network provisioning and management of cloud compute and network resources at a regional scale.
Founding members include Click2cloud, Distributed Systems, Futurewei, GridGain Systems, Reinvent Labs, SODA Foundation and Tu Wien Informatics. Centaurus is an umbrella project for modern distributed computing and hosts both Arktos and Mizar. Arktos is a compute cluster management system designed for large scale clouds, while Mizar is the high-performance cloud-network powered by eXpress Data Path (XDP) and Geneve protocol for high scale cloud. More members and projects are expected to be accepted in the coming months.
“The market is changing and customers require a new kind of cloud infrastructure that will cater to modern applications and workloads for 5G, AI and Edge,” said Mike Dolan, senior vice president and general manager for Linux Foundation Projects. “Centaurus is a technical project with strategic vision, and we’re looking forward to a deep collaboration that advances cloud native computing for generations to come.”
Current cloud infrastructure technology needs are evolving, requiring companies to manage a larger scale of compute and network resources across data centers and more quickly provision those resources. Centaurus unifies management across bare metal, VMs, containers and serverless, while reducing operational costs and delivering on the low latency and data privacy requirements of edge networks. Centaurus offers a consistent API experience to provision and manage virtual machines, containers, serverless and other types of cloud resources by combining traditional (Infrastructure as a Service) IaaS and Platform as a Service (PaaS) layers into one common infrastructure platform that can simplify cloud management.
“The Linux Foundation’s support in expanding the Centaurus community will accelerate cloud native infrastructure for the most pressing compute and networking demands,” said Dr. Xiong Ying, the current acting TSC chair, Centaurus Infrastructure Project. “It’s large network of open source developers and projects already supporting this future will enable mass collaboration and important integrations for 5G, AI and Edge workloads.”
To contribute to Centaurus, please visit: https://www.centauruscloud.io/
Supporting Member Quotes
“Click2cloud has been part of the development of Centaurus, which is world class software that will lead organizations to have a clear transition from IaaS to Cloud Native Infrastructure. Click2cloud has already started a development program to enable the journey from IaaS (Openstack) to Cloud Native migration, 5G cloud based on Centaurus reference architecture to support the partner ecosystem. We are very excited for Centaurus to be a part of Linux Foundation,” said Prashant Mishra, CEO, Click2cloud.
“Distributed cloud architecture is a natural evolution for cloud computing infrastructure. Centaurus is a cloud native infrastructure platform aiming to unify management and orchestration of virtual machines, containers, and other forms of cloud resources natively at scale and at the edge. We have seen many enterprise users and partners wanting a unified solution to build their distributed cloud to manage virtual machines, containers or bare metal-based applications running at cloud as well as at edge sites. We are very pleased to see, today, the Centaurus Infrastructure project becomes a Linux Foundation open-source project, providing an option for community and enterprise users to build their cloud infrastructure to run and manage next generation applications such as AI, 5G and IoT. We look forward to working with the open-source community to realize the vision of Centaurus,” said Dr. Xiong Ying, Sr. Technical VP, Head of Cloud Lab, Futurewei.
“Creating and managing a unified and scalable distributed cloud infrastructure that extends from cloud to edge is increasingly a challenge for organizations worldwide. GridGain Systems has been a proud sponsor and active participant in the development of in-memory computing solutions to support the Centaurus project. We look forward to helping organizations realize the benefits of Centaurus and continuing to help extend its scalability and adoption,” said Nikita Ivanov, Co-Founder and CTO, GridGain Systems.
“We are a young company, which specializes in cloud computing and delivering cloud-native solutions to our customers across various industries. As such, we are ever stronger witnessing the need to manage cloud services and applications that span across complex and heterogeneous infrastructures, which combine containers, VMs and serverless functions. What is more, such infrastructures are also starting to grow beyond traditional cloud platforms towards the edge on the network. Being part of the Centaurus project will not only allow us to innovate in this space and deliver a platform for unified management of infrastructure resources across both large Cloud platforms and the Edge, but it will also enable us to connect and collaborate with like-minded members for thought leadership and industry best practices,” said Dr. Stefan Nastic, founder and CEO of Reinvent Labs GmbH.
The SODA Foundation
“The SODA Open Data Framework is an open source data and storage management framework that goes from the edge to the core to the cloud. Centaurus offers the opportunity for SODA to be deployed in the next generation cloud infrastructure for 5G, AI and Edge, and allows both communities to innovate together,” said Steven Tan, SODA Foundation Chairman and VP & CTO Cloud Solution, Storage at Futurewei.
“We are very excited to be part of the Centaurus ecosystem and honored to be part of this open source movement and contributing in the fields of IoT, Edge intelligence, and Edge and Cloud Computing, including networking and communication aspects, as well as orchestration, resource allocation, and task scheduling,” said Prof. Schahram Dustdar, IEEE Fellow, Member Academia Europaea Professor of Distributed Systems, TU Wien, Austria.
The ACRN™ Open Source Hypervisor for IoT Development Announces ACRN v2.0 and Functional Safety Certification Concept Approval
New hybrid-mode architecture expands the scope of the project to include industrial IoT and edge device use cases, delivers new flexibility in resource sharing across virtual machines and new levels of real-time and functional safety
Postman joins 35 current members on the fast-growing initiative that includes Atlassian, Google, Microsoft, Red Hat, and Bloomberg
LF Edge’s Fledge project announces release 1.8 that integrates with industry leaders like Google, Nokia, OSIsoft, ZEDEDA and Dianonic to enable open industrial edge software with AI/ML and Public Cloud Integration
Expanded community includes integrations and contributions from Google, Nokia, Flir, OSIsoft, Nexcom, RoviSys, Advantech, Wago, Zededa and Dianomic
LF Edge’s Akraino Project Release 3 Now Available, Unifying OpenSource Blueprints Across MEC, AI, Cloud, and Telecom Edge
6 New R3 Blueprints (total of 20) covering use cases across Telco, Enterprise, IoT, Cloud and more
This original, collaborative community-driven white paper details the new LF Edge taxonomy with the goal of clarifying market confusion by breaking the continuum down based on inherent technical and logistical tradeoffs rather than using ambiguous terms.
ONAP’s 6th Release, ‘Frankfurt,’ Available Now – Most Comprehensive, Secure and Collaborative Software to Accelerate 5G Deployments
Rich feature set including End-to-end 5G network slicing, security and deployment-ready automation anchored in Frankfurt
Download this paper for an exploration of the business opportunities in 5G, the role of open source, Linux Foundation projects, and how to participate.
Produced by Avid Think and Converge! Network Digest with DPDK community support, the paper outlines the critical role DPDK plays in the evolution of networking infrastructure while dispelling a number of myths and misconceptions about the technology.
See the quick highlights from the June event and the LFN workstreams in motion.
Software Package Data Exchange (SPDX) is an open standard for communicating software bill of materials (SBOM) information that supports accurate identification of software components, explicit mapping of relationships between components, and the association of security and licensing information with each component. The SPDX format has recently been submitted by the Linux Foundation and the Joint Development Foundation to the JTC1 committee of the ISO for international standards approval.
A group of eight healthcare industry organizations, composed of five medical device manufacturers and three healthcare delivery organizations (hospital systems), recently participated in the first-ever proof of concept (POC) of the SPDX standard for healthcare use.
This blog post is a summary of the results of this initial trial.
Why do we care about SBOMs and the medical device industry?
A Software Bill of Materials (SBOM) is a nested inventory or a list of ingredients that make up the software components used in creating a device or system. This is especially critical in the medical device industry and within healthcare delivery organizations to adequately understand the operational and cyber risks of those software components from their originating supply chain.
Some cyber risks come from using components with known vulnerabilities. Known vulnerabilities are a widespread problem in the software industry, such as known vulnerabilities in the Top 10 Web Application Security Risks from the Open Web Application Security Project (OWASP). Known vulnerabilities are especially concerning in medical devices since the exploitation of those vulnerabilities could lead to loss of life or maiming. One-time reviews don’t help, since these vulnerabilities are typically found after the component has been developed and incorporated. Instead, what is needed is visibility into the components of a medical device, similar to how food ingredients are made visible.
A measured path towards using SBOMs in the medical device industry
In June 2018, the National Telecommunications and Information Administration (NTIA) engaged stakeholders across multiple industries to discuss software transparency and to participate in a limited proof of concept (POC) to determine if SBOMs can be successfully produced by medical device manufacturers and consumed by healthcare delivery organizations. That initial POC was successfully concluded in the early fall of 2019.
Despite the limited scope, the NTIA POC results demonstrated that industry-agnostic standard formats can be leveraged by the healthcare vertical and that industry-specific formats are unnecessary.
Next, the participants in the NTIA POC explored whether a standardized SBOM format could be used for sharing information between medical device manufacturers and healthcare delivery organizations. For this next phase, the NTIA stakeholders engaged the Linux Foundation’s SPDX community to work with the NTIA Healthcare working group. The goal was to demonstrate through a proof of concept whether the open source SPDX SBOM format would be suitable for healthcare and medical device industry uses. The first phase of that trial was conducted in early 2020.
Objectives of the 2020 POC
The stated goals of this 2020 proof of concept (POC) were to prove the viability of the framing document created by the NTIA SBOM Working group (of which the Linux Foundation was a contributor) from their earlier POC for the medical device and healthcare industry.
This NTIA framing document defines specific baseline data elements or fields that should be used to identify software components in any SBOM format, which can be mapped into corresponding field elements in SPDX:
|Supplier Name||(3.5) PackageSupplier:|
|Component Name||(3.1) PackageName:|
|Unique Identifier||(3.2) SPDXID:|
|Version String||(3.3) PackageVersion:|
|Component Hash||(3.10) PackageChecksum;|
|Relationship||(7.1) Relationship: CONTAINS|
|Author Name||(2.8) Creator:|
The 2020 POC conducted by NTIA working group had a stated objective to determine if SBOMs generated by Medical Device Manufacturers (MDMs) using SPDX could be ingested into SIEM (Security, Information and Event Management) solutions operated by the participating Healthcare Delivery Organizations (HDOs).
The MDMs included in this POC included Abbott, Medtronic, Philips, Siemens, and Thermo Fisher. The HDOs included Cedars-Sinai, Christiana Care, Mayo Clinic, Cleveland Clinic, Johns Hopkins, New York-Presbyterian, Partners/Mass General, and Sutter Health.
Execution and implementation of the SPDX SBOMs
- The participating HDOs provided an inventory of the deployed medical devices in use within their organizations.
- A best-effort approach was used to determine software identity as the names that software packages are known by are “ambiguous” and could be misinterpreted.
- An example SPDX was created along with a guidance document for the MDMs to follow for use with the medical devices identified by the HDO inventory exercise.
- The MDMs produced 17 distinct SPDX-based SBOMs manually and with generator tooling.
- The SBOMs were delivered via secure transfer using enterprise Box accounts, simulating delivery via secure customer portals offered by each MDM.
Consumption of the SBOMs in the SPDX POC
As a result of the 2020 POC, all participating HDOs successfully ingested the SPDX SBOM into their respective SIEM solutions, immediately making the data searchable to identify security vulnerabilities across a fleet of products. This information can also be converted into a human-readable, tabular format for other data analysis systems.
Multiple HDOs are already collaborating with vendor partners to explore direct ingestion into medical device asset/risk management solutions as part of their device procurement. One of the HDOs is working with one of their vendor partners to explore direct ingestion into a healthcare Vendor Risk Management (VRM) solution, and another has developed a ”How-To Guide,” focusing on how to correctly parse out the Packages fields using regular expressions (regex).
As a positive indicator of SPDX’s suitability when used with asset management systems, two HDOs have begun configuring their respective internal tracking systems to track software dependencies and subcomponents. Additionally, multiple HDOs are collaborating with vendor partners to manage devices into medical device asset/risk management solutions through the device’s life by allowing for periodic updates and an audit trail.
Ongoing considerations for SPDX-based SBOMs for medical devices in healthcare organizations
Risk management, vulnerability management, and legal considerations are ongoing at the participating HDOs related to the use of SPDX-based SBOMs.
All of the responding HDOs are exploring vulnerability identification upon procurement (i.e., SIEM through initial ingestion of the SBOM) and on an on-going basis (i.e., SIEM, CMDB/CMMS, VRM). The participating HDOs intend to explore mitigation plan / compensating control exercises that will be performed to identify vulnerable components, measure exploitability, implement risk reduction techniques, and document this data alongside the SBOM.
The SPDX community intends to learn from these exercises and improve future versions of SPDX specification to include requested information determined to be needed to manage risk effectively.
Vulnerability management at HDOs
An HDO is already working with its Biomed team to manually perform vulnerability management processes on information extracted from SBOM data.
Another is working with their Vulnerability Management team to evaluate correlated SBOM data to credentialed/non-credentialed scans of the same device, which may prove useful in an information audit use case. A second HDO is currently working with their Vulnerability Management team on leveraging the SBOM data to supplement regular scanning results.
Participating HDOs have been developing SBOM product security language to add cybersecurity safeguards to the contract documentation.
The original POC was able to validate the conclusions of the NTIA Working Group that proprietary SBOM formats specific to healthcare industry verticals are not needed. This 2020 POC showed that the SPDX standard could be used as an open format for SBOMs for use by healthcare industry providers. Additionally, the ability to import the SPDX format into SIEM solutions will help HDOs adequately understand the operational and cyber risks of medical device software components from their originating supply chain.
There is work ahead to improve automation of SPDX-based SBOMs, including the automated identification of software components and determining which component vulnerabilities are exploitable in a given system. Participating HDOs intend to perform compensating control exercises to identify and implement risk reduction techniques building on this information. HDOs are also evaluating how SPDX can support other improvements to vulnerability management. In summary, this POC showed that SPDX could be an essential part of addressing today’s operational and cyber risks.
FinOps Foundation to Become Linux Foundation Effort
DevOps in the cloud has broken traditional procurement, which is now outsourced to engineers. Engineers spend company money at will and make financial decisions on cloud providers like AWS, GCP and Azure at rapid speed with little time to consider cost efficiency. Finance teams struggle to understand what is being spent on the cloud. Leadership doesn’t have enough input into how much will be spent or ability to influence priorities. Enter the concept of FinOps, and the need for a community of practitioners to advance best practices beyond vendor tooling, whose aim is to increase the business value of cloud by bringing together technology, business and finance professionals with a new set of processes.
That’s why we’re so excited to announce our intent to host the FinOps Foundation with the Linux Foundation to advance the discipline of Cloud Financial Management through best practices, education and standards. The FinOps Foundation focuses on codifying and promoting cloud financial management best practices and standards to help the community. It currently includes 1,500 individual members representing more than 500 companies and $1B in revenue. They include Atlassian, Autodesk, Bill.com, HERE Technologies, Just Eat, Nationwide, Neustar, Nike, and Spotify among founding charter members.
Also part of today’s announcement is a new edX course, Intro to FinOps, which will give anyone interested in this area a primer on what it is and how to advance their career by becoming an expert in this emerging and critical discipline.
As the cloud native movement continues within organizations, understanding how to optimize the cloud infrastructure footprint through cultural change and engineering practices is critical. Technology and business leaders are seeking support for understanding how to manage cloud technologies and spending across their enterprises. The FinOps Foundation brings to bear the resources required to enable innovation inside the organization and will work together to define cloud financial management standards and advance the ubiquity of this discipline across industries.
The FinOps Foundation has grown significantly since its inception back in February 2019. We expect to support this burgeoning community and further accelerate growth and engagement. We invite you to get involved in this effort, no matter your role inside your company. As with any emerging discipline, the earlier you get involved, the better for your career.
Last month, the Joint Development Foundation (JDF), which became part of the Linux Foundation family in 2019, was recognized as an ISO/IEC JTC 1 PAS (“Publicly Available Specification”) submitter. With that recognition, Linux Foundation can put forward specifications to JTC 1 for national body approval and international recognition. Once JTC 1 approves a PAS submission, it becomes an international standard. Also in May, the JDF announced that The OpenChain Specification was the first specification submitted for JTC 1 review for recognition as an international standard.
The Linux Foundation today announced that the latest SPDX release (version 2.2) is the second specification to be submitted through the JDF to ISO/IEC JTC 1 for approval. In brief, the Software Package Data Exchange (SPDX) is an open standard for communicating software bill of material information, including components, licenses, copyrights, and security references. SPDX reduces redundant work by providing a common format for companies and communities to share important data, thereby streamlining and improving compliance. The first version of the SPDX specification was 10 years ago, and it has continued to improve and evolve to support the automation of more software bill of materials information over the years.
SPDX serves to verify the accuracy software bill of materials information metadata which is important both from a security and compliance standpoint. Consider that there are millions of open source software projects (34m open repositories are on GitHub alone) making it hard to know which are most critical, who created them and what are their security vulnerabilities? SPDX plays an important role in building more trust and transparency in how software is created, distributed and consumed. While many consider SPDX a defacto standard already, JTC1 certification will encourage accelerated adoption and acceptance on a global scale.
“The SPDX specification has played a vital role over the last 10 years in enabling open source adoption and establishing a foundation for automating compliance,” said Jim Zemlin. “Through the submission to the ISO/IEC JTC 1 by JDF, we are hopeful that it can become a accepted international standard that addresses how open source metadata information is shared, while reducing the risks and costs of compliance for organizations.”
All: I want to formally congratulate the Linux kernel project for earning a gold badge!! You can see their details here:
The Linux kernel has been close for a while. The final one they completed was to add some HTTP hardening headers to key websites.
Of course, a gold badge doesn’t mean that there are no vulnerabilities, or that it’s impossible to improve their development processes. Perfection is rare in this life. But it *does* mean that they’ve implemented a large number of good practices to keep the project sustainable, to counter vulnerabilities from entering their software, and to address vulnerabilities when they are found. The Linux kernel project takes many steps to do this, and it’s good to see.
The Linux kernel joins some of the few other gold applications, such as the Zephyr project, who have been at gold for a while. You can see the current gold holders here:
My thanks to Greg Kroah-Hartman, who spearheaded getting the badge “over the finish line.” Thank you for your effort.
I hope that this result will help inspire other projects 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 I think it’s clear that good practices can help make our software more secure, and we want to praise & encourage projects to have good practices.
David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation
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 its role as an ISO PAS submitter, JDF and LF now can move from idea to code, to standard, to an internationally recognized standard, vastly improving the reach and availability of the technologies created by our amazing communities.
This week, we are proud to announce that the Joint Development Foundation (JDF), which became part of the Linux Foundation family in 2019, has been accepted as an ISO/IEC JTC 1 PAS (“Publicly Available Specification”) Submitter. The OpenChain Specification is the first specification submitted for JTC 1 review and recognition as an international standard.
The JDF was formed to simplify the process of creating new technical specification collaboration efforts. Standards and specifications are vitally important for the creation or advancement of new technologies, ensuring that the resulting products are well defined, provide predictable performance and that different implementations can interoperate with one another.
Why the Linux Foundation cares about standards
The Linux Foundation itself was formed out of the merger of the Free Standards Group, which maintained the LSB (“Linux Standards Base”) and the Open Source Development Labs. Open standards and open source software have been part of the mission from the very beginning.
Standards play a role in everyone’s life. Think about the things you touch every day, as simple as a power plug, the USB connector on your phone or laptop, or the WiFi that you use in your business and your home to connect your mobile devices wirelessly. All of these devices need to be able to interoperate with each other.
A pragmatic and sensible approach to solving interoperability issues would be to create open source software projects everyone can use. However, there are cases where open source software alone will not solve all the implementation challenges that open standards can achieve.
Open source software in and of itself may not solve particular situations where there will be many implementations in many different device or delivery models (e.g., video codecs or 3D printer designs with many software design tools and many hardware printers and scanners). Still, in other cases, that fragmentation is due to different device capabilities, implementation details, or limitations that open source software cannot resolve alone.
The design and capacities of many things are defined by industry stakeholders as a standard so that every plug and device is interoperable and capable of the same connectivity. Every country in the world has its own national standards bodies that define the standards it deems necessary, from power transmission, radio spectrum, food safety, and others.
Not all standards bodies are national standards bodies, with standards organizations coming in many shapes and sizes. Many standards are developed by industry-specific organizations that have a common set of technical objectives and are seeking a common set of use cases, a shared set of key design and performance criteria, and a common test specification to ensure interoperability.
For the Linux Foundation, our collaborations can range in size from small to large, but their impact can extend internationally. There is not a Linux kernel per country or an Open Container Initiative specification per country, and so on. The world is dependent on our communities.
Like Linux Foundation source code projects, JDF standards and specification development projects can range from small, industry-specific efforts, to large multi-industry collaborations. And it is the JDF’’s goal to serve these various communities. By obtaining PAS status, JDF can help specification and standards communities ranging from the smallest collaborations through to international standardization.
How Open Standards differ from Open Source projects
Open standards are best defined as specifications made available to the public, which are developed and maintained via an inclusive, collaborative, transparent, and consensus-driven process. Open standards facilitate interoperability and data exchange among different products or services and are intended for widespread adoption.
Open source software is defined by the OSI’s Open Source Definition. In practice, we generally care more about communities that form to work on open source software in a public, transparent collaboration where the code evolves over time to address new use cases, features, requirements, and gaps.
Sustainable open source software communities also see continuous improvements as bugs and security issues are identified and fixed. Open source code is typically created as a collaborative effort in which programmers improve upon the code and often share the changes among the programming community for such projects. At a high level, open source licenses allow users the freedom to use, modify, and distribute the source code without requiring any further permission.
So, for example, software such as the Linux kernel is open source software in an open community, whereas the IETF curates open standards that enable the world to connect through an open Internet.
Another excellent example of how standards come into play across different hardware and software platforms are web servers. There are many web server platforms, both open source, and proprietary — such as Apache’s and Microsoft’s IIS. Some are optimized for speed, others for large deployments, some for low power devices, and for other applications. But as long as they can all speak HTTP (and other standards), they can still all communicate across the spectrum of devices.
The process of creating standards
Standards bodies are usually formed by industry stakeholders to support the activities needed to develop a specific solution to a common problem. The resulting solution is generally referred to as a specification, a blueprint for building an implementation of a solution to the problem. In some cases, the same group may also create an open source implementation, but the implementation will be specific to a set of use cases and requirements.
A standards body is the legal organization often created to provide a neutral home to the collaboration, including financial and legal support, guardrails against antitrust issues, managing copyrights and other intellectual property terms that might bear on the specification. Many will say the most important role of a standards body is to provide a neutral governance model that enables inclusive participation from all parties, where no one organization controls the specification.
The challenges in creating specifications
For something as crucial as a specification, the process of creating a specification setting body can be complicated.
And even when the participants are aligned, the devil is always in the details. The negotiations to establish a new standards organization often involves hundreds of hours of lawyer time and a method of negotiating the nuances of the working rules and the license terms for copyrights, patents, and trademarks related to the effort. The entire process can take many months — and it’s a requisite precursor in most cases to the technical contributors getting started. So before anyone knows what the output will be, or if it will even work, many organizations collectively invest thousands to millions of dollars on months of negotiations that delay the start.
Once the mass negotiation is done, the legal entity needs to file for non-profit status, set up bank accounts, set up accounting, finance, and HR operations, collect fees from its members, and file its taxes, just like a commercial company. These activities need to occur even if all the initiating organizations are 100% aligned on the need for the specification. Once that is all done, the engineers can get together to develop a specification, often a year after the initial idea was created.
The JDF was founded to make the entire process of forming a new standards body faster, and remove the negotiations. The JDF has created a set of default terms that reflect industry best practices and proven widely accepted legal terms. By providing a choice of pre-existing, industry-accepted terms, JDF replaces custom negotiation with a “check the box” model. This model adopts best practices while giving flexibility through a few commonly known choices to the founders about essential terms such as copyright, intellectual property licensing, source code licensing, and governance structures. It also allows JDF projects to be customized to meet the needs of the community, without resorting to time-consuming line-by-line negotiations.
And once those terms are in place, the new project is formed as an entity under the non-profit JDF. In combination with world-class operational support programs, a new project can get started in a matter of days, with resources ready to go, rather than the months to the years-long process required to form a traditional standards body. The cost of this effort is so low that a specification project can be established without any funding needed for the creation or ongoing entity management.
In essence, the JDF provides a “standards organization in a box.” Just pick a few menu options, give the effort a name and off you go creating specifications.
The net impact of the JDF process means that companies with the need to collaborate can form the project, define the technical scope and begin inviting engineers to contribute to the project in a matter of days with minimal friction.
Internationally recognized standards through the ISO/IEC JTC 1 PAS process
One method of recognizing international standards is via the ISO/IEC JTC 1 PAS (Publicly Available Specification) Process. Once accepted through this process, the specification is recognized as an international standard.
ISO is an independent, non-governmental international organization with a membership of 164 national standards bodies, and its standards are among the most universally recognized and accepted throughout the world.
The IEC (International Electrotechnical Commission) is the world’s leading organization for the preparation and publication of International Standards for all electrical, electronic, and related technologies.
ISO and IEC joined together to create ISO/IEC JTC 1, which is the international group dedicated to developing worldwide Information and Technology (ICT) standards. JTC 1 has been responsible for many key IT standards — including video compression technology and programming languages, among many others.
The Publicly Available Specification (“PAS”) process was created by a collaboration between ISO/IEC JTC 1 to allow for transposition of technical specifications from recognized standards bodies, which will enable them to become an ISO/IEC recognized standard.
PAS Submitters must first be approved after a review of an extensive set of criteria by the external standards bodies. Once approved, a PAS Submitter may put forward some of its specifications (the publicly available specifications, PAS) to JTC 1 for national body approval and thereby international recognition.
And once ISO/IEC JTC 1 approves a PAS submission, it becomes an international standard.
The JDF’s acceptance as a PAS Submitter is vital to the industry because it reduces friction on the path from great ideas, to well-formed technical specifications, to international recognition of the best of those specifications. JDF has the responsibility for ensuring that the process of creating the specifications is rigorous, inclusive, and conforms to the quality standards set by ISO/IEC JTC 1. The benefit of having a professionally managed standards organization like JDF is that we help ensure those requirements are met.
And it also means that JDF provides a capability that few other organizations can — a path for communities to start from a small collaboration and grow to become an international standard.
Understanding the OpenChain specification, our first PAS submission
The OpenChain Specification identifies the key requirements of a quality open source compliance program. It is intended to foster a software supply chain where open source is delivered with trusted and consistent compliance information. It provides a clear way to achieve effective management of open source for software supply chain participants, such that the requirements and associated collateral are developed collaboratively and openly by representatives from the software supply chain, open source community, and academia.
“The OpenChain Project is a clear example of cooperative development to share a common challenge,” says Shane Coughlan, OpenChain General Manager. “Hundreds of companies have come together, shared knowledge, and built a clear, focused industry standard based on their experience. The result is a compact but effective standard suitable for companies of all sizes in all markets.”
The OpenChain Specification has been in the market since late 2016 and has seen increasingly broad adoption to-date. The OpenChain participants include national user groups exceeding 100 participants and over 3,500 subscribers to the primary communication channel mailing list. ISO/IEC JTC 1 recognition will help to guide the evolution of the specification from de facto to de jure standard, and in the process assist procurement, sales, and other departments around the world adopt and manage OpenChain specification-related activities easily.
With its recognition as a PAS Submitter, JDF now provides the broadest range of support to standards communities – from small collaborations to those seeking international standards. As part of the Linux Foundation family, JDF is providing communities with new ways to collaborate.
By affiliating with JDF, the Linux Foundation ecosystem can benefit from the support and expertise to move open source specifications into an open standards-track, that empowers engineers and developers to collaborate in the creation of a specification and standard. By using this new submissions process, they can take their standard a step further to achieve international recognition. Conversely, the importance of the JDF joining the Linux Foundation family is significant because it is in alignment with the organization’s overall goal of furthering the commitment to neutral governance and alignment of open source software and open standards.
— Jim Zemlin, Executive Director, The Linux Foundation
The SPDX technical community is delighted to announce that the 2.2 version of the specification has been released! We started working on the first version of the SPDX specification 10 years ago, and it has continued to improve and evolve to support the automation of more software bill of materials information over the years. This release incorporates a significant amount of input from our tooling and user communities to enable new use cases to be better represented.
Some of the highlights for this release include:
- Updated Charter to broaden applicable scenarios that SPDX documents can be used to represent that have been requested by users, and align with NTIA SBOM efforts.
- Extended the valid file formats that can be used to represent an SPDX document to include JSON, YAML, and a development version of XML. A set of example documents illustrating use of these formats can be found in v2.2/examples
- Extended Relationships by addition of 13 new relationship types requested from tool creators (mostly to represent dependencies), as well as support for relationships to NOASSERTION or NONE as a way to indicate “known unknown” and “no relationships” respectively.
- Added new fields to Packages, Files, and Snippets to capture “Attribution text”.
- Extended Appendix VI: Appendix VI: External Repository Identifiers to include support for PURL (Package URLs) and SWHIDs (Software Heritage Persistent Identifiers).
- Added Appendix VIII: SPDX Lite as a first recognized SPDX profile. This subset of SPDX 2.2 originated from the use cases that the OpenChain Japan workgroup highlighted. They created it to be able to accept basic information from their suppliers who were not able to generate full SPDX documents with all optional fields.
- Added Appendix IX: SPDX File Tags to enable use of file-specific information from SPDX defined fields in source code as supported by Version 3.0 of the REUSE Software Specification.
- Updated Appendix V: Using SPDX License List short identifiers in Source Files to include support for use of LicenseRef- identifiers, to express custom identifiers for licenses that are not on the SPDX License List. This has been coordinated with Version 3.0 of the REUSE Software Specification to enable projects to provide a standardized format that can optionally be used for providing the corresponding license text for these identifiers.
- Updated Appendix II: License Matching Guidelines to allow embedded rules within optional rules for generated SPDX license templates.
- Updated Appendix IV: SPDX License Expressions to add some clarification on the case sensitivity of license expressions and handling of multi-line license expressions.
- Updated Appendix I: License List to now reference version 3.8.
- And numerous formatting, grammatical, and spelling fixes that escaped our reviewers in version 2.1.1
The project members would like to thank our recent contributors to this release, who have enriched it with their new perspectives, as well as our ongoing participants. A full list of those who have contributed by participating in the many discussions, adding comments, and making suggestions for improvements to the SPDX specification as it’s evolved over the last 10 years can be found at the Credits page!