OpenStreetMap

The use of Free and Open Source Software in the OpenStreetMap Foundation

Posted by pantierra on 29 January 2021 in English. Last updated on 31 January 2021.

The Free and Open Source Software (FOSS) Policy Special Committee of the OpenStreetMap Foundation has been asked by the Board of Directors to assess the degree to which Free and/or Open Source Software or Services are being used within the OpenStreetMap Foundation (OSMF), the board itself, the different working groups, and committees. This analysis focuses on collaborative services to be used over the Internet. The FOSS Policy Special Committee was explicitly excluding the software used by the community at large, local chapters, or systems running on personal computers.

Indicators

The committee has defined two indicators that cover the most important aspects of freedom and openness of software. These are:

1. Programs or Services released under a Free and/or Open Source Software license: Are the programs or services used released under licenses that have been officially approved by either the Free Software Foundation or the Open Source Initiative. Only these licenses are following the standards to be considered free and/or open.

2. Control over data stored at hosted services: The key aspect of hosted services is the ability of the OSMF and the community to fully control the data hosted and to prevent this data from being used for other purposes by a third party. Some of such services are based on open-source software and can be self-hosted by the OSMF, then offering full control and ownership of the data. Non-open services usually do not offer this ability and the full control of the data is at least questionable if not completely impossible.

Inventory

The committee investigated the programs and services used by the different groups: Board of Directors, Communications Working Group, Data Working Group, Engineering Working Group, Licensing Working Group, Local Chapter and Communities Working Group, Operations Working Group, and State of the Map Organizing Committee. A total of 51 different programs or services were identified. The overall percentage of programs and services matching the two indicators are:

  • 57% of the collaboration software in the OSMF is Free and/or Open Source Software.*
  • 31% of the collaboration software is being hosted by or under control of the OSMF.

Looking into each of the different groups separately leads to the following results:

OSMF FOSS Inventory Report Numbers - Currently

Recommendations

The FOSS Policy Special Committee would like to provide practical, feasible, and impactful recommendations. The committee has identified several programs to be used and services that the OSMF should be hosting or subcontracting their hosting with a trusted partner. All selected programs and services can be considered as standards in the open-source world and beyond.

To make things easy, the committee suggests evaluating the services offered by trustworthy providers such as cloud68.co, which is already a partner for the OSMF hosting the BigBlueButton video chat. The committee considers the mentioned providers below as good possible partners that together have most of the following services in their portfolios:

1. osmfoundation.org email addresses

Emails have always been the core and often times the fallback for communication in and around OpenStreetMap and the OSMF. All osmfoundation.org email addresses are currently hosted by the Google Suite, either as simple email address or group. Hosting an email server by the OSMF or a trusted partner seems to be the most urgent and important step for moving towards FOSS and retaining control over the communication data. The committee sees this as the most relevant item and would like to encourage the OSMF to pursue this as soon as possible.

2. Code collaboration platform

Currently, most OSM(F)-related software is being hosted on github.com, and this has a high lock-in potential, it is not FOSS and far away from OSMF having any control over it. It seems that this is mostly due to a lack of alternatives. Therefore the committee recommends that the OSMF hosts or subcontracts the hosting to have an own OSM-related software collaboration platform (similar to Debian’s platform Salsa) using GitLab or Gitea. This is a great opportunity to build a coding community around OSM and to not depend on a commercial offer that likely monetizes on user behavior and, in violation of the true openness of OSM, exclude contributors from certain countries. This platform should become the place to go for OSM-related software.

3. Social media (microblogging)

Microblogging is dominated by Twitter. While the committee does not argue to abandon Twitter, it likes to suggest supporting the distributed (Twitter-like) social network based on Fediverse running on the Mastodon software. The OSMF can tap into an existing initiative on en.osm.town, currently serving 350 users and 1300 followers of the @openstreetmap account. The operation of cross-posters will allow everybody to use the free and open Fediverse first, while simultaneously sending and publishing their social-media messages to commercial market leaders, such as Twitter, Facebook, and Instagram. The active OSM-mapper RoryM is administrating the en.osm.town instance and has expressed openness to move it under a domain and the control of the OSMF.

The committee recommends endorsing this instance as the official social media platform for OSM and establishing cross-posters to existing commercial platforms. Thus living the spirit of open-first with subsequent inclusion of everybody else.

4. Collaborative editing and document sharing

The foreclosure and monetization of user data by Google are well known. The open Nextcloud can replace most of the Google services the working groups depend on (e.g. Docs, Drive, Calendar, Forms). The Nextcloud should become the “swiss-army knife” of the OSMF. Combined with OnlyOffice, LibreOffice online, or Collabora, it can offer rich-text word-processing, spreadsheets, and presentations. It contains a comfortable team calendar, surveys, etc. and it is developed by a vibrant community. Relying on Nextcloud will move a lot of the collaboration in the OSMF towards Free and/or Open Source Software while maintaining the overall functionality and comfort people are used to.

5. Meeting scheduler

For scheduling meetings proprietary services most often used. These are hosted everywhere. Consideration should be given to deploying the software Framadate hosted by or under the control of OSMF.

6. Online surveys

Currently, there is no consistent tool for surveys in the OSMF groups. Limesurvey is already successfully used by the Board and hosted through a paid plan. It is recommended to extend this offer to all groups in OSMF for complex surveys and to rely on the Forms App included in Nextcloud for more simple polls, to protect the data of survey participants.

In summary, the six recommendations suggest evaluating the provision of hosting for the following five online software tools:

Purpose Potential software Potential provider(s)
osmfoundation.org email server There are many good solutions to choose from mailbox.org, servercow.de
Code collaboration platform GitLab or Gitea cloud68.co
Social media platform Mastodon Self-hosted (RoryM)
Collaboration suite Nextcloud cloud68.co
Meeting scheduler Framadate Self-hosting needed

Conclusions

The six recommendations formulated to ensure that the OSMF follows its FOSS policy of preferably using Free and/or Open Source software over any proprietary options. This would guarantee inclusive global participation and protect all active people from having their data used for purposes other than OpenStreetMap.

By following the recommendations the overall numbers of the inventory would change to:

  • 79% of the collaboration software in OSMF was Free and/or Open Source Software.
  • 68% of the collaboration software was being hosted by or under control of OSMF.

And this would lead to the following results for each of the groups:

OSMF FOSS Inventory Report Numbers - Potential


  • All information about the tools in the individual groups of the OSMF and how we classified them according to the indicators can be found in the raw data document.
  • This report in PDF format

  • Authors: Felix Delattre, Danijel Schorlemmer, Enock Seth Nyamador and Tobias Knerr
  • Date: January 2021

Discussion

Comment from LivingWithDragons on 29 January 2021 at 16:31

Between your two coloured-tables (group scores, and group scores if adopting proposed changes) there is a drop in the total number of softwares used. You don’t point out that drop, or explain why it is there.

I suspect that it is if the groups consolidate use of similar software. E.g. a group currently uses two code-hosting platforms that are closed, they would score 0/2 (0%). Switching to only use your suggestion they would score 1/1 (100%). Consolidating should have been done as it’s own step and an extra table included because it greatly affects the percentage and thus the colours.

Your recommendations look good with so much yellow/red turning yellow/green. It won’t be easy for all groups to switch, especially those with lots of software used and integrated into the team workflows or containing vital historic information. Switching may take time, especially with all the volunteers involved. I hope you appreciate that, and I thank you for the recommendations which is surely a helpful step.

Comment from pantierra on 29 January 2021 at 16:35

Thanks for the feedback. Please take a look at the raw data document (you can toggle the sheets for each of the groups in OSMF) and you can explicitly see why there is a reduction in the number of tools. It is indeed because a single tool sometimes replaces a few others.

Comment from Mateusz Konieczny on 29 January 2021 at 16:42

Thanks for this overview!

Currently, most OSM(F)-related software is being hosted on github.com, and this has a high lock-in potential, it is not FOSS and far away from OSMF having any control over it. It seems that this is mostly due to a lack of alternatives.

I think that “lack of alternatives” is not the primary reason.

It seems to me that reason us that it is highly popular and nearly everyone is there so I have no need to juggle different logins and keep creating accounts.

Network effect is ugly and frustrating but it exists, I would consider it as primary reason - not lack of alternatives.

has a high lock-in potential

Is it so bad? Repository itself is not a problem, Github Wikis are in general unused, issue tracker can be easily exported to GitLab (and I regularly do it as a backup).

Maybe if you setup some elaborate CI? Or is it referring to network effect?

And for other GitHub reasons:

  • I really like GitHub interface (that was my primary reason for selecting it rather than its alternatives long time ago)
  • I hate overloaded GitLab interface, nothing is where I expect it (it is not just that I am used to GitHub, I liked GitHub from the very beginning)

Thought it may be just me.

exclude contributors from certain countries

Which countries are still affected?

Comment from pantierra on 29 January 2021 at 16:57

Which countries are still affected?

The US embargoed countries (I personally checked with friends in Iran but probably it is also the case currently for Cuba, North Korea, Sudan, Syria and Crimea)

Comment from osm-sputnik on 29 January 2021 at 17:49

Well, the fact that users in Iran can supposedly access GitHub again (quick check revealed that this is not the case) is not the solution but rather pointing to the real problem. It is at other people’s discretion who is granted access to our collaborative projects. This is certainly not a good starting point and the OSMF should support solutions to grant equal access to everybody.

Arguing that the network effect is ugly but then keeping to justify the use of the lock-in platform (that excludes people) sounds to me like surrendering.

Freedom was never for free. If we want freedom for our projects, freedom for people to contribute to it, freedom from platforms monetizing our data, behavior and personal/professional networks, we need to do something, to move, to create alternatives. Sacrificing a bit of user experience and handling two instead of one login by switching from GitHub to a self-hosted GitLab seems a tiny price to pay for what we would gain.

Comment from Mateusz Konieczny on 29 January 2021 at 18:23

It was not intended as “and therefore nothing should be done”.

I was rather expanding on “It seems that this is mostly due to a lack of alternatives.”, as I think that there are some reasons for that.

On topic of Gitlab - https://josm.openstreetmap.de/ticket/16857 tracking JOSM attempt to switch to it may be useful.

Comment from SimonPoole on 29 January 2021 at 18:56

Did the group consider recommending gitea over the (incredibly clumsy imho) gitlab?

gitea while not perfect would seem to be nearer to what we would expect from FOSS and it would seem to be substantially more realistic to implement something like authentication via osm.org than with gitlab.

Comment from pantierra on 29 January 2021 at 19:12

Yes, we took a closer look at Gitea and we like it a lot! (I personally host it myself and am also very happy with it) It’s much easier to maintain than Gitlab. But it seems quite difficult to connect to OSM’s OAuth, and it has a bit less social interaction features. In the end, we based our recommendation on Debian’s decision and their Salsa (with Gitlab). In any case, Gitea is definitely a good option too!

Comment from mmd on 29 January 2021 at 19:16

OSM’s OAuth will support OAuth2 anyway in the future, which should rule out many of today’s issues with OAuth 1.0a.

For reference: https://github.com/openstreetmap/openstreetmap-website/issues/1408

Comment from ImreSamu on 29 January 2021 at 22:39

imho: in the next version .. please add some long term vision/recomendations about open-source computing hardware !

  • When we will using “Fully open-source hardware” in the server side? ( CPU, … )

  • When we will using “Fully open-source hardware” in the mapping process?

    • Open Source Hardware based GPS (Satellite and a receiver ) ; RTK ?

Comment from jambamkin on 30 January 2021 at 09:55

Was there discussion of event organisation software? I know a lot of it is handled on the wiki, but investigating mobilizon as a dedicated event platform would be cool.

Comment from gileri on 30 January 2021 at 10:09

Nice work ! I wasn’t aware of this Special Comittee, but I’m glad it exists and creating those useful recommendations.

Comment from SimonPoole on 30 January 2021 at 11:10

@xamanu while this is not really the right place for a tech dicsussion. gitea uses https://github.com/markbates/goth for OAuth support and while most of the providers are for OAuth 2.0 support at least the Xero one is 1.0a. So I’m not quite sure what would be “quite difficult” about adding OSM, work yes.

In any case does your answer imply that gitlab supports (mis-)using 1.0a?

Comment from Richard on 30 January 2021 at 12:01

If we want freedom for our projects, freedom for people to contribute to it, freedom from platforms monetizing our data, behavior and personal/professional networks, we need to do something, to move, to create alternatives

I’m not convinced that, as a project, we do.

“OpenStreetMap is an initiative to create and provide free geographic data, such as street maps, to anyone.” (First sentence of the OSM Foundation homepage.) “Welcome to OpenStreetMap, the project that creates and distributes free geographic data for the world.” (First sentence of the OSM wiki.)

If we can do that and use open-source software then that’s great. But our mission is open geographic data, not open-source software. If our developers find Github helps them build tools for open geographic data more effectively than Gitlab does; or if self-hosting Gitlab would divert our sysadmins from the core geodata hosting; or if paying for a third-party Gitlab install would divert funds from geodata initiatives; then we should stick with Github.

Comment from osm-sputnik on 30 January 2021 at 19:18

I’m not convinced that, as a project, we do. “OpenStreetMap is an initiative to create and provide free geographic data, such as street maps, to anyone.” (First sentence of the OSM Foundation homepage.) “Welcome to OpenStreetMap, the project that creates and distributes free geographic data for the world.” (First sentence of the OSM wiki.)

Is OSM supposed to be free as in beer or free as in speech? What is free enough? Would you agree that everybody has to watch an ad before being able to download a small chunk of data? The data would technically still be “free”. Would you agree to OSM monetizing user behavior (which part of the map you are looking at and when?, which part of the map you are editing and how?, what you focus on when editing?) to pay for the server infrastructure to be “free”? Would you agree that the editors and the rendering software will charge you for their use while the data stays free? Would you agree that OSM uses free services that exclude users from downloading or participating at the service’s discretion, making your access to OSM “free”? I do not agree to these scenarios. I also consider the software ecosystem developing around the pure data as part of OSM and equally important. Therefore, why shouldn’t we pay the same attention to these aspects?

If OSM code resides on GitHub, people from some countries cannot participate. And if they can, their data is monetized. Is this OK as long as the data is free? I’m not saying we should abandon everything that is not completely free and open and hosted at own servers, however, I argue for striving for more openness and inclusion. This is better served by building an OSM-software community on an OSM-hosted repository (similar to Debian Salsa). I don’t want OSM to be free as Google services but truly free.

Comment from pantierra on 30 January 2021 at 20:08

Really tank you all for these very interesting discussions!

SimonPoole, you are right. We should add Gitea together with Gitlab as an option - probably it is worth including it as such in the report. Will ask if this is still possible.

jambamkin, we haven’t looked at that so far, thanks for bringing it up. The current event organization with Pretalx and Pretix doesn’t seem to be a wrong direction from our point of view. But if there is room for improvement, it is good to have the tool you mention on our screen.

Good point, ImreSamu! In this first report we wanted to highlight the most important and also “easy to address” or practical points. We do see there is more to do in the future, and more to envision. So, I appreciate you throwing in the open hardware aspect, too.

Comment from SomeoneElse on 30 January 2021 at 20:12

I have to say I’m somewhat puzzled by some of the suggestions in here. Just to take one example (email) the suggestion seems to be move away Google Workspace (which is what G Suite is now called) and to move to something hosted by someone else? I can think of several reasons to avoid relying on Google for email, but “FOSS” isn’t really one of them. If the purpose is to avoid relying on a third-party which may be blocked, how does using a different third party help? For completeness, and as I’m sure you’re aware (though others may not be), the OSMF already runs both Google-hosted and internally-hosted non-Google email infrastructure.

Whilst I understand what Richard’s saying above with regard to e.g. github and Google Docs, I do have more sympathy there. Imagine we had a board member from somewhere like Iran (and why not - there’s a large vibrant OSM community there). Anyone from anywhere on this list would have difficulties participating in anything if Google Docs access was assumed.

Comment from pantierra on 31 January 2021 at 21:22

Gitea has been added to the report. And we are actually thinking about offering hosting an instance for the community to see if there is interest in using it.

Comment from blendergeek on 1 February 2021 at 03:53

I am disappointed that Slack was never mentioned in any of this. ID, the “official” OSM editor, recommends that users collaborate on Slack. Is there any chance that OSMF could host a Matrix (or other F/LOSS Slack competitor) alternative?

Yes, I am aware of the current perceived benefits of Slack over Matrix. On the other hand, someone could point out many features the Google Maps has over OSM and suggest that we should just use Google Maps.

And I see a mention of GitLab (the shiny open core Github alternative) but I see no mention of Source Hut, the up-and-coming cloud collaboration suite that may lack Gitlab’s sparkle but it makes up for it in freedom (in my opinion).

Comment from Mateusz Konieczny on 1 February 2021 at 06:38

ID, the “official” OSM editor, recommends that users collaborate on Slack.

To be more specific - iD is using https://github.com/osmlab/osm-community-index data where for given area primary communication channels are mentioned.

Order can be specified.

For example in Poland https://forum.openstreetmap.org/viewforum.php?id=23 is listed as a primary place.

If primary channel of a community is not Slack then it can be easily changed, but if people actually use Slack primarily then it is more complex.

Comment from SimonPoole on 1 February 2021 at 07:06

@blendergeek using slack is a deliberate choice of the US “community” well to be exact, some prolific members, that migrated the US community more or less “voluntarily” off IRC and other OSMF operated channels. The community index (which is what displayed by iD) is only relevant in that it was part of the “voluntarily” bit.

Comment from pantierra on 1 February 2021 at 09:20

Is there any chance that OSMF could host a Matrix (or other F/LOSS Slack competitor) alternative?

In this very first report, we wanted to address the most urgent and easily solvable matters. And in particular, we only looked at the OSMF with the official bodies (neither local chapters, nor software communities). We are well aware of the unsatisfactory chat situation. However, in the OSMF groups, IRC and Matrix are quite common and only Telegram seems to be used as a proprietary tool (with explicit reference to the server).

On the other hand, chats are the most difficult to discuss. I have seen many groups talking endlessly without coming to an end. Although I agree with you that a FLOSS chat tool would be great to have. We propose to address the urgent issues and recommendations in the report and move to chat discussion as a second step.

Comment from mmd on 1 February 2021 at 10:03

Regarding the code collaboration platform: almost all projects in the https://github.com/openstreetmap organisation depend on some sort of CI/CD pipeline (by the way, are those the projects which are in focus here?).

I’m not 100% sure what the options are available when using Gitea, but in any case I would consider CI/CD as an absolute must have feature for any kind of new platform to switch to.

OSMF based code hosting isn’t an entirely new idea: we used to have svn.openstreetmap.org (+ trac) for quite some time before some projects started moving to Github.

Comment from SomeoneElse on 1 February 2021 at 10:47

(to add to what Mateusz said above) you can see what the Community Index suggests for an area by looking at https://openstreetmap.community/ . I presume you’re seeing OSM-US’ Slack mentioned because you’re editing in the US. Depending on where in the world you are you might get a mailing list appearing first, or a Telegram channel, or something else. For me it suggests a pub meeting at the top of the list. OSMF can’t really dictate where local mappers choose to communicate (“yes - you can create a Facebook group, but don’t dare talk about maps in there!”) and it makes sense to me for iD et al to point to where other local mappers actually are.

Sometimes there will be separate groups that don’t cross over much (for example, the frequent posters of the “talk” mailing list and the OpenStreetMap Telegram group are mostly different people) and that’s OK; people are people, and don’t always fit into “organised” hierarchies.

Comment from SimonPoole on 1 February 2021 at 12:24

@mmd yes there are a number of CI/CD options available with gitea. The problem is however not just one of FOSS though.

We know that providing free, essentially unlimited, computing resources is not a winning or sustainable business model, and that the party with any one specific CI is going to end after a while. So now the party at the expense of travis has ended, most projects have simply moved on to github, but at some point in time that is going to end too and the wailing and teeth gnashing will be large and loud.

IMHO moving to a self hosted software collaboration platform really only makes sense if the OSMF can provide a stable CI/CD infrastructure with it too, which naturally impacts ops a bit more than running just another service.

Comment from IpswichMapper on 3 February 2021 at 17:05

A Openstreetmap gitea would be really nice. I have currenlty posted my OSM-related software (SwiftAddress) to Github, because I am worried that otherwise it wouldn’t get as much recognision and issue reports, since alternatives require you to create an account most people don’t have.

Conversly, openstreetmap gitea would allow you to sign in using your openstreetmap account, and since everyone who is trying to use SwiftAddress already has an openstreetmap account, the “accounts issue” is somewhat fixed.

Comment from IpswichMapper on 3 February 2021 at 17:06

Also, don’t try and forcefully transition away from twitter / facebook / youtube in favor of the fediverse. Using the fediverse for OSM is nice, however accounts on conventional media must be kept. By deleting them you are effectively deplatformating yourselves. Not a good idea when OSM really needs more contributors.

Comment from pantierra on 3 February 2021 at 17:44

Thanks, @IpswichMapper for the nice comments!

This is not to force anybody. We want to show and give constructive alternatives that are as much fun as OpenStreetMap itself. Clearly, we want the communications to reach as many people as possible and it is not about encouraging anybody to move entirely away from Twitter/Facebook and Youtube. The OSMF has a FOSS Policy that basically says, it is better if there is an open solution first and a proprietary solution second. In the end, I’m very much convinced, people can and should decide for themselves.

Comment from ImreSamu on 4 February 2021 at 08:48

@xamanu:

TLDR: We need a checklist/guideline, what is the “true” FOSS (in spirit)!

:)

OSMF FOSS dogfooding

for me ~ “FOSS allows for better collaboration among various parties and individuals with the goal of developing the most efficient software, hardware, documentation, open data, map data, … “

1.

for the outsider - the https://wiki.osmfoundation.org/wiki/FOSS_Policy page is not a true FOSS .. because collaboration is disabled! “Only foundation website editors have accounts on here” and this can be miss-interpet as a “We don’t want your feedback, suggestions, collaborations in this website !”

2.

The better example: https://welcome.openstreetmap.org/ this can be edit ( the github repo is linked ) .. but this is “hidden” .. not visible …

3.

(for me) the best example is “the postgis workshop page” : “Edit this page” Gitlab | Github “ is visible, and there is 2 alternative .. so the “everybody with an anti-github-sentiment” can collaborate.

check yourself: https://postgis.net/workshops/postgis-intro/geometry_returning.html

collaboration not only allowed .. you have a choice !

second order thinking:

“Often when we solve one problem, we end up unintentionally creating another one that’s even worse. The best way to examine the long-term consequences of our decisions is to use second-order thinking.”

The postgis project has 3 Source code repository, but the most popular is still the github mirror.

My pragmatic suggestion: just create another 2 git mirror and keep the github :

  • mirror1: in the openstreetmap.org (gitea)
  • mirror2: in gitlab

diversity

We need multiple alternatives ( ~ git(hub) mirrors ) so

can contribute as they like …

Comment from ImreSamu on 4 February 2021 at 09:38

@xamanu: “In the end, I’m very much convinced, people can and should decide for themselves.”

the clear OSMF FOSS guideline and checklist is very important, because the github exodus has been started ( ~ because we have a FOSS policy and there is a recommendation inside )

On the other hand we also have a diversity policy:

“The OpenStreetMap Foundation and the global OpenStreetMap community welcome and encourage participation by everyone.”

imho: the definition of the “everyone” == ( current and future github users included and not excluded ) ! so every big changes like this “github exodus” .. should be discussed by the “OSMF Diversity and Inclusion Special Committee” because it has a long term effect.

So if the” diversity policy” is important —-> probably we need multiple git mirror - as in the postgis project

Comment from iandees on 5 February 2021 at 16:21

From Richard:

If we can do that and use open-source software then that’s great. But our mission is open geographic data, not open-source software. If our developers find Github helps them build tools for open geographic data more effectively than Gitlab does; or if self-hosting Gitlab would divert our sysadmins from the core geodata hosting; or if paying for a third-party Gitlab install would divert funds from geodata initiatives; then we should stick with Github.

I want to +1 this. OpenStreetMap Foundation should not prescribe any particular tool upon itself or any of the volunteers that participate in the OSM community. It should use tools that make the map better or support our community making the map better. Our volunteers have limited energy and time. We should ask that they spend it on making OpenStreetMap better and not worry about pushing a FOSS mindset.

Comment from Mateusz Konieczny on 5 February 2021 at 17:39

OpenStreetMap better and not worry about pushing a FOSS mindset.

Note that in many cases even more FOSS mindset would make OSM better.

Comment from Tordanik on 9 February 2021 at 22:12

IMO, the chat issue has slipped through the cracks because the proprietary tools are run by entities other than the OSMF. Nevertheless, it has a greater impact on a regular OSM contributor (as opposed to an OSMF working group member) who wishes to use FOSS than many of the tools listed in the report. So while it may not fit the scope of the report well, I believe that bridging existing communities with a Matrix server is the way forward, and that the OSMF should help make that happen.

I also agree with some of the criticism of the community Index, especially given that it is – through iD – arguably part of the OSM website. Before this discussion, it always recommended proprietary platforms over our own, self-hosted ones, and it still does so by default unless a local community explicitly requests a different prioritization.

Comment from SimonPoole on 10 February 2021 at 20:02

IMHO it is a bit dangerous to conflate the issue of which tools and systems the OSMF is using (aka the FOSS question), with in many ways different issue of maintaining user privacy.

The only touching point is really that FOSS communication channel software makes it easier to self host, or at least host with a trusted provider. FAANG+M are the leading contributors to OSS, but that doesn’t make them in any form a trusted provider of services.

Naturally there is a bit of a (very big and deep) culture gap at least between the US and European developer communities in this, and to generalize a bit, on the US side they are mainly seen as potential future employers (if not already the current one) and critical views are widely considered inappropriate.

Just see the already mentioned community index, or iD leaking OSM contributor information to FB by default for examples. The later which seems to be, judged by the lack of action, considered totally OK by the OSMF.

Now local communities can choose what they want, but as I’ve suggested multiple times over the years, the OSMF should provide at least one communication channel per “type” that allows contributors to participate without requiring them to create new accounts and have their data monetized. If the users take it up or not is up to them, but at least we’ve then provided the option of choice.

Comment from mmd on 22 February 2021 at 11:24

@1ec5 reported on Slack that Framadate doesn’t distinguish timezones, which is “pretty much a dealbreaker for anything in OSM that I would use it for”.

See https://framagit.org/framasoft/framadate/framadate/-/issues/158

Log in to leave a comment