OSMF should host a Forgejo/GitLab instance

Foundation
1

This is a reboot of this thread which I started last night on the mailing list, before realizing (with the benefit of input on IRC) that it may be better off on the forum. Quoting my initial post, with minor edits -

Hello.

I’m sharing (and voicing my support for) a suggestion made by Simon Poole on IRC - that the OSMF set up its own Forgejo or GitLab Community Edition instance. Such an instance could use existing OpenStreetMap accounts for authentication, reducing friction for OpenStreetMap contributors. Critical OpenStreetMap software projects, including editors, presets, etc could be encouraged to leave GitHub and move there.

Why?

Currently, the proprietary code-hosting platform GitHub has the dubious distinction of hosting the majority of OpenStreetMap-related software projects.

There are many issues with this situation -

  1. A growing number of potential contributors refuse to use proprietary platforms on principle. These contributors are naturally excluded from contributing to OpenStreetMap software projects hosted on GitHub. (Contributing via email is possible, but a terrible downgrade in UX, more so when you consider that platforms like GitLab and Forgejo exist.)

  2. GitHub violates copyright and free software license terms - free software hosted on GitHub is used to train its Copilot tool, which can reproduce the code verbatim in legally-significant quantities, without regard for reproducing the attribution statement (e.g. for MIT and similar licenses) or copyleft clauses (e.g. GPL).

  3. Proprietary platforms such as GitHub have a history of tracking users.

  4. User content (such as comments) on proprietary platforms is being used to train LLMs without the users’ informed consent. If GitHub is not doing this already, we can expect it to happen soon.

  5. Proprietary platforms have been used in the past to inject adware and malware into software installer downloads - see SourceForge - Wikipedia . The same could happen again, if it is not happening already.

  6. Platform lock-in. The more non-standard and GitHub-exclusive features a project depends on, the harder it is to migrate away from it when the time comes.

  7. GitHub can delete repositories without the consent of the repository owner(s).

Other alternatives to GitHub

  1. Codeberg is a Forgejo instance that is gaining popularity among people fleeing GitHub. It includes CI/CD and static web hosting.

  2. Radicle allows hosting Git repositories, issues, pull requests, and other repository metadata in a peer-to-peer and offline-first way. However, it is in early stages and may not currently be suitable for large projects.

  3. Gitlab.com is a service commonly suggested as an alternative. However, I do not recommend it because of its use of CloudFlare to - there are really no better words for it - harass, frustrate, and outright block Tor users.

Concerns about migration

I have urged several OpenStreetMap projects time and again to move away from GitHub to one of the numerous alternatives. The following objections are frequently raised -

  1. Ease of authentication - because “everyone” has a GitHub account, it is allegedly easier to access. Thus, projects moving away from GitHub are supposedly at risk of receiving fewer contributions.

    As mentioned, a self-hosted Forgejo or GitLab instance would fix this by providing SSO using contributors’ OpenStreetMap accounts.

    That said, I’m not convinced that ease of authentication is really an issue in practice, for three reasons - one, most forges (including Codeberg) support SSO with popular services, including GitHub. Two, setting up a new account takes two minutes and is no obstacle to someone who wishes to contribute. Three, Codeberg is fast growing in popularity and quite a few people have an account there already.

  2. The work involved in migrating CI/CD actions to a new platform.

    I would hope the problems with GitHub are more than justification enough for this. Furthermore, switching to a free software CI platform would be a one-time cost which makes future migrations to other forges easier.

  3. Future-proofing - some contributors have great faith in the longevity of platforms run by private companies, and community-run platforms are seen as a downgrade in that regard.

Conclusion

I ask the OSMF and the OWG to consider Simon’s proposal. In doing so, OpenStreetMap would -

  1. Offer a unified, trustworthy, and independent platform for software collaboration.

  2. Join the ranks of projects like Debian, which host a forge for their communities. The Debian project operates Salsa, a GitLab instance for hosting Debian-related repositories.

  3. Continue its own precedent of providing services for the benefit of the OpenStreetMap community. An example is the BigBlueButton instance, which is used not just for OSMF meetings but also for e.g. online OSM editing workshops.

  4. Support its own culture of free software, extend it to source code collaboration services, and encourage projects to choose freer alternatives for hosting.

I and other members of the free software community would be happy to assist with the migration.

For whatever good it does, I’ll also quote one of my responses to that thread -

Let me address this very early on for everyone’s benefit, so this conversation stays on the right track - there’s nothing quite so infuriating as someone dismissing or minimizing one’s concerns as “philosophical” or (another popular term) “ideological”.

If anyone does not see the issues I’ve listed as important, it reveals their complacency, short-sightedness, and ignorance of history. Such persons should refrain from erasing others’ concerns by calling them “philosophical” or “ideological” on account of their own limitations - such an attitude is not conducive to constructive discussion.

5 Likes
2

note: this is not extensive reply or official statement of any organisation, it covers one specific aspect - Gitlab as alternative.

tl;dr: please no Gitlab.

I would add one more objection to specifically Gitlab: its UX is horrible.

Doing anything is exercise in frustration, while Github has a stable sane interface which is much much less confusing than what Gitlab designers created.

I am using Gitlab for some projects, including OSM-specific and OSMF-specific and it is highly annoying: specifically due to entire Gitlab UX being really bad.

I tried Gitlab and Codeberg mostly as attempt to find alternative to Github and at this point I would definitely not use Gitlab if I can avoid it. And yes, I would prefer Github despite in general trying to avoid proprietary software.

(and it is not just due to being used to Github: at least for me my first thoughts when I started using it years ago was that it is a really nice website - and so far interface was not seriously degraded, while my first reaction to Gitlab was among lines “arrrgrrhr, why”.

To be more specific. It includes some annoying barriers on login - from

screen09
screen09903×408 20.8 KB

on basically every single login (often " Verifying you are human. This may take a few seconds." also appears for quite long time). (and yes, I reported this problem)

It heavily pushes paid version, with functionality deliberately removed/skipped from free trial open source version - even when reimplemented by contributors not affiliated with the company.

Its UX is terrible, finding functionality is extremely frustrating and even keeping notes where given option are placed does not help as much as usual as they keep moving it around. And next iteration of that is coming right now:

The 17.0 major release is coming on May 16, 2024! This version brings many exciting improvements to GitLab, but also removes some deprecated features. We are introducing three breaking change windows during which we expect breaking changes to be deployed to GitLab.com. You can read more about it on our blogpost. The first breaking change window begins **2024-04-22 09:00UTC **and ends 2024-04-24 22:00UTC.

(I have not tried creating issue as properly documenting/describing some examples of problem would be multiple hours of work and almost certainly would be anyway ignored)

Gitlab already tried something similar, though it was rather attacking developers using git. See Remove ads from git push CLI response (#412112) · Issues · GitLab.org / GitLab · GitLab (rolled back after protest)

5 Likes
3

Thanks for the response, @Mateusz_Konieczny .

It’s important to distinguish between GitLab.com (the service) and GitLab CE (the self-hosted option).

  • The login issue you mention is related to GitLab.com - this is the use of CloudFlare I mentioned. I can’t even login to GitLab.com from Tor Browser, no matter how many CAPTCHAs I fill out.
  • The adware issue also seems to be related to GitLab.com, and not GitLab.
  • It seems GitLab.com is also looking to train LLMs on its hosted code. That makes the service as objectionable as GitHub. But a self-hosted GitLab instance does not have those issues.

My experience with GitLab is limited (e.g. to make issues on https://dev.gajim.org/), so I can’t comment on the UX.

3 Likes
4

Is Gitlab CE is also having them enabled by default? If yes, then you would need to spend time on reconfiguring/patching Gitlab to get rid of them significantly increasing deployment and upkeep costs.

5

I go with the opinion that OSMF self-hosting GitLab/Gitea/Forgejo (only became a hard fork of Gitea about 2 months ago) would be the ideal solution.

It would require some amount of support and funds to host it but somewhat doable I believe.

A growing number of potential contributors refuse to use proprietary platforms on principle.

I would like some numbers for this, while some may be inclined for more free platforms (myself included), it only includes a very small userbase.

I use GitHub myself and found to be exactly what I needed a couple of years ago, similarly to CloudFlare, they both provide valuable resources to a lot of people despite being proprietary.

User content (such as comments) on proprietary platforms is being used to train LLMs

It’s not like anyone is stopping LLMs of any kind from going into our shiny new selfhosted git instance :slight_smile:

Ease of authentication

It would be nice to be able to login with my OSM account indeed but not necessarily a dealbreaker as you put out.

1 Like
6

I’m honestly not sure that insulting people who disagree with you is the best way to win them round, though I grant you it has a long and honourable tradition on the OSM mailing lists.

21 Likes
7

Repeating, and expanding on, my own comment from the mailing list thread:

I understand the sentiment, I am however not sure if the number A of “people just waiting to contribute to OSM but unable to because they reject GitHub” is larger than or even equal to the number B of “people who have a GitHub account and are willing and able to help out in OSM coding but who don’t want the hassle of signing up to, and learning the ropes of, yet another free GitHub clone”.

I would also like to point out that using a self-hosted GitHub clone will cost us a non-trivial amount of money in maintaining it. This money has to be earned through donations and memberships, which more often than not come from large corporations like Microsoft (owners of GitHub), on whom we depend more the more money we spend on stuff.

The thing I am most concerned about with GitHub is the vendor lock-in danger; that we might come to depend on shiny features they offer to such a degree that we lose the freedom to simply change away from them. But as long as we can profit from the free-as-in-beer stuff they offer, and don’t become too dependent (because we can break away any time), I think I’m fine with it.

13 Likes
8

What tasks should the OSMF stop doing and which services should it stop providing in order to pay for standing up a GitLab instance?

I am reminded of the major effort that @Firefishy and others went through to stand up this Discourse server. And that’s just a message board. I can’t imagine that a system for software development and continuous integration would be less work than that.

6 Likes
9

When we closed let us say 80% of the Issues · openstreetmap/operations · GitHub and Issues · openstreetmap/openstreetmap-website · GitHub then we can look at running our own Gitlab (or whatever) instance.

14 Likes
10

I would love to help out with that…but since it involves continuing to collaborate over GitHub, it’s a no from me :stuck_out_tongue:

It’s ironic (and tragic) that the OSM community - working on a free data project and ever-concerned with upholding copyleft and attribution requirements - should display such cavalier disregard for blatant violations of copyleft and attribution in the free software realm.

1 Like
11

If you want to encourage solidarity with the FOSS movement, then please do so directly and positively. There can be a reasonable debate about advancing causes beyond the project’s core mission. But you don’t need to accuse our developers of, essentially, hypocrisy by association to make that point.

10 Likes
12

This is the first time I’m hearing that. Exactly how many are there? I don’t have any issues with GitHub.

There are thousands of public GitHub repositories related to OpenStreetMap, which means there are thousands of potential contributors out there.

13

That’s what I thought was doing when I started this discussion. Having seen the responses, though, I’m less likely to try again.

14

If I may make a suggestion: this community has seen proposals for many things, large and small, that flounder because they start with a preferred solution. Without a common understanding of the problem, of the needs that aren’t being met, your proposed change seems quite drastic. The skepticism and defensiveness shouldn’t come as a surprise.

As @SimonPoole pointed out on the osmf-talk list, he wasn’t even focused on any of your seven points per se. He was primarily interested in a venue for OSM community members to provide feedback and interact with developers, regardless of their technical background. Maybe the discussion can be about the degree to which developers and users find this to be a pain point, and whether any of our existing communication channels can help to mitigate the pain.

Do you agree that this is the problem to solve, or do you find that the other issues you’ve raised are all more relevant to this project?

1 Like
15

@Minh_Nguyen My problem is that I want to continue contributing (be it bug reports/testing, feature requests, UX feedback, PRs) to a variety of OSM projects - Vespucci, its presets, NSI, EveryDoor, etc - but I don’t want to use GitHub for that anymore.

At @SimonPoole 's suggestion, I shared the self-hosting idea. Given the negative responses, I’m left with just one option - fork the repositories to Codeberg, contribute there, and let everyone (myself included) suffer the consequences.

I also don’t mind if OSM projects (the website, editors, NSI, presets, etc) move to Codeberg. That’s an alternative worth considering, and one I have been proposing for a while on IRC. But I had hoped a self-hosted server with SSO for OSM accounts would address all the incredulous complaints about “contributor friction”.

16

I agree - I regularly come across people who are struggling to “get” OSM; often they’ve seen a map using OSM data, and would like to understand what is shown there and influence what is shown there too.

There are lots of tools available to help people add things to OSM Data (editors for all sorts of use cases) but relatively little to help people contribute to map styles or other software. The bigger problem here is that we’re actually not short of ideas, but we are short of people willing to put the effort in (for free!) to convert ideas into usable software.

Whenever anyone suggests “OSMF should do X” a reply is “why don’t you do a small scale X first, as a proof of concept”. That’s how many things that are now part of OSMF started (including the original web forums), and it might be workable here. I’ve no idea what’s required to set up SSO using OSM as an IdP for Forgejo (I’d never heard of it until your message above), but it’d be good to outline what you’d need to do the project yourself (including presumably a small virtual server somewhere) as an initially-entirely-separate-to-OSMF thing.

Once you’ve got some PoC infrastructure working I’d suggest picking an initial project that would benefit from the better integration with OSM accounts that this infrastructure would provide. You’ve written about hosting mapping parties etc. - maybe something around that would be a good “first project”?

3 Likes
17

Are you potentially interested in working on setting up such instance?

No promises at all for now (as it depends on other people). But there is a big difference between “someone should put work into moving someone’s else project between platforms, as I prefer platform A to B” and “I am willing to move project X to another platform, and I consulted this idea with maintainer of this project, but I need access to server with X RAM and Y disk space as I am not independently wealthy”.

(mentioning this as you mentioned “@SimonPoole 's suggestion” so maybe there is support to at least have non-github issue report location for Vespucci, maybe accessible with OSM account)

2 Likes
18

I would want to point out that the problem is not running a gitea/forgejo instance, it is one of the most trivial IT things I’ve done in the last 40+ years or so (see https://hub.poole.ch/).

The problem is that running it outside of the context of the OSMF just boils down to, even if completely well intentioned, supplying PI to a 3rd party and if that is OK, then you can just as well go to a 3rd party hoster.

3 Likes
19

I am definitely not promising anything, and this may be entirely bad idea not worth doing for one reason or another and I may be missing something important or unaware of implications and I am not instructing anyone to do anything, and this is not an official statement of any organisation…

But is “Someone volunteers to do entirety of work of deploying and maintaining this software on OSMF server and gets access to do this” maybe a viable thing to do?

And yes, I can see some potential problems:

  • if someone start doing this and disappears week/month/year later then we have one more service that needs to be maintained by OSMF or shut down
  • I am not entirely sure is it possible to give someone necessary server access without potentially causing problems elsewhere
  • maybe hardware costs of running such service are high…
  • time may be invested into this and it turns out to be too complex or someone running it will require too much assistance
  • other problems I am likely missing

But it seems potentially more viable than “someone else should do this” if someone would be invested enough to run it and can do this. And maybe doing a bit of pet project may be for someone a start to help with other sysadmin things on OSM servers if they would be interested?

disclaimer: see first paragraph, maybe it is an entirely bad idea for reasons I am not seeing as I am not OSM sysadmin. If they will tell me or others that it is bad idea please believe them.

20

This is a very important thing to remember. OSM has a very small number of sysadmins who do Trojan work, and have limited time. When I wanted an OSM Mapstodon server/instance, I knew the sysadmins didn’t have enough free time especially for something (at the time) with such low usage, so I just got a paid SaaS service.

If you’re asking/demanding that the sysadmins do this thing… well you might be in for a bad time. If you wanna set up a gitlabhubforge yourself, go for it.

3 Likes