Hey internals,
I would like to open the discussion to "End PEAR Project Endorsement":
https://wiki.php.net/rfc/end_pear_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
Hi Nick,
Hey internals,
I would like to open the discussion to "End PEAR Project Endorsement":
https://wiki.php.net/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
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]
Thanks Rowan,
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. :)
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
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.htmlOne 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: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Hey everyone,
I would like to open the discussion to "End PEAR Project Endorsement":
https://wiki.php.net/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
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.
Hi
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.
I agree. This change in circumstances seems substantial enough that it
might cause folks to vote differently, without changing the actual
proposal.
Best regards
Tim Düsterhus
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
https://pear.php.net/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: https://github.com/NickSdot/pear/pull/1
Thanks again,
--
Rowan Tommins
[IMSoP]
Hey Rowan,
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
https://pear.php.net/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: https://github.com/NickSdot/pear/pull/1
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
Hey Rowan,
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.
That's a pity. In hindsight, if we'd acted sooner we could have rescued that content before it disappeared; but we couldn't have known that.
Chuck is the one who had the authority to archive the repos in the PEAR GitHub organisation.
I would make a distinction between technical ability and moral authority. For example, many people have access to commit to the php-src repo; they have the ability to make whatever changes they want, but they only have the authority to make changes within our agreed process.
In this case, Derick has the ability to repoint the DNS for pear.php.net, but holding this discussion and an RFC vote is a way to grant authority.
Chuck has apparently been keeping parts of the PEAR project running after others drifted off, and I thank him for that. If he disagreed with the plan, that would have been significant - but so would anyone replying on the four PEAR mailing lists I posted to last October. Hearing that he is in favour is welcome, but it doesn't change much in terms of moral authority.
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?).
Yes, I kept the favicon part in a separate commit in case it was controversial; feel free to cherry-pick the main styling and skip that one if you prefer.
Cheers,
Rowan Tommins
[IMSoP]
Hey Rowan,
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: https://github.com/NickSdot/pear/pull/1
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?).
I don't care what the favicon is, as long as there is one.
cheers
Derick
Hey everyone,
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?).
I made the following changes to the RFC:
- Removed the mentioned sentence and added a section to reflect the new
situation. - Removed "Future Scope" and added explicit timeline to the proposal
(coordinated with Derick).
This is a major change, which means the discussion remains open until at
least 2026-09-27.
Additionally, there is another good news. Chuck from PEAR made an effort
to recover the missing bug pages and was successful. Thankfully, he now
can and will provide us with everything we need for the archive.
Cheers
Nick