While I agree that the dev machine is not ideal for non-experimental projects, on the other hand there is a long tradition of services being run on it that are considered essential by large parts of the community. At the same time there is no concept from the ops side of things of moving such services to a different, permanent, home, or even taking over such services, so I guess it is what it is.
Further we have a volunteer that has offered to do the work to support the service, so I don’t quite see what the workload issue is supposed to be (at least not different than for anything else running there). I guess it would be nice if the OSMF provided a location to store backups, but that can be worked around too.
Back to the topic at hand: there are plenty of OSM-specific projects that are not really looking for external developer contributions, take for example the editor layer index, NSI and so on. These could easily (modulo CI) be hosted on such a service without loss of potential contributors, it could actually open things up the other way around.
The 2nd realistic use case (as I already pointed out) is to provide a secondary issue tracker for projects (likely in conjunction with a mirror of the github/gitlab repo) that can be accessed with the users OSM login. Obviously there is no guarantee that any projects will take up such an offer, but it would seem really low hanging fruit to provide.
3 Likes