I’ve been weighing some complex issues lately, and one of those issues is the use of telemetry data collection in my extensions. While usage data is commonly collected in commercial software, it isn’t generally the first priority for hobby projects. When it comes to understanding how many people have installed one of the Azure Data Studio extensions I’ve worked on or how it is being used, I’m somewhat flying blind. Through the magic of GitHub APIs, I can see how many times a specific release has been downloaded – but I’m unable to see which extensions are getting the most use or which features are most popular.

As of the December 2019 release of Azure Data Studio I will have four published extensions (and a color theme). I can guess based on the number of downloads for each release how many people might be using them – and it’s approaching a number that I didn’t imagine when I started building extensions.

Without more information on how often the extensions are used, it’s difficult for me to determine where to focus the limited time I have available to work on these projects.

It’s almost impossible to describe the joy that I’ve experienced from working on these extensions for the past approximately 18 months. It felt like there were dozens of us using SQL Operations Studio in July 2018. (it would be renamed to Azure Data Studio a few months later when it went to General Availability) When 1,000 people downloaded the first release of the First Responder Kit that month I was over the moon. I’ve invested time in adding functionality to each extension and enjoyed both the process and the learning involved.

The decision to add telemetry collection to these projects wasn’t made flippantly or without regard to the privacy of the users. The priority for the telemetry data is how the extensions are being used – for example when the extension activates or when a command is run.

For example, in the extension Demo Mode:

if ( telemetryOn ) {
    reporter.sendTelemetryEvent('enabled', { }, { });
}

The telemetry event is practically empty, sending the command that is run with the standard VS Code telemetry info. I will be using the VS Code package for extension telemetry, not trying to reinvent the wheel here.

My Ground Rules

1. Each extension will have the use of telemetry clearly marked in the README.
2. Each extension will have a setting for telemetry collection and will only collect telemetry if the extension’s telemetry setting and the Azure Data Studio telemetry setting are both enabled.
3. I will share aggregated telemetry information with the Data Platform community for our collective benefit.

Next Steps

With new releases for each extension, I will incorporate telemetry along with new features/fixes. The previous releases will continue to remain available and all extensions will continue under their MIT license.

If you’d prefer to not participate in telemetry collection, you are welcome to disable that through the Azure Data Studio settings – either for the specific extension or for the entire application. If you’d prefer to install the extension with telemetry removed, you are welcome to fork the extension’s repository, remove the telemetry code, package, and install.

<p>
  I&#8217;m looking forward to knowing better how the extensions are being utilized and that spurring further improvements. I suspect that the data platform community may find information about a subset of Azure Data Studio users to be interesting.
</p>

Further Information

• Blog post: How to add telemetry to an Azure Data Studio extension
• Upcoming blog post: 3 months of telemetry data on my open-source Azure Data Studio extensions