Coverage and source collection
SoftwareIQ collects source-native activity from five public developer ecosystems on a daily operating schedule.
Current coverage includes npm and PyPI packages, Docker Hub repositories, NuGet packages, and Terraform Registry providers. Each observation is tied to the source-native artifact identifier used for collection. SoftwareIQ does not substitute general web traffic, search interest, or repository popularity for an ecosystem’s reported distribution activity.
Collection receipts record the requested source object, observation period, retrieval time, response status, payload fingerprint, and byte count. Repeated responses are deduplicated; a changed upstream response produces a new receipt. These controls establish when and from where an observation was obtained without publishing credentials, request headers, or raw source responses.
Projects, artifacts, and company mappings
The dataset retains source-level identity while supporting project- and company-level analysis.
An artifact is the source-native package, repository, or provider that produces an observation. A project is a maintained analytical entity that groups related artifacts representing the same software project or product family. A project can contain artifacts from more than one ecosystem.
A company association links a project to a covered company for analytical attribution. The mapping is researched and maintained separately from the source metric. It supports company and category aggregation, but it does not by itself assert legal ownership, exclusivity, commercial terms, or the share of activity attributable to paid use.
Project-level analysis does not require every mapped artifact to be added together. Some product-facing packages are independently adopted; others are shared dependencies installed mechanically with another package. Maintained analytical cohorts identify the independently interpretable artifacts and document exclusions where summing package observations would double count overlapping activity.
- Use the source and artifact identifier to audit or reproduce an individual series.
- Use the project identifier to combine related artifacts only when project-level analysis is intended.
- Use the stable company identifier for cross-dataset joins; ticker and display name are descriptive attributes.
- Company and category aggregates inherit the coverage boundaries of the mapped artifacts included on each date.
Metric definitions and time grain
Daily flows and cumulative snapshots are different measure types and require different aggregation rules.
| Ecosystem | Observed object | Source measure | Published grain | Definition and use |
|---|---|---|---|---|
| npm | Package | Downloads during a calendar day | Daily interval | Observed package-distribution activity for the stated day. Values are flows and can be summed across non-overlapping dates. |
| PyPI | Package | Downloads during a calendar day, excluding mirrors | Daily interval | Observed Python package-distribution activity for the stated day. Values are flows and can be summed across non-overlapping dates. |
| Docker Hub | Repository | Total pulls reported by the source | Daily snapshot | A cumulative counter as of collection. Snapshot levels are not additive; changes require continuity and reset controls. |
| NuGet | Package | Total downloads reported for the exact package ID | Daily snapshot | A cumulative counter as of collection. Exact package matching prevents a nearby search result from being assigned to the requested artifact. |
| Terraform Registry | Provider | Total downloads across the provider's published versions | Daily snapshot | A cumulative provider counter as of collection, calculated from the source's version-level totals. |
For npm and PyPI, a daily value represents activity during that day. For Docker Hub, NuGet, and Terraform Registry, a daily value is the source’s cumulative total as observed on that date. Cumulative levels must not be summed across dates. Changes between valid snapshots can be used as interval activity only after continuity checks.
The observation date describes the source period or snapshot date; the retrieval timestamp describes when SoftwareIQ collected it. Missing observations remain missing. They are not converted to zero and should not be bridged automatically when calculating changes.
| Measure | Calculation or scope | Definition and use |
|---|---|---|
| Indexed activity | Trailing activity ÷ activity in the first complete trailing window × 100 | Compares the direction and relative rate of change across series without treating unlike raw volumes as equivalent. The base date, trailing window, and artifact set must remain fixed. |
| Defined-cohort activity share | Artifact or project activity ÷ total activity for the fixed comparable cohort × 100 | Measures observable activity share only within the named cohort. Cohort membership, ecosystem, metric, and trailing window are part of the definition. |
| Portfolio activity mix | Product-surface activity ÷ total activity for the fixed selected portfolio × 100 | Shows how observable distribution activity is allocated across selected products from the same company and ecosystem. The components sum to 100%; the measure is not a user-level attach rate or reported revenue mix. |
| Programmatic activity | Activity for maintained official SDK or client-library artifacts | Provides evidence of software being integrated or automated beyond its primary interface. It is not API-call volume, unique users, paid usage, or revenue. |
Raw measures from different ecosystems are not additive or directly rankable. For a cross-ecosystem comparison, each series should be normalized independently—for example, to a fixed-date index—and interpreted as directional change. A share calculation requires comparable observations from the same ecosystem, metric definition, date range, and maintained cohort.
Normalization and quality controls
Observed, normalized, and adjusted records remain distinguishable so transformations do not obscure the source value.
| Level | Definition |
|---|---|
| Observed | The valid value returned by the identified public source for an artifact and observation period. |
| Normalized | The observed value represented with consistent identifiers, dates, units, and metric semantics. Normalization does not change the source-defined economic meaning. |
| Adjusted | A controlled analytical value produced when a documented rule is required for continuity or comparison, with its processing version and upstream observation retained. |
Validation covers artifact identity, metric type, date and period consistency, response status, duplicate observations, and expected counter behavior. A zero returned for a normally cumulative or activity-bearing metric is treated as a potential source-lag or inactive-artifact condition unless the source evidence supports a valid zero.
For cumulative counters, normalization evaluates negative changes, resets, identifier changes, and missing intervals before producing a change series. A reset is not treated as negative organic activity. When continuity cannot be established, the affected change remains unavailable rather than being forced into a complete panel.
- Valid zero: the source produced a defensible observation whose measured activity is zero.
- Unavailable: no defensible value exists for the artifact and period because the source, mapping, or collection state is incomplete.
- Inactive artifact: an artifact deliberately removed from current safe aggregation after review; its prior observations are not reinterpreted as current activity.
- Adjusted value: a versioned transformation retained alongside—not in place of—the source observation.
Release and version observations
Release metadata separates changes in software distribution from changes in the activity counters themselves.
Where supported by the source, SoftwareIQ records package or provider versions, release time, semantic-version components, and release-channel context. Docker observations can include repository and tag state. NuGet and Terraform observations preserve exact package or provider version identity. Release records describe the latest normalized source state; prior source states remain traceable through collection provenance.
| Channel | Definition |
|---|---|
| Stable | A generally available release without a prerelease designation. |
| Prerelease | A version explicitly identified by the source or semantic-version metadata as not generally available. |
| Canary or nightly | A rapidly updated testing or development channel identified separately from stable releases. |
| Platform-specific | A release or tag whose identity is specific to an operating system, architecture, runtime, or other platform target. |
Processing releases carry a deterministic version. Improvements to mapping, normalization, or counter treatment are validated before adoption and can produce a documented restatement of maintained history. Retaining the extraction date and processing version allows a research team to distinguish a methodology update from new ecosystem activity.
Research interpretation
Developer Signals measure observable ecosystem activity; they do not directly measure commercial outcomes.
Package downloads, container pulls, provider downloads, and release activity can contribute evidence about adoption, developer engagement, distribution intensity, and changes in a product ecosystem. Their meaning depends on the source population, packaging model, release process, automation, mirrors, and the artifacts included in the maintained mapping.
- Compare like measures and ecosystems; a package download and a container pull are not equivalent units.
- Review artifact coverage and mapping changes before interpreting a company- or category-level inflection.
- Use level and change measures consistently, particularly for cumulative source counters.
- Do not interpret activity as revenue, paid seats, unique users, market share, or management-reported consumption unless independent evidence establishes that relationship.