Listing the OSM XMPP community on the OSM Community Index

The OCI contains at least 2 maybe 3 different entities:

  • accounts (supposedly) speaking on behalf of the project. xtter, mastodon, facebook etc. We don’t want these being promoted except if they are controlled by the OSMF. There might be a bit of community building around such accounts, but they are still mainly a conduit from and to OSM and the outside world.

  • OSM themed communities on platforms that are primarialy chat/discussion orientated. Some of these are technically/financially provided by the OSMF and therefore are subject to moderation by it. But that is not part of the CWGs remit.

Now while you can argue that there needs to be some importance criteria for ordering and therefore prominence in the OCI (anybody remember Facebook being at the top?) of the later, inclusion should be the default and only not offered if there are serious issues (as in large reputational impact).

1 Like

Many local resources have been removed on the basis that they were added by an overzealous contributor without the involvement of the people maintaining the resource, or because they are no longer active. Naturally, the level of activity expected of a local group is somewhat lower than that of a national or international group, and there isn’t a firm cutoff. We’re talking about groups typically maintained by one or two people as a hobby. There are far too many of them for a body like the CWG to assess individually, but the stakes are quite low, since very few people will see a given local group.

By the way, the index’s coverage of local meetups (either online or in person) is arguably more valuable to newcomers than the coverage of chatrooms. Traditionally, OSM encourages mappers to get out and survey, and a local meetup can be a key factor in encouraging that kind of activity. More than once, a mapper called into my local meetup from India (because it’s in Silicon Valley :sparkles:) and was thrilled to learn that there’s a local meetup in their part of India too. It immediately expanded their perception of OSM’s seriousness as a project.

Unfortunately, by far the most common platform for organizing OSM meetups is Meetup.com. Besides being proprietary and expensive, Meetup also facilitates cybersquatting, which can make it difficult to tell whether a group is still being run by and for the OSM community or whether it’s just a vehicle for e-mail harvesting.

Some Meetup groups undoubtedly benefit from exposure to local non-mappers looking for something to do, but I think many would be content with simply managing their events on OSMCal, which is run by the OSM community. Ideally, iD would list upcoming events by local groups, making it unnecessary for these groups to maintain more than, say, a wiki page.

But probably not at the top, as you suggested, unless there’s some solution for the usability issues for inexperienced newcomers. This screen isn’t a replacement for one’s personal browser bookmarks, after all.

Unless we expect such an instance to serve a significant existing user base, why not instead focus those OSMF resources on enabling Discourse Chat on this Discourse instance, which already has a large user base, plenty of daily activity, and community-approved moderators who may be willing to help out? As far as I can tell, it would meet most of your personal criteria for an upstanding service, but the user experience would be similar enough to those proprietary services that it might actually shift some activity toward this open-source platform.

4 Likes

I would certainly suggest we at least try that to see if it works well enough to keep around. Currently in the global list we have the following that might reasonably be considered “some sort of chat”:

Of those Twitter just shows random stuff unless you’re already logged in, and everything other than IRC needs you to agree to some third-party Ts and Cs.

4 Likes

I now registered the domain openstreetmap.chat. Maybe we can create a trusted chat room for OSM that can be accessed using standard XMPP clients.

Here is what I have in mind for this to be a success:

  • The server and its domain are controlled and moderated by trusted members of the OSM community with a bus factor of at least 2.
  • People should be able to join the server using their OSM account (OAuth).
  • Accessing the website should serve users a web client similar to https://chat.joinjabber.org/ where they can log in using their OSM account.
5 Likes

A belated reply to this, but since it hasn’t been covered and I feel it’s important, I would like to break a lance against this notion, based on negative experience with (the consequences of) this.

Not (or only partial) bridging leads to fragmenting communities. Which in some cases actually already are local subcommunities. So what you’re creating is essentially subcommunities within subcommunities.

All with some stuff they share, e.g. the love for OSM/mapping, but also different cultures, norms and values, standards, and with the exception of some members who obsessively (try to) participate in all of them (don’t look at me :flushed:) most are not even aware of the other communities (including other viewpoints those have, things that are “currently at play”, willingness to help new members, etc).

Illustrating this point with an example: last year I made the below “spaghetti chart” for the Dutch community - because some people didn’t understand why a message they sent in the one Matrix channel wasn’t visible to “some other matrix users in the Dutch Matrix” (who turned out to be in the other Dutch matrix channel).

To add to that, yet some others weren’t even aware there was also a Telegram group/community, most of whom in turn know not or care nothing at all about the existence of this forum, and/or the Discord/Matrix part of the community).

And all the stuff I written before applies: they all have a different vibe, their own set of standards, etc.

So, adding (even) more channels and intentionally not bridging them on some principle objection over proprietary networks (while bridging actually allows people to participate in them without having to deal with the proprietary part!) seems outright foolish to me, fragments (and thus damages) the community even further. Based on my experience it’s a very bad idea and I’d fully understand if it’s something the OSMF or whatever WG ends up being responsible wouldn’t want to promote.

Side note

It actually reminds me of another discussion (and there are probably more), where someone seemed to confuse that “Open” in openstreetmap, and it’s general open-source-ish nature, means that it does/should apply to everything OSM does and offers. And while that’s not a bad premise to start with, it’s shouldn’t be a hard-and-fast rule either, or become prohibitive in some way.

It’s not a hill I’m willing to die on, because trying to fix this just for the Dutch community with all the parties and subsequent bureaucracy involved, turned out to be a Sisyphean effort.

You can read that any way you like. And I’ve heard, seen and can empathise with both positive and negative viewpoints: justified worries about administrative issues that bridges involve, such as spam, abandoned/ownerless rooms (and similar platform-related issues), subsequent required safeguards and agreements, etc. Or on the other hand: owners of their own little kingdoms who are reluctant to let go of the status and power that it gives them.

Long story short is that I’ll be the first to admit that bridging can be a messy process that requires a lot of time, grit and energy. But I still think it’s better then creating little groups that unintentionally are very unaware of the other stuff going on outside of their happy little “clique”.

3 Likes

We faced similar issue in India community, when xmpp group was created disconnected from existing community. New groups can be created for specific needs, but shouldn’t call it official without consensus from existing community.

I agree with roelant regarding bridges here.
Osm India community is mostly active on telegram and its also bridged to telegram, and the same is accessible from xmpp. This enables easy discovery, low friction onboarding, and easy collaboration. These are public groups where anyone can join or listen.

For such a community avoiding bridging is only disabling people from communicating easily with other mappers.
This fragments the community as roelant said. Also have seen other bad effects of this as, which makes new joiners hard to find and talk to existing community.

Was there a request to call the xmpp service in question “official” (whatever that means in an OSM context)?

Taking a step back: I’ve long advocated that the OSMF should provide “one of each” of the types of social communication platforms, that is:

  • an async BBS (haha)/forum style platform, typing in to that right now.
  • mailing lists (mainly for internal comms these days)
  • an irc/matrix/xmpp/slack sync interactive/chat communication service

the reasoning mainly being able to support OSM-centric discussion without forcing OSM contributors to create accounts with third (and sometime very questionable) parties. That doesn’t rule out people running OSM themed things all over the place, just where I see the limits of what the OSMF should be financing.

We currently don’t have a self-controlled offering outside of the IRC channels (which don’t require an account to use) for the third point, and that is these days likely just too basic and xmpp too exotic. But there is no reason the OSMF can’t simply contract out for a dedicated matrix service, just as it has for mastodon and BBB (and I believe this works well in both cases).

Simon

5 Likes

Given Discourse’s native email support I’m struggling to think of a reason to use e.g. country-specific mailing lists if a community or tag exists here.

The recent flurry of activity on osmf-talk showed just how crap humans in general are at mailing lists. I can see the point of “important read only announcements” going there, but not any more discussion.

8 Likes

I didn’t specify how they should be provided, just noted that they are alive and kicking for internal communications (no idea if it would be feasible to do that with discourse).

E-mail addresses like those of the board and each working group are necessarily implemented as mailing lists (else hooked into a ticketing system), but Discourse could be used for other purposes that require an access control list but not a public intake system.

While we’re at it, we might as well click the button to enable Discourse Chat on select categories or subcategories. That can always be limited to OSMF-internal categories at first, to test the waters before expanding it to other communities that ask for it. It isn’t a perfect chat system, but the required investment seems pretty low.

2 Likes

Why did I know that that was going to come :slight_smile: But my take would be people would probably prefer a proper client and something that other groups use (synergies etc)… Personally I can just barely live with Discourse as a forum UI, god forbid voluntarily using it for anything else.

6 Likes

I like my cyclesheds painted #FFEFD5. But yes, fair enough, if enough people are already using something like XMPP or Matrix to justify spending additional OSMF funds on it, then Discourse Chat can take a back seat to it. The checkbox will still be there, ready to click if, say, folks need to abandon Slack in a hurry.

5 Likes

I agree. Seems sensible to try it and see how it works for people.

2 Likes

@roelant @muzirian Your views on bridging are, firstly, irrelevant to this thread. But since you have chosen to start this…

It’s quite fashionable to set up bridges, but the issues behind them are invariably downplayed -@roelant and @muzirian 's answers are excellent examples. I’ll ignore the commonly-acknowledged ones - feature mismatches, bad UX, spam - and focus on some critically understated ones.

Merely “principle”?

Eschewing proprietary software is not merely a matter of “principle” but of pure practicality. To use proprietary software is to open yourself up to exploitation at the hands of the copyright holder.

But even if it was just a matter of merely “principles”, those principles are the same as those of OpenStreetMap itself. Which means that the OSM community should avoid being hypocritical and have solidarity for those principles…and that means supporting free software, and boycotting proprietary software (including by de-bridging with it).

Data control

Bridges may allow the use of proprietary services with free software clients, but they also allow said proprietary services to easily access all data pertaining to the communities.

Some like to claim that this doesn’t matter for public channels, but “public” is a spectrum, not a binary. Even a “public” XMPP channel has control over who may or may not join, who may or may not see the logs, how long the logs are retained on the server, etc. Even public IRC channels (like #emacs) can forbid public logging. But bridging to a network with promiscuous data sharing policies like Matrix, or to a proprietary centralized network, effectively hands over all data to them without even trying.

Favoring the rich

Bridges also favor those with more financial power. Consider Network A, funded and developed by the free software community. Then consider Network B, funded and developed by a company worth billions or by a VC-funded startup. Network B will obviously have better clients, more features, better UX, better infrastructure, etc. If one can join all (or even most of) the same communities through both Networks A and B, that gives people the incentive to move to Network B. Most will conveniently ignore that this opens them up to the inevitable mistreatment expected of private companies - as I pointed out in the earlier GitHub thread.

Why communities should care

Communities constantly create pressure on participants to use their media of communication. For example, I’m forced to use IRC because OSM is on IRC. If I had to talk to the StreetComplete developers, I’d have to join their proprietary Slack or GitHub. And each time a community chooses a proprietary platform, or chooses to bridge to one, we’re creating value for the proprietary platform and social pressure to join it.

So why not take cognizance of the consequences of these choices, and make a stand to change things for the better? That’s what the XMPP-only community has done. It’s an example worth following.

Those in favor of bridging are like the people who want to be “apolitical” (another fashionable myth in tech circles). Anybody with an ounce of sense will recognize that all an “apolitical” person is one merely preserving the status quo. It’s as foolish a position as contributing to both OSM and Google Maps - such people have my unvarnished contempt.

I have no interest in preserving the status quo, be it the dominance of proprietary maps or that of proprietary software. I’m here to do my part to change the world for the better.

The solution to fragmentation is to select ONE time-tested and future-proof solution, forget about bridges, and proactively onboard people. To the best of my knowledge, XMPP fits the bill perfectly.

My position on bridges and free software has resulted in me onboarding loads of non-technical users to XMPP (both into OSM and other communities). The pro-bridge/“apolititcal” people cannot boast of such positive impact. If more people were to support us, we could have the whole world weaned off proprietary platforms in no time.

EDIT - Those not in support should consider using their words and actually refuting the content of the post, instead of merely downvoting it. (cc @Negreheb)

1 Like

For India community part we had issue around that.
And can create such confusion when listing it as the communication channel for community on wiki or lists like this, unless specified.

An excellent initiative! @SimonPoole 's post reminded me that we may also want to set up anonymous authentication on this server, so users can chat even without signing in.

1 Like

Note that people may be unhappy about XXL offtopic post in the thread about someone else (personally, I will mute thread instead of down voting as I have not read it)

2 Likes

Here’s that thread in case anyone missed it:

It seems to me like the main issue here isn’t about bridging, or which communication channels are the right kind of free.

The main issue here is how popular should a channel be before it warrants global listing? All of the other aspects are a red herring. We have very free, quasi-free, and fully proprietary channels all in use. The community index documents where the predominance of the usage is, without regard for philosophical preferences on software freedom.

Since there is no fixed number of popularity that answers to this question, the discussion will somewhat uselessly go round and round. If this XMPP channel is more popular than the least popular existing channel, that would be a better argument for its inclusion (or for the exclusion of the least popular channel). Certainly, a user wanting to be involved in the community shouldn’t have to join many spaces before finding ones that are popular.

I can’t help but observe that the community index and @contrapunctus have somewhat conflicting goals. The community index seeks to document where the community has chosen to manifest. Conversely, @contrapunctus seeks to use the community index as a mechanism to promote the community choosing to use this XMPP channel. Hence the conflict.

The main OSM communication spaces I’m involved in have thousands of users and are frequently citied in other spaces and places like changeset comments. Certainly critical mass. A community of 80 seems nascent at best, but I’m willing to be proven wrong if there were other small communication spaces that got global listing before achieving critical mass.

14 Likes