sometimes I wonder whether the OSM discussions are undermined by commercial map providers,
see the Simple Sabotage Field Manual: (Page 18)
(a) Organizations and Conferences
(1) Insist on doing everything through "channels." Never permit short-cuts to be taken in order to expedite decisions.
(2) Make "speeches", Talk as frequently as possible and at great length., Illustrate your. "points" by long anecdotes and accounts of personal experiences. Never hesitate to make a few appropriate "patriotic" comments
(3) When possible,refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible,never less than five.
(4) Bring up irrelevant issues as frequently as possible.
(5) |Haggle over precise wordings of communications, minutes, resolutions.
(6) Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision
(7) Advocate "caution." Be unreasonable and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on.
(8) Be worried about the propriety of any decision - raise the question of whether such action as is contemplated lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon.
- wikipedia:Ignore_all_rules "If a rule prevents you from improving or maintaining Wikipedia, ignore it."
- "These Do-Nothings profess a commitment to social change for ideals of justice, equality, and opportunity, and then abstain from and discourage all effective action for change."
- Although there are some which simply |love to discuss (probably as in real life no one listens to their line of argument).
Found an interesting article and wanted to share an excerpt :
"Serge Wroclawski worked on the OpenStreetMap project for around eight years, and he helped set up OpenStreetMap US, a nonprofit organization dedicated to OpenStreetMap in the United States. In 2014, he wrote a widely discussed article "Why the world needs OpenStreetMap", which explores many of the points mentioned above in greater detail, and with greater authority. It's well worth reading, as is his latest exploration of OpenStreetMap, ominously called "Why OpenStreetMap is in Serious Trouble". As he writes:
- While I still believe in the goals of OpenStreetMap, I feel the OpenStreetMap project is currently unable to fulfill that mission due to poor technical decisions, poor political decisions, and a general malaise in the project."
Why OpenStreetMap is in Serious Trouble
"...at the same time, the ultimate choices for the website, the geographic database and the infrastructure are not under the direct control of the Foundation, but instead rest largely on one individual, who (while personally friendly) ranges from skeptical to openly hostile to change.
As a former professional system administrator, I relate strongly to these types of individuals. At the same time, the desires of them need to be balanced by the overall needs of the project to make progress and keep momentum to keep its userbase happy and engaged.
That is not the case here, and it's to the detriment of the project.
The obvious question is why the OpenStreetMap leadership takes the positions that it does, despite the clear need for change. The answers in my view are commercialism in the project, along with a cultural desire to retain the feel of the project's early days.
I've limited my article to the scope of concerns I have that I feel are stopping the entire project from progressing. There will be time to fix the small issues if (and only if) the project as a whole succeeds. If it doesn't, then the small nit-picky problems are going to be irrelevant anyway."
My personal point of view :
OSM can't continue with it's current "eighties" structure as it's undemocratic.
The "rest" of the > 5 Million participants is not as nerdy to participate in unstructured mailing lists and edit "source code" to participate in a voting.
A couple of people think they got the ultimate wiki power and avoid progress. The way they act (without "social control") leads to the idea of "another wiki besides", means documenting outside OSM, probably on a modern platform which may also be handled by people with less IT affinity.
In the IT sector, there's currently a move away from the classic "waterfall" model
"requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams
[...] evolutionary development, early delivery, continual improvement, rapid and flexible response to change"
If I have a look at the proposals and discussions, that's currently not the case for OSM, see the cited "small nit-picky problems" above.
There could be more space for failure (let's see what the majority chooses)
and more sense for standardization (define a general namespace format instead of discussing every single tag type and the naming).
To give an idea how namespaces are currently used, I created a Namespace_tag_overview page. Feel free to extend or restructure it (Except those who didn't understand the principle, examples on the discussion page). There's currently a terrible mess with the shop=car "service" values, but it seems that nobody cares as I mentioned it twice on the mailing list and all that happened was the repeated removal of a hint to the tag users about this discrepancy. The namespaces of vehicle shops should (obviously) be harmonised, but the focus of active wiki users seems to be on discussion instead of standardisation, as some keep on nagging aroud instead of investing their time in a proposal how (else) to solve it (also see "Simple Sabotage Field Manual" above).It makes no sense to have prefixes (service:) that have no meaning, even if they have been approved.The same applies to "random" service tags. So what's so difficult in a simple namespace which just mentions the usual things offered by a shop like
Also see User:Rtfm/namespace_overview
At the moment, I concentrate on
- Tourism- POIs in general (hotels, campings, restaurants, bars etc.) - see Tourism_tag_overview & User:Rtfm/SMB_overview
- Motorbike-related POIs, see shop=motorcycle,Motorcycling
- According to German statistics , the number of registered motorcycles is approximately 10% compared to registered cars. Just for those who seem to think those POIs are irrelevant.
- check shop=motorcycle or shop=boat.
- The same system should work with a lot of shops, examples : User:Rtfm/namespace_overview
- Nobody seems to have a clue (as often) what industrial=* stands for and when which object should be tagged with either landuse, office=company or anything else. Chris2map was so kind to create a sandbox page to figure out. Which is IMHO still not "state of the art" to find a solution (especially vote), but at least a start.
- The problem with the shop=car services is still not solved and creates a lot of mess. Also thanks to the idiot who removed the hint about this problem :
- The office structure is also a mess and the troll army doesn't make it better (see top of this page).
- The KISS_principle ("keep it simple, stupid")
("allowing information to be shared within a larger network and attracting more consumers to use the new technology,
further enhancing network effects")
- OSM namespace (see above)
- When to create a proposal
(not necessarily if I have to go to the toilet or change a comma, so please don't bother me with "profound mental retardation" issues, try to be constructive)
- Solving problems instead of endless discussions
- Documentation problems and other understanding issues