Ha, not sure why it got submitted here now, but since I wrote the software, I'll provide some background:
A couple of years ago we had a hand-fiddled table in our OpenStreetMap wiki with events, but discovery was poor and nobody really wanted to write wiki table syntax _shudder_ to add events. So people either didn't do it or only advertised their events in their group chats or Facebook groups.
Thus I started writing some code, and now people can add an event by just logging in with their OpenStreetMap account and filling out a small form. We still display our events in a Wiki by using the API and a small Mediawiki plugin to maintain human compatibility for people who are used to getting events from the wiki. There are also RSS feeds, iCalendar subscriptions and event file downloads, so that everybody can subscribe to events in their preferred form.
It's a small project that I've been running for a couple years and it's really rewarding to see people using it every day.
Sorry, I can’t agree with your characterization. Obviously nitpickers exist, but the general community can be very helpful. Some people have strange ideas and expect everyone to go along, but everything is up for discussion.
Especially for people coming from cultures where confrontation or directness is frowned upon this leads to the impression that OSM is a fighting ground, but there can be no discussion without disagreement.
OSM is more like a community of communities: There are people mapping with very diverse value systems (ranging from underserved people to semantic data aficionados), groups and corporations building software, volunteers running the servers etc. Making a decision with such a large body of people with very different interests can be very troublesome, but this is something you have to deal with.
A central point of the ecosystem is the editing software: This is the gateway through which people will touch the data and can massively steer the data and thus the community into a certain direction. E.g. if you throw a validation error on every object which doesn't have a name, soon all objects will have names.
There are several editors available for OSM, but iD is the most prominent one at the moment, as it will be presented to you if you click the "Edit" button on osm.org. Thus people developing iD have a large burden to carry. And there is the growing disconnect that the author is writing about: A small group (in other words: two people) control in which direction the project is being steered. And with a complaint from within the community, one of the maintainers has disabled the issue tracker for the general public. (Edit: Issue tracker has been reopened now)
Making a decision with everyone involved is hard and takes a lot of effort, but at the moment we have a situation in which very few decide without the mandate of the community.
Hope I could shed some light (though it's late over here).
Just a few months ago SpaceX fanboys were telling us those satellites were no problem, because "space is so large". The problem is, they’re operated by overworked, delusional people.
People are going to die, because hype is more fun than security.
Blocks are useful, because you can distribute the workload onto several workers. Most encoders nowadays write first blocks with just nodes, then blocks with just ways and then just relations.
Yeah, the OSM PBF format is really efficient in size, but it can be quite a pain to work with those files. Every way consists of nodes, which are usually at the very beginning of the file (first nodes, then ways, then relations). So in order to work efficiently, you'll need a node cache (which at the moment is more than 40G). Seeking is not viable because there is no indication in which block the node will be. On-disk caching is an option, but it will slow you down substantially.
So unless you are doing meta-analysis of the raw OSM data, without assembling geometries, hand-rolling an OSMPBF reader is viable, otherwise I would suggest either using something pre-processed (extracts in real geodata formats), an established parser like osmium or rather import the data into e.g. postgres and do some querying there.
For me it's because they do damage their workers' rights and their fans are so insufferable: The denial that they have quality issues, the repeated lies ("we are going to build a factory in weeks", while everyone knows that it will take years), the massive overvaluation. It's either you are on team Tesla and celebrating every of Elon's brainfarts or you are "big oil" that is trying to destroy them: Just look what happens when countries try to introduce standardised charing cables.
I just wish they would be frank about what they can and cannot do.
EDIT: And by the way about that pathetic "climate change" argument. Right, they are now selling Fiat their CO2 certificates thus enabling them to do wonderful green washing.
"How hard must being a bank be, it's just a few numbers in a database."
After all those new-ish, app-based banks are for people with too much time on their hands. You mostly can't talk to anyone, and when they answer it's just a copy-paste from their FAQ. They also lack features, e.g. Kontist doesn't support international bank transfers. Support will tell you "well it could work, but we can't give you any assistance". I don't have six months until your development team understands and implements some protocol!
Objects are dependent on each other and new, legitimate edits can happen on top of damaging ones which we would not like to revert automatically.
Yes, there are tools in place which can revert edits, but there is still manual checking required. The annoying thing is that companies sometimes go ahead and "invest" money into edits which turn out to be garbage and then volunteers need to revert or fix them up.
In case you want to control your HS100 from Apple Homekit, I recently wrote a small tool that you can run in your local netrwork: https://github.com/thomersch/tplink-homekit
A couple of years ago we had a hand-fiddled table in our OpenStreetMap wiki with events, but discovery was poor and nobody really wanted to write wiki table syntax _shudder_ to add events. So people either didn't do it or only advertised their events in their group chats or Facebook groups.
Thus I started writing some code, and now people can add an event by just logging in with their OpenStreetMap account and filling out a small form. We still display our events in a Wiki by using the API and a small Mediawiki plugin to maintain human compatibility for people who are used to getting events from the wiki. There are also RSS feeds, iCalendar subscriptions and event file downloads, so that everybody can subscribe to events in their preferred form.
It's a small project that I've been running for a couple years and it's really rewarding to see people using it every day.