Ask HN: How would you build an community around an open-source project in 2021?
Github for hosting the primary repository as that's where people will likely already have an account. As much as I don't like the closed platform, discord has overtaken IRC, so have a discussion channel there. If things scale to needing a non-realtime channel I'd wager a forum like solution similar to discourse would work nicely. It should be hosted in a way that at least looks like an independent website (i.e. at minimum buy your own domain name). Last, an announcement ML or other way to alert people to updates is a good-to-have.
Once those basics are setup it's a matter of attracting users. First and foremost your software needs to solve a problem that people are encountering. Once there's a reason to use the project, then there need to be incentives to assist in the development. Tell users clearly how they can help and provide some issues in the style of first-timers-only issues. There's going to be a good number of drive by contributions, but if they're handled correctly some of them can turn into repeat contributions. In that vein, issues/PRs/etc need to have prompt responses to keep people interested, they need to point out resources, and otherwise convince the community members they're being heard. Overall growing and cultivating a community is a ton of work.
For context I've been maintaining a fairly popular open source synthesizer project for over a decade. Feel free to ask more specific questions and I should be able to point out some ideas.
I do have my own domain name. I use Fossil as the repository; although fossil supports exporting to git, this doesn't currently work remotely (although I could provide a git-fast-export file to users who ask for it, I suppose). I have it set up so that no accout is required to send bug reports or to clone the repository, and I will not allow others to commit to the repository. (If people want to mirror it elsewhere, that is OK.)
I do not and will not use Discord, and do not like Discourse. For fast communication, I would use IRC (although do not currently have one set up); if someone else wants to provide a bridge of the IRC to Discord I would accept that though. For slow communication, I would use NNTP (which I already have set up), but I would accept contributions to provide a web interface and mail interface to the same messages (the messages are stored in a SQLite database, and I can provide a link to the database schema and documentation for those who are interested).
In the case of my projects, I do not allow others write access to my repositories. However, if someone writes a bug report or other message with a patch included, then I can review it and then possibly apply it.
I agree with your second paragraph ("Once those basics are setup it's a matter of attracting users ... Overall growing and cultivating a community is a ton of work") and unfortunately, I am not really sure what to do. Hopefully, if someone on here looks and is interested in these projects (whether mine or someone else), then they can go on there. You can also post here, if wanted.
I also agree that documentation is important (comment 26106008). (I often see projects without good documentation.)
I don’t know that you can overstate the importance of being on GitHub. The vast majority of developers are familiar with GitHub and can quickly contribute to something that is well written and documented. I’m not familiar with Fossil, but the way you described contributions is not at all community friendly. You need to allow users to fork your repo and PR their changes back in openly. The platform must facilitate inline discussion around code changes. No, you should not allow direct write access but they should be able to propose a diff and you should be able to have a threaded conversation about each line of code if necessary. If they can’t do that, then you will never grow a community.
OK, it is a valid point.
I will allow others to propose a diff, and others can also fork the repository if they want to; nothing is stopping that. (Although, those who wish to fork it must store their own copy (or use chiselapp); I will not host it for them.) If other people want to use GitHub, that is also OK.
Threaded discussions are possible with NNTP. Making a threaded conversation about each line of code (or a group of contiguous lines of code) is also possible; if the message body is formatted in a certain way to find the code in there, then a header could be added to reference the individual line of code (or range) being commented on. (The relevant line(s) of code should also be quoted in the follow-up message.)
However, code patches are not the only kinds of contributions that can be made; there are also documentation, bug reports, feature requests, FAQ, artwork, discussion about how something should be implemented, etc.
A large part of intentionally building a community is removing barriers to entry. If you have a large following some barriers can improve the average quality, but starting out they do slow down growth. Fossil is cool. I've used it for some projects of my own in the past, but it's not a common tool, so it will limit who will check out the development of a project. I know with some tooling I have preferences which increase the barrier to entry, but I try to acknowledge that some personal preferences do limit community growth.
It's 100% fine to develop things which are openly available, but not try to build a community. That seems to match your description with your current setup.
If someone who uses git wants a git-fast-export file, I can provide that. Unfortunately, they will have to ask me for it, because the possibility to do this remotely is not available at this time.
I'd start by reading People Powered by Jono Bacon, because it's complicated and typically unique to each project.
Documentation is always important, and what I am working on for my own project exclusively right now.