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.
The supplied component is not owned by the first or the second party.
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)
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.
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.
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 well-reasoned contributions that day you eventually decide to do so.
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.
After all, when you depend on them, you might as well rely on them.
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.
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.
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.
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.
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.
Maintainers’ mental health and well-being is also a dependency.
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.
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.
Ecosystem tooling and infrastructure communicates this metadata to their downstream users and consumers.
(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.
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.
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!
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?
Things seldom happen by themselves, but when they do, there is luck, help and sweat involved. — Unknown
If you ever find yourself at the Chaos Communication Congress, you may eventually snap out of your awestruck haze to realise you probably want a memento to bring home. This happened to me at last year’s event, and while I usually go for a t-shirt or a hoodie, this time I found something unexpected and much, much better!
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.
“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.
“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.
“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.
“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.
“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.
“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.
“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.
