Relation to .NET‘s Activity type

I think we should try to figure out if/how this project can/should coexist with the new .NET framework type Activity.

Please see https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md for some documentation. It’s very similar to OpenTracing but it has a few important differences.

The userbase for the C# OpenTracing implementation is very small (basically non-existent) so we should make sure people who are interested in this topic invest their time properly.

I really want proper feedback from multiple people before I invest any more time into this.

[Aaronontheweb]

As someone working on consuming this package inside a large framework at the moment, let me be unambiguous: the Activity type is going to be yet another not-invented-here MSFT standard that no one outside of a handful of die-hard Microsoft Solutions Consulting customers ever end up adopting at scale.

One day it may have buy-in in the form of back-end tooling for visualization, but today it doesn’t. I’m not sure it even has any users at the moment. Debating whether or not we should halt the development of this standard and this project in favor of consuming the Activity type would be like the jQuery folks deciding not to pursue their implementation because Microsoft was developing ASP.NET WebControls.

Microsoft doesn’t have any mindshare, tooling, or history in this space. There are dozens upon dozens of Zipkin client implementations in C# already - the demand for OpenTracing and its implementations has already made Activity irrelevant.

So IMHO, close this issue and let’s move onto updating this package and unblock the project. If Activity ever does get any traction in the future, we can revisit later. Don’t stop the work in the meantime.

[cwe1ss]

I’m going to close this as there’s been no new comments.

PS: My OpenTracing.Contrib.NetCore project is a big DiagnosticSource/Activity -> OpenTracing bridge.