These are good takeaways from someone who seems to actually care about the users of their project, which is refreshing to see. I've gotten into discussions on this forum with people who think and do otherwise. (Case in point[1].)
> they're not demanding. they're engaged. that's a gift.
100%!
Open source maintenance is a difficult and sometimes thankless job. It requires a lot of communication, careful balancing of the project's vision and user requests; tolerance, patience, honesty, transparency, gratitude, humility, but also confidence, sternness, and above all else, dedication to improve the project for everyone, not just a select few. It seems that the author gets quite a few of these right.
A few notes from my own experience:
- Documentation is important, and they're right that it is never "done". That said, you also have to assume that it's written for a specific audience. If a baseline level of technical proficiency is needed for your project, then you shouldn't need to explain topics that bring people up to that level. Sometimes it's a better use of your time to address the occasional support question, than to add documentation that would be irrelevant for the majority of your users. Besides, if those support questions are visible to the community (e.g. they're on a discussion forum), then your answers there can serve as unofficial documentation for people who need it.
- Speaking of which, a discussion forum is crucial when building a community around an open source project, or any project, for that matter. It is another source of information for users, you can use it for announcements, etc. And once you have power users and people passionate about your project, the community itself can help out with support duties. Definitely make this as accessible as possible, make it public, and don't use a closed platform like Discord. A real-time chat platform could be useful, but an async searchable old-school forum is much better for discussion and support.
- Code contributions are a double-edged sword. On one side, it's incredible that some users are passionate about the project enough to invest their time and effort in improving it, and are willing to share their improvements with everyone else. But on the other, when their code is merged into the mainline project, it becomes an additional maintenance burden for core maintainers. Those contributors will hopefully be acknowledged for their work and everyone will appreciate it, but if there are issues with that part of the code, it will be the original maintainers' job to fix it and improve it, not the contributors'. The article mentions this already, but this is another reason to be extra vigilant and judicious about which code to accept, and which not. Most contributors will understand.
Kudos to the author, and best of luck with the project! It's certainly on my radar now.
BTW, looking at Kaneo's web site now, the "free forever" next to the Cloud link is not a good sign. Maintaining infrastructure is a financial burden. Nothing should be "free", and definitely not "forever". Please: add a commercial tier where people can pay you for the resources they consume. This is orthogonal to open source, and you should be compensated, not just for the infrastructure you maintain, but for your work. Everyone will understand this, as long as you keep it fair. In fact, it serves as assurance for any potential users that the project is in a healthy state, and that it will likely continue to be maintained.
I'd be happy to discuss this further and offer any guidance if I can. My contact info is in my profile.
[1]: https://news.ycombinator.com/item?id=46051393#46052504