The front page has "everything is configurable", but that doesn't mean much to me since lots of loggers are also configurable.

I actually don't know why I would need or want a global store for logs. Usually shipping logs goes to a third party via something like fluentd, unless I'm missing something here.

Maybe first understand what problems people are encountering and think about how your library addresses that and convey that on the front page as a start?

I can tell you put a lot of love into it, and hope you solve your marketing issues!

I've also written my own logging library with a fluid API that does what I feel are common use-cases:

- standard logging levels - ability to record metadata - ability to ingest errors - flexible hooks that allow you to add in your own functionality - is meant to be used with your existing loggers

https://github.com/theogravity/loglayer

I built it because my workplace was having the issues mentioned at the top of my library and we now use it everywhere at work because of the consistency it provides and the ability to swap out the underlying logging libraries easily.

We've had some employees leave the company over time and have told me they use it in their workplace too, so I think part of it is get it popular at your job and hope it can spread to others through word of mouth.