Category Archives: Perl

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”

Encyclopedia.com

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 agreement. When this party is an Open Source project you depend on directly, I propose we use term “second-party.” Here’s why.

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

  1. The first and second party may not be free to use this component without triggering terms in the contractual agreement (e.g. there may be terms governing how many individual users are allowed to use the component, leading to an increase in fees if this increases.)
  2. The first and second party may be allowed to learn or introspect the third party component in non-invasive ways, such as reading any supplied documentation, or through basic use of the component. But this usually disallows more intrusive tools and methods used to figure out how a component preforms – like reverse-engineering, de-compiling or instrumentation. Source code is usually not available for inspection.
  3. The first and second party may not permanently fix, improve or make other non-trivial changes to the third party component, beyond basic configuration – even if source code has been made available.
  4. The first and second party may not share any changes made to the third party component.

This list is looks quite a lot like the four freedoms of the Free Software 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 offered by the component author or owner. When you do, they (in a sense) become the second party in a new relationship, where the terms of the agreement are laid out in this license, and with this, you gain privileged access to the Open Source component in ways that you – by definition – will never get from an agreement with a non-Open-Source component supplier. Privileged access and rights as laid out in the Free Software Definition.

And from the component author’s perspective, they (your second party) are still likely to appreciate your well-reasoned contributions that rainy day when you eventually decide to do contribute. You may be using their software in ways that exposes it to new situations which may lead to experiences to learn from and later used to improve the code you both depend on.

But while most users of Open Source components don’t exercise the rights afforded by the licenses they accept, they still retain these rights. They are still allowed to inspect, fix and share their improvements at any time, without asking for permission. And this privilege will still be there on that rainy day when you really need it.

Suppliers, colleagues or volunteers?

From the Open Source developer’s perspective, it may look different. You are maybe one of hundreds or thousands of users, but your constructive feedback and support is still appreciated. You are also a second-party to them, Both of you care about the long-term sustainability and success of the same project. The difference is one of scale – you may be second-party to hundreds of projects. They may have one or two orders of magnitude more.

So for second-party relationships to work at this scale, we should remind ourselves that constructive relationships like these, should be treated as an ongoing, long-term, low-frequency activity.

When tending long-term relationships with where good communication is important, it helps that we use the appropriate terms. If you treat your colleague the same way you treat a stranger, you’ll eventually find that this colleague becomes a stranger – this can be troublesome that day you need them the most!

So when an Open Source author says they are not your supplier – take the hint! If you depend on them, they are something closer to a colleague, or partner. If they have a bad day, you may be affected in ways similar to when a colleague has a bad day – If a colleague struggles with burnout, would you treat them as a “third party”?

Second-party

To remind ourselves that we’re in a low-frequency long-term relationship, let’s adopt terms like “second-party component”, developed in a “second-party project” with help from “second-party developers”. This is especially important when referring to people and projects we depend on directly. Even the term “second-party suppliers” could be used if you are paying for this privilege.

And while low-cost reminders like “thank you” or “I need you” are just as necessary in Open Source relationships as they are at work and at home, we can also keep an eye out for our second-party colleagues. If you have resources the second party needs to stay around in the long term – make sure to support them before it’s too late! You can even turn your second-party projects into your second-party suppliers with communication, collaboration and funding.

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

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. (Edit: The slides from this presentation can be found under the CPAN Security Group list of presentations.)

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’s Postmodern Metanarrative

Now and then, it’s good to remind ourselves what “There Is More Than One Way to Do It” means.

A long time ago, Larry Wall said Perl is the first postmodern programming language. I’ve thought about this – asking myself what does that even mean?

Today I think this is just a nice way of saying that Perl has no metanarrative. Let’s unpack this.

Continue reading Perl’s Postmodern Metanarrative

A Perl Toolchain Summit 2018 organiser’s report

The PTS is a gathering of key contributors to the CPAN and Perl ecosystems. These people spend a long weekend extra every year on building, improving and fixing many important parts of infrastructure most Perl developers and their companies use to do business.

This time we were in Oslo! 10 years ago the very first one was also organised in Oslo (then called the Perl QA Hackathon), so we had good reasons to come back. Together, we spent our time on hacking, breaking, fixing, arguing, deciding and much more. We had lots of fun and were quite productive.

There are several other reports from PTS attendees, all worth reading. This one focuses on the organiser’s perspective.

Preparations

The first real movements towards PTS in Oslo were done in October and November 2017; Reserving dates for the venue and contacting the first few “Core” invitees to the PTS to determine which dates are the most convenient.

The “Core” is a group of roughly 10 leaders of well-established, best-practice and/or important toolchain projects: MetaCPAN, PAUSE, Test2, CPAN Testers, ExtUtils::MakeMaker, major CPAN clients, Devel::Cover, Dist::Zilla, Carton, Test::Smoke etc. This list (and the people behind them) change over the years, but they form the base of invitees. This group helps the organisers select the others that are invited – people that are making meaningful contributions to the CPAN ecosystems.

Much of the local activity was about planning, budgeting, finding a summit hotel, coordinating with the venue, sort out decisions around printing & hoodies, and making sure we have the resources to pull everything off. Much of this would be a lot more more difficult if it weren’t for the help we got underways; Stig Palmquist for handling all things related to food; Oslo Perl Mongers for letting us use some of their banking resources; The French Perl Mongers for handling invoicing.

Philippe Bruhat (BooK)
“Considering how late we started the actual work, this went awfully well! This is the first time we deliberately organised the summit remotely, and it confirmed the importance of having a good local team.” — Philippe Bruhat (BooK)

Venue

Our venue was Teknologihuset in Oslo; They’ve been incredibly supportive throughout the preparations and during the event. I can’t say enough good things about the support they’ve given us.

Thanks to them, we had plenty of rooms, workspaces and areas to work and discuss. The network worked spotlessly, access to the building was exactly what we need. All this within a budget that allowed us to pull off a PTS in one of the most expensive cities in the world. We decided it was appropriate to declare Teknologihuset as a Venue Partner, for the first time in PTS/QAH history.

But when we mention Teknologihuset, we should also mention Macsimum for being a fantastic partner. These two organisations are joined at the hip, and supported us also with graphic design resources, helped us with printing hoodies and creating posters and roll-ups.

Todd Rinaldo
“The venue is very nice, the wifi is awesome, and great to be able to have lunch without having to leave.” — Todd Rinaldo

Breakfast & lunches

As for food, we focused on having coffee, snacks, fruits and vegetables available at all times, and offer at least breakfast and lunch for everyone at the venue. Three of the days we also organised supper, and all meals except for the anniversary dinner were in-house so everyone could quickly get back to work. We even got (quite well-received) lasagna lunch thanks to a generous donation from FastMail.

Olaf Alders
“The food is great! Loved to finally try brown cheese, and really liked the variation; The different kinds of breads for breakfast, the pastries, the “Skolebrød”, and BooK’s portions of Lasagna.” — Olaf Alders

Anniversary Dinner

With 10 years since the first QA Hackathon (now PTS), we felt it appropriate to organise a better dinner at a local restaurant, Sofies Mat og Vinhus. We had a three course dinner with drinks, and a very pleasant opportunity for several of the attendees to give both prepared and impromptu speeches. Salve chose to tell a classic Norwegian folk tale about conflict resolution and stubbornness.

Andreas König
“I really liked that we went to a local and not touristy restaurant for the dinner. We filled a large portion of the place, but it still felt like we were eating with the locals. The salmon was great, and I liked the beer and the company. I enjoyed myself very much.” — Andreas König

The Atmosphere

One important thing we were aiming for was creating a positive atmosphere with “Strong opinions, Weakly held”. The Perl Toolchain summit is a place for working and good relationships, and while productivity is the main focus, we also paid attention to make the social aspects of the event as frictionless as we could. Good food and drink, a few social gatherings in the evenings, and some friendly reminders of giving someone a hug are all part of this.

Babs Veloso
“Relaxed, Googly, Friendly, easy to get in touch with each other. The size of the group and place is very good. It’s easy to be creative here; We don’t feel the time passing! And smart people make all the difference.” — Babs Veloso

Productivity

One major goal of ours was to make sure everyone had reasons to stay at the venue and hack until they felt “finished for the day” and still have enough tuits left for socialising. On-site food, plenty of snacks (much due to our snacks sponsor, Oetiker+Partner), and coffee and tea – all this gave people extra reasons to stay at the venue and continue working.

Sawyer X
“The benefit of this event for me is that it provides a place for everyone who is necessary to resolve complicated issues, to sit and focus on resolving them. If you think about serious challenges, with multiple people, systems, skills – all these are gathered here in one place with all hands on deck. It allows us to find solutions quickly, and find new and novel approaches that we couldn’t by ourselves. While a typical team at a company would produce a product in a few weeks, we produce several products within a few days here with all the know-how and experience that takes years. Also, resolving conflicts within infrastructure issues can take years, but are handled here immediately. This «Get Stuff Done» approach is very invigorating.” — Sawyer X

The Sponsors and Partners

Finding new sponsors and partners is always a difficult task, and because of this we are always happy to hear it when long-standing supporters chose to continue sponsoring us. This year we changed the offer too, by adding a “Diamond” level partnership because of the incredible level of support we got from the NUUG Foundation (local partner) and from Teknologihuset (venue partner). They made it possible to organise this summit in one of the most expensive countries in Europe.

Still, the most important support we get are from the companies that actually use Perl in their daily business – those who see the long-term value of the Perl Toolchain Summit – First among those are Booking.com, cPanel, FastMail, Elastic, ZipRecruiter and MaxMind. Without them, we wouldn’t be able to invite many of the volunteers our businesses and communities so much depend on. Their continuing support is invaluable.

We also received welcome support from several other companies: MongoDB, SureVoIP, Campus Explorer, Bytemark, Infinity Interactive, OpusVL, Eligo, Perl Services and Oetiker+Partner. All of these made a difference in making the summit a success!

H. Merijn Brand (Tux)
“Firstly, I love that we have sponsors. I’m very grateful because they sponsor part of my trip. What I miss now is actual involvement from more of them. We have had very good experience with earlier sponsors sending very driven people, and I’d love to see more of this. Especially from companies that wish to demonstrate they understand how Open Source communities work, and how to interact with them.” — H. Merijn Brand (Tux)

Open Source as Neutral Ground

For me, the Perl Toolchain Summit is a fantastic event which embodies many of the best qualities of the Perl community.

  • We manage to improve important and useful tools, while spending appropriate amounts of attention on ensuring old code still keeps running with minimal change.
  • We may have heated discussions and still demonstrate to everyone that we’re actually on the same team and that we can show both grace and humility.
  • That we’re an Open Source community that involves businesses that depend on us, without becoming tied to just one company.
  • That the successes of Perl Toolchain Summit and other events like this give clear indication on how neutral grounds for developing our tools are beneficial for everyone.
  • That we’re far from done with both Perl 5 and Perl 6, and that improvements will continue to happen as long as we have people who care.
  • The Perl community has people who care a lot – enough to take a week out of their busy schedules just to improve the foundations the rest of us use to create value in our companies.
  • We can all can benefit from this work if we make sure to support these people as much as we can. Open Source projects like Perl depend on the interaction with our community, and anyone who is determined to work with the community is welcome to take part.

I hope you agree, and choose to help us make Perl better.

Days Since Last Time CPAN Broke: N

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