It would be cool to arrange some kind of anniversary 
.
OSM-NG makes the best OSM platform, whatever happens after that is up to the God’s (and community’s) will. OSM-NG devs’ primary role is to show that we can do better.
Of course yes, I believe it will be a significant improvement for the whole ecosystem. I plan to start proposing this idea whenever the OSM-NG has all the core features set of the existing OSM + a live demo website.
If they say no because of XYZ, I will fix XYZ and try again.
The question is, what will you do if there is a fundamental disagreement between the operational requirements for replacing the OSM software stack and your vision for OSM-NG? Would you be willing to compromise and make those changes?
Here’s one huge likely blocker:
Any new implementation of the API realistically needs to be able to run in parallel to the old one initially to have some kind of trial and transition period. Having one big switchover day where all OSM servers are stopped, the database is migrated and then started again with a completely new implementation that has never been tested at that scale is extremely risky and should only be done for very good reasons.
The core architecture of OSM-NG seems to be incompatible with this.
Not to put too fine a point on it, this is my opinion, I’ve always seen the “Next” here as “Another.” What @Woazboat says is true. What we have (with TNG) is partial vaporware being dubbed Next by its author for a while now. Slow down, with jumping the gun, author. You haven’t written your masterpiece yet; we only have sketches so far. There never has been anything “Next” about it, except as part of your visioning for this project.
We listen. You propose a sort of “parallel universe” (to OSM’s existing, robust architecture) which has interesting thrusts in particular directions. So, we listen.
“This” (TNG of OSM in Python, so dubbed) is a construction project. It has some code written, it has some vision. OSM listens.
Please answer those excellent questions of @Woazboat, @NorthCrab . “I will fix XYZ and try again” is shown with actions, even as those words of yours (they seem humble and correct) are spoken.
“Whenever -NG has all the core features set of existing OSM + a live demo website” indeed. We’re a ways away from that. “Up to the community’s will,” well, of course, this almost goes without saying, and there, you said it.
Cool anniversary arrangements? Something must be born first. Keep gestating, please, there is interest where interesting things happen.
Let’s not confuse “a public demo that @stevea can play with” with “vaporware”. We all reacted quite skeptically to the original announcement, but from where I sit, I see:
There is certainly code that someone can check out of a github repository and run for themselves. Despite @NorthCrab’s flamboyant announcement style, ChatGPT-style prose, and over-use of emoji, describing his project as “vaporware” is quite unfair to this apparent group of community contributors that are earnestly working on it.
It appears that not only has @NorthCrab ignored the naysayers, but he has also come to be leading a community project with a small cadre of contributors. A better response would be “thank you”.
As I’ve noted previously, even if he fails, we lose nothing in the attempt, and may learn something from it.
I, for one, will be amused if we find ourselves in a situation where the official OSM software for something is demonstrably worse than a competitor project that is run by folks that aren’t in the “in group” that controls what software flies the project’s flag. In other words, what we have today with iD versus Rapid.
“Slow down” is bad advice to give on this or any FOSS project. What happened to the “do-ocracy”? He is doing. Sit back, pass the 
, and see what happens. If it fails, THEN you can fling the unpopped kernels at him. Until then, if you aren’t part of the solution, we have little to gain by poo-pooing people that have rolled up their sleeves and are trying to be.
And one last note, as a FOSS agitator and maintainer myself – publicity is necessary to gain contributors. We cannot simultaneously say “go off and do” but also “but be quiet about it”. He must be loud about it if he aims to achieve community participation.
So please, if this thread is bothersome, avail yourself of the dropdown box at the bottom of the thread:
I was trying to click the damn thing to get it off my screen, until I’ve read the whole post. 
Couldn’t agree more. To begin with, this all seemed like a side project that would go nowhere, and now we’ve got something that could potentially be what runs OSM in the not too distant future. There’s obviously things that might have to change before it could be seriously considered to replace the Rails port, but there’s always been difficulty getting people to contribute and maintain it, so maybe this is the answer to get more people contributing to the most crucial part of OSM.
I knew some would misinterpret my missive; it can be difficult to “do this” (ask someone to more precisely hit a precise “less hubris, please” target) with text-on-screen. If “vaporware” is either discouraging or incorrect, I apologize. There are aspects of over-sensationalizing though not necessarily under-delivering, more like over-hyping.
I don’t wish to be discouraging, quite the opposite: my tone included aspects of “keep up your work.” Aspects of “vaporware” are that deliveries are vague, late, cancelled, slow to materialize or fundamentally different in end results from what was promised to be (if it ever materializes).
By “slow down,” I meant with “jumping the gun” (at calling it “Next” or celebrating anniversaries when it is still under development). Some softwares take years to develop, I understand that (well); there is nothing wrong with lengthy development cycles (when its needed), unless it is accompanied by moving targets (and it can be difficult to hit a bullseye to please a community as large as ours) or is overly hyped. Chiming in that I’d like somebody else’s questions answered isn’t “poo-pooing.”
Being loud to trumpet a vision or garner support is fine. Being flamboyant? Well, not my style, but OSM isn’t about everyone reaching consensus about style. Tempered with humility, yes (and I’ve seen more recently; good).
And I do mean to say “thank you” to @NorthCrab , as this work isn’t easy and it is “good and interesting.” With powerful potential ramifications. So, thank you. Keep up your work. Good that you have built a cadre of contributors, that isn’t easy either. And as your “xyz being broken as the community sees it means we’ll fix xyz” is actually a great thing to say explicitly.
I agree it’s interesting to answer these questions. I’ve asked elsewhere before seeing this discussion. I think it’s ok not to have answers yet, but at some point it will be necessary to make a decision in order to decide what’s in scope for the project and what’s not.
Which brings me to another interesting point:
Do you mean a new codebase may help multiply topical forks of OSM? I had not even considered it possible or desirable, but sometimes things work out in unexpected ways. Maybe a good comparison is all the English Wikipedia forks, think Everipedia: people who used to edit there would likely have wasted their own and everyone’s time editing the English Wikipedia directly, but by working on a fork they may sometimes accidentally produce some article that ends up being reimported on the English Wikipedia.
If I weren’t the one who came up with this crazy idea, I would probably share sentiments similar to most of the chatters here. I completely understand that perspective, and the best I can do in this situation is remain quiet and continue building until it’s ready to show.
I want to approach this problem in two ways. First, for testing, OSM-NG will be tested on real data and may also run in parallel with the Ruby implementation, processing the same duplicate requests. Over time, it will collect sufficient information to identify any unexpected issues. OSM-NG will feature an amazing error collection system. Second, the migration scripts will be designed to migrate 99% of the data while the Ruby database remains online. A subsequent migration script will migrate the remaining 1% offline. This strategy should turn “switchover day” into “switchover hour”.
I would like to do that. Although reaching “official” stability remains the higher priority, I think this will greatly benefit the OSM ecosystem. Since I have limited experience with topical forks, ideally this would involve two-way cooperation with the maintainers of such forks. I will assist with technical needs. This will obviously include alternative branding and custom pages contents.
No, I never mentioned the idea of forks, I meant making it easy to use OSM software for consistent alternate history fantasy mapping – for the roleplay people like NationStates and Dungeons & Dragons?
Why would somebody that has consistently refused to cooperate with anybody actually running the and working on the current system, get the level of cooperation that such a migration would require?
I’m not going to dwell on the gaping holes in the “plan” that are essentially unfixable without going back to square 0.
My work-plan is to do the talking when there is a functional OSM-NG product with concrete results. With a working visualization, it helps to convey the idea to other people. It’s simply a better use of everyone’s time (there are real concretes to talk about). Discussing migration details seems like a cherry on top - the difficult part is to get the idea going.