| They are good ideas. For my own projects, I do try to avoid scope creep. (In some cases I had thought something should be in scope but later changed my mind (before actually implementing it), though.) I did not add a file called VISION but maybe that would help, so I will consider that. I do want to keep communication public (mainly using NNTP, although IRC and GitHub issue trackers can also be used), but nevertheless there isn't any communication on there. > If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. Forking a project doesn’t have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project’s vision. This is correct. However, it is also possible for some of the features of a forked version to later be put into the official version (or a different fork) (after being reviewed by the maintainer). This does happen sometimes, too. > Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. Nevertheless, it make sense; there is more to say if they have a complaint (or a suggestion for improvement, or a question, etc) than if it works OK. I don't mind this; my problem is that I rarely receive any feedback at all, regardless of good or bad. (However, I think that it is helpful even for positive feedback to be specific. This way, it can also help other people to decide whether or not they think this program is suitable (or almost suitable) for their intended uses.) (I have received stars on GitHub (for some projects), but they don't help me at all, since they do not say anything.) > Working alone: Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. This is my problem; lack of other people discussion and contributions. |