Taking the Pulse of the OpenTAP Ecosystem

Welcome to 2021 OpenTAP Community! We hope you are as excited as we are about open source test automation, and OpenTAP, looking to the year ahead. In keeping with our mission to grow OpenTAP to become the de-facto standard for test automation in the T&M industry we are planning to introduce new functionality to visualize the health & vibrance of the community & ecosystem.

Over the coming months we will add graphs on the OpenTAP homepage that will visualize the installation count of each of the available OpenTAP packages in the repository, including the OpenTAP package itself. With this, it will be possible for the community to follow the adoption of the available plugins and as well track the popularity of your own contributions.

The anonymous ping that OpenTAP sends to the package repository during startup is a hash of the package names and versions installed as well as an anonymous ID to distinguish installations. For details take a look at the feature implementation in GitLab that is planned for V9.12 which is only a few weeks away.

Note that the feature is a configuration and can be disabled in the engine config file.

For The OpenTAP Package itself, we imagine something like the below:

Let us know if you have further ideas, questions or concerns. This is what the forum is all about.

Wherever in the world you are we hope you are staying safe and productive during these unique times and we look forward to your engagement & collaboration in the OpenTAP community!


The OpenTAP Team


This kind of adoption data is very difficult to obtain w/o generated telemetry. Counting downloads just doesn’t cut it - one download can generate a single installation, hundreds of installations, or zero. The same goes for forks and pull requests from repos. The insights gleaned from the OpenTAP engine itself highlight both rapid adoption and a very active community. OpenTAP project dev team - keep up the good work!


Seems interesting. Would this telemetry only apply to OpenTAP packages/plugins, and the opentap.io repository? Or would it be extended for users to track their own packages from their own repositories?

1 Like

@david-wsd the idea is this would apply to all packages, however, a package would just appear as an arbitrary hash, unless it existed in the public repo. The reason for this is we wanted to keep the data anonymous, that way no one can see plugin growing in usage called “David’s secret plugin” and know what you are working on.

That said, one thing I had not considered until you mentioned it is it is possible we could potentially provide users the mapping to plugins they own, so they would be able to track their plugins specifically, even if they weren’t public. An interesting idea.


How did you know about that plugin?! Initiating self-destruct sequence. :rofl:

That would be cool, as it would expand the benefits of telemetry to the community.

I see the gitlab issue, does that mean this telemetry will be developed within OpenTAP and therefore open source? Not that I anticipate a security concern from this, but I’d be interested in reviewing the implementation.


@david-wsd exactly! I’m glad you see the value. The goal is to be open. Aligning with the overall values of the OpenTAP Project. On security, there actually are some interesting studies on open source projects actually being more secure than proprietary solutions as developers are temped to leave “back doors” and anything nefarious is easily caught and rectified.

On that note, I think it would be great to have an external reviewer both from a sanity check perspective as well as to help ensure what we are doing continues to benefit the community.

@asger_iversen can you point David to the Merge Request once it is ready?

1 Like

@brennen_direnzo Yes, that would be great.


Hi @david-wsd, @brennen_direnzo

The merge request is here: Call update check in the background when any CliAction is started. (!740) · Merge Requests · OpenTAP / OpenTAP · GitLab


Thanks @asger_iversen

Looks like it’s indeed storing just a hash. No concerns here.