Why not drop the TER completely? Actually the TER could be a simple static website that only shows the filtered results of the packagist API. In addition I could imagine that it could be beneficial to

work together with packagist.com to ensure used packages are not unpublished

work together with coders.care / marketplace so an extension can be replaced with a maintained one without changing the composer.json

Of course that means that the Extension Manager in the TYPO3-Backend also needs to change. Maybe it is possible to completely use composer under the hood? Then no TYPO3-specific solution is needed anymore. A those kind of infrastructure could be also shared with other open source or commercial products.

A first step of course could be to automatically transform Git-Repositories to legacy extension archives, as described in the budget idea. But I think that it needs more than 5,000€ to accomplish this goal.

That are some of the reasons that I just think about, but there are definitely more.

Yes, we are planning to rebuild the TER to create a beautified packagist image with some more meta data than packagist currently has. But that’s a process for over a year and should be well communicated what people has to do for the switch.

I do not get why it is so clear that we are talking about how to fund the server team to deprecate TER. We are trying to reduce infrastructure not replacing one part with a new one.

This idea, which I fully support btw., is about removing the need for TER entirely. In the long run one can therefore expect that funds that previously went to the server team become unallocated again.

In the meantime I’d suggest that TER will not be enabled to host extensions for TYPO3 10, rendering 9 LTS the last release TER would provide extensions anymore. We are already in the situation that 9 only provides subtree-split sysexts via Composer (which is good) but still a full ZIP package. IMO that does not make any sense.

I agree with @tomalo.stuttgart that many installations do not use composer yet. Therefore, please invest said money into beating the big drum for Composer-based deployments. Or even better: fund the entire removal of the code base handling legacy extension management out of TYPO3.
Of course, this is not about talking down your work on TER, but - seriously - its days are IMHO over.

The Server Team is spending money in infrastructure. The TER is one of 25 servers (https://status.typo3.org), so you won’t get that much money to invest in big drums

Beating big drum for composer is good but most of the TYPO3 domains are hosted on hosting partners not providing composer or the possibility to use it via CLI. Therefore a UI in the TYPO3 Backend for composer should be mandatory.

Why generally shutting down TER, why not showing just all composer packages with type “typo3-cms-extension”. Every CMS has an overview of packages, this is the first place a person is looking for.

I do not get why it is so clear that we are talking about how to fund the server team to deprecate TER. We are trying to reduce infrastructure not replacing one part with a new one.

Since I’m the leader of the server team, I’d like to point out that this project is a nice idea by Thomas and was not initiated by us. I also don’t see a necessity that only the server team can do that.

We will certainly host whatever will be the result of this project, but I don’t insist that anyone of the server team will implement it. @tomalo.stuttgart do you agree?