[Osmf-talk] Hosting OpenStreetMap source repositories on free software platforms

Tue Apr 23 08:16:47 UTC 2024

Given that I'm mentioned a couple of times I probably need to make my 
position a bit clearer.

For starters, yes I'm not a particular fan of that big dependency on 
github and find certain aspects of it quite troubling. But it's free (in 
particular the CI system they provide), very popular, with lots of reach 
in developer communities and the collaboration model they invented works 
surprisingly well.

My point in the discussion with Kashish was that simply moving to a 
replacement 3rd party provided service would not only not make things 
better, but for developers just implies yet another service they would 
have to sign up to and expose PI, with other words this would be worse 
than just staying with github. That's where the having an OSMF hosted 
instance of whatever comes from. The practicality of that hinges more on 
the whole complex of providing a CI service and the related costs, both 
in funds and person power, than anything else. Realistically the OSMF 
has neither right now in abundance.

But there's one aspect that hasn't really been touched on in this 
discussion, but it is by far not new: the audience that we serve with 
our github repos is not just other developers, it includes our users 
reporting issues or submitting feature requests.  What we should really 
not be doing is requiring non-developers to sign up to github or any 
other 3rd party service just to submit a bug report. Now there are ways 
around this. For example Vespucci provides a semi-anonymous (if 
available the OSM display name will be included in the issue) way to 
create a github issue, but obviously this causes quite a bit of friction 
and is not ideal for both parties.

Providing an issue tracker for OSM related projects that is accessible 
with the users OSM account, even if it isn't a full blown github 
replacement with all bells and whistles (CI), is an undertaking that I 
believe would be completely in line with OSMFs policies and not unduly 
stress operations. Naturally this would only make sense if there was 
take up on the developer side, which I suspect is not a given at all.

Simon

Am 22.04.2024 um 23:04 schrieb Kashish via osmf-talk:
> 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 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. The same could happen again, if it has not happened 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](https://codeberg.org/) is a Forgejo instance that is gaining popularity among people fleeing GitHub. It includes CI/CD and [static web hosting](https://codeberg.page/).
>
> 2. [Radicle](https://radicle.xyz) 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](https://salsa.debian.org/), 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](https://osmcal.org/event/2492/).
>
> 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.
>
> Kashish (contrapunctus)
>
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20240423/e03ec627/attachment.sig>