Doc: client libraries - C

[jelmd]

Wrt. https://prometheus.io/docs/instrumenting/clientlibs/ you may add libprom, a client library written in C. The nvidia GPU metrics collector nvmex is an example, how one may use it.

[roidelapluie]

Thanks, I am moving the issue to the correct repository.

[SuperQ]

We prefer to list a single implementation when possible for integrations. Since this is a fork, without good reason (ie abandoned, archived), we would only list the upstream. In this case, digitalocean/prometheus-client-c.

Perhaps you can contribute patches upstream, rather than fragment the ecossystem.

[jelmd]

@SuperQ Well, this is a real fork, not just another dangling copy. digitalocean/prometheus-client-c has been choosen as base, but after fixing/optimizing/enhancing/KISSing it, it is basically a complete rewrite with much better performance, re-usability and testing.

[beorn7]

@jelmd did you try contributing your changes upstream? Are there any reasons not to?

[jelmd]

No, would not make any sense because it would be more or less a cp -a repoA/* repoB/*. It is a different implementation, e.g. like IBM JDK and Oracle JDK or MySQL and MariaDB ...

[beorn7]

Well, in those cases, there were actual difficulties with upstreaming, like the Sun (later Oracle) JDK wasn't open-source initially, or the MariaDB people were former MySQL contributors who didn't trust the new owners of MySQL to be a good custodian of the codebase. (I might get the details wrong here, but the important thing is that there were good reasons to create a competing implementation.)

Personally, I think we can list multiple entries for "the same thing" here if they have made different trade-offs that are significant enough in effect. (Example out of the blue: A super-slim C library meant for small embedded devices vs. a feature-rich fat C library with high concurrency in mind.)

What's behind our de-facto policy of generally only listing one entry "per thing" is the intention to encourage collaboration rather than spawning many competing projects that are all trying to accomplish the same. We want to list the one project where potential contributors can rally behind. So far, we assumed that project is https://github.com/digitalocean/prometheus-client-c . Now you come along and say: "That project needs fixing/optimizing/enhancing/KISSing. So I wrote my own thing with much better performance, re-usability and testing." Which prompts us to ask why you haven't collaborated with the upstream project to improve it. If your answer is "they haven't responded" or "they told me they don't have time to integrate my patches and they aren't interested in evolving the project", then that's fair game, and listing your fork or rewrite here instead seems the right move to encourage progress and collaboration. However, if your answer is "I prefer to do my own thing and to not waste time collaborating with others", then that's a fair point, too, but we should probably keep the current listing, even if your implementation really was in a better shape at the moment, because you probably wouldn't be open to other contributors improving your code. (Which would in turn lead to those contributors creating their own fork/rewrite, asking us to then list their version rather than yours.)

[jelmd]

Hi @beorn7, thanks for your insights, but take it easy: Just gave the info because people usually like to have a choice and thus it may help to get more prometheus clients ... However it is entirely up to you, to make use of the info, or to ignore it.

FWIW (TLTR): Sometimes one takes a source, starts experimenting with/looking at it and realizes, that it needs some quirks and workarounds to really become useful. So one starts modifying it, and when doing this and the code gets understood much better, one may encounter several other places, which need to be fixed, can be implemented much better. Finally, after all the adjustments one has something new, which is much more suitable for the intended purpose than the original. This is evolution, real life. And this is a good thing, because it gives people the choice and my experience says: people wanna have the choice. Of course, one may declare them uneducated and try to dictate what they have to use, but I'm pretty sure, this will fail and may even drive them to switch over to another product, which gives them the freedom they need and room to breath (e.g. from prometheus to VictoriaMetrics). So IMHO it is much smarter to embrace every fork and accept them as an essential part of the evolution and thus as a very valuable part of a working, living, healthy ecosystem. If there is no evolution, then the thing is basically dead, no much progress possible, and that's why IMHO OSS repos like github, gitlab, etc. encourage people "to fork to death" ;-). It is like in the real life: VCs do not invest in just a single startup because they know, that probably 80+% will fail, but cannot say, what finally makes the difference. It could be such an "unimportant" thing like the color of the product, location of the company, ..., or like in this case the fact, that one does not need any docker bloat to be able to build the lib and therefore can be used easily on other, i.e. non-Linux platforms. So asking people to check, whether contributing to a certain repo/fork is an option is ok, but trying to rule the world, to stop any evolution by insisting to do that will IMHO fail and may actually cause the opposite.

Takeaway: forks are a good, healthy thing - one should embrace them.

[beorn7]

@jelmd I think you are not talking about what I'm talking about.

In any case, I assume the Prometheus community has consensus of not changing the entry in this particular case and will close this issue.

It would still be good to have written guidelines for listings, both for ourselves to get clarity as well as transparency for the general public. @RichiH you wanted to draft a document. What's the state of that?