We've often spoken about how it's good to write software which others will want to use. This is really important but it's only one of the various undertakings which will transform you from a hacker into a good software author. What your users want the software to do is only one aspect of their needs when it comes to any programming you do. In addition there's the aspect of where they want it to work. Now, I'm not going to suggest that you must make your software work everywhere. But I am going to suggest that you need to consider where your users live in terms of their software environment.

If you're having to use lots of bleeding edge libraries in your software development then your users will need to have those libraries in order to use your software. If you're targetting people who use Arch or similar then that might be just fine, but if you're hoping that people who use the stable version of Debian or Fedora then you might need to consider using less bleeding-edge dependencies.

Another solution could be to include the libraries you depend on inside your software, but that tends to make it significantly harder to manage your software as part of a distribution. Or you might make your build system download the new libraries as part of compiling/installing your software in the hope that will help. Unfortunately many build systems are deliberately not allowed to talk to the Internet to improve reproducibility which will scupper your plans.

Some languages have their own packaging solution which can be used to automatically deal with this to a greater or lesser extent, but they have the side-effect of constructing confusing messes on your users' systems unless they are proficient with ways to construct virtual environments for whatever language you have selected.

Instead, the best option for increasing the usability of your software is, simply, to ensure that you don't depend on things which are not already in the distributions you are targetting. This doesn't mean that you must limit yourself to the stable version of a distribution; particularly if you're targetting your software at the distribution's next release; but if you can limit yourself thusly then it will be must easier to have a wide user base. This option also has the benefit that if there's a security issue in any of your dependencies, the distribution will take care of that for you, reducing one potential source of headaches for you.