@AngocA, you managed to encapsulate in a single post what the UN just devoted an entire week to exploring. Governance and maintainership issues are not unique to OSM. Acknowledging that can help us understand the issue better without making people get defensive about it. Unfortunately, I’m sleep-deprived and busy at a conference, or else I’d respond more fully to your line of questioning, but I’ll start with some of the more basic questions you asked to get those out of the way.
The important thing to understand is that “core software” has always been a very nebulous term, just like in many organizations and projects. After I took the Core Software Development Facilitator role, I realized the wiki didn’t even define this term, so I belatedly wrote up a stub that highlights some common perspectives about what to consider “core”.
So far, in this CSDF role, I’ve taken the approach of prioritizing my attention on some projects over others based on their proximity to day-to-day operations and some other factors like compliance. This has more to do with the mechanism through which the role is being funded than any single right definition of “core”. On occasion, people have asked me for help with more peripheral projects. My response is to try to connect them to people who are in a better position to help – as this community ought to do anyways.
Of course this really isn’t about me – what you’re talking about is about how we move forward as a whole community – but hopefully that gives you an additional data point for something that doesn’t have a clear answer.
The OWG runs instances of several core software projects, among other things. As the name implies, they’re more focused on keeping things running smoothly than blue-sky feature development, which would more naturally involve the Engineering Working Group. The SDRP is charged with arbitrating disputes in specific software projects, not necessarily core projects. (Only iD is within its purview currently.)
The OSMF is the organization that convenes these working groups and panels. Or did you mean to ask about the OSMF board’s responsibilities?
Anyways, that’s how things are organized on paper. But we’re a big loose collective of projects, so sometimes things get done because people have ignored this structure and made their own arrangements.
If you mean this in the context of defining “core software”, then no, the only process is to convince enough of the community to start referring to it as core software.
But it sounds like you’re asking more broadly about the software lifecycle for OSM software. Various parts of the OSM tech stack have gone through replacement cycles in the past, like Osmarender giving way to the Mapnik style, OSM Carto, and vector styles, or the old Gazetteer giving way to Nominatim. I’d love to hear from the folks involved with those transitions about the challenges they had to overcome both technically and socially, and any lessons they took away from that experience.
In the meantime, since website design has been top of mind in recent days, here’s one perspective from the people at Mapbox who worked on the last big redesign:
