Again I would ask, how does that invalidate the article’s premise that the core software API hasn’t changed in ~10 years?

What other significant, widely used software, depends only on the “ecosystem” for APIs development, while having no active API efforts in the core project?

I can think of none. Maybe some examples exist somewhere, but at the least it’s unusual, especially given the overall context of the article.

The core editing API hasn't changed in years. HTTP/1.1 come out in 1997 and HTTP/2 in 2015. Was web programming in 2014 the same as web programming in 1998?

This discussion might be more productive if you laid out what you believe the OSM API being discussed already does and what you think it should do in addition to that.

And then you could lay out why those things should be done centrally rather than on separate servers. For example, there is a sophisticated data query api https://wiki.openstreetmap.org/wiki/Overpass_API that keeps up with edits within a minute or two but is free to lay out the backing database in a way that is optimized for queries and people can run their own instance and so on.

Oh yes, I agree. In fact, I’m taking a close look at the architecture, organizational efficiency and results to form an opinion of the bigger picture. Indeed, I haven’t, scratch that, can’t, even assert an opinion on the article as a whole without doing so.

Then how is this productive you ask? Because for now I’m only drawing much smaller conclusions, which also generalize to most actively developed software. Rich, well maintained APIs tend to be useful. As of yet I see no real explanation of why that doesn’t apply to OSM.

To start, not sure why you mention a central server vs. “separate servers”. SaaS users shouldn’t care, or ideally even need to know whether something runs on 10 or 100 servers.

Maybe instead of separate servers, you meant different companies? Knowing which organization is the provider of each service is paramount. For each provider it’s also important to know something about their business model, reputation, roadmap, and the pros/cons of using multiple providers vs. one stop shopping. It’s important enough that companies like Gartner are paid a truckload of money by SaaS users to analyze these details.

So back to my original point: Most significant and active projects benefit from investing in rich and well maintained APIs.

Take that fact, and add in a domain expert taking the time to write an article asserting it’s indeed a problem relevant to OSM. One person’s opinion is not always a smoking gun. But combined with the fact a 10 year old stale API is so unusual, and the fact that what other companies do is a red herring argument being made, at minimum it sure seems like a bright red flag that warrants better understanding of what’s going on over there.

I mention a central server vs. “separate servers”. because that's pretty much the only way you could come to the incorrect conclusion of 10 year old stale API.

There's a particular service running on some OSM servers that provides data to editing software and receives changes from editing software and applies those changes to the master database. The primary version number on that api is 10 years old. It has still evolved over that time. But it is not the entirety of the OSM API, it is the OSM editing API, which probably benefits from being at least somewhat stable.

I mean, I guess the basic data model could be changed all the time so that all the tooling had to chase after it, but the only big proposal along those lines is to add an explicit "area" type which would simplify some things (it wouldn't really create room for any new capabilities).

Take a look at the vector tile stack Mapbox has put together if you want to see a new way of working with OSM data that has come about over that same 10 year period. Mapzen and OpenMapTiles have also worked on vector tile stacks.