Take Zipkin off the "supported" list

[codefromthecrypt]

No one is supporting Zipkin, @pavolloffay writes code in brave-opentracing and doesn't fix bugs. Usage patterns in READMEs are questionable at best and impact us. Your java issues list includes changes that impact us but don't proceed.

Please take Zipkin off the supported list as it misrepresents it. Doing ones best despite the odds is far from "supported"

cc openzipkin people who have stake in opentracing @basvanbeek @devinsba @jcchavezs

[codefromthecrypt]

this comment has a small selection of abandoned issues.

[isaachier]

You may not have to go to this extreme yet. We are working on OpenTracing API unification. For example, thread awareness is a feature that is not yet implemented in many languages (C, C++, probably a number of others). As we progress in the API unification we intend to take more responsibility in terms of our API stability/compatibility. I cannot speak for the OpenTracing contributors to this project, but that is my suggestion.

[codefromthecrypt]

forgive me if well over 2 years of this state of those making decisions don't help with the damage of those decisions.. forgive me if I don't hold my breath. The community who's dumped on should be the ones deciding if they are supporting something. Hopes, dreams and marketing, or wishes of communities who compete with us are irrelevant.

[basvanbeek]

I am ok with Zipkin being removed of the list.

Zipkin's native ecosystem is vast and touches many languages, frameworks, etc. We shouldn't signal that we have the same breadth and user experience when using OpenTracing implementations or bridges for Zipkin. Some languages are closer to a good UX like Go, others not so much.

The OpenTracing implementations/bridges in the main OpenZipkin organization can expect proper support as long as we can keep them there (dependent on OpenTracing API stability and compatibility with our core concepts) but this is in my opinion not enough to help feed consumer expectations on OpenTracing-Zipkin compatibility like a native OpenTracing ecosystem would.

[codefromthecrypt]

#260 will fix this