Tag Archives: cpan

Open Source components you depend on are not “third-party components”

Third party

– adj. relating to a person or group besides the two primarily involved in a situation

“third-party suppliers”


When using the term “third-party”, we usually refer to someone who is not part of an agreement, but who may still be influencing (or be influenced by) this relationship. When this party is an Open Source project, I propose to use term “second-party” in the case where one has an actual ongoing relationship. Here’s why.

Looking at software suppliers, they often have a few qualities that are common between them.

  1. The supplied component is not owned by the first or the second party.
  2. The first and second party may not be free to use the third party component without triggering terms to the contractual agreement (e.g. there may be limitation on how many individual users that may be allowed to use the component, triggering an increase in fees if this changes in certain ways)
  3. The first and second party may be allowed to learn or introspect the third party component beyond non-invasive ways, such as reading any supplied documentation, or through basic use of the component. This usually means tools and methods for reverse-engineering, de-compiling, and instrumentation are not allowed to be used to figure out how the component preforms. Source code is usually not be available for inspection.
  4. The first and second party are not allowed to permanently fix, improve or make other non-trivial changes to the third party component beyond basic configuration, even in the case where the source code is made available.
  5. The first and second party may not be allowed to share any changes made to the third party component.

This list is looks quite a lot like the four freedoms of the Open Source Definition, doesn’t it? It is.

When you (as the first party) decide to use an open source component, you are accepting a license agreement with the component author or owner. They (in a sense) become the second party in a new relationship, where the terms of the agreement are laid out in the license. You, as a first party, gain privileged access to the Open Source component in ways that you – by definition – will ever get from an agreement with a closed-source component suppliers.

So while it’s common for most first-party users of Open Source components don’t exercise the rights afforded by the licenses they accept, they still have these rights. And most importantly – the other party is still likely to appreciate your contributions the day you eventually decide to exercise your right to “contribute”.

But what happens in the meantime?

Ghosting in Open Source – Silence is indistinguishable from death

Consider what happens when you don’t interact with the Open Source project owners and developers you depend on. How will they know that you need them? Or that you care?

In smaller Open Source projects, “ghosting” is a real risk. For first-party users, this lack of communication can quickly lead to new concerns, some of them of the worrying kind. “Is this person too busy?”, “Was my suggestion not useful?”, “Will the projects developers be able to respond in a timely manner?”, or even “Did the project bus factor just decrease to zero?”

The same goes for the other direction. For Open Source developers, the concerns may sound like “Does even anyone use my software?”, though you might find that many are content with just having scratched their own itch. Nevertheless, some appreciation is much better than none, and for the thankless work of maintaining an upstream component, positive feedback can be critical.

Open Source Ghosting is eerily similar to Warnock’s Dilemma – and as with the dilemma, the concerns above are pretty much removed instantly when the other party engages.

Second-party Volunteers or Suppliers

To help remind us that constructive communication is an ongoing activity, let’s just use the proper terms – “second-party components”, “second-party projects” and “second-party volunteers” when referring to people and projects we actually depend on. Even the term “second-party suppliers” could be used by someone paying for this privilege.

Small reminders like “thank you” or “I need you” are just as necessary in Open Source relationships as in most others. And if you (as a first-party user) have resources the second party needs – make sure to support them before it’s too late. Turn your second-party volunteers into your second-party suppliers with communication, collaboration and funding.

And don’t insult them by relegating them to a “third” party.

After all, when you depend on them, you might as well rely on them.

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.

Perl Toolchain Summit 2023 in Pictures

PTS2023 was this time in Lyon, France; Organized primarily by Philippe “BooK” Bruhat and Laurent Boivin.

This event wouldn’t be possible without it’s sponsors, Booking.com, Deriv, Grant Street Group, FastMail, cPanel, Perl Careers, MaxMind, Fastly Inc., Perl Maven, OpenCage, Perl Services, Oetiker+Partner, and Procura. Thank you!

All pictures in this gallery are ©2023, Salve J. Nilsen, CC-BY-NC-4.0. Please reach out to me on Mastodon if you consider using any of these in a commercial setting.

NIS2 and CRA – EU LAWS that may kill Open Source?

New EU laws are coming that will affect Open Source. Should we worry?

One is the NIS2 directive, which cares about the state of computer and software security in sectors that work on critical infrastructure. Another is the Computer Resilience Act, which tries to improve the security landscape around network-connected devices.

Depending on how these two directives are implemented, and how companies and communities react, this may either lead to increased funding for badly needed efforts in resource-starved Open Source communities — or — motivate affected businesses to move in the direction of software mono-cultures and away from the culture of permission-less innovation that Open Source software developers have practiced for decades.

Of course, these laws aren’t finished yet. NIS2 has to be implemented in local law, and the CRA is (as of this writing) still a work in progress. While the situation may still change, I believe there are a couple things Open Source communities can do to prepare already now.

  • Ensure supply-chain security procedures are in place and all issues resolved.
  • Create easy-to-find-and-use documentation directed at business managers that are forced to be introduced to their new Open Source colleagues.
  • Clarify project adoption and takeover procedures so the ones with a bus-factor of zero get a chance to be revived.
  • and more…

I’ve summarized some of my thoughts on this in the presentation I gave at the Perl Toolchain Summit 2023 in Lyon, France, on April 27th 2023, embedded below.

Presentation about NIS2 and CRA at PTS2023

As a background and preparation for this talk, I and the Norwegian chapter of the Internet Society organized a fireside chat on April 22nd 2023.

In this conversation, we explored these laws (and others) both from a legal, security and Open Source perspective. The panel consisted of Simon Phipps (Director of EU Policy at the Open Source Initiative), Kaspar Rosager Ludvigsen (Lawyer and PhD candidate, working on the Cyber Resilience Act), Hans-Petter Fjeld (Senior Security Analyst at Defendable), and myself (Community activist and organizer in the Perl and Raku communities).

ISOC Norway fireside chat with Simon Phipps, Kaspar Rosager Ludvigsen, Hans-Petter Fjeld and Salve J. Nilsen

This event was graciously funded with a grant from NUUG Foundation.

If you find these topics interesting, feel free to reach out to me on Mastodon!

A FIXIT-dive into an old CPAN module

Let’s have a thought experiment. Assume there is an Open Source-licensed Perl module published on CPAN that you care about, and that hasn’t had any updates in a very long time – what are your options?

In this blog post, I’ll take a dive into this problem, and use the Geo::Postcodes::NO module as an example. As of this writing, the module version is 0.31, and it’s most recent release was in September 2006. Continue reading A FIXIT-dive into an old CPAN module

Perl Toolchain Summit 2018: Oslo, Norway

Every year we bring together the lead developers of the Perl and CPAN toolchain! This event was previously known as the QA Hackathon, but in 2016 it became the Perl Toolchain Summit (PTS) to more accurately reflect the scope and purpose.

This is an event where pressing issues around Perl’s toolchain, CPAN, testing infrastructure and much more are hacked on, fixed and improved, and where important issues are discussed and decided on. The focus is the continued support and development of the tools used every day by individuals, organisations, and companies that rely on Perl in Production.

Many improvements in the CPAN ecosystem can trace their roots to this event, including Test2 improvements, the «River of CPAN» analogy, numerous MetaCPAN additions, improvements to the Perl Authors Upload Server (PAUSE), policies on how to handle CPAN distribution adoption and takeover, work on the CPAN Testers service, several consensus documents and much, much, much, more!

This year’s summit will be in Oslo, Norway running from Thursday 19th April 2018 through Sunday 22nd April. Attendees be staying at the Smarthotel Oslo, with the event itself at Teknologihuset, a short tram-ride away.

Continue reading Perl Toolchain Summit 2018: Oslo, Norway