Hacker News new | past | comments | ask | show | jobs | submit login
The Sourcehut Project Hub (sourcehut.org)
320 points by ddevault on April 30, 2020 | hide | past | favorite | 117 comments



Like many others I too admire Drew's work. But one thing I appreciate the most is the visual style and usability of Sourcehut. I don't know what it is exactly (am not a UX or visual designer myself, although work with them a lot), but to me it is one of the most aesthetically appealing sites I visit.


I used some of their work, so I'm forever indebted to them.

However, I don't like how they treat users, potential contributors, etc.

Like, I started using sway full time, posted a question, started looking at the source code to fix it myself, and then just ended up fixing it for my fork and never pushing it upstream because the main thing I learned through my questions was that my free time is to valuable to deal with them.

Maybe 30 years ago the badge of being able to contribute to open source even though the maintainers are "super tough" meant something. But it's 2020: I want to do things in my free time that make me happy, I want to learn something while contributing to open source, and ideally learn from those who know more than me. So I'd rather just continue contributing to Rust, where everybody is super nice, those who know more teach and mentor those who know less, and in general the community is super open and reflective (e.g. the attitude is not "how come you didn't know this" but rather "which mistake did _we_ make that led you here without learning this along the way").

To me sourcehut is just a fence that keeps the kind of maintainers I don't like at the other side of the github fence.

This attitude is super harmful. Drew is just one person, and they can only do so much, and that does reflect on Sway, which is why I ended up switching back to i3.


Someone on this thread called Drew "militant", which isn't as negative as it sounds but accurate.

I will say, having observed his interactions in a few places, he rubs me the wrong way sometimes, even though it seems his heart is in the right place. I get it, totally guilty of it myself with strongly held views.

Don't mean this as a criticism but rather as a friendly suggestion if Drew is reading, but there are a lot of situations where backing down or just a softer approach is in order, especially now that he's running a business. There are a lot of us that are interested in what he's doing, but hesitant about using his services because it isn't obvious when the it is my way or the highway approach is going to come out.


My observation is that most of the people who get projects done, in the sense that they can manage a project with many contributors over a long period of time with successful outcomes, are considered somewhere between militant and obnoxious by others. The project leaders who are all-around considered nice, like GvR and (so far) Andrew Kelly (not an exhaustive list!) are the exception, not the rule.

I do want to point that millitant/obnoxious/ahole is a very subjective judgement. Personally, I've read many of (what's considered) Linus' worst responses, and I did not find them a problem - he is not gentle, and he occasionally uses expletives, but he is factual, and drives the point through in places gentler people waste ten times as much effort, by themselves (and everyone else) to get the same result - and the result IS good.

I, for one, much prefer to be told "this is sh*t, you need to redo this" (assuming, of course, that's a good summary) than going around and around in endless deliberations about specific details.


> To me sourcehut is just a fence that keeps the kind of maintainers I don't like at the other side of the github fence.

I was with you for a while, but this goes way too far. You had a bad experience with Drew on Sway, and because Drew is responsible for Sourcehut you project this on any project using Sourcehut as its platform?


> You had a bad experience with Drew on Sway, and because Drew is responsible for Sourcehut you project this on any project using Sourcehut as its platform?

I've interacted with ~15 projects on Sourcehut, and all of them are by the same team of people maintaining Sway.

I'm not projecting to all sourcehut projects, just recollecting the experience of all sourcehut projects I've ever interacted with.


> However, I don't like how they treat users, potential contributors, etc.

What are you talking about? The mailing lists are super friendly.


I only interacted with them on Github issues in the sway repo.

The interaction was of the form: "I'm having this problem, I've looked at this, what would be the best way for me to improve this". Reply from Drew "No [issue closed]".

Then using sway, I ran into a lot of problems, and many of them were already reported, but closed issues, which closed with a similar exchange.

At some point, every time I had a sway problem, I would search for my issue on Github with the closed filter first. Finding those issues, with no rationale, workarounds, path forward, discussion of any kind....

Yeah, I just stopped using sway a while after and went back to i3. It at least worked, so I never had to interact with their community.


I'm sorry you had a bad experience with Sway. If you can be more specific, with links to issues, it would be helpful for me to learn to deal with those cases better.

It's worth keeping in mind that maintainers see a lot more issues than you do. It's likely that I've heard and declined your feature a dozen times already, or that it's part of a broader class of problems which has been heard a hundred times. Sometimes, it tests my patience. And sometimes we do just have to say "no" - not every feature or change is desirable, and if we said "yes" to everything, then sway would quickly become a Cronenbergian mess.


Being more specific would give away my identity, but this is one issue I ran into while moving from i3 to sway:

https://github.com/swaywm/sway/issues/1005#issuecomment-3315...

where the comment that closes the issue just says "we'll never implement this, issue closed".

I sympathize with you in that, if you had little time and other things to attend to, then just closing an issue is an instant reward of having something less to do.

But I think it would have been better to, first, don't do anything about that issue if you didn't had the time to do it properly (even if you were the one that filled the issue!), which would have been to write down the rationale why you think that feature is not worth its tradeoffs, and also, to have let other users speak up their mind, and see what others think, before making a decision.

For me, that difference in "project culture" is the difference between an open source project that's worth contributing to, and one that is not.

I've grown a couple of very large open source projects, and some of them I look at once a year, and they keep growing with dozens of PRs per week or day! The main reason I am able to just move on to other things is because I've grown and mentor the new maintainers and leaders of these projects , and I know they both carefully listen to the projects users, and are able to grow new contributors, just like I did.


This was 3 years ago. I usually treat these issues a bit better these days.

However... I disagree with your suggestions about how to go about this better. You're still coming from a place where all paths lead to the implementation and inclusion of the feature. We will say "no" sometimes, and there's no amount of discussion which is going to change that. We're volunteers with a limited amount of time, why should we lead everyone on by entertaining a fruitless discussion in on a feature for which we have no interest in supporting?

There's a lot of discussion you don't see, too. Discussion on the IRC channel, private discussions between maintainers, snippets here and there on patch reviews and other issues... just because you didn't get your say, doesn't mean that the issue wasn't sufficiently discussed. At some point I just don't want to discuss it any more. I could redirect you to /dev/null and let you say your fill, but I don't think that's fair to you, either. You can't always get what you want, and if I don't always give you what you want, that doesn't make me a bad maintainer IMO.


> You're still coming from a place where all paths lead to the implementation and inclusion of the feature.

Not really. Ideally, I'd have read a comment saying: "We discussed this on IRC, and for this and that reason, we decided that this is probably never going to be worth doing. If you have any new information or argument that was not considered above, please do raise it with us, but we are closing this issue for now."

> There's a lot of discussion you don't see, too. Discussion on the IRC channel, private discussions between maintainers, snippets here and there on patch reviews and other issues... just because you didn't get your say, doesn't mean that the issue wasn't sufficiently discussed.

If your discussions don't happen in the open, how open is your open source project really?

You can discuss things on IRC, or whatsapp, or wherever you want, but if a synchronous and/or private communication channel is used to decide on technical issues that impact the project, then you are essentially excluding everyone that doesn't live in your same time-zone, wasn't there on IRC at that time, can't search those IRC logs, wasn't invited in the room, etc. from impacting your project.

That's just not open enough for me, so I don't contribute to projects that work like that.

Rust or th linux kernel discuss everything in the open, so that everyone can see it and participate, whenever they have time to, and make their case. Whether that's a mailing list, a forum, or a github issue doesn't matter.

But closing an issue with "no" isn't very helpful for all those users that weren't in the room where that was decided, and they will all wonder "why".

> that doesn't make me a bad maintainer IMO.

There are dozens of different ways of maintaining open source projects. Just because sway's way doesn't fit me doesn't mean it's bad. It just means that it doesn't fit me. If you'd like to change something so that it fits people like me, the above hopefully explains what the issues for me were. But I don't expect you to do that, and you don't have to do that, and its perfectly fine for you to disagree and don't want to do that.


Our IRC channel is open, and many people watch and participate in discussions there. Many of our contributors and maintainers are also friends, people we ping for advice on unrelated things, and so on, and sometimes discussions happen incidentally. We don't go out of our way to conduct discussions in private, and we make our primary communication mediums available to the public. Just because you don't like IRC doesn't make it less open. If you ask for more details, we will also often entertain your question, especially in the context of "I want to know so I can write a patch". But if you're just another grumpy user bringing their bat up for a swing at the dead horse, then no, we're not going to entertain you.

We're human beings, and we acknowledge that. I don't go out of my way to try and build a community which avoids that fact. Treat us like human beings, people with feelings and knowledge and a limited amount of time. You didn't pay for it, so you're not entitled to support, features, or yes, even explanations of why decisions were made. It's a collaborative effort, run by volunteers, who can stop volunteering whenever they want. Some users get burned by this, but contributors don't, and contributors are more important than users.

Sway is not some abstract concept of a project - it's made out of people.

I know this doesn't directly address many of your comments, but I feel that it hits on a deeper and more important difference in our beliefs. User entitlement is a huge problem in open source, and it burns out maintainers faster than anything else. I don't stand for it.


> Just because you don't like IRC doesn't make it less open

No, but having discussions somewhere completely unlinked to your open source repository without a searchable archive and no way to link to discussions does.

Hell, even gitter, which is a pretty clumsy tool lets you link directly to discussion, e.g. https://gitter.im/SublimeLSP/Lobby?at=5dce95d835889012b111a0... (although the fact that this project immediately moved to discord, a less open discussion tool without easy searching isn't amazing).

Do you prefer having to answer the same questions over and over in IRC rather than link to the discussion from a single authoritative issue?

For context: I'm 27 and in the last 10 years, I've used IRC maybe twice. To me, and many others, IRC is an opaque, closed, system. I have absolutely no idea how I would start to search your IRC channel. Hell, I thought IRC logs were only for conversations you were present for. If you can't just give somebody a link to a conversation (which you can in Slack, Gitter, Discord, Teams, mailing lists, Jira, bug trackers, etc) then I'm not sure it counts as open.

> so you're not entitled to support, features, or yes, even explanations of why decisions were made

I was initially going to respond by saying "then you shouldn't ask for contributions". However, the sway repo is actually much better than most and the CONTRIBUTING.md makes it pretty clear you should discuss things with the maintainers first.

Perhaps I'll update my projects with clearer guidance as to whether I'm interested in contributions...


> No, but having discussions somewhere completely unlinked to your open source repository

https://github.com/swaywm/sway#sway

> Join the IRC channel (#sway on irc.freenode.net).

This is a clickable link.

>without a searchable archive and no way to link to discussions does

This misrepresents how IRC is supposed to work. You're not supposed to catch up on what you missed. You're supposed to have the conversation there. It's like chatting at the watercooler, not writing into stone.

If you're "searching" the logs as part of your normal IRC routine, you're using IRC incorrectly.

>> so you're not entitled to support, features, or yes, even explanations of why decisions were made

>I was initially going to respond by saying "then you shouldn't ask for contributions".

You're not entitled to it, but you might receive it anyway. And the only one of these which relates directly to contributions is explanations - withholding features and support, in fact, leads to more contributions. I have written about this on my blog on several occasions if you want to learn more about this approach.


> If you're "searching" the logs as part of your normal IRC routine, you're using IRC incorrectly.

I fully agree, nobody wants to search IRC logs for technical information about a project.

If the only documentation about a technical decision in an open source project is an IRC discussion, then that project is just doing open source wrong. Those logs are at best hard to search for, and more often than not, non-existent.

When we have "online" meetings (IRC / Discord / Zulip / Matrix / Zoom / ...) to discuss technical issues in our open source projects, we always publish a full summary of the meetings so that everyone who wasn't there can read them and follow the rationale, or raise issues with it.


> Just because you don't like IRC doesn't make it less open.

IRC isn't the problem, the problem is synchrnonous communication channels in general (IRC, whatsapp, telephone, Matrix, ....). If somebody is not available when the discussion is ongoing, they can't participate. That does make your communication channel much less open than, e.g., a mailing list, where somebody from a different timezone can read the discussion 8 hours later and participate in it.

> User entitlement is a huge problem in open source, and it burns out maintainers faster than anything else. I don't stand for it.

What burns maintainers is having too much to do, and the root cause of that is failing to grow other maintainers to help you with your projects, which is impossible to do if you act as a burned maintainer, because open source is something most people do on their free time for fun, and stressed / burned / overworked maintainers aren't fun to deal with.

Sustainable projects have a high-ratio of contributors relative to users. When this ratio is high, it doesn't matter that some users act entitled, because there are enough maintainers to deal with that load. If you have a lot of users, but a relatively small contributor base, that's when things become problematic.

Attracting contributors is probably the hardest part of open source, and like it or not, every project is competing against all other projects for contributors. Projects that are super nice to every user that interacts with them, no matter how "wrong"/"entitled" the user is, or tired its maintainers are, attract the most contributors, because people like working there.

Being tired while dealing with an entitled user and trying to be super nice with them is super tough, but all other alternatives I know are much worse.


you cannot be that emotionally involved, what you take as aggressive is simply someone not giving you enough attention.

and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.


The problem of course is that if you have

- an open source project which you advertise as collaborative open source

- a personal vision for what you want in your project

- and hence, a secret list of requests you will turn down

Then frequently people might spend 10, 20, 30, 60 minutes trying to do something with your project then writing up an issue. You then immediately shoot it down, because it doesn't match your vision, and that person gets burned.

If you have MIT license and no guidance on contribution, that's user error. But if your project has a PR workflow or has that "Imposter syndrome" line about contributions, well, maybe it's partly your fault.

I'm not saying all open source projects should have guidance. But perhaps all projects with a CONTRIBUTING.md and ISSUE_TEMPLATE.md really should have a clear list of features they will outright reject.


One thing that I’ve learned from the Kubernetes community is to have a list of “Non-Goals” right next to every list of “Goals” in documentation, and of course to have a list of “Goals” at all.


> and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.

So if someone sends you a contribution that isn't good enough, you reject them with a "no", and that's it?

Sure, you can do that. A different project might expend some time teaching that contributor and being nice to them, until their PR can be merged. And then the contributor submits another one that's better, and then another one, and then before you realize it you have another full time maintainer that you can trust.

So when you say that if a contribution isn't good enough you reject it I say "Thank you", because that person will move on to a different open source project, which might be one of mine, and I'll be getting another contributor instead.

You might not think that the work required to attract a new full-time contributor is worth it. To me it is.


I feel the same way, and as someone who has struggled to make his open source projects look like anything other than roaring garbage, I am perplexed, and jealous, and guess somehow a little hopeful?

I can totally imagine making something like Sir Hat (sorry) a part-time project and, in an alternate universe where I am a better coder and more dedicated than I actually am, producing something super solid after a few years. I cannot, however, imagine any universe in which I would produce something that looked as good as this.

I recommended it to the Emacs developers (who are considering moving to some sort of forge-alike site) in part because it seems to fit the FSF's principles, but more because the aesthetics are what Emacs should aspire to: plain text that looks good.


What exactly do you think is so revolutionary about its design? I love it, personally, but I love it because it's not revolutionary. It takes some basic design principles and sticks to them militantly, which is sort of how Drew seems to handle everything. It's a successful approach.

Some tips:

If you're going for a flat look (which you should), don't go the Google direction.

* Make it actually flat; no shadows. Shadows are your enemy. Only use shadows if absolutely necessary, and even then think twice.

* Use solid lines to separate buttons and other colorful objects from the page. This is more accessible than shadows, and looks pretty instead of Google's weird 2014 pseudoskeuomorphism.

Use accessible colors!

* You have no excuse for using a color scheme that isn't accessible; accessible color schemes generally work better for people who aren't design-inclined, anyway.

* There are a bunch of sites you can use to check whether a color scheme is accessible, and there are also a bunch that have a bunch of accessible color schemes already laid out for you.

* Do not believe yourself when trying to justify an inclusion of a pretty color that makes the site less accessible. I know the color is pretty. There are a lot of colors that won't make the site harder to view, though!

Don't break from your design. Ever.

* Nobody likes using an application that has seven different styles of interaction and looks like it's from three different eras depending on the page you're on.


What you've described is exactly what I like about it! Just nice visible text, interactive elements are very evident, your eye goes in the right direction, and there's "nothing special" about it.

The tips you've provided are how not to screw up an excellent design. Not how to get an excellent design to begin with.


Thanks for the tips.

I wasn't aware of what an accessible colour scheme is, a bit of searching and clicking led me to the Web Content Accessibility Guidelines guidelines [1]. Now I know to search for something like "WCAG colour scheme" there seem to be many more resources that are a bit less dry.

[1] https://www.w3.org/TR/WCAG20/


There's some really good advice right here:

Take some basic design principles and stick to them


I don't mind the visual style of sourcehut but I find the UI very confusing. I just went to do a few common tasks and I was struggling. First I went to find a list of branches and I had to click through every tab until I landed on "refs" that had it. What does refs mean? I assume its some internal git terminology but why not just call the tab branches. I then went to find out where I could submit a PR/MR and I couldn't find any such feature. I also couldn't find a list of bugs or how to open one.

I'm not really sure what case you would want to use this over GitLab/Gitea which work very well for basically every use case. Especially when you consider that you are driving away potential contributors by using this.


The refs tab is not called branches because it is for references. We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. On hg.sr.ht, for example, it's named differently, because Mercurial is designed differently and has different terminology.

SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such. I have no intention of building yet another GitHub clone. If you insist on everything having the same workflow, then what utility is there in different tools? Be prepared to challenge your preconceptions when learning how to use SourceHut. The documentation is thorough and has lots of tutorials to help you along the way:

https://man.sr.ht/

There are no pull requests or merge requests. We use email, which is how Git was designed to be used. This tutorial will get you started:

https://git-send-email.io

If you just want a GitHub clone, use a GitHub clone. Don't evaluate SourceHut by that critera.


> There are no pull requests or merge requests. We use email, which is how Git was designed to be used.

I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has:

- Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky.

- Ability to search by tags/labels

- Automatic linking between related issues and pull requests (with backreferences)

- The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.

- Highlighting changes in the diff (source hut actually does this)

I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.


Many of these features can be implemented in lists.sr.ht.

lists.sr.ht already has support for threads and diff highlighting. Example thread: https://lists.sr.ht/~emersion/public-inbox/patches/7077


Quick drive-by response:

>Ability to subscribe to individual pull requests

>Automatic linking between related issues and pull requests (with backreferences)

Both are planned

>The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.

Not planned, but you can pretty trivially do this yourself. Just git checkout -b test-branch before applying the commits locally.

>Ability to search by tags/labels

Already there, kind of. You can search by the patch prefix, which is generally used to indicate the subproject. This is also supported outright on tickets, for which it's arguably a lot more useful.


> Just git checkout -b test-branch before applying the commits locally.

I guess that works, but it is a few more steps than clicking on a link. And if you are actively working on the project, it means you have to either switch branches or make a new workspace.


TBH it sounds to me that you just need a better email client ?

Like... that's the program that handles everything that you mentioned.


The best solution to email filtering is not receiving irrelevant emails in the first place. It’s always funny seeing people bending over backwards to justify terrible inconveniences they’re merely used to.

Plus, an email program that handles automatic cross referencing of tickets and commits? Where can I find that “better email client”?


aerc [1] supports arbitrary content filters (programs invoked when showing a message body). These are used for quote and diff highlighting. It would be nice to write a filter that auto-links tickets and commits depending on the List-Id.

[1]: https://aerc-mail.org/


Automatic cross referencing is more than linkifying ticket ids and commit hashes. Issues, PRs and commits elsewhere that reference an issue/PR show up automatically on its page (think pingbacks in blogging), which apparently doesn’t fit into the mailing list model at all.

Edit: Forgot to mention, even

> It would be nice to write a filter that auto-links tickets and commits depending on the List-Id.

is not possible with sr.ht, due to non-1-1 relationship between mailing list and repository/tracker.


Well, an email client isn't a tool just for developing - it's a generic tool that has a lot of use cases. I don't think one should sacrifice features to get diff highlights or filtering PRs, nor should a generic email client try to implement out-of-the-box SourceHut filtering functionality.

Yes, one can use specific filters to accomplish subscribing to a particular PR, but that's complex, and when I'm using a generic email client I can't think of how it can not be complex.


Nothing is stopping you from using more than one email client.


then you would need to configure filters across multiple email clients, which only makes the filter problem worse.


I use two, with very different filters. Since I use them for different things there’s not much overlap between the configurations. The total volume of conf is probably larger than if I’d used one client only, but the user experience is also a lot better (for me) since I can use the best tool in more cases.


Sure. What is that better email client? I don't mean to imply there isn't one, I'm genuinely curious what you email client you think has these features.


> We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools.

I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for.

> There are no pull requests or merge requests.

If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?


>I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for.

In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use. I don't believe that users are not capable of learning new things. In this particular case, this is the first time anyone has commented on "refs" being difficult to understand in the 1.5 years that SourceHut has been around.

>If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?

Yeah, this is still true, and somewhat implemented now. The large blue button on the repo summary page can clone the repo to your account, and then be used to interactively prepare a patchset to send to the mailing list. I'm not sure how Polylactic_acid missed it, actually, unless they don't have an account. The UI only works for account holders, though the big button is replaced with instructions on how to contribute by email if you're logged out.

There's a video of the process here:

https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...


> In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use.

IMHO progressive disclosure is important, because if you want something to be widespread, beginners should be able to use SourceHut with little guidance.

> I don't believe that users are not capable of learning new things.

Well, for the users to learn git terminology, one has to start using git — and one of the biggest reasons is to start using git is to clone popular projects or cooperating between different people. If SourceHut is hostile (I’m not saying that it’s currently hostile, but I think it may improve) for people who don’t what a ‘ref’ is, people have to start using GitHub — and the newcomers of SourceHut becomes the very small portion of people who are already an ‘git expert’ and is interested in emailing patches.

If SourceHut wants to make the email patches/other workflows that SourceHut encourages mainstream, I think it’s crucial for git newcomers to be able to use it. It’s a losing game otherwise.


But your suggestion relies on them knowing what "branches" are - an equally tenuous proposition for a new programmer, I think. Recall that at one point, you didn't know how to use GitHub, either. Pull requests? Cloning? What do these words mean, out of context? New users on GitHub struggle a lot, too, something I know from firsthand experience dealing with new programmers on my GitHub projects all the time.

I would prefer to solve these problems by fostering a culture of mentorship, and being responsive to questions. This is what I do on GitHub, too.


Just to support your philosophy a little bit, most git users are very surprised to learn that a "branch" is a single commit. When they need to do something where this distinction matters, in my experience they are usually stymied. Using a precise model where it doesn't sweep the details under the carpet is good for me. However, I suspect that it will limit adoption to a certain extent. Pretending that something is the way you wish it to be is pretty common in the world ;-) Refusing to use tools that show you truths that you do not wish to acknowledge is similarly common, I think. Still I appreciate the precision and if you are targeting users like me, I certainly won't complain!


A branch is more accurately a text pointer pointing to a single commit


And this is a crucial point. To understand git, you need to understand data structures strung from pointers. Branch then being a [pointer to a] single commit makes perfect sense, just like a linked list being a pointer to the first element makes perfect sense.


You could even call it a "reference", or a "ref" for short :)


I agree with that PRs are a foreign concept — but branchs and cloning is text that almost always appear on introductory git tutorials which make them friendlier than the other terms.

I actually just realized that if SourceHut has a site (like git-send-email.io) that explains git that uses the terms ‘ref’ and etc... (so that a git newcomer can build a proper fit mental model), this problem goes away. Not sure if explaining it easily would be possible though.


I agree with all of this and it's worth pointing out that unlike "ref" which some posters are claiming is too obscure, "pull request" is not even a term within git itself.

As someone who was quite familiar with git before using GitHub, GH's use of that term was the only confusing thing. (It is only not a request for others to `pull` your branch to inspect the changes, it's also a request to merge it into some other branch.)

A term like "ref" is at least part of the standard git terminology, and used in important commands that everyone should know like "reflog".


Thank you for that attitude.


> In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use.

I agree deeply with the ethos this statement represents. It's hard for me to formulate at the moment what I think this "ethos" is exactly, but I think it's really important. I'll try to explain by example. I think we should favor manpages over Stack Overflow, documentation over Google, composable CLI tools over monolithic IDEs, etc. I think that every engineer on a team should have read the most popular O'Reilly book (or some equivalent) for each of the tools the team works with. Of course, these "rules" are not commandments and we should always strive to be prudent.

Sometimes I'm accused of being cranky for these sorts of opinions, and I guess I might be, but I also see so much time and money wasted because nobody in an organization understands basic tools like SSH or how to use systemd.

The other day there was a developer tool on the front page of hacker news that lets you "run apps in the cloud from the comfort of your own editor". This is in my opinion a sign of the techpocalypse.

Edit: s/UPPERCASE/italics/


I generally agree with you. Especially strongly on the point about books.

It is my observation that, just as much as Stack Overflow and various on-line cheatsheets are replacing man pages (which is unfortunate), man pages are replacing info pages. By that I mean they aren't thorough enough. My eyes opened to that point when I started browsing M-x info in my Emacs, and run across documentation of non-Emacs things. Info pages tend to be more like a book than a short manual. And it's great, since if you're going to be using a tool semi-regularly, going through a book explaining it is a boost in learning time and scope.

And as a more general point: I miss the times when software shipped with book-sized manuals.

> run apps in the cloud from the comfort of your own editor". This is in my opinion a sign of the techpocalypse

I guess it depends on where you compose. The above goes against Unix philosophy, but not necessarily against Emacs philosophy. I.e. I consider Emacs as a 2D interface to composable applications (vs. 1D interface a command line is). So a bit of Elisp that implements a cloud API provides a piece that can be composed with just about every other piece of Elisp in Emacs, yielding a solution that's both composable and convenient :).


The issue here in my opinion is not that someone would “run apps in the cloud from your editor”, it’s that a software engineer would need or want an entire SaaS product for such a trivial task.


> I think we should favor manpages over Stack Overflow, documentation over Google

these are not really comparable things. I definitely don't think that Stack Overflow should replace man pages, but I still find Stack Overflow valuable. It's value is in finding how someone else solved a problem similar to the one you had, or where you go to ask other developers for help when the your attempt at finding the needed information in the documentation has failed.


I almost entirely agree, and I think the word "favor" wasn't the best choice. My opinion is that many developers will often consult Google or Stack Overflow before consulting a manpage or documentation or will only briefly consult documentation before a Google search. I'm definitely guilty of this, especially when I'm under a tight deadline, but I think it's a behavior that should be avoided when possible. Navigating documentation and/or manpages forces you to engage with the structure of the tool you're using, Google and Stack Overflow do not.


The issue is that when we hire skilled craftsmen or engineers, we expect them to be familiar with and capable of using the tools of their craft.

You wouldn't hire a carpenter who didn't know how to use a hammer, why do we expect so called "software engineers" to be handheld through using a basic tool like git, which is entirely based on simple structures like a DAG, immutable hashes and pointers?


> In this particular case, this is the first time anyone has commented on "refs" being difficult to understand in the 1.5 years that SourceHut has been around.

To be fair, when I tried sourcehut the first time around, I did go ‘wtf’ when I saw branches being called refs.

I didn’t end up using it though, so I’m probably not the target market.

I do like the reasoning behind the hub released now though, so maybe I’ll try again.


I use hg by choice and git when needed. The git interface feels confusing to me, but after learning the data model (enough to construct commits with the github data api) it suddenly seems a lot simpler, which I feel is a good reason to grok what "ref" actually means.


That is true, but I’m not sure if it’s a good reason to use ‘ref’ in daily conversation.


> We use email, which is how Git was designed to be used.

> If you insist on everything having the same workflow, then what utility is there in different tools?

I'll admit many if not most git users have only ever tasted the GitHub workflow, but there are also many who have experienced the old school email workflow and the GitHub workflow and legitimately prefer the latter. Two major considerations:

1. A lot of value-add around pull requests, both in terms of organization/filtering and lifecycle features (inline comments/reviews, CI/CD integration, policy enforcement, merging from web interface, etc.). I planned to go into details here and actually wrote quite a few bullet points before realizing I can't do this topic justice without spending a lot of time to produce a huge wall of text, so please excuse me for the lack of details. (Note: not saying CI/CD integration is impossible with the email workflow, but it doesn't seem possible on sr.ht at the moment without manually pushing someone else's patch to a branch of yours -- correct me, and other implementations I have seen are nowhere as streamlined as those provided by GitHub and clones.)

2. Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete (e.g. In-Reply-To is not covered). Even the incomplete coverage highlights the complexity. Now what about the git-am side of the equation? How do I fish out a patch from my email client, any email client? How do I figure out which commit to apply the patch on top? Then there's the branching and git-am dance. Maybe it could be streamlined if you use some sort of hacker's mail client with ninja plugins, but you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly. The PR workflow, on the other hand, stays within the boundaries of push/fetch/pull/checkout, the basic operations required for working with any git remote and core competency of any git client (if you choose to use one); no ninja mail client required. hub(1) makes it even easier.

I don't think "how Git was designed to be used" is a strong defense, Linus isn't almighty and what he originally designed could be improved.

I can understand not being a GitHub clone, but when flexibility is a stated goal (I'm sort of reading between the lines, correct me if I'm wrong) maybe it doesn't hurt to support multiple workflows (a lot of work of course). Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table, which is in itself okay depending on your goal.


>inline comments/reviews

>CI/CD integration

>merging from web interface

All of this is possible and planned for or already working on SourceHut. Remember, SourceHut is an alpha - don't write it off just yet because it's not entirely complete.

>Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete

I intend to follow-up with git-am.io at some point, for what it's worth. And I disagree that it's incomplete: it just encourages a workflow which doesn't use In-Reply-To. It covers follow-up patches without it.

>you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly

My response to this is (1) you can use multiple email clients for different reasons, you don't need to give up your current one; and (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.

>Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table

Popular, yes. Superior, definitely not. But leaving that aside: I am okay with leaving potential users on the table. I'm not maximizing the possible userbase of SourceHut. I'm building a platform that embodies my development principles, for people who find those principles worthwhile.


Good to hear all the planned features in this reply and https://news.ycombinator.com/item?id=23041522. One small clarification: re: inline comments/reviews, what I had in mind was all reviews aggregated on a single page, not scattered and obsoleted by each patch version, which means comments are basically lost if not immediately addressed.

Anyway, it seems to me that once you have all these planned features, the workflow would inch towards the Phabricator workflow, and to a lesser extent the GitHub workflow. The only major differentiator would be that you use emails to send in patches instead of using a branch. The actual code review activity would center around the web interface instead of the mailing list. That would mean (if my interpretations are correct) we disagree to a much smaller extent than I thought, but that would also mean your workflow is actually pretty different from “how git was designed to be used”, which I interpret as the mailing list-centric workflow of lkml (as I understand it; I’m not involved) and other old school projects I have participated in.

Re mail clients:

> (1) you can use multiple email clients for different reasons, you don't need to give up your current one;

It’s possible, but not pleasant. Each client needs to be configured so that mail intended for the other doesn’t clutter it up (not only inbox, but also search, archive, etc.). Usually people already use two or more mail clients to begin with (pc, mobile), so, more configurations.

> (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.

Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails...


>Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails...

_I_ like using emails. But the point of tools like that are so that people who don't like using emails can use other tools instead, and seamlessly collaborate with people who prefer to use emails.


Out of curiosity: what do you think of the attempts to create something better than emails for communication? Maybe easier to host without getting harassed by big corps anti-spam systems. Maybe with cryptography being easier and less error prone to use.

What do you think of something like Matrix?


What I found confusing is that after finding the source code page for a project, I couldn't figure out where to go navigate to the related bug tracker, mailing list, wiki, etc. It looks like the project hub now has project pages that help with that, but the individual pages don't seem to have backlinks to the project that contains them (or at least if they do, I can't find them). But it's still a work in progress, so hopefully that will come in due time.


I find the text a bit hard to read (and it seems at least one other commenter mentioned the compressed line-height).

What I do notice is that the site loads very fast (sub-1s w/ cache disabled via devtools to simulate first visit, and sub-50ms otherwise). That alone deserves big props.


I am very proud of our performance :)

https://forgeperf.org/


I think Codeberg.org is not doing the (normally very fast) Gitea any favors here, because it's hosted on Hetzner in Germany. Lighthouse may only throttle the connection further.

Where are the tests being run from?

Is there any way to control for network latency (maybe subtract the ICMP rtt from the tests?)

You might consider comparing it to other Gitea instances like https://try.gitea.io/ (Digital Ocean / USA), https://mirror.git.trinitydesktop.org/ (Czech Republic) or https://gitea.com/ (China), but I guess Codeberg is probably the most representative instance for public use.


This has been brought up many times, but latency and bandwidth is controlled for with Lighthouse. The same tests have also been run from Germany without appreciably different results. It's also easy to run the test suite yourself if you have an hour of compute time to spare:

https://git.sr.ht/~sircmpwn/forgeperf

The goal here isn't to compare forge software (that would require a completely different approach to level the playing field), but to compare hosted options. The test suite is easily extended with other hosts or pages, and a few people have tested against their own Gitea instance - usually it ranks somewhere just above the middle of the pack.


Line-height on Sourcehut itself is reasonable. It's just on the blog that it's off.


some heavy caching is happening somewhere.


No caching (except for the CSS file, which your browser is probably caching), just simple pages and lightweight backends.

https://forgeperf.org

All of our pages are done in 2 requests, or 1 with a warm cache.


I was going to ask how you speed up pygments so much, but apparently the answer is "actually, some stuff is cached".


Ah, yes, some stuff is cached :) but it doesn't do much, we kind of cache it on principle. An example that makes more of a difference is the git SSH pipeline.


Drew, congrats! I love the principles you hold fast too.

Q: does this mean pricing is no longer optional?

https://sourcehut.org/pricing/


Payment is still optional, and SourceHut is still considered an alpha. This completes only one of a few important milestones blocking the beta.

And, thank you for the kind words :)


Well, don’t wait too long before you charge :)

I realize we can all make optional payments but I’d love for you have committed reoccurring revenue you can count on.

(I say this as a huge admirer of what’s you’re working on and accomplished)


We have enough :) Not a lot, but enough, and a little more than that. You can keep an eye on the financial reports if you want to see for yourself:

https://sourcehut.org/blog/2020-04-13-sourcehut-q1-2020-fina...

Note that I have secondary income sources, and we also make some money from lending our staff out as part-time consultants. It's not important to me to maximize the earning potential of SourceHut. The mission is to make the free and open source ecosystem better, not to make our own pockets richer.


I have a hard time telling if I admire your mindset more than your work or the opposite… :)


Drew, Consider adding a line-height on .content of 120%. Should make it a little bit easier to read.


Good suggestion, thanks.


I love sr.ht but for the love of God can we please have an easily deployable Dockerfile for selfhosting? I'm almost positive its lack stems from Drew's ideals of how software ought to be distributed but it would really help with wider adoption. Sometimes you don't have he luxury of dealing with a NixOS or straight Debian system or you're running containers-only because of company policy and so on and so forth.


This was brought up a couple of times, start here for the response:

https://news.ycombinator.com/item?id=23037904


Let me be real with you for a second in one of those let's pretend we've just taken a bunch of psychedelics and all the structures that prop us and our beliefs and ideals have collapsed: I really think you should reconsider your position on this. Containers are ok, they are not a threat; the kinds of people who are going to be selfhosting your stack are the same kinds of curious, investigative people who will debug when it all falls down. Those people do not need to be pushed through a manual series of commands as a hazing ritual.

I'll be just as real with you that I'm not going to be the one to maintain it. It's in the best interest in the platform's broader adoption I make my plea. Because people like me will just flounder on the rocks of the GitHubs of the world. And that's not a future either of us really want.


It's not a hazing ritual, it's a necessary series of learning steps which equips you to be a good sysadmin of your new instance. Whatever did we do before Docker? The world must have sucked back then!


Not to be snarky but Docker (+ Hub) is mostly just packaging with some isolation to avoid conflicts, right? So why would you recommend packages from "regular" package managers (as seen in the installation instructions) but not Docker? (This is a serious question, maybe I am missing something.)


Because Docker is a really shitty way to package applications. You don't package the application, you package an entire linux distro, with it's packages, and your application into a single opaque blob. Normal package managers just package your application in a more simple manner which works in conjunction with your OS, not on top of it.


It makes sense to package and isolate the base system since it avoids any "hidden state" that could influence the behaviour of your program and introduce hard-to-debug errors.

And it's not packed into a single opaque block: You can specify an image to derive your image from and Docker will overlay-mount your image on top of the base image, avoiding the need to store multiple copies of a base image.


I can equip myself by reading the docs. I don't need to run through the Arch Linux or Gentoo Handbook because I want to run Arch or Gentoo. I can do those experiments in my own time, after I've delighted in what those distributions have to offer.

Besides, none of this addresses the laundry list of reasons why running the distributions that package your stuff is unfeasible: a server administrator with a Synology NAS, an enterprise lackey with a limited environment, or one working with any of the containers-only enterprise distributions.

Guix System (another really cool FOSS thing) and sr.ht are beautiful projects from the outside but they are hampered by their inflexibility, adherence to dogma, and resistance to critique. I once wanted to play with Guix System's new `deploy` command on a DO droplet and nobody really wanted to consider that their newfangled command was entirely bungled. You can see this kind of treatment to potential contributors echoed in examples throughout this post's comments. It is endemic to FOSS communities. And it sucks.

Ideals are only realized in compromise. There is no example in history of anything else.


Hey ddevault, thank you for work, especially Sway and Wlroots. Is there any plan to distribute Sourcehut as a docker image for installation? I personally self-host a number of applications myself (using Docker+Traefik), and would like to move to Sourcehut from SCM Manager.


Thanks for the kind words :)

However, there is no Docker turn-key installer, and no plans to make one. I elaborated on this here:

https://news.ycombinator.com/item?id=23037232

But, I've also long acknowledged that if someone else wanted to make a set of third-party Docker images, it would be feasible, and I wouldn't be bothered by it (so long as you didn't ask me to support it).


I see, thanks for the reply. I didn't make my own only because I don't usually have time to maintain and monitor for new updates; but if updating it is as simple as `apk update`, then that shouldn't be a problem.



Happy for you Drew, I've been following you on and off for a few years, feels good to see someone being able to live off the kind of work you do.

I like the minimalist approach of many aspects of your work. And the whole website using no JavaScript is also very nice to see.

Have you thought about adding some opt-in JavaScript to enhance the user experience?


There are 2 or 3 small touches of JavaScript here and there which make conservative enhancements. But, it's a base design requirement that all features have to work without JavaScript - and once they do, adding JavaScript doesn't often seem very compelling.


Where would you imagine JavaScript being added?


Great to see things progressing. We're currently self-hosting gitlab, and the relatively tight coupling of repo and issues/issue boards is an itch for us.

How is the self-host story for sourcehut (paid or gratis)?

Is there a turn-key variant with turn-key upgrades a la gitlab omnibus installer?


The self-hosting story is pretty good(TM). It's not turn-key, and there is not an installer. You need to run through the steps manually, which are documented here:

https://man.sr.ht/installation.md

Most people get this done in an hour or two, sometimes with the help of #sr.ht on irc.freenode.net. It's also often made easier by the fact that you can skip any services you don't need, like paste hosting or wikis. By making you go through the steps and set it up, it makes sure to leave you with an understanding of the pieces and how they fit together, so you're better equipped to deal with it if/when it breaks and to adapt it to your particular circumstances. After you set it up, upgrades are usually pretty painless, you just run `apk upgrade` and it takes care of the rest. In general, I think this approach makes a lot more sense than the turn-key Dockerized approach.


Thank you - I followed a link that said "open source" and it took me to a list of repositories (which is nice, we all like open source) - but I apparently didn't land on the install-link (to be fair, I didn't look very hard).

I'm not sure I'm a fan of many approaches I've seen (gitlab omnibus is not a docker install, BTW).

You appear to be supporting alpine Linux - and also Debian derived systems - via packackes?

Packages, obviously, is a nice way to install software... If I wanted an appliance - I should set up an alpine vm, install source-hut components I like, point it at a managed postgres instance and a smart mail host - and assume I'll only ever need to do rolling updates via apk - and distro upgrades via alpine?

Is running on Debian likely to be as smooth?


If you remember where you found that link, let me know, so I can update it.

>Packages, obviously, is a nice way to install software... If I wanted an appliance - I should set up an alpine vm, install source-hut components I like, point it at a managed postgres instance and a smart mail host - and assume I'll only ever need to do rolling updates via apk - and distro upgrades via alpine?

Yeah, that's about right. Upgrades are done just by running your normal package manager updates.

>Is running on Debian likely to be as smooth?

The Debian repository is community-maintained, but the maintainer does a good job and a few people have reported sucess using his packages. We also set it up so that upstream releases automatically update the Debian repo. You'll have to depend on him for support, though, not me - his nick is dlax and he hangs out in #sr.ht on irc.freenode.net; and his email is given on the package page. He's a helpful fellow.

Alpine Linux is indeed the officially supported platform, though, and I highly recommend it. I wouldn't dream of running a different system in production, Alpine is simple and reliable and it's easy to fit the whole thing into your head.


Thank you.

> If you remember where you found that link, let me know, so I can update it.

I belive it was the "100% free and open source" link in this very post:

https://sourcehut.org/blog/2020-04-30-the-sourcehut-hub-is-l...

Which goes to: https://git.sr.ht/~sircmpwn/?search=sr.ht

Which does indeed link the repos - which is good - but from a mindset of "how do I self-host?" maybe a bit bare bones.

Looks like if one follows any of the repo links - the install info is at the bottom. May be an artifact of me being on my phone.

As I said, I didn't look very hard.

I really appreciate the no-nonsense/no hype vibe - but at the same time, I really do want a "here's a sane way to get up and running" front and center.

Now, obviously there's a hosted offering - but at my current company we have a few projects that we feel more comfortable self-hosting due to the nature of some of our customers. For some, we avoid third parties, where we can.


Thanks for the tip! I've updated that URL to the following, which is much more helpful:

https://sr.ht/~sircmpwn/sourcehut


Pretty sure you can find all of the code here: https://git.sr.ht/~sircmpwn?search=sr.ht However, I don't know how easy it would be to piece all of the components back together... but, I did find the installation instructions here: https://man.sr.ht/installation.md

And if you're just looking for Git hosting, here is the install doc: https://man.sr.ht/git.sr.ht/installation.md


You can also find all of the code here:

https://sr.ht/~sircmpwn/sourcehut

In a nice new project hub UI ;)


:) That's where I looked!


In case it helps anyone: you can turn off issues in a GitLab project if you don’t want to see them.


Oh, it was more a reference to the opposite thing - we have some projects under an org umbrella (gilab/yellow/slicker gitlab/yellow/wellingtons) - and those issues aggregate nicely under (gitlab/yellow).

But both for managers managing many top level projects, and for developers that are part of those (gitlab/yellow, gitlab/pink...)-gitlab falls down a bit on keeping things organized - it's hard to see if issues in yellow is keeping someone busy and so leaving issues hanging in pink.


Community Advocate from GitLab here! If I understand you correctly, you are looking for a way to aggregate analytics across GitLab, so that users can view information across multiple projects and groups in one place.

We have the Analytics feature designed for that [1]. Please be aware of the distinction between Group-level and Project-level analytics described there.

If you have any feedback on how we can improve this feature, or if you have other ideas, please open an issue [2] and share as many details and examples as possible. We'd love to look into it!

[1] - https://docs.gitlab.com/ee/user/analytics/index.html.

[2] - https://gitlab.com/groups/gitlab-org/-/issues


No, I just want an issue board where I can view/assign/create issues across users and projects, with common labels - so I have one board with todo/doing/blocked/in-review/done.

Ideally with a filter on which projects to show.

This works for hierarchical structures today, but not across them. (I'm not sure the current data model is easy to bend into this, so it's understandable - it's just one of the few things we've seen that would let us to more of the project mgmnt in gitlab directly).


Thank you for the explanation! I just opened an issue proposing this [1]. Please add a comment with any additional feedback that you might have or feel free to ping me if I didn't fully understand what you are proposing.

[1] - https://gitlab.com/gitlab-org/gitlab/-/issues/216573


Sorry but it is late for me and I don’t understand. In general we try to allow you to aggregate at all the group levels and help you group under epics.


This is excellent. The great thing about Sourcehut is that if you have extra git remotes, you can keep working like nothing ever happened if the site goes down. Issues and patches are decentralized over email.

The Project Hub looks like an excellent way to tie together all the separate Sourcehut services to better compete with other "complete" VCS-based collaboration suites like GitHub and GitLab. In the future, it would be really cool to expose an API to allow adding "custom" services that aren't part of Sourcehut.

It's good to see Sourcehut focusing on project discovery, since this is the area where GitHub excels at the most. When I search for a small CLI/TUI utility, I often run these filters:

- filter out weblangs, frontend-oriented languages, and languages with heavy runtimes (JS, TypeScript, CoffeeScript, Vue, CSS, HTML, Dart, Purescript, Livescript, Elm, Swift, JVM languages, .NET languages, Vala, QML, etc.). I have several shortcuts for many combinations of languages so I don't have to type them out every time.

- filter repos below a certain size (a repo above 10mb is probably full of bloat).

- If applicable, filter out repos whose last commit was before a certain date.

- If applicable, filter by topic

- If it concerns a recent technology, I can filter repositories created after a certain date.

- If I want to try a smaller project that isn't cursed with mainstream success, I filter repositories below a certain number of stars.

For instance, if I feel like my MPD setup is missing something, I might search:

  mpd stars:<150 pushed:>2019-01-01 size:<8000 -language:purescript -language:livescript -language:vue -language:javascript -language:typescript -language:coffeescript -language:elm -language:dart -language:java -language:scala -language:kotlin -language:clojure -language:groovy -language:php -language:objective-c -language:objective-c++ -language:swift -language:css -language:HTML -language:haxe -language:csharp -language:fsharp -language:"jupyter notebook" -language:powershell -language:cuda -language:assembly -language:tex -language:batchfile -language:erlang -language:elixir -language:emacs -language:vim -language:plpgsq -language:julia -language:xslt -language:systemverilog -language:verilog -language:hcl -language:tsql -language:jsonnnet -language:gdscript -language:r -language:smarty -language:freemarker -language:nix -language:saltstack -language:"visual basic" -language:"visual basic .net" -language:plsql -language:"rich text format" -language:dockerfile -language:vala -language:QML -language:actionscript -language:matlab -language:alloy -language:cobol -language:graphql -language:m4 -language:qmake -language:fish -language:opencl -language:json -language:rmarkdown -language:xml -language:markdown -language:applescript -language:puppet
The result [0] shows quite a few nice utilities. If I want to go even more minimal, I could filter out Ruby and even Python projects.

It would be great to have a FOSS implementation of an advanced project search utility that isn't limited to (or even part of) any particular hosting provider. Maybe ActivityPub could help facilitate connecting and indexing project metadata from different hosting providers.

[0]: https://github.com/search?o=desc&q=mpd+stars%3A%3C150+pushed...


Congratulations to everyone involved and using Sourcehut! It is good to see viable, free alternatives to Github rising. The developer ecosystem becomes weaker if almost everyone get trapped in a corporate monoculture.

Personally, I trust fossil-scm for my side projects. Albeit based on a completely different design philosophy, I recommend to check it out for everyone eager to look outside the box.


Thank you. I spent ten minutes looking for a project index when I discovered sourcehut today, and failed to find one.

Am I blind, or is there no link to https://sr.ht/projects from the main sr.ht or sourcehut.org pages? What is the expected path of discovery?


Bravo! Congrats! Thank you!




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: