Project status?

[systemed]

It seems to be a reasonably open secret (by which I mean SOTM bar chat ;) ) that Mapbox is currently putting most of its development efforts behind Valhalla; and that many of the developers formerly working on OSRM are no longer involved with it.

From a distance it looks like OSRM is in "maintenance mode", which is obviously much better than being abandoned, and it's good to see PRs like #5197 moving the project on. Nonetheless the fast pace of development since 2013 has evidently abated for now.

OSM data does (slowly) evolve and if OSRM is to continue to be useful then it'll need to keep up with this. Much of this can be achieved via profiles, and keeping these up-to-date is fairly trivial, but there are some more significant data issues which will require real engineering commitment (I'm thinking in particular of #4439 to address the increasing number of multiple-via-way restrictions, but there will be others).

So it would be good to have a steer as to the future direction of the project. Does Mapbox intend to continue maintaining OSRM in perpetuity, or only until Valhalla reaches feature/performance parity, or...? Is there any interest in moving it to the community (a la CartoCSS)?

(FWIW I'm not concerned for cycle.travel, which uses an extensive fork of 4.9 and which is very unlikely to return to trunk, but I do use current versions of OSRM for some contract work. Looking at the issue tracker here, there is still a lot of interest in OSRM and people are building solutions on top of it.)

In any case, thanks for supporting so many great improvements over the last five years and being good stewards of the project!

[jcoupey]

only until Valhalla reaches feature/performance parity

Judging by both projects choices and focus, plus valhalla/valhalla#1514 (comment), it seems pretty clear that for some use-cases feature/performance parity will never occur. I'm thinking about fast computing times for huge matrices, a killer in OSRM and probably one of the reasons for part of the ongoing interest.

Not a problem, just something to keep in mind.

[systemed]

From a distance it looks like OSRM is in "maintenance mode", which is obviously much better than being abandoned

18 months on, I think we can probably say that OSRM is to all intents and purposes abandoned. That's fine - priorities change and I certainly wouldn't mean this as a criticism of anyone. But Mapbox have evidently ceased development and promotion, yet the Project-OSRM organisation is still essentially Mapbox employees or alumni.

At the least, it would be good to have a maintainership model where there's some assurance that decent patches (even if trivial) are likely to get merged. At present, my reading is that potential new users are unlikely to use OSRM because it's been abandoned; therefore there are fewer patches; therefore people are less likely to use OSRM; etc. etc.

Mapbox has successfully transitioned legacy products to community maintainership in the past (carto, Tilemill) and it would be good to see the same happen here.

(For clarity, I'm personally happy to take on issue-gardening, profile stuff and so on, but my C++-fu and graph theory knowledge are certainly not strong enough for me to be sole maintainer!)

cc @danpat @DennisOSRM @jcoupey @datendelphin @frodrigo

[frodrigo]

Yes, I will be nice to let the community gardening or maintaining the project. The are still some people around, and using it. At least dealing with small issues or PR will be good. I will be part of this.

[danpat]

As I haven't really heard from any of the old crew in a while (many have moved on from Mapbox), I'm going to grant myself the temporary authority to approve more community involvement.

Feel free to JFDI on whatever tasks you think need doing. I spend what time I can answering the odd ticket, but don't have the bandwidth for anything much more than that - certainly not the hours it takes to implement new features or fix complex bugs (or roll a new release for that matter).

I'm happy to grant maintainer access to anyone who can promise they'll try not to totally break everything :-) Happy to provide advice/feedback to any questions folks have about why things are the way they are.

OSRM has lots of historical standards/practices in place, but I don't think any of them are set in stone, given that the primary creator of most of those things, Mapbox, is no longer invested in the project. It should morph to suit the community of folks that are still using it.

[systemed]

🚀

That's great. Thank you (and thanks for keeping the lights on in recent months!).

I'm happy to become a maintainer so that I can keep the issues under control, make small fixes to profiles and docs, and help to prepare a release (I think we could do a 5.22 pretty easily, and the release process looks sane). I won't do any open-heart C++ surgery, at least not without consultation/review with others.

@frodrigo, I think you might have access already. @jcoupey and @datendelphin, would you be interested?

[jcoupey]

@systemed yes I'm interested in taking a part in a community effort to maintain the project. I'm using it right now and would like to keep using it with confidence in the future.

I can't commit to any huge C++ work within OSRM, due to bandwith and because I don't have a deep knowledge of the internal implementations. But I can take part in peer-reviews and help with handling issues and questions.

[datendelphin]

Sure I'll help, time permitting.

[frodrigo]

@danpat Any news on allowing more commiter on the project?

[jcoupey]

The questions raised in this ticket are more than ever relevant, given that:

1. Lots of people use and love OSRM, and the various technical questions popping out show that newcomers to routing still consider it as a valuable option;
2. Even in maintenance state, OSRM still provides an opinionated trade-off between flexibility and computing times that is definitely and advantage over other routing engines for some use-cases;
3. There are significant external (read unrelated to Mapbox) contributions, see e.g. Add support for multiple via-way restrictions #5907 that touches the core codebase internals and addresses a significant feature.

Mapbox has done a tremendous job pushing OSRM development to it's current state, but now the lack of clear governance rules is to some extent a problem. The worst scenario in the long run would be that the current situation deter external contributions and reduce trust in the project's future.

On the other hand, the switch to a community-based hosting for the project demo server has been completed successfully, so hopefully there are options on this side?

[systemed]

Thanks @danpat!

[danpat]

Yeah, sorry about that - I have the attention span of a goldfish, and adding more members to the team just slipped off my radar.

[SiarheiFedartsou]

Hey, is someone there?
The problem I currently see is that project is still being widely used by community, but there is lack of people in "official" OSRM team who have time to review PRs or do some simple things like turning off CI check.
Can we do something with it? I would at least "promote" folks from OSRM team who is still active to be able to do everything with this project(like enabling/disabling checks, adding integrations, doing releases, inviting people to the team etc). I would propose @mjjbell as most active person from the team recently.
WDYT?

[mjjbell]

We can make an "official" community fork, although it would be a shame to do so given the project is already an independent Github organisation, and this repo still continues to maintain its inertia.

There are also question marks about ownership of other parts of the infrastructure. e.g. Project-OSRM/project-osrm.github.com#26. In which case it might be simpler to make a clean break.

[DennisOSRM]

Well, then let's get cracking at this things. 😉 Questions are basically who and what needs to be done.

Happy to work with you to get the little annoyances fixed and to give folks from the community proper privileges to merge changes.

[mjjbell]

Thanks Dennis.

Two immediate fixes that will help

• Disable AppVeyor in the Github PR status checks
• Update project-osrm.org DNS to support HTTPS

Beyond that, can I humbly request that I be bumped to an admin role, and @SiarheiFedartsou is added as a member. That should unblock our future progress.

[DennisOSRM]

Just did the above things:

• @mjjbell is maintainer now,
• DNS entries are updated (website works now)
• @SiarheiFedartsou added to Team-OSRM

Let me know if you need anything else.

[mjjbell]

Many thanks @DennisOSRM!

[mjjbell]

We will need the NPM credentials to publish the OSRM package for the next release.
Is it possible for these to be shared? Judging by the package collaborators, it might still have some Mapbox linkage.

[DennisOSRM]

Apparently, I was locked out of this in the past. Thanks Mapbox. 😒

[SiarheiFedartsou]

Judging by the package collaborators, it might still have some Mapbox linkage.

@danpat as you are probably still at Mapbox, will you be able to somehow help here?

[mjjbell]

The new osrm-backend containers in Github Packages are private by default.

@DennisOSRM would you be able to switch them to public access?

https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#configuring-visibility-of-container-images-for-an-organization

[DennisOSRM]

Should be public now.