[PHP-DEV] [RFC] End PEAR Project Endorsement

Mailing Lists php.internals
1

Hey internals,

I would like to open the discussion to "End PEAR Project Endorsement":

Over the last months the state of PEAR was several times discussed here. Multiple people reached out to PEAR via direct and official channels; no finite solution could be found. About three months ago I started going through all previous discussions and old (not voted) RFC attempts; I don't see an unsolvable blocker. Hence, I drafted this RFC, and created a static mirror of the PEAR website (to keep the CLI working; infra team was consulted). After that, it once again was tried to find a cooperative solution (foundation also aware), and things given time to play out another two months -- with no finite result.

PEAR was a great effort, and we can all be grateful to the people who invested their time to make it happen.

However, times changed -- people use Composer. The PEAR site is partly broken, spammed, has very little activity, and as of recent happens to be unmaintained.

We win nothing by further stalling a decision; I believe we should stop the endorsement for PEAR.

This RFC attempts to address all open questions from previous discussions, and seeks to offer a balanced and practical solution.

---

Cheers
Nick

2

Hi Nick,

On 27 August 2026 04:36:50 BST, Nick Sdot <php@nicksdot.dev> wrote:

Hey internals,

I would like to open the discussion to "End PEAR Project Endorsement":
PHP: rfc:end_pear_endorsement

Thanks for putting this together and moving the conversation forward. I wholeheartedly support this course of action.

We win nothing by further stalling a decision; I believe we should stop the endorsement for PEAR.

I think this is the key: a lot of the comments on previous discussions were about "giving a chance" for one or other individual or group to revive the website. Multiple attempted contacts were made, and many months have gone by, with nobody reporting a positive result.

If that's not long enough, how long is? If the site stays alive in its current state for 10 years, it will continue to be exploited by spammers and probably worse. That's not in anyone's interest.

-

Coincidentally, Andrew Nesbitt, who writes tooling and analysis comparing different packaging systems, wrote a recent post about approaches to sunsetting: <https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html&gt;

One of the points he discusses is that freezing a channel rather than taking it offline means that security vulnerabilities are also frozen in place, with no way to supersede them for anyone still using the old tooling.

I think readonly is probably the right approach in this case at least in the short term, but actively sunsetting later is maybe something to consider.

-

My only other specific comment is that looking at the draft mirror, only some of the bug reports seem to be there. I'm guessing this is because of the problem Juliette reported a while ago that many of them have started showing an error about unconfirmed email addresses.

I wonder if being logged in as a package maintainer would be enough to see them, or if they're gone for good unless someone with admin access appears. Does anyone have an account to check?

Thanks again - and thanks also to everyone who has contributed to PEAR in the past, and everyone who has tried to reach someone to bring it back to life.

Regards,

Rowan Tommins
[IMSoP]

3

Thanks Rowan,

On 27.08.26 20:17, Rowan Tommins [IMSoP] wrote:

One of the points he discusses is that freezing a channel rather than taking it offline means that security vulnerabilities are also frozen in place, with no way to supersede them for anyone still using the old tooling.

I think readonly is probably the right approach in this case at least in the short term, but actively sunsetting later is maybe something to consider.

Agreed. The infra team also would prefer sunsetting at some point; it's in the future scope of the RFC.

Also, it's mentioned in the RFC but probably worth to be highlighted here: only 6 packages are still publishing to PEAR.

- 3/6 are PEAR infra packages
- 2/6 are non-PEAR infra packages (but by a PEAR Group member) were recently marked as unmaintained

Which makes it exactly one single independent package that is still maintained (legend!):
Net_SMTP (which is also on Packagist).

I think we can safely say that security is not a very pressing concern in this very situation; and that keeping the CLI alive for a while is to demonstrate good manners rather than serving high demand. :slight_smile:

My only other specific comment is that looking at the draft mirror, only some of the bug reports seem to be there. I'm guessing this is because of the problem Juliette reported a while ago that many of them have started showing an error about unconfirmed email addresses.

I wonder if being logged in as a package maintainer would be enough to see them, or if they're gone for good unless someone with admin access appears. Does anyone have an account to check?

Correct. Only bugs that are accessible on the PEAR website are in the archive. Rather than archiving and linking error pages with no relevant content, I omitted those. Saves resources and clicks. Some of the pages could be recovered from year 2007 snapshots on archive.org, but that's quite some extra work. Since the PEAR site itself no longer has those pages, it’s probably:

A) reasonable to expect anyone who wants to look up such old bugs to visit archive.org themselves
B) not the job of the archive to me more complete than its source; hence, out of scope for the RFC

That said, if an admin would provide a database dump I am keen to backfill missing bugs at any time (before or after the archive goes online).

--

Cheers
Nick

4

On Thu, 27 Aug 2026, Rowan Tommins [IMSoP] wrote:

On 27 August 2026 04:36:50 BST, Nick Sdot <php@nicksdot.dev> wrote:

>We win nothing by further stalling a decision; I believe we should
>stop the endorsement for PEAR.

I think this is the key: a lot of the comments on previous discussions
were about "giving a chance" for one or other individual or group to
revive the website. Multiple attempted contacts were made, and many
months have gone by, with nobody reporting a positive result.

If that's not long enough, how long is? If the site stays alive in its
current state for 10 years, it will continue to be exploited by
spammers and probably worse. That's not in anyone's interest.

-

Coincidentally, Andrew Nesbitt, who writes tooling and analysis
comparing different packaging systems, wrote a recent post about
approaches to sunsetting:
<https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html&gt;

One of the points he discusses is that freezing a channel rather than
taking it offline means that security vulnerabilities are also frozen
in place, with no way to supersede them for anyone still using the old
tooling.

I think readonly is probably the right approach in this case at least
in the short term, but actively sunsetting later is maybe something to
consider.

I agree. I think we should commit to leaving it on for a specified
amount only (a year), and then also turn off the archival variant of the
site. We can move a tarball onto our museum.php.net property for
archeologists.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud
Author of Xdebug. Like it? Consider supporting me: Xdebug: Support
mastodon: @derickr@phpc.social @xdebug@phpc.social

5

Hey everyone,

On 27.08.26 11:36, Nick Sdot wrote:

I would like to open the discussion to "End PEAR Project Endorsement":
PHP: rfc:end_pear_endorsement

Got news. The tl;dr is that Chuck Burgess from PEAR got in touch with me (and also Elizabeth from the foundation). He did let me know that he is good with looking at sunsetting the website and removing PEAR from PHP source.

This is great, because A) everyone involved agrees on the goal and B) this makes the vote a formality.

He said he doesn't read here, but anyway from me a thank you to Chuck!

That said, I would soon bring this to vote -- so this mail could be seen as my "intend to vote" mail. However, there is one detail I would want to double check with you all. The RFC currently has this sentence:

> Attempts to find solutions with PEAR maintainers, directly and through official channels, did not lead to results.

Given that Chuck now got in touch and is in favour, I am not happy leaving this sentence unchanged in the RFC. I'd much rather remove it (or strike it and amend the agreement?).

The question is, when the "Proposal" section remains explicitly unchanged does it count as a minor change? Given the state of the PEAR website, and that the vote will be a formality, it would be pity to have to wait another two weeks to open the vote. Thoughts?

Since this is a policy question I added Tim in CC.

--

Cheers
Nick

6

I would consider that a Minor change, so 1 week cool down, and you can post an intent to vote basically any time during that week as it has a 1 week allowance.

7

On 07/09/2026 20:24, Nick Sdot wrote:

Got news. The tl;dr is that Chuck Burgess from PEAR got in touch with me (and also Elizabeth from the foundation). He did let me know that he is good with looking at sunsetting the website and removing PEAR from PHP source.

That's great that someone finally got in touch. Does he have access to provide a database dump, so we can fill in the missing bug data?

This is great, because A) everyone involved agrees on the goal and B) this makes the vote a formality.

Unless you know something I don't, Chuck's agreement is just one vote, not any kind of final authority. He is listed at The PEAR Group as one of eight members of "the PEAR Group", so in theory the other seven could decide they want to continue the project. In fact, the Group was supposed to be re-elected annually, so even their collective authority is shaky if anyone really wanted to replace them.

In practice, he's the only person involved who anyone has managed to track down, and even that took several months, so I think we're safe to say nobody's that interested.

In other news, I noticed the mirror you created didn't yet have much styling, so I've put together a quick PR copying in the colours and basic styles from the existing site, plus an idea I had for a "locked PEAR" logo: Add some styling based on the existing PEAR site by IMSoP · Pull Request #1 · NickSdot/pear · GitHub

Thanks again,

--
Rowan Tommins
[IMSoP]

8

Hey Rowan,

On 08.09.26 06:17, Rowan Tommins [IMSoP] wrote:

That's great that someone finally got in touch. Does he have access to provide a database dump, so we can fill in the missing bug data?

That was brought up. Unfortunately, the user accounts are gone. Hence, the bug data cannot be provided.

This is great, because A) everyone involved agrees on the goal and B) this makes the vote a formality.

Unless you know something I don't, Chuck's agreement is just one vote, not any kind of final authority. He is listed at The PEAR Group as one of eight members of "the PEAR Group", so in theory the other seven could decide they want to continue the project. In fact, the Group was supposed to be re-elected annually, so even their collective authority is shaky if anyone really wanted to replace them.

Chuck is the one who had the authority to archive the repos in the PEAR GitHub organisation.

Also, allow me to highlight the "Non-goals" section of the RFC:

> The goal is not to take over the governance of the independent PEAR package ecosystem. *If an independent PEAR team wants to continue PEAR as an active project, they remain free to do so under domains they control.*

In practice, he's the only person involved who anyone has managed to track down, and even that took several months, so I think we're safe to say nobody's that interested.

That too, yes.

In other news, I noticed the mirror you created didn't yet have much styling, so I've put together a quick PR copying in the colours and basic styles from the existing site, plus an idea I had for a "locked PEAR" logo: Add some styling based on the existing PEAR site by IMSoP · Pull Request #1 · NickSdot/pear · GitHub

Thanks, Rowan! I am fine with that. One thing I'd add: I think having the "locked PEAR" is nice. Not sure about the favicon change. It's will be a The PHP Group hosted archive, not the successor of the PEAR project. Keeping the PHP favicon feels more sound to me, personally. But I happily leave that decision to you and others (infra team?).

---

Cheers
Nick