How open source development provides a roadmap for digital trust, security, safety, and virtual work

Introduction

During COVID-19, we’ve all seen our daily lives, and those of many of our colleagues, friends, and family around the world completely changed. Many are adjusting to working from home and homeschooling their children, or caring for family and those with the virus. At the same time, billions worldwide are connected, sharing, and working together virtually despite their daily routines and working arrangements changing drastically. 

While there’s no disputing that the pandemic will dominate our collective attention for months to come, it’s a natural time to reflect on what is essential. It’s also a natural time as open source developers to consider how we should prioritize the most impactful work, and collaborate on technology development that can influence our world, for the better, after COVID-19. 

We’ve seen an uptick in interest around open source, in particular, as a means of helping humanity through these challenging times. What better way to solve a problem that affects all of us, collectively, than to share and build solutions to our problems, together? 

Here we outline the trends we’re seeing shape technology development in this unprecedented time. We believe this can also provide insight into what a post-COVID world may look like. 

Open collaboration embraces remote work and provides a guide for others

Open source developers have always fostered a sense of adaptability. It’s always been a critical skill needed to work on any open source project — we’re ready to meet the challenges of this moment. All of us hope for a quick return to normalcy, but we know that it will likely be months (hopefully not years). 

The Linux Foundation is also conscious of the economic reality facing the world as economists and accountants tally the cost of this pandemic. Like our communities, we are seeking to optimize for a new reality, but also working to redeploy and transition employees into new areas to fill in gaps where they can be most helpful to our communities. 

Open source communities during this time have been resilient. Open source software development by its very nature happens, and thrives, amongst a distributed group around the world. Many individuals in our communities are already working in a distributed virtual environment on their open source collaboration efforts.

Open source communities are still moving forward. As the world quickly migrated to virtual work environments, the online developer communities familiar with working together virtually had a pretty smooth transition, or in some cases, no disruptions at all. We are seeing many open source communities push forward despite all the challenges around them at home and in their local communities. Given their experience working in virtual environments, many open source community members and organizations are sharing their best practices and helping others adapt to working virtually. 

Developers helping coronavirus response with open source software and hardware solutions

It’s uplifting to see so many in our community contributing to the fight against this virus, whether it be providing supercomputer access to scientific researchers, open source personal protective equipment (PPE), offering bots to help people assess their symptoms, empowering doctors with access to diagnostic toolssupporting families struggling to transition to work and school from home, or contributing to relief efforts. We’ve also seen the medical industry and open source coming together to solve problems, such as an OpenLung project. As locals are starting to “reopen,” contact tracing will become critical, and we’re seeing communities form to address contract tracing application needs.

Governance and trust through applied open source governance models

We believe that the broader technology industry can use open source governance models to address more widespread industry challenges that could not be as easily solved with more traditional, proprietary solutions. Many blockchain open source software projects have arisen over the last few years that are now ready to support industry ecosystem and utility networks. We see early adopters moving beyond just software to addressing challenges with trust and verification in blockchain systems in our recently announced Trust over IP project.

In open source software communities, many organizations leverage nonprofits like the Linux Foundation to have a neutral home for an open governance model that no one company in the industry controls. We see a trend that those same principles apply in the case of the governance of an industry service built on blockchain technology with nodes contributed by multiple organizations. 

We expect to see initial governance communities emerge in 2020, focusing on identity and tracking and tracing use cases. Those initial communities will likely enable new applications and innovations that can be built on top of these industry and ecosystem platforms.

Open source at the edge of the network to address security, safety, and growth challenges

We’re also seeing trends of open source technologies becoming critical systems that are often viewed as the “last mile.” 

With open source becoming pervasive, we now have to think about these technologies as they support critical infrastructures. LF Energy and LF Networking are becoming more focused on economic and financial systems (see FINOS), and also safety systems (see ELISA).

Many other critical infrastructure systems have a severe impact if they fail. With open source software underpinning these critical systems, we need to figure out how to manage these systems. To succeed, our members started with identifying and tracking what software is in a system (see SPDX) and how to maintain software over a very long lifespan (see  Civil Infrastructure Platform). 

Additionally, LF Networking & LF Edge are seeing a significant uptake in Developer contribution as 5G, Edge, IoT, and Network Automation become increasingly crucial in the enterprise.

Securing the software supply chain

Beyond identifying the software (open source or not) in a system, the software supply chain deserves more security attention. We started exploring this issue within our Core Infrastructure Initiative and its Census I and Census II studies, and the practical challenges of managing supply chains in our OpenChain project. Looking out through the end of the year, we expect to explore the problem from the perspective of maintainers. We hope to see additional resources to help fix broken projects, increase the adoption of standards, and help address the entire challenge’s entirety. A challenge this large requires the community to come together and focus its efforts on solving security problems, together. We think the industry is ready and able to take this on.

Embracing and creating open standards

The fourth trend we’re looking at this year is a convergence of standards and open source. This trend has been increasing over the past few years, but we’re now at a point where organizations better understand where standards play a role and where open source plays a role. Standards development is a collaboration that can happen with open source implementations, often trailing an open source implementation, open source software development has turned conventional standards development upside down — and inside out. 

Within the Linux Foundation ecosystem, we have open technical communities building software and specifications. We also have communities that have identified interoperability points, processes, or frameworks for technology or managing technologies, that all benefit from being formally written as specifications. Standards are a natural next step in their journey as ecosystems coalesce around a common specified way of doing things. This year started with the Joint Development Foundation (JDF) being approved as an ISO PAS Submitter, making it possible for our communities to go from a specification repository to an international standard. We expect to see many more communities forming that is focused on a hybrid of standards and open source development. 

In addition to its work with the JDF, LF Networking also has a great collaboration with other established standards development organizations to ensure harmonization of specifications and code in the open source projects that facilitate deployment for carriers globally. 

Conclusion: Life after defeating the virus

Finally, the last trend we wish to highlight goes back to the beginning of this article — we see a pattern of our communities adapting to help society move forward in the face of a pandemic. I’ve already covered some of the COVID-19 response initiatives above, but this is a different point.  

We’re seeing a shift to virtual events, remote work cultures, virtual “happy hours,” and other means of productively working together, virtually. Many of these practices will stick with us post-pandemic. Our organization is already exploring how to use virtual events to augment future physical events (yes, they will exist again). 

Virtual conferences may be a great path to offering more inclusive events where those of us unable to travel to an event physically can still find a way to participate at some level. We’re seeing the impact of virtual training and certifying professionals in freely available open source technologies — and it has a real impact on job prospects and employment. Virtual testing proctors have become an effective way to certify professionals. Similarly, virtual platforms can help facilitate mentorship and enable less experienced developers to find and connect with more skilled developers willing to lend a hand.

The coronavirus has opened the world’s eyes to the needs of systems and plans for pandemic situations. This year we will likely see technology communities and organizations adapt and develop the “playbook” for how the world does business in the face of a pandemic. But many of those practices will likely stay with us long after we defeat COVID-19. 

Open Source Communities and Trademarks: A Reprise

Intellectual property and how it is shared have been the cornerstone of open source. Although it is more common to discuss “code” or “copyright,” there are other IP concerns around patents and trademarks that must be considered before investing time and effort in a major open-source project. There are long-established practices that govern these matters. Companies and lawyers involved in open source have been working on and evolving open source project trademark matters for decades.

Neutral control of trademarks is a key prerequisite for open source projects that operate under open governance. When trademarks of an open source project are owned by a single company within a community, there is an imbalance of control.  The use of any trademark must be actively controlled by its owner or the owner will lose the right to control its use. The reservation of this exclusive right to exercise such control necessarily undermines the level playing field that is the basis for open governance. This is especially the case where the trademark is used in association with commercial products or solutions. 

Open source licenses enable anyone to fork the code and distribute and modify their own version. Trademarks, however, operate differently. Trademarks identify a specific source of the code. For example, we all know MariaDB is not the same as MySQL. They’ve each developed their own brand, albeit they’re derived from a common codebase. The key question is who decides when a company should be allowed to associate its product or solution with the brand of the community?

A trademark is a word, phrase or design that denotes a “brand” that distinguishes one source of product or solution from another. The USPTO describes the usage of trademarks “to identify and distinguish the goods/services of one seller or provider from those of others, and to indicate the source of the goods/services.” Under US trademark law you are not able to effectively separate ownership of a project mark from control of the underlying open source project. While some may create elaborate structures around this, at the end of the day an important principle to follow is that the project community should be in control of what happens to their brand, the trademark they collectively built up as their brand in parallel with building up the functionality of their code. 

For this reason, in communities that deem their brand important, we also file registrations for trademark protection to reserve the rights in the mark for the project, commonly in the United States, China, European Union, Japan, and other countries around the world. Registered marks will often have a ® symbol. This is different from a common law trademark right where you often see a ™ symbol with the mark. Having a registered trademark is often important because it enables us to better protect the community against misrepresentation, misuse, and confusion in the ecosystem between what is actually the community-built project, and what is not. This is often based on specific benefits that arise from the registration, which may vary from country to country.

The Linux Foundation started hosting projects outside of Linux a decade ago. From the outset, the brand of a project community we host has been an important asset that we have been asked to protect for our communities. The communities’ goals and motivations are always different, but, in general, the organization contributing a trademark usually wants to ensure it denotes the community they’re helping to establish at the LF, and the other participants in the ecosystem want the confidence that one company can’t tell them what they can or cannot do with a project we host because they retained ownership of the trademark.

This neutrality is the very essence of what we try to establish at the Linux Foundation with our projects. Our projects are set up to be neutral – the Linux Foundation or our project entities own the mark. We then put the control over decisions about the mark into the hands of our project communities, to be determined by them in an open and transparent manner to achieve their collective goals.

For example, in March of 2017, we participated in a meeting hosted at a KubeCon in Berlin, where the organizations involved in Kubernetes sat down in a packed room to discuss what they wanted to do with the Kubernetes brand as it related to companies using Kubernetes in conjunction with their commercial products or solutions. When drafting the governance for CNCF, Google had insisted it was important for the Linux Foundation to also own the Kubernetes mark as part of CNCF—so that branding control would go hand in hand with neutral, community-driven governance. 

However, the LF was not in a position to determine when one company should or should not be able to say their solution was a “Kubernetes”-based product. We needed a program to allow companies and other organizations to use the trademark commercially to denote their distribution or compatibility with the community’s Kubernetes releases. That initial group worked for months to define what it means to have a conformant Kubernetes distribution. That’s also why the promise of portability amongst cloud providers actually works today. Those technical experts from the community as a whole defined exactly what it would take to deliver on the promise of portability. And then the definition of conformance that they established has been backed up by the neutral ownership of the Kubernetes trademark, in the Linux Foundation. What’s even more important is that the community remains in control of the program. In fact, the definition of conformance is controlled by Kubernetes’s SIG Architecture and changes in a carefully controlled process in each release as new APIs become stable and obsolete ones are deprecated. 

This same story has played out in other communities we have hosted. We’ve had many communities build consensus around what it means to be compatible or conformant with the releases coming from our project communities. So many that we recently wrote an entire blog just about the topic.

What these examples show is that a community can neutrally manage a trademark within the LF’s structure. We tend to refer to these as “community-managed trademark” programs. The marks are owned by the LF entity for the project, and we work with the communities we serve to establish the rules around usage of our marks.

Recently there has been a new round of conversations about open source projects and ownership of trademarks. Understandably there has even been concern that open source hasn’t addressed issues of trademarks as it relates to major OSS projects. This is not the case. While the motivations vary, one aspect remains constant: trademark law. 

We’ve been asked, “can we have the LF manage our trademark too?” The answer is yes. Let us know what project you’re managing and we’re happy to help you understand what’s involved in setting up a community-managed trademark program for your project. To date, we have successfully done this for the most important open source projects in the world and projects that are the most important to a few people. We can probably help support you as well.

Driving Compatibility with Code and Specifications through Conformance Trademark Programs

A key goal of some open collaboration efforts — whether source code or specification oriented — is to prevent technical ‘drift’ away from a core set of functions or interfaces. Projects seek a means to communicate — and know — that if a downstream product or open source project is held out as compatible with the project’s deliverable, that product or component is, in fact, compatible. Such compatibility strengthens the ecosystem by providing end-users with confidence that data and solutions from one environment can work in another conformant environment with minimal friction. It also provides product and solution providers a stable set of known interfaces they can depend on for their commercially supported offerings. 

A trademark conformance program, which is one supporting program that the LF offers its projects, can be used to encourage conformance with the project’s code base or interfaces. Anyone can use the open source project code however they want — subject to the applicable open source license — but if a downstream solution wants to describe itself as conformant using the project’s conformance trademark, it must meet the project’s definition of “conformant.” Some communities choose to use words other than “conformant” including “certified”, “ready”, or “powered by” in association with commercial uses of the open source codebase. This is the approach that some Linux Foundation projects take to maintain compatibility and reduce fragmentation of code and interfaces. 

Through this approach, we enable our projects to create flexible, custom-tailored conformance programs to meet the needs of their respective communities. In fact, our conformance programs can operate as open source projects themselves (see, for example, https://cncf.io/ck ). They incorporate a balance of interests from vendors, end-users, and contributors to the project and enable the community to define how the commercial ecosystem participants can leverage the use of the community’s mark. 

Products or solutions that meet the requirements of the trademark conformance program can use the conformance program’s trademark. Those that do not meet its requirements, cannot. If the project community learns that someone is misusing a conformance program trademark — say using the mark to show compatibility without achieving all of the requirements of the conformance program — the community could work with the LF to take steps to advise them on how they can come into conformance with the program requirements, or discontinue their use of the trademark.

How Can an Open Project Establish a Conformance Trademark Program?

When our projects establish a conformance program, we recommend that they follow the following basic steps:

  1. Determine what you want the trademark to signify.

Are you interested in showing compatibility with a core segment of project code or interfaces? Do you want this mark to indicate backward compatibility? Do you want the mark to imply a certain level of ‘rigorousness’ of compatibility? How broad or narrow a focus of compatibility are you interested in (e.g., all of the code base, or a key portion)? Does a “compatible” solution necessarily need to use the underlying open source codebase at all, or just present a compatible interface? 

This question is best addressed by involving interested stakeholders across business, marketing, and technical functions including discussions to resolve upon the intended meaning for the mark. Relevant stakeholders will likely include the project developers; downstream vendors who develop products based on the project’s outputs; and potential customers and end-users of those vendors.

A conformance program’s guiding star should be to ensure neutrality and objectivity in the conformance definition’s metrics. In order for an ecosystem to accept that the conformance trademark has relevance, it should be tied to a specific, articulated definition of what it does and doesn’t include. If the definition of conformance includes aspects of subjective evaluations by the project members, the result may be a perception that non-technical considerations such as favoritism were used as factors — and that the mark is not a reliable indicator of technical functionality. Objective criteria that are applied neutrally can help to avoid such a perception. In addition, the process by which the mark or requirements are defined should be specified and made known.

  1. Decide upon the specific requirements of conformance.

Once you have identified what you want the trademark to signify, you can craft a specific set of requirements necessary for a product to be able to use the conformance trademark. These requirements should also be developed within the community, and the development of these requirements is often closely tied to the work in item 1 above.

Additional questions to consider are:

    • How long can a product or solution provider claim compatibility, and against what version(s) of the open source project? How many future versions will that conformance be valid for?
    • Will the community create a test suite to provide an objective “pass / fail” determination for compatibility, or rely on more subjective considerations? (ideally, the answer should be the former)
    • What triggers a requirement for a vendor to re-test and confirm that their solution remains conformant — every time a change is made, or after a set period of time, or only if/when complaints are received from the community, or something else?
  1.   Determine how products and solutions will be qualified as meeting the requirements of the conformance program. 

There are many approaches that our projects take with respect to qualifying products or solutions, and they range in expense from none/nominal to significant. A common approach is to publish the requirements and allow self-certification with the requirements via a registration page. The project would then publish a current list of all registrants so that end-users could — by way of the project’s web site — know that a particular vendor had self-certified their product as meeting the requirements. Depending on the nature of the project and the conformant vendors’ solutions, end-users themselves might be able to run the same set of self-tests on the solutions, to confirm compatibility for themselves. In some cases, end users may use the same tests to keep their internal teams conformant in their internal deployments. Tooling costs are also a consideration for projects in setting up automated testing systems.

Another approach is to engage with third-party test labs that will test whether submitted products or solutions, in fact, meet the conformance program requirements. This model may also be setup by publishing criteria or requirements that a test lab can follow to offer conformance program testing.

As you can imagine, the expense involved in contracting with third-party test labs can be significant. Many of our communities choose to lower barriers to entry for the ecosystem and keeping costs low is often a priority.

  1. Publish the requirements and begin operating the trademark conformance program.

Maintain the program’s requirements in a highly visible manner, and begin accepting registration applications! Keep a list of certified solutions on the project’s website or code repository.

In fact, the development and administration of the conformance program itself can even be run as an open source project (see: https://github.com/cncf/k8s-conformance). 

Keep in mind that these programs will need to be maintained as well, especially as the project evolves and makes significant changes to its modules and interfaces. We often treat these conformance programs as their own open source collaboration that evolve with the project. 

Example Programs Employed by Projects Supported by the Linux Foundation

A number of our projects have trademark conformance programs. These include:

1. Certified Kubernetes®

The Certified Kubernetes program is run by the Cloud Native Computing Foundation (CNCF) and is intended to ensure that open source code and vendor products based on Kubernetes support the core APIs that make up Kubernetes. Vendors that are interested in using the Certified Kubernetes mark are required to submit conformance testing results to CNCF for review and approval. Additional information on the program can be found here: https://www.cncf.io/certification/software-conformance/.

2. ODPi Egeria Conformant

The ODPi Egeria Conformance program is intended to ensure both consistency and alignment with the interfaces developed by the ODPi Egeria project. The participation form and the terms and conditions of the program can be found here: https://www.odpi.org/projects/egeria/conformance.

3. OPNFV Verification Program (OVP)

Created through collaboration between OPNFV and ONAP, two projects within LF Networking, OVP focuses on compliance, validation, performance, and interoperability testing for commercial NFVI (cloud platform infrastructure) implementations and VNFs (telco cloud applications). This conformance program is used to indicate that an OVP-branded product or solution:

    • Supports key behaviors, functions, and related APIs and packaging requirements of the OPNFV and ONAP release
    • Implements defined NFV functions
    • Supports end-to-end life cycle management interoperability among an NFVI/VIM built on the conformant products, applications designed to run on that infrastructure, and ONAP
    • Is a good candidate for internal testing by the operator in their own specific environment

Products or solutions that meet these requirements are then able to use the OPNFV VerifiedTM brand under the appropriate usage guidelines. The program supports both self-certification by vendors and testing via approved third-party labs. Detailed information on OVP can be found here: https://www.lfnetworking.org/ovp/

4. Powered by OpenDaylight®

OpenDaylight is one of the technical code projects within our LF Networking umbrella which has a “Powered by OpenDaylight” conformance trademark program. Products using the mark are required to implement certain core sections of the open source code with the current release of OpenDaylight or the prior two releases. A FAQ on the program can be found here: https://www.opendaylight.org/ecosystem-solutions/for-solution-providers/powered-by-faq-page 

The registration page for a company interested in applying to use the “Powered by…” trademark can be found here: https://www.opendaylight.org/ecosystem-solutions/for-solution-providers/powered-by-reg-form 

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.”

Accelerating Open Standards development with Community Specifications

Introduction

In an earlier post back in May, the Linux Foundation and Joint Development Foundation (JDF) announced its ability to propose international standards by being recognized as an ISO/IEC JTC1 PAS submitter and that it had submitted its first standard, OpenChain, for international review. We also discussed why Open Standards were essential to the Linux Foundation’s efforts, just as Open Source projects are.

Today, we’re announcing a new way for communities to create Open Standards. We call it the Community Specification, and it allows communities to develop standards and specifications using the tools and approaches that are inspired and proven by open source developers. It’s standards development explicitly designed for Git-based workflows. The Community Specification brings the frictionless approach of open source collaborations to standards development.

It’s flexible, enabling small and large standards collaborations. And it’s built for growth. When or if the time is right, Community Specification projects can move to the Joint Development Foundation or another standards body. From there, the Joint Development Foundation can provide a path to international standardization.

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. 

Open Standards are best defined as specifications made available to the public, 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.

Setting up a well-formed standards project is important. Items like due process, balance, inclusiveness, and intellectual property clarity are vital to developing technology that meets the needs of the broader community that can be implemented without intellectual property surprises.

The Community Specification builds on these best practices and brings them to the Git repository development environments that developers are already using. And it makes it easy to get started. You can start using the Community Specification by bringing its terms into your repository and getting to work — just like starting an open source project. 

Lowering the costs and reducing the level of effort of creating specifications

Starting a new standards effort is traditionally a time consuming and expensive project. It takes time, money, and effort — from negotiating multi-party agreements to dealing with the legal and corporate formalities to obtaining professional support.

The Joint Development Foundation created a much-streamlined alternative to setting up a traditional standards-setting activity. We created a standardized set of formation documents and procedures that allow the collaborators to choose from a predefined set of licensing terms. 

JDF took this expensive multi-month process and replaced it with a “check-the-box” approach that has already enabled over 13 communities like Open Manufacturing Platform, GraphQL, and Trust Over IP to get up and running quickly, and allowing these communities to create technologies with worldwide impact.

For these projects, the JDF shortened the process of creating a new standards project from many months to as quickly as a few days and removed much of the ongoing legal overhead of creating a new non-profit company to host the project.  

And while JDF has streamlined the creation of new standards organizations by providing a “standards organization in a box,” sometimes an even lighter-weight approach is desired. Today, the JDF is pleased to announce its latest innovation, the Community Specification.  

The Community Specification is the next step in reducing the friction of standards development.  By incorporating the Community Specification materials into a Git-based repository, communities can now start a standards development effort as quickly as an open source project, using proven standards-based best practices for governance and intellectual property. And it’s free. The Community Specification provides a “standards-organization-in-a-repo.” All you have to do is clone or copy the Community Specifications repository, fill in a few details, and get started.

JDF takes its inspiration from the developer community. We know the ultimate consumer of a specification is the implementer, and implementers are by and large developers. So it is no accident that the Community Specification relies on Git-based repositories like GitHub and GitLab as its platform for creating new standards. 

The tools that are natively available for managing contributions in a Git-based repository via an open and inclusive process are based on best practices from standards and open source development models. To make this process attractive to developers, we have adopted a single set of agreements for technical contributions, source code, governance, code of conduct, patents, and copyright. 

The Community Specification will allow communities to employ a fast and easy way to start a specification development process using software development-style tools and workflows that they already know. 

Conclusion

The new Community Specification process allows contributors to start a specification collaboration with a simple set of licenses and procedures at no cost. The Community specification is efficient and runs using tools and approaches that lower the administrative burden on the organizers and ensures contribution integrity. The project can run as a repository-based collaboration or as a legal entity under JDF, depending on the project’s needs. 

From this starting point, the collaborative can move seamlessly into a more structured JDF project that allows the project to scale up the support services to allow for broader member participation, collections of membership dues, test events, and marketing services. As part of the Joint Development ecosystem, the projects may also enjoy the benefits of being part of the world’s largest developer ecosystem at the Linux Foundation.  

In the ultimate expression of a standard’s success, the project may apply to submit the specification to JTC1/ISO/IEC through the JDF PAS submitter program, which allows the specification to reach national standards bodies worldwide.  

The Community Specification can dramatically reduce the time developers spend on building and meeting spec requirements and ensure important work is not lost and time is not wasted. By democratizing the specification build process, developers have more time to innovate and build the technologies that differentiate their work from others. 

We invite interested projects and people with great ideas to benefit from an organized collaboration platform to reach out to the Joint Development Foundation. 

 

Linux Foundation interview with NASA Astronaut Christina Koch

Jason Perlow, Editorial Director at the Linux Foundation, had a chance to speak with NASA astronaut Christina Koch. This year, she completed a record-breaking 328 days at the International Space Station for the longest single spaceflight by a woman and participated in the first all-female spacewalk with fellow NASA astronaut Jessica Meir. Christina gave a keynote at the OpenJS Foundation’s flagship event, OpenJS World, on June 24, 2020, where she shared more on how open source JavaScript and web technologies are being used in space. This post can also be found on the OpenJS Foundation blog.

JP: You spent nearly a year in space on the ISS, and you dealt with isolation from your friends and family, having spent time only with your crewmates. It’s been about three months for most of us isolating at home because of the COVID-19 pandemic. We haven’t been trained to deal with these types of things — regular folks like us don’t usually live in arctic habitats or space stations. What is your advice for people dealing with these quarantine-type situations for such long periods? 

CK: Well, I can sympathize, and it can be a difficult challenge even for astronauts, and it can be hard to work through and come up with strategies for. For me, the #1 thing was making sure I was in charge of the framework I used to view the situation. I flipped it around and instead about thinking about all the things I was missing out on and the things that I didn’t have available to me, I tried to focus on the unique things that I did have, that I would never have again, that I would miss one day. 

So every time I heard that thought in my head, that “I just wish I could…” whatever, I would immediately replace it with “this one thing I am experiencing I will never have again, and it is unique”. 

So the advice I have offered since the very beginning of the stay at home situation has been finding that thing about our current situation that you truly love that you’ll know you will miss. Recognize what you know is unique about this era, whether it is big, or small — whether it is philosophical or just a little part of your day — and just continually focus on that. The biggest challenge is we don’t know when this is going to be over, so we can quickly get into a mindset where we are continually replaying into our heads “when is this going to be over? I just want to <blank>” and we can get ourselves into a hole. If you are in charge of the narrative, and then flip it, that can really help.

I have to say that we are all experiencing quarantine fatigue. Even when it may have been fun and unique in the beginning — obviously, nobody wanted to be here, and nobody hopes we are in this situation going forward, but there are ways we can deal with it and find the silver lining. Right now, the challenge is staying vigilant, some of us have discovered those strategies that work, but some of us are just tired of working at them, continually having to be our best selves and bringing it every day. 

So you need to recommit to those strategies, but sometimes you need to switch it up — halfway through my mission, I changed every bit of external media that was available to me. We have folks that will uplink our favorite TV shows, podcasts, books and magazines, and other entertainment sources. I got rid of everything I had been watching and listening to and started fresh with a new palette. It kind of rejuvenated me and reminded me that there were new things I could feast my mind on and unique sensory experiences I could have. Maybe that is something you can do to keep it fresh and recommit to those strategies. 

Christina Koch

JP: I am stuck at home here, in Florida, with my wife. When you were up in the ISS, you were alone, with just a couple of your crewmates. Were you always professional and never fought with each other, or did you occasionally have spats about little things?

CK: Oh my goodness, there were always little spats that could affect our productivity if we allowed it. I can relate on so many levels. Being on the ISS for eleven months, with a lot of the same people in a row, not only working side-by-side but also socializing on the weekends, and during meals at the end of the day. I can relate because my husband and I were apart for almost two years if you take into account my training in Russia, and then my flight. Of course, now, we are together 24 hours a day, and we are both fortunate enough that we can work from home. 

It is a tough situation, but at NASA, we all draw from a skill set called Expeditionary Behavior. It’s a fancy phrase to help us identify and avoid conflict situations and get out of those situations if we find ourselves in them. Those are things like communication — which I know we should all be doing our best at, as well as group living. But there are other things NASA brought up in our training are self-care, team care, leadership, and particularly, followership. Often, we talk about leadership as an essential quality, but we forget that followership and supporting a leader are also very important. That is important in any relationship, whether it is a family, a marriage, helping the other people on your team, even if it is an idea that they are carrying through that is for the betterment of the whole community or something like that. The self-care and team care are really about recognizing when people on your team or in your household may need support, knowing when you need that support, and being OK with asking for it and being clear about what needs you may have.

A common thread among all those lines is supporting each other. One way, in my opinion, the easiest way to get yourself out of feeling sorry for whatever situation you might be in is to think about the situation everyone else is in and what they might need. Asking someone else, “Hey, how are you doing today, what can I do for you?” is another way to switch that focus. It helped me on my mission, and it is helping me at home in quarantine and recognizing that it is not always easy. If you are finding that you have to try hard and dig deep to use some of these strategies, you are not alone — that is what takes right now. But you can do it, and you can get through it.

JP: I have heard that being in the arctic is not unlike being on another planet. How did that experience help you prepare for being in space, and potentially places such as the moon or even mars?

CK: I do think it is similar in a lot of ways. One, because of the landscape. It’s completely barren, very stark, and it is inhospitable. It gives us this environment to live where we have to remember that we are vulnerable, and we have to find ways to remain productive and not be preoccupied with that notion when doing our work. Just like on the space station, you can feel quite at home, wearing your polo shirt and Velcro pants, going about your day, and not recognizing that right outside that shell that you are in is the vacuum of space, and at any second, things could take a turn for the worse. 

In Antarctica and some of the Arctic areas that were very isolated, should you have a medical emergency, it can often be harder to evacuate or work on a person in those situations than even working on the ISS. At the ISS, you can undock and get back to earth in a matter of hours. At the south pole, weather conditions could prevent you from getting a medevac for weeks. In both situations, you have to develop strategies not to be preoccupied with the environmental concerns but still be vigilant to respond to them should something happen. That was something I took away from that experience — ways to not think about that too much and to rely on your training should those situations arise. And then, of course, all the other things that living in isolation gives us.

The one thing that I found in that realm is something called sensory underload. And this is what your mind goes through when you see all the same people and faces, you keep staring at the same walls, you’ve tasted all the same food, and you’ve smelled all the same smells for so long. Your brain hasn’t been able to process something new for so long that it affects how we think and how we go about the world. In these situations, we might have to foster new sensory inputs and new situations and new things to process. NASA is looking into a lot of those things like reality augmentation for long-duration spaceflight, but in situations like the Arctic and Antarctic, even bringing in a care package, just to have new things in your environment can be so important when you are experiencing sensory underload. 

Hurricane from space

JP: The younger people reading this interview might be interested in becoming an astronaut someday. What should the current, or next generation — the Gen Y’s, the Gen Z’s — be thinking about doing today — to pursue a career as an astronaut? 

CK: I cannot wait to see what that generation does. Already they have been so impressive and so creative. The advice I have is to follow your passions. But in particular, what that means is to take that path that allows you to be your best self and contribute in the maximum possible way. The story I like to tell is that when I was in high school, I was a true space geek, and I went to space camp, and there we learned all the things you need to do to become an astronaut. 

There was a class on it, and they had a whiteboard with a checklist of what you should do — so everyone around me who wanted to be an astronaut was just scribbling this stuff down. And at that moment, I realized if I were ever to become an astronaut, I would want it to be because I pursued the things that I was naturally drawn to and passionate about, and hopefully, naturally good at. If one day that shaped me into someone who could contribute as an astronaut, only then would I become truly worthy of becoming one. So I waited until I felt I could make that case to apply to become an astronaut, and it led me to this role of focusing on the idea of contributing. 

The good news about following a path like that is even if you don’t end up achieving the exact dream that you may have. Whether that’s to become an astronaut or something else that may be very difficult to achieve, you’ve done what you’ve loved along the way, which guarantees that you will be successful and fulfilled. And that is the goal. Eyes on the prize, but make sure you are following the path that is right for you.

JP: Some feel that human-crewed spaceflight is an expensive endeavor when we have extremely pressing issues to deal with on Earth — climate change, the population explosion, feeding the planet, and recent problems such as the Coronavirus. What can we learn from space exploration that could potentially solve these issues at home on terra firma?

CK: It is a huge concern, in terms of resource allocation, so many things that are important also warrant our attention. And I think that your question, what can we learn from space exploration, is so important and there are countless examples — the Coronavirus, to start. NASA is studying how the immune system functions at a fundamental level for humans by the changes that occur in a microgravity environment. We’re studying climate change — numerous explorations, on the space station and other areas of NASA. Exploration is enabled by discovery and by technological advances. Where those take us, we can’t even determine. The camera in your smartphone or in your tablet was enabled by NASA technology. 

There are countless practical examples, but to me, the real answer is bigger than all of that — and what it can show us is what can be accomplished when we work together on a common goal and a shared purpose. There are examples of us overcoming things on a global scale in the past that seemed insurmountable at the beginning, such as battling the hole in the ozone layer. When that first came out, we had to study it, we had to come up with mitigation strategies, and they had to be adopted by the world, even when people were pointing out the potential economic drawbacks to dealing with it. 

But the problem was more significant than that, and we all got together, and we solved it. So looking towards what we can do when we work together with a unified purpose is really what NASA does for us on an even bigger scale. We talk about how exploration and looking into space is uplifting — I consider it to be uplifting for all across the spectrum. There are so many ways we can uplift people from all backgrounds. We can provide them with the tools to have what they need to reach their full potential, but then what? What is across that goal line? It is bigger things that inspire them to be their best, and that is how NASA can be uplifting for everyone, in achieving the big goals.

JP: So recently, NASA resumed human-crewed spaceflight using a commercial launch vehicle, the SpaceX Crew Dragon capsule. Do you feel that the commercialization of space is inevitable? Is the heavy lifting of the future going to come from commercial platforms such as SpaceX, Boeing, et cetera for the foreseeable future? And is the astronaut program always going to be a government-sponsored entity, or will we see private astronauts? And what other opportunities do you see in the private sector for startups to partner with NASA?

CK: For sure. I think that we are already seeing that the commercial aspect is playing out now, and it’s entirely a positive thing for me. You asked about private astronauts — there are already private astronauts training with a company, doing it at NASA through a partnership, and having a contract to fly on a SpaceX vehicle to the ISS through some new ways we are commercializing Low Earth Orbit. That’s already happening, and everyone I know is excited about it. I think anyone with curiosity, anyone who can carry dreams and hopes into space, and bring something back to Earth is welcome in the program.

I think that the model that NASA has been using for the last ten years to bring in commercial entities is ideal. We are looking to the next deeper set, going back to the moon, and then applying those technologies to go on to Mars. At the same time, we sort of foster and turn over the things we’ve already explored, such as Low Earth Orbit and bringing astronauts to and from the space station to foster a commercial space industry. To me, that strategy is perfect; a government organization can conduct that work that may not have that private motivation or the commercial incentives. Once it is incubated, then it is passed on, and that is when you see the commercial startups coming. 

The future is bright for commercialization in space, and I think that bringing in innovation that can happen when you pass off something to an entirely new set of designers is one of the most exciting aspects of this. One of the neat examples of that is SpaceX and their spacesuits — I heard that they did not consult with who we at NASA use as our spacesuit experts that have worked with us in the past. I think that is probably because they did not want to be biased by legacy hardware and legacy ways of doing things. They wanted to re-invent it from the start, to ensure that every aspect was re-thought and reengineered and done in a potentially new way. When you’ve been owners of that legacy hardware that’s difficult to do — especially in such a risky field and in a place where something tried and true has such a great magnetic draw. So, to break through the innovation barrier, bringing commercial partners onboard is so exciting and important.

Christina Koch

JP: Let’s get to the Linux Foundation’s core audience here, developers. You were an engineer, and you used to program. What do you think the role of developers is in space exploration?

CK: Well, it cannot be understated. When I was in the space industry before becoming an astronaut, I was a developer of instrumentation for space probes. I built the little science gadgets and was typically involved in the sensor front-end, the intersection of the detectors’ physics and the electronics of the readouts. But that necessitated a lot of the testing, and it was fundamentals testing. Most of the programming I did was building up the GUIs for all the tests that we needed to run, and the I/O to talk to the instruments, to learn what it was telling us, to make sure it could function in a wide variety of environmental states and different inputs that it was expected to see, once it eventually got into space. 

That was just my aspect — and then there is all the processing of the data. If you think about astronomy, there is so much we know about the universe through different telescopes, space-based and ground-based, and one of the things we do is anticoincidence detection. We had to come up with algorithms that detect only the kind of particles or on wavelengths that we want to identify, and not the ones that deposit energy in different ways that we are trying to study. Even just the algorithms to suss out that tiny aspect of what those kinds of X-Ray detectors on those telescopes do, is entirely software-intensive. Some of it is actual firmware because it has to happen so quickly, in billionths of a second, but basically, the software enables the entire industry, whether it is the adaptive optics that allow us to see clearly, or the post-processing, or even just the algorithms we use to refine and do the R&D, it’s everywhere, and it is ubiquitous. The first GUIs I ever wrote were on a Linux system using basic open source stuff to talk to our instruments. As far as I know, there is no single person who can walk into any job at NASA and have no programming experience. It’s everywhere.

JP: Speaking of programming and debugging, I saw a video of you floating around in the server room on the ISS, which to me looked like a bunch of ThinkPad laptops taped to a bulkhead and sort of jury-rigged networked there. What’s it like to debug technical problems in space with computer systems and dealing with various technical challenges? It’s not like you can call Geek Squad, and they are going to show up in a van and fix your server if something breaks. What do you do up there?

CK: That is exactly right, although there is only one thing that is inaccurate about that statement — those Lenovos are Velcroed to the wall, not taped (laugh). We rely on the experts on the ground as astronauts. Interestingly, for the most part, just like an IT department, just like at any enterprise, the experts, for the most part, can remotely login to our computers, even though they are in space. That still happens. But if one of the servers is completely dead, they call on us to intercede, we’ve had to re-image drives, and do hardware swaps.

JP: OK, a serious question, a religious matter. Are you a Mac or a PC user, an iOS or an Android user, and are you a cat or a dog person? These are crucial questions; you could lose your whole audience if you answer this the wrong way, so be careful.

CK: I am terrified right now! So the first one I get to sidestep because I have both a Mac and a PC. I am fluent in both. The second — Android all the way. And as the third, I thought I was a cat person, but since I got my dog Sadie, I am a dog person. We don’t know what breed she is since she is from the Humane Society and is a rescue, so we call her an LBD — a Little Brown Dog. She is a little sweetheart, and I missed her quite a bit on my mission.

JP: Outside of being an astronaut, I have heard you have already started to poke around GitHub, for your nieces and nephews. Are there any particular projects you are interested in? Any programming languages or tools you might want to learn or explore?

CK: Definitely. Well, I want to learn Python because it is really popular, and it would help out with my Raspberry Pi projects. The app that I am writing right now in Android Studio, which I consulted on with my 4-year-old niece, who wanted a journal app. I’m not telling anyone my username on GitHub because I am too embarrassed about what a terrible coder I am. I wouldn’t want anyone to see it, but it will be uploaded there. Her brother wants the app too, so that necessitated the version control. It’s just for fun, for now, having missed that technical aspect from my last job. I do have some development boards, and I do have various home projects and stuff like that.

JP: In your keynote, you mentioned that the crew’s favorite activity in space is pizza night. What is your favorite food or cuisine, and is there anything that you wished you could eat in space that you can’t?

CK: My favorite food or cuisine on Earth is something you can’t have in space, sushi, or poke, all the fresh seafood type things that I got introduced to from living in American Samoa and visiting Hawaii and places like that, I missed those. All the food we have in space is rehydrated, or from MREs, so it doesn’t have a lot of texture, it has to have the consistency of like mac and cheese or something like that. So what I really missed is chips — especially chips and salsa. Because anything crunchy is going to crumble up is going to go everywhere. So we don’t have anything crunchy. Unfortunately, I have eaten enough to have made up for without chips and salsa since I was back. 

JP: Thank you very much, Christina, for your time and insights! Great interview.

Watch Christina’s full OpenJS World keynote here:

Linux Foundation & Harvard Announce Free/Libre and Open Source Software (FOSS) Contributor Survey

“Open source software is everywhere. Now, more than ever, we need to get a better understanding of it to help make it even more secure.” – David A. Wheeler, Director of Open Source Supply Chain Security, Linux Foundation

In 2020, given the wide proliferation of Free/Libre and Open Source Software (FOSS), we aim to identify how to improve security, including the sustainability of the FOSS ecosystem, especially the FOSS systems heavily relied upon by organizations worldwide.

To do this, the Linux Foundation’s Core Infrastructure Initiative (CII) and the Laboratory for Innovation Science at Harvard (LISH) have developed a survey for contributors to FOSS. If you contribute to FOSS, we would love for you to participate in our study. This voluntary survey takes around 15-20 minutes to complete and allows you to advocate for the FOSS projects you care about. 

Please participate now; we intend to close the survey in early August. In appreciation of your participation, we would like to offer our participants the option to have your name included in the overall results. If you opt to be attributed in the final report, you will still have the opportunity to keep your detailed survey responses confidential.

The CII takes a collaborative, pre-emptive approach for strengthening cybersecurity by improving open-source software security. We aim to support, protect, and fortify open software, especially software, critical to the global information infrastructure. We take a holistic view of security; we include security risks in critical projects that are inadequately sustained or vulnerable to supply chain attacks. We intend to use this survey information to help guide this approach.

To take the FOSS Contributor Survey, click the button below:

 

Why CII best practices gold badges are important

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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