Considering Sourcehut
postmarketos.org
postmarketos.org
I too am not really happy with GitLab.com. It requires contributors to fill a reCAPTCHA and I'm not a fan of it being open core. I chose Gitorious (and was moved to GitLab.com when it disappears) precisely because I don't want to endorse proprietary software, nor tracking. I don't want to run proprietary code - from Google! - and, above all, make people run Google's proprietary code and tracking. That's just not coherent. GitLab is considering moving to hCaptcha if I remember correctly but that's still proprietary and still a third party.
So I made the jump two weeks ago. I now self host my code. I pay for the resources I use so no more strange free lunch. I personally find SourceHut a bit bare but that might just be habits. I picked Gitea instead. People can log in with their GitHub or GitLab account if they wish so the argument that it prevents contributions because you have to create yet another account does not hold. Gitea is quite fast and works well without JS at least for consulting the code. It's quite easy to set up - I have already been self-hosting a number of services for years know. It's also very straightforward easy to use - much more than GitLab so far. I don't force anybody to run proprietary software to use or contribute to my projects.
For people who don't want to self host but would like an alternative to GitLab, Codeberg [1] is worth checking out, in addition to Source Hut. It uses Gitea. It's been mentioned in one of the latest blog posts from Drew Devault (the creator of SourceHut) by the way. It's hosted in Germany, too, if it matters. I guess it would be good to support them.
I also chose this exact approach.
Previously, I ran GitLab, GitLab Registry and GitLab CI and while I think that it's a nice ecosystem to work within (especially at work, where it still is an excellent option, as long as someone else manages the instance), it was also a bit heavy on the resources and updating across major releases... just didn't work. I wrote about that previously, "GitLab updates are broken": https://blog.kronis.dev/everything%20is%20broken/gitlab-upda...
So, eventually I switched over to Gitea, Drone CI and Nexus, all of which now comfortably live on a single VPS with 4 GB of RAM. The performance is good, the resource usage is acceptable and when things break it just takes the individual component down instead of the whole platform (which is also nice for more granular updates).
I actually did a writeup about the switch in more detail "Goodbye GitLab; Hello Gitea, Nexus and Drone": https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...
Of course, actually applying those updates is still somewhat of a problem and will definitely be so until the end of time or until I get enough spare income to make someone else worry about all of that for me (including moving back to cloud platforms and paying for private Docker image storage, CI etc.).
But honestly my current setup is good enough for me, at about 6 euros per month for the hosting (my time is more or less worthless so not counting that).
I'm not going to say that GitLab is evil. I don't think it is. I don't see the world like this anyway. But yes, there are proprietary bits involved in Gitlab.com (and the service actually runs Gitlab EE afaik). What do you expect from me as a free software enthusiast? Close my eyes and suck it, or live to my principles, which is easy considering there are good open source forges that are also not based on an open core model?
As cool as GitLab is to the eyes of many people, I don't like making unnecessary exceptions.
Now, I would still be fine self-hosting GitLab CE. But from a technical perspective, Gitea is probably better than GitLab for me: it's lighter on resources and easier to maintain. I also like the UI better.
AFAIK Sourcehut is only free currently because it is in alpha stage. So it will cost at least $20/year in the future. (Which is still way cheaper than GitLabs Premium plan, but still: it isn't "free")
I don't think people think enough about that fact. Sourcehut is not a "free" alternative if you plan long term.
I think something like codeberg.org would be a real "free" alternative. Because Codeberg - as a non-profit - doesn't plan to sell anything in the future.
- It's always affordable; if you cannot pay for any reason then you'll be given free service.
- Payment is not required to contribute to projects, just to host them.
- Paying for SourceHut makes more sense than paying for other platforms. The money stays in FOSS and keeps the platform accountable to its users, not its investors. Choosing a free service means that you're subject to someone else's demands -- that is, whoever is actually footing your bill.
pmOS is already aware of this, in fact they're already paying to use the CI service. Still: it's important for new users to understand this. Everyone who signs up is sent a welcome email which lays out these details.
Free as in beer or as in freedom? In podcast they say that GL isn't entirely open source and they don't like that they're using some proprietary features of it.
(1) “After gitlab.com's recent changes to the free tier, we have been seriously reconsidering if gitlab.com is still the best development platform for postmarketOS.”
(2) “SourceHut is a great match for the postmarketOS principles: AGPL licensed, no Open-core model; ...”
I don't think you think enough about this fact. For a large open-source project, $20 a year is about as close as "free" as one can get.
The git-by-email setup is more inconvenient. I haven't found an email setup I'm comfortable with. I also haven't tried a lot, but with a pull request system like github there's not really anything to try.
Overall quite happy with sourcehut for my needs.
Due to the distributed nature of git, that's not actually required. Any sourcehut project can merge branches that exist in different places on the Internet.
The feedback and reviewing process might be more cumbersome, but accepting code contributions is not impeded in any way.
I guess the various hubs, labs and buckets make it slightly harder to run malicious code on your own box, but the difference might be smaller than one would think.
Of course I can't speak for the devs of PostmarketOS, but on my own projects hosted on Sourcehut, that's how I ask for alternative contributions coming from people uncomfortable with sending patches using email.
Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden.
* And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.
What are you talking about? (The general tone suggests that you're refuting something about my comment. What part are you trying to refute?)
Surely it would be a million times more intuitive for forges to offer a "submit a patch to this project" feature?
FWIW, it's possible to do it for GitHub etc as well. These CI providers try to get you to use their bespoke "Actions", ie custom DSLs that only work with the one CI provider, but nothing prevents you from ignoring all that and just writing an "exec this shell script" step. It's what I do for all my GitHub repos. I can run the script locally just like the GitHub CI does it in its VMs.
The cloud is really about one thing and one thing only. Vendor lock-in. I don't accept that. And I don't see any sensible reason for it.
[1]: https://scm-manager.org/ [2]: https://www.mercurial-scm.org/wiki/MercurialHosting
As the administrator I also really appreciate that there is an APT package available, so it is updated with the rest of the OS via unattended-upgrades. They also provide Docker and k8s installations. Except for the v1 to v2 migration 3 or 4 years ago that was a bit chaotic at first, it has been a very solid software.
This is "just" a repository hosting software though. It will not force you to use a specific git flow, there is no PR/MR interface. There are some plugins to enable some workflows, but nothing specific. While not numerous, there are several integrations available, like JIRA or Redmine, even LDAP for authentication.
There are no CI/CD part either. There is a Jenkins plugin though. Or you can also configure webhooks to be called on push events and design your own CI around it.
>Projects running on Replicant may be hosted on Savannah. Projects having dependencies on nonfree software, such as proprietary software drivers or AndroidOS, are not permissible.
Edit: As a commenter suggested, I will elaborate a little:
I'm a big fan of minimalist and lightweight UIs, that's not my issue with SourceHut's design. My issue is the disregard for several established UI principles (balance, proportion, repetition, etc.). Some examples:
- The login[0] and register[1] pages have completely inconsistent layouts (left aligned vs centered aligned, one has a header and the other not, etc.).
- The margin between the top navigation and page content is inconsistent from page to page.
- Inconsistent styling of links. Some links have an underline that disappears on mouseover, while for some other links, it's the opposite[2].
- Inconsistent use of margin/padding all over the place.
Etc.
[2] https://sr.ht/~martijnbraam/photoflow/ see "View project feed" vs "public-inbox" links at the top.
It's like that so that page sizes are as a small as possible, to cater for all users on all platforms in all locations. Not everyone is American or European with a gigabit connection. No pointless theming, no pointless javascript, no trackers and so on.
Yet I find the layout in Sourcehut really confusing and not self-explanatory.
Not having a bugtracker UI and having to jump around different FQDNs related to the same project is a usability killer for me.
I don't expect forges to copy github. E.g. trac is very different but still has a rational and friendly layout.
EDIT: I also like that codeberg.org is non-profit and community-driven. If the sourcehut UI was to become usable I wish codeberg would run an instance of sourcehut.
Another aspect I would love to see is federation.
I'm eager to see that implemented, because it will be a good step forward.
The register link is actually: https://meta.sr.ht/register. You pointed to meta homepage. When you proceed to enter your info (username/password) you'll see the layouts are consistent.
Even if we compare, https://meta.sr.ht/register/step2 and https://meta.sr.ht/login, the widths of the layouts are different (730px vs 920px).
Or maybe it's just a matter of taste? Personally I find many popular proprietary applications (including web "applications") as comfortable and enjoyable to use as walking on two hands backwards while blindfolded. Yet most people around me seem quite satisfied.
it feels all too common for folks to rage against bloaty interfaces (i agree, they're terrible!) but swing wildly back towards clunky browser-default randomness. you can have a consistent, polished interface without javascript and tons of images!
one thing w/ sourcehut that i find adds confusion is their choice to make their various services (source vs tickets vs mailing lists) completely separate apps. start on this page:
https://sr.ht/~martijnbraam/photoflow/
when you click on the "source" tab what do you expect will happen? i expect i'll go to a page with a source tree, listing files and directories. i also expect that i'll now be on the "source" tab at the new page, and will have the option to click back to the "summary" tab or any of the others that i currently see.
instead, you're taken to basically the same exact summary page (displaying README content) but with some git commit info on top. the highlighted tab is now... SUMMARY, AGAIN and there's a completely different tab set available to you. there is no way to click anywhere to get back to the previous version of the summary page and explore that tab group further.
i'm sure this makes sense to some folks (and they'll explain why i'm wrong below), but to me it feels like a cohesive user experience is not being prioritized here, and that's something i value ¯\_(ツ)_/¯
A sourcehut project can have as many as them as there are required. Therefore the Source tab takes you to the main git/HG repo that you have added for your project.
That's also the reason why the descriptions are different, one is of the project, the other is of the repository.
It's only confusing if you dismiss everything that's not a clone of github without investing the little time it takes to learn about the differences.
> "bloated Javascript"
> "pointless javascript"
> "javascript-free UIs"
I don't know how much people have worked in UI and with front-end code (HTML/CSS/JS) but... the commenter criticised the UI. Javascript is not a UI language. Being a front-end language it's used a lot in close conjunction with UI components to control interactivity and data flow, but it has no responsibility for their appearance. In terms of aesthetic visual design, the amount of Javascript you have behind it isn't really relevant.
I do see a lot of people mentioning performance (which is a great feature of Sourcehut's), but is also a separate topic.
(fwiw I also love Javascriptless interfaces, not arguing that)
That's why people were mentioning JS. If you've worked on frontend UI then you can't tell me you don't know what I'm talking about.
(And yes, I know it can be done with just CSS instead of moving an absolutely-positioned header with JS in scroll events. Tell that to the websites that do it, not to me.)
Noone was talking about whizzbangs here, least of all the gp.
However reviewing now I’ll say that for whatever reason it seems things are much improved. Still not my personal favorite but significantly more clear.
e.g.:
The current homepage has an odd out-of-place looking blue banner. This is largely down to uneven margins and paddings applied to the banner content - in particular vertical paddings aren't optically aligned with horizontal.
This same issue was once common through sourcehut's content but it's already clear how much that's improved looking at how much better the primary homepage content looks in contrast to the banner.
There's little tiny niggling issues like that everywhere - often related to vertical alignment not matching horizontal alignment - and while each is individually negligible, the cumulative affect is a bit jarring. But I still see it improving all the time.