Maintaining an open source projects is certainly a long and (possibly) never ending journey. Commit after commit, bug after bug, typo after typo you slowly grow traction for your library. But at what point is your project, no longer "your" project? What I mean by this is, once your project reaches the point where it has hundreds to thousands of followers, and your choices can impede the progress of other people's projects, such as when you're maintaining a library, can you actually make choices you want, to in your eyes change the library for the better?
Now don't get me wrong, if you own, and/or are the lead maintainer of a project, it is in a ethical sense your project. However there is a threshold that after a certain point, only basing things off of your own opinions/wants for the library are no longer a plausible option, the userbase of your project is going to want new features, code changes, bugs fixed, they're going to make pull requests, forks, all these things, and at this point in my mind you have passed the threshold of "your" project, to "everyone's" project.
I bring this up as I was recently in a debate with a friend about a library, specifically Discord.py's maintainer supposedly refusing to implement a new feature because the api is 'messy', while I can understand this, this also impedes the progress of people using the library, and sure people can make pull requests, forks, etc, but what if they deny the pull request, for this reason as well? I can understand not wanting to ruin the code base with "messy" code, so a branch is a more reasonable option than injecting it directly into the central code base, but it seems not even this is being done.
What would you do in this situation? Would you implement the new feature, and improve it later once the api has been improved more? Or would you hold off on it, potentially impeding/preventing people using the feature with your project?