Tag Archives: open source

Community, Open Source

A Vocabulary for a New Open Source Age

With the EU Cyber Resilience Act arriving in 2024, software in general is – for the first time – about to be legislated.

This means any business who wishes to place software on the EU market will have to comply to new cybersecurity demands, and by implication this will affect tens of thousands of Open Source authors and maintainers indirectly.

A couple of ramifications are safe to expect.

  1. Businesses are now required (after a risk assessment) to get a full overview of what their software is and is composed of – including their Open Source transitive dependencies “all the way down” – in order to ensure they have no vulnerable components in use.
  2. Well over 80% of software in use is coming from Open Source ecosystems, authors, developers and maintainers. These communities should expect to get a level of scrutiny much greater than before, and are expected to share whatever metadata that is downstream users are obliged to share.
  3. Most businesses will realize that they depend on components and people that are in dire need of support.

With this in mind, I would like to propose the adoption of an updated vocabulary to use in the coming years. The purpose is to help management of these businesses make decisions that are both beneficial for the continued sustainability of their commercial activity, but also for the same regarding the Open Source projects, authors and communities their business depends on.

A New Open Source Vocabulary

Invest on Return (not Return on Invest)

The idea that a business should get a “Return on Investment” (ROI), is completely backwards when it come to Open Source software. Companies depending on Open Source components already have their return by the fact that the business is already using these components in their value-chain, and therefore already depending on these projects. It’s better to think of FOSS funding as an investment in the continued well-being of these projects, just as much as it is sensible in investing in the continuation of any profit-bringing venture. The business is already benefiting from the Return, and the next step is to Invest in the reliability of this source of income – Invest on Return (IOR).

Source: Conversation with Chad Whitacre on the SustainOSS podcast episode 213 (starting at 13m58s).

Open Source Sustainability

Open Source Sustainability is about ensuring the continued responsiveness of the component project authors, so they both are available and capable to fix bugs and respond to vulnerabilities as the world proceeds. If a project owner is burned out or alone (or worse!), this situation directly impacts the risk landscape of their downstream users. A recent example of this can be found in the revelations of social engineering leading to the 2024 xz-utils hack.

Open Source Bystander Effect

The effect one sees when everyone is waiting for someone else to make the first move (or accept the burden) to support a resource-starved Open Source project. This is a consequence of businesses having never felt the need to involve themselves (in a budgetary sense) in Open Source communities, with the predictable result that these Open Source projects and communities have become so resource-starved that many just abandon their projects, and thereby worsening the risk and reliability landscape for everyone.

Open Source Colleague

An Open Source author, developer or maintainer that the business depends on. If they have a bad week or month, and the business is in risk of consequences because of this, then the business should consider treating them as any of their regular highly competent colleagues.

If the business decides to support their Open Source Colleague in a sustainable way, they may become an Open Source Supplier. Until then, they are Open Source Volunteers, with the risks and liabilities this entails.

Open Source Supplier

An author, developer, maintainer or contributor working on an Open Source project that is financially supported in a way that is sustainable in the long-term. This is an especially useful term to use when taking into account the requirements for sustained support and updates laid out in the EU Cyber Resilience Act recitals 60-63. In this context, I mean “Supplier” and “Manufacturer” to be equivalent.

Open Source Volunteer

An author, developer, maintainer or contributor that is working on an Open Source project in a way that unsustainable in the long run.

Second-party component

A component depended on or used in a product, that is licensed with an OSI approved Open Source license. Since the company (“first-party”) has accepted the FOSS license, they are now – in a sense – partners in the further development of this component. They both gain the benefits of the license, and are subject to the obligations of it.

While the obligations are “cheap”, they still involve considerations around project sustainability, interaction with volunteers and their long-term sustainability, and using the term “Second-Party” can help remind us to help these projects’ sustainability.

Software Sustainability (Budget line item)

A budget line item dedicated to supporting the authors and projects behind components that the business depends on. This is spending money on the continued and sustainable reliability of software in use. This item is not sponsorship and not charity.

Third-party component

A component depended on or used in a product, where the component owner does not gives all four freedoms the Open Source definition affords to the user (Use, Learn, Modify, Share).

Partnership (not Sponsorship)

When considering business-critical Open Source projects or ecosystems, a business would do well to treat this relationship as a partnership. For the project or ecosystem user (the business) this partnership is already hugely beneficial, and since the business already has accepted the terms of their Open Source license, they have demonstrated that they already depend on the continued reliability of this project or ecosystem. If an Open Source developer or project (or ecosystem contributor) approaches the business for Sponsorship, they are making a mistake! The business is already a Partner, and should expect to be treated accordingly.

Final words

The vocabulary proposed here is meant to help business stakeholders and decision-makers to inform themselves enough to prompt a re-evaluation of their relationships with their upstream open source component providers. The first step in this awareness-raising, is to introduce some new useful concepts that can help them see the nuances and realities of the landscape they are operating in. I hope that you, the reader, agrees and decides to adopt this vocabulary in your daily dealings.

Uncategorized

A FOSS Ecosystem Checklist for the Benefit of Maintainer Sustainability

  1. Maintainers and authors are found everywhere throughout our dependency trees. This includes the authors of the tooling others use for maintaining, building, testing, writing and running the infrastructure they depend on. Even maintainers depend on other maintainers.
  2. Maintainers’ mental health and well-being is also a dependency.
  3. So is their outlook on the sustainability of their projects, both in personal, technical, systemic and economic respects.

This means that personal, technical, systemic and economic well-being in the end are all actual and real dependencies for the businesses that rely on these people and their projects.

What can an ecosystem provide to make the lives of these maintainers easier in this regard?

Here are a few suggestions.

  1. Ensure that sustainability metadata fields (intended to be kept up-to-date by maintainers and authors) is specified and made available. These fields may include…
    • Project life-cycle status (supported, support-period end date, unsupported, replaced, discouraged, abandoned).
    • Project sustainability status (available for adoption, needs help, is available for a managed hand-off, requests funding, under custodianship).
    • And related metadata, like…
      • Links to funding services that are available or preferred.
      • Recommended alternative projects.
      • Relevant CE conformity information.
      • …or whatever else helps end users and businesses decide to support their open source colleagues and second-party component providers.
  2. Ecosystem tooling and infrastructure communicates this metadata to their downstream users and consumers.
  3. (Bonus) Up-river maintainers are invited to events that are specifically suited for their needs, free of cost, where they may learn and share new developments from and with their peers.

But why?

Mostly because businesses usually don’t have the tuits to figure out this information (even if it is available). Lowering “the bar for caring” with a few metadata fields may at least increase the possibility for these businesses to make a difference for their upstream component maintainers— a possibility that for many won’t exist unless their ecosystems help by enabling the communication of project sustainability metadata.