I believe that cooperation is essential in development of (F)LOSS software to ensure that the software is robust, reliable, and available to everyone so that it can compete with the proprietary solutions.
This cooperation is often difficult and next to impossible to achieve on current options.
Thus i propose that FSFE should lead the industry by example and provide a constant reminder about the importance of Free Software while proving it’s reliability in the wild instead of keeping the gitea instance on https://git.fsfe.org behind a paywall with disabled user-created organizations.
There are excellent associations that gathered expertise with hosting source forges for the wide public, all with Free Software. E.g. check out codeberg.org or sr.ht.
The FSFE runs a lot of services, partly for everyone, partly for its supporters, partly only for staff and core volunteers. However, our core mission is not prividing Free Software services for everyone (here’s our mission statement).
For the Gitea project itself, we evaluated opening up the service for everyone a number of times. As System Hackers, we decided against it for the following reasons:
We do neither have the hardware nor the time resources to host such a sensible and complex service for an uncertain amount of users.
We are convinced that there are a lot of Free Software friendly offerings out there (see my examples above), and we are happy to support them and inform people that these platforms exists as alternatives to proprietary services.
Our priority is to make the FSFE work efficiently, and all its contributors – volunteers, association members, staff and so on. Git is one part of it, but expanding the potential account holders is not contributing to this priority.
instead of keeping the gitea instance on https://git.fsfe.org behind a paywall with disabled user-created organizations
A large number of persons using git.fsfe.org did never contribute money to the FSFE. We offer volunteer accounts upon request. Also, organisations can be asked for, e.g. for FSFE local groups or activity teams. Please note again: the platform shall be used for FSFE-related work.
SourceHut would be an option, but it requires submitting patches through an email which is currently not popular as it’s imho less efficient and less appealing to the next generation that as a result prefers proprietary services supported by their education.
I would argue that the mission statement supports my proposal as:
helps individuals and organisations to understand how Free Software contributes to freedom, transparency, and self-determination.
enhances users’ rights by abolishing barriers to Free Software adoption.
The biggest issue and the barrier that i see in adaptation of Free Software in Central Europe is that there is no trust in Free Software (mainly on government and business level) which makes the costumers and users to prefer proprietary alternatives as they seems to view the software with warranty as some kind of certification of quality that is very difficult to convince otherwise and as such I believe that by providing gitea and services alike such as mastodon instance, invidious, nitter, etc… would support the trust in Free Software.
encourages people to use and develop Free Software.
From my experience FSF and FSFE are doing terribly in this area as the new generation is from my experience very unlikely to consider using and writting Free Software due to the financial support of companies such as Microsoft that force education institutions to force students to use C# and learn proprietary model while making Free Software movement look bad through the mentors.
I believe that we should do better in this area and focus on educating the new generation on how to write the software, how to cooperate and why is Free Software important where approving this proposal would give us the platform and confidence to do so.
provides resources to enable everyone to further promote Free Software in Europe.
Would argue that providing the platform as proposed fits in this point by definition.
To address the concerns about system resources
We do neither have the hardware nor the time resources to host such a sensible and complex service for an uncertain amount of users.
I see there being many ways to handle the system resources where I am currently proposing adapting the Codeberg E.v. approach that from my experience they failed to deliver on which in short would make the current utilization of processing resources available to the users using frontend such as grafana (demo on https://grafana.dotya.ml/) and limit the creation of new repositories e.g. when the service hits 70% of allocated storage capacity prompting the end-users to consider joining FSFE or sending financial contribution for FSFE to afford providing more resources.
Scheduler optimization can then handle the load on CPU which based on informations from dotya.ml woudn’t be more then 12% of current usage for 5000 users including onion service and not including DroneCI.
In terms of the time i propose to make the deployment available for public contribution and review and process that with lower priority depending on FSFE’s priorities.
EDIT: Links redacted as discourse only allows me 2 links per post
I know I’m risking starting the flame war or a hate speech here - so note it’s not my intention here.
Our goal is to make Open Software as popular as possible. We all have very limited resources. I believe that providing source code and project hosting platforms is important but is not the priority.
To be blunt - use github. As this is at the moment de-facto standard and go-to place for most of the developers, using it will help your project gain popularity.
And smile to yourself that you’re using Microsoft resources in the service of Open Source :).
I don’t agree with recommending GitHub. If you want a GitHub-like experience you can use Gitlab.com, which at least offers a pathway to self-hosting a cleansed variant of it which is only free software.
With this sentence you have already illustrated why it’s not appropriate for FSFE to run such a forge: users would come with expectations, and it’s a struggle to meet them, especially when running a forge is not one’s core activity. And that’s without getting into “political” struggles, e.g. what happens when a project has disagreements over access levels or over banning a user.
I think that Gitea is so easy to install, that any organization (or person) can install its own instance. Can we make it easier for them to install and maintain it? This would be a better help for them then offering them to use the FSFE instance.
Besides, if they cannot trust GitHub, GitLab, etc. for hosting their projects, why they should trust FSFE?
By the way, I have developed some scripts that hopefully make it easier to install and maintain a Gitea instance. Maybe you can have a look and let me know what you think about it: docker-scripts / gitea · GitLab
Rather the issue is that FSFE is setting a bad example by hiding it’s source code behind a paywall for something that doesn’t take lot of resources to run from my experience with git.dotya.ml
Gitea devs are providing a docker image so the deployment is painless, but the processing resources are an issue.
There is also a work on gitea’s federation that would solve these concerns imho.
This looks great.