Related to this is Concurrency Kit [0], which is BSD-licensed, written in C, and provides concurrency primitives and data structures.
I believe CK offers a delete-supporting hash, too, so it has a full O(1), which liblfds does not yet have.
What those things might be I cannot much tell you, where I'm not particularly au fait with CK.
It's free and open source but in some regards it's similar to product design/marketing. If you don't pitch it, some reviewer on the internet will make a stackoverflow post about it, and they won't know your strengths as well as you do.
A blog I read recently outlined some things to figure out: https://blog.orangecaffeine.com/the-art-of-saying-no-db012a2...
From the other comments here it sounds like some unique things you have are:
* versioned datastructures that won't change during library upgrades
* self-documenting code style
I write the library for the pleasure of it. I'm aiming to create something I think beautiful - for better or for worse, from other people's point of view :-)
I'm not actually looking for it to be used as such. It may well be, if my idea of beautiful is any good, it will come to be used, but that's... it's like a side effect.
When you paint a picture, or sculpt a sculpture, or write a song, you're not competing with other artists to make what other people will judge to be the better picture, sculpture or song.
Many, many years ago, back at Uni, a friend of mine received 100% for his Uni project. I could code many years before I went to Uni, but I was shallow in all other ways - all the ways in which we actually produce quality, reliable, usable software. He showed me some of his project, and I saw his docs. What he'd done was absolutely fantastic - a page per API function, documenting the standard set of information that you need to use an API function. The approach you see in all the major projects today, the MS API docs, for example - this from a twenty year old!
That experience permanently set my expectations for documentation, and is reflects in the library docs. One page per function, per enum, per struct, etc, etc, etc. It's ALL documentated. Painstakingly, exhaustively.
There's absolutely no point in writing an API which people cannot use, for whatever reasons.
When I come to make a release, and I'm done (or rather, I think I'm done) with development, I write the docs.
This induces, always, a large final round of development work, as I come to realise, from attempting to document them, that some of what I've done is simply too complex or too awkward or too inherently confusing to use, and has to be rewritten.
I am of the view from my experiences that all developers should write their own documentation, because of the improvement in code quality that is induced by the code changes which come from keeping the docs comprehendable.