[sneak]

I always got the impression that sr.ht was not intended to be social software, but simply a git frontend.

To me, this makes it unsuitable as a frontend for community-focused projects that cater to involving and attracting strangers, and much more something for single-committer repos.

Ultimately, building large software ends up being a team sport, and I never got the impression that your product had the express goal of facilitating (and causing) collaboration; in fact quite the opposite: that those are explicitly out of scope for the project.

[ddevault]

SourceHut is designed to facilitate collaboration, of course, but it's done differently from platforms like GitHub and those that seek to emulate it. And of course it is more than a git frontend, providing tools specifically to facilitate collaboration such as mailing lists and bug trackers. SourceHut is an engineering tool, not a social network. It is designed to get your work done and then get out of your way.

GitHub is explicitly designed like a social network, and this is a design that we reject. Counting stars and scrolling through feeds is a distraction from getting work done, not to mention an unhealthy relationship to have with your work. Popularity is not a metric we think that people should be optimizing for, or one that can even be effectively measured.

So our design deliberately skews away from what we think of as "dopamine dispensers" and instead focuses on getting the work done. We make it easy to onboard new collaborators by skipping the account requirement to send patches or file tickets. The UI is simple and accessible for users with any accessibility needs, and free of distractions. Colors are used deliberately to attract your eye to the action items on each page, not to dazzle you with information overload. These are the kinds of motivations which guide the design of the platform.

For the social aspect, we encourage you to branch out. Talk about your project on Hacker News. Maintain a fediverse presence. Put up a marketing page and documentation on SourceHut pages. Cultivate welcoming mailing lists. There are many ways to crack an egg.

[sneak]

> So our design deliberately skews away from what we think of as "dopamine dispensers" and instead focuses on getting the work done.

What about the case where getting the work done involves doubling the number of people involved in the project, and not a single line of code?

Nobody's on the fediverse, and email is not taken seriously by most modern developers. These interactions still happen on the web.

[ddevault]

Hundreds of thousands of people are on the fediverse, and many large projects use email every day for their work - Linux, GNU, Postgres, Debian, etc. It might not be for you, but it works for many people.

[sneak]

I don’t think your first assertion is true. Hundreds of thousands of accounts have been created. I think the DAU is in the low thousands.

It’s the only social media I use, and it’s a ghost town. We have to live in the world that is, not the one we wish were.

I used to have a Twitter follower count on my niche little tech/privacy account that is higher than the DAU count of the entire fediverse.

[ddevault]

I haven't been on Mastodon in a while, but when I was, it was far from a ghost town. You see what you federate with, and following or engaging with more people will fill your timeline up more. If you don't use it much, then you won't get much out of it.

No, it's nothing like Twitter in terms of DAU. However, your Twitter account compared to your Fediverse account is not a good representation of the entire state of the Fediverse. And: it's not necessary to capture 100% of the market share on attention. It's simply necessary to capture enough that your project is successful.

[bayindirh]

You can automatically send these patch e-mails with "git send-email" command. So there's no friction involved. It only works differently.

Moreover your mailing list can facilitate discussion, so nothing is lost.