a call to sponsor the Perl Toolchain Summit

[book]

I planned to publish this on my personal blog on blogs.perl.org.
@oalders suggested to make it an article on perl.com.

[oalders]

@briandfoy do you have any thoughts on this? It would be nice to ensure we've got the right vibe here. PTS is not yet in danger, but the amount of required funds is pretty significant.

[briandfoy]

Well, since you've asked, here are some thoughts, which I've mostly kept to myself. Any activity needs to justify itself through concrete value. There's nothing in this announcement that tells anyone how the world will be different or better after the conference, and what value any sponsor would see for their own interest.

There is Olaf's 5 Reasons, but as a hypothetical sponsor who probably mostly has remote workers, I wouldn't care about any of those reasons. We are used to getting money because our sponsors had too much of it. For those of you who haven't been through the low part of the economic cycle before, money is going to be tight for several years and you'll have to work harder to get it.

There are several concrete things that PTS could do, and, having been to a couple a long time ago, deciding that list or organizing when you get there is not that interesting to people who will give you money. This shouldn't be a self-directed hackathon. Or, it can be, just without other people's money.

First, ask people what they need Perl or CPAN to do better. Figure out the pain points, and make those not painful. This should be an ongoing activity with a rolling list of concerns. The problem currently is that Perl is shedding people who feel empowered to do anything and people are catching on to that. You can't shake down companies for money when their recent experience is that their issues and pull requests receive no response or languish in purgatory.

I don't care what people want to work on; I care about what I want fixed. As the hypothetical sponsor, my money means my choice. Consider the Hollywood adage "two for them, one for me". Likewise, Milton Friedman's "other people spending my money on other people".

There are a variety of high-value pressing issues that the Summit could address not just in conversation but real activity, and some that would require tough decisions. Each of these things are critical for the Perl ecosystem:

• Fix CPAN Testers, which suffers from single-maintainerness. Let's figure out how to spread that load. It's mostly a static website with something the needs to generate static webpage. See https://www.reddit.com/r/perl/comments/1j3xpxc/what_is_going_on_with_cpan_testers/ (and, the new HTML presentation is less than awesome for me).
• Figure out what's going on with CPAN.pm. Although there was a 2.38 hot fix release, overall the repo is apparently abandoned with no response from maintainers to any issues or patches. I've forked cpan just so I can fix my own code: see Should I fork the cpan script? andk/cpanpm#187.
• Likewise, cpanm and carton are on shaky ground after a complete backend rewrite stalled.
• There are many good things the CPAN Security Group are doing, and @sjn's work on SBOM is becoming more critical. Perl needs a way to generate that stuff with almost no thought from module maintainers. Notice this mentioned in CPAN unexpectedly changed permissions andk/cpanpm#192
• Figure out service level guarantees for things like the Perl Toolchain Gang. If there can't be some better project management there, why should anyone give this summit money? For example, there's Don't normalize versions in provides hash Perl-Toolchain-Gang/CPAN-Meta#139 that's approved but unmerged, and I have to workaround in a few places. As a sponsor, I want the confidence that things will be fixed, responded to, and cared about. I think the bystander effect is preventing progress because no one takes responsibility. Sort that out.
• Figure out how to make PAUSE use SSH keys for uploads, or GPG signing, or whatever. GitHub Attestations are very easy, and uploading from GitHub releases have some identity info that uploads could leverage for greater confidence.

Publish the agenda right now, commit to having a solution at the end of the conference, and then commit to implementing the solution in one month (or some reasonable time). Then deliver. That is, maximize time together for solving the problem instead of making the list of problems.

If you think you can only do one thing, only do one thing. We have, as a group, enough software life cycle experience to succeed, and we just have to decide to succeed.

[mohawk2]

I think the above list is a set of important things that need doing, and serves as a pretty good agenda for this PTS. Publishing that as the aim of it sends an important message about a focus on solving people's (and companies') real problems and needs.

[Leont]

Fix CPAN Testers, which suffers from single-maintainerness. Let's figure out how to spread that load. It's mostly a static website with something the needs to generate static webpage. See https://www.reddit.com/r/perl/comments/1j3xpxc/what_is_going_on_with_cpan_testers/ (and, the new HTML presentation is less than awesome for me).

This is already on the radar AFAIK.

• Figure out what's going on with CPAN.pm. Although there was a 2.38 hot fix release, overall the repo is apparently abandoned with no response from maintainers to any issues or patches. I've forked cpan just so I can fix my own code: see Should I fork the cpan script? andk/cpanpm#187.
• Likewise, cpanm and carton are on shaky ground after a complete backend rewrite stalled.

Frankly, I believe we need a new CPAN client. CPAN.pm is collapsing under the weight of 25+ years of development. cpanm was always a minimalistic one person project that is difficult to stretch much.

I have already been gathering ideas and talking to a few people about their needs. It's definitely not a "will be done at the end of PTS" kind of thing but I do hope we can get a consensus on where to go and a start at implementing it.

Figure out how to make PAUSE use SSH keys for uploads, or GPG signing, or whatever. GitHub Attestations are very easy, and uploading from GitHub releases have some identity info that uploads could leverage for greater confidence.

We have been discussing such things in the CPAN Security group, but doing this well is quite hard actually. The real difficulty is not signing, but key management.

[ferki]

TL;DR

I share the view of @briandfoy about potential sponsors likely requiring clear, specific advantages to justify their financial investment. While some sponsors may already know why they support PTS, uncertain ones may need more convincing arguments to aid them in making their decision:

• If we may share a list of potential topics collected, that may serve as a valuable aid already.
• If sponsors get to add their topics to the list, or can signal interest by voting, that may prove interesting too.
• If we possibly commit to working on the “top N with most impact” in advance, that may worth even more.

Longer version

About pain points

Figuring out what decision-makers may need to make a decision

Knowing the actual pain points enables better targeting of messages, which in turn helps convincing the sponsors.

I expect two main cases leading to sponsoring:

1. Decision-makers (who can actually sign-off spending money on sponsoring) would need to clearly connect the dots between spending part of their budget and their business goals – generally speaking, they need to see the return on their investment.

2. A person approaching their organization and asking them to sponsor PTS, would need to convince a decision-maker to actually spend the money – see the previous point.

That decision-maker may not find “We use Perl and CPAN, so PTS is good for us” a good enough reason to sponsor, and also justify the investment towards their own supervisors.

Something like “Remember when had to delay our release because CPAN Testers was down? PTS works on fixing that, and ensuring it won’t happen again” may have more convincing power.

Ideally we’d learn their own words about their own experience, and match the call-for-sponsors message to include the top N pain points, for example.

About my approach

What I started out with

What I decided to follow in my communication so far is a mix of the following:

1. State what I intend to work on (=How I can help?), like “I look forward to joining the work on critical systems, like CPAN Testers, and MetaCPAN, ensuring their reliability, performance, and sustainable maintenance” -> using my own pain as a starting point, seeing others have similar experience

2. Call for actions (=How you can help?)

   • we need sponsors, please consider supporting us -> aimed at (reminding) early sponsors, who already made a decision, but did not take action yet
   • share this message, so it spreads -> the more the merrier
   • share your challenges, even privately, so we know what to work on -> aimed at collecting pain points, so I can learn what to address, and also what to write in my next post

[book]

@briandfoy thanks for your long comment, this definitely brought some useful insights.

I'll add a section with some of the topics that will be on the agenda (and what problems we'll try to solve).

This conversation also confirms what I already knew: that the organization of a PTS is more than just finding the venue and arranging for the people to come. It's a year-long endeavour, and the current organizing team is definitely too small for that.

[book]

After another reading, I think this article is good to go.

[ferki]

After another reading, I think this article is good to go.

Thanks, @book, for refining and improving the text! 👍

I also read it again, and whenever I felt my flow interrupted, I left a comment for your consideration (2 typos, and one potential rewording.)