Engineering Working GroupPosted by drolbr on 4 October 2021 in English (English).
While the heart of OpenStreetMap is the community of mappers, it has also a remarkable ecosystem of software developed and used for OpenStreetMap. Many people are surprised to learn that it is so federated that the OpenStreetMap Foundation does only a tiny part of it.
The key to understand that is that many software projects have developers out of personal passion. The long time editing tool Potlatch has been developed and kept alive by Richard Fairhurst, JOSM luckily has a whole team behind it, and also Vespucci, OSMAnd, Nominatim and Osmium each are closely tied to names, as well as many other tools. This both keeps each of the tools focused and gives them a direction. Large organizations cannot offer that, because more often than not the managerial fashion of the season will interfere with pursuing long term goals.
Nonetheless, outsiders that expect a single point of contact shall have one. This is where the idea of the Engineering Working Group comes into play: it has a more specific mission than the board in general, but it still can send people and inquiries to the right places.
The EWG does not replace issue trackers. The EWG is not the right venue for comprehensive visions of the future. But it shall help to improve the flow of information related to development of OpenStreetMap related software.
I’m happy to chair the just restarted EWG.
My biggest contribution to the OpenStreetMap software ecosystem is the Overpass API: to enable all mappers to search for the information they want in the OpenStreetMap database by suitable formal expressions. I have developed the Overpass API completely in spare time, mostly because no organization by any measure ever would have approved such a project. This also includes to do reliable and meaningful testing, and this is again is in any organization a hard point to sell, even more because lip service and self-perception say otherwise. Hence the Overpass API itself is also a good example to illustrate the development model of personal passion.
My day job is at MENTZ, a company that develops software for public transit. It is itself a heavy user of OpenStreetMap data, most notably for pedestrian routing including routing of disabled people. We use OpenStreetMap also for better public transit information in general, but that is more like yet another stylesheet for the renderer than something specific. The challenge in pedestrian routing is that walking habits and potential states of ways are so wildly different that there is no standardization how to tag things and thus essential attributes still missing in many places - because it is so hard to explain to mappers what properties really matter.
The sessions of the EWG are public by default, and we encourage everybody else who has to say something on a topic to tell it the EWG. We will do our best to distill the factual arguments even out of contributions that take a stand.
Of course the best way to do that, to be as neutral and well-informed as possible about the OSM software ecosystem is to have enough members. So if you think your knowledge about OSM software development can help, please ask on firstname.lastname@example.org for joining the EWG.
Comment from lonvia on 10 October 2021 at 08:49
The romantic notion of the heroic programmer that develops essential open source software in their spare time is nice but doesn’t really hold in reality. Lets just take the example projects that you have listed above: Vespucchi is being developed by somebody who can afford an early retirement. OSMAnd is a company that sells an app. Nominatim has switched to a full-time paid-for development model last year after years of stagnation. Osmium is pretty much 100% paid for by Mapbox.
The gist of if is that programmers work better when they eat and sleep and can feed their kids. So you’ll find that behind every successful passionate programmer there is an organisation that pays the bills. How much that organisation interferes with the long time goals of the project depends on the actual arrangements.
I’d further like to add that it is not healthy for any of the named projects (including Overpass) that they depend on a single person for survival. It introduces a dangerous bus factor for projects that are essential for our infrastructure and severely limits the amount of progress you will see in the project.
The problem with the open source software around OSM is not one of large organizations against small time programmers. The problem is that we need to find an operation mode that is sustainable for all involved, individuals and large companies alike. I hope the newly founded EWG can help with that.
Comment from drolbr on 10 October 2021 at 09:09
Thank you for the feedback. The term “personal passion” has not been meant as “unpaid”. And both are unrelated to Open Source.
If you report a bug to say, Apple or Microsoft or Google Maps, then most likely for a year or longer simply nothing perceivable will happen. Any attempt of communication is diverted away from those that could make decisions. This is not only a common flaw of large organizations, it is rather a design goal of large organizations.
By contrast, in the federated OpenStreetMap model, in all the listed cases you will talk pretty immediately to the real people that are able to change the software.
Comment from Pieter Vander Vennet on 11 October 2021 at 11:40
I’ll probably join the next meeting, but I’m having a few issues with that:
Kind regards, Pieter
Comment from Pieter Vander Vennet on 11 October 2021 at 11:43
I’m in the same boat as Roland with development of MapComplete. I’m quite passionate about it too, but funding of it isn’t really a problem as there is a market for tailored, easy to use OpenStreetMap-editors (!). The entire project started of by with a small fund from someone, and since then I’ve had many requests.
However, it is true that this model certainly has drawbacks (such as bus factor), but being able to have a good vision of what I want the project to be is a huge benefit and allows for lots of innovation.
Comment from drolbr on 12 October 2021 at 10:12
@Pieter: Thank you for asking back: The emails address is email@example.com . The date is indeed 2021-10-18, I’m sorry for the typo.