That makes sense, and I think I probably come down in a similar position to you. I'd say it can be great for a project to have a community, but I don't think I'

That makes sense, and I think I probably come down in a similar position to you. I'd say it can be great for a project to have a community, but I don't think I'd conflate managing and supporting that project, with interacting with the community in quite that way. Years ago I looked after a product that the company I'd worked for had acquired which had hundreds of thousands of users. Originally the only avenue for support for that product had been email and that was a problem because we were overrun with emails asking very similar questions, and nobody was responding to them (or had time to). So I started creating blog posts to answer these questions, every time I encountered a new question, and sending them in very short responses to emails. I.e., effectively I created a knowledgebase, but I used a blog because it was the most convenient, and least bureaucratic way of achieving the solution: I won't say it wasn't politically charged, because it definitely pissed a couple of people off, but it got the job done and avoided a zero outcome scenario because I didn't get blocked by these people (one in particular). Sending out these knowledgebase posts started to reduce the support burden because now, of course, we had a search-engine indexed body of content that people could find online. The point being if you're a small team and you want to minimise the amount of work you need to do to support your project, unless you have a very small and niche community, you're much better off creating resources that are openly available, than in some sort of walled garden, especially if the walled garden means you have to repeat yourself a lot.