GSoC Open Data Methodology, Limits and Reuse Guide

A GSoC open data methodology is trustworthy when another researcher can trace a displayed number back to a public source, reproduce the transformation and see what is missing. Clean JSON is not enough. Identity, time, snapshot state and denominator decisions shape every result.

This local archive covers 2016 through 2026. The 2016 to 2025 yearly snapshots are marked finalized and contain 10,951 project records. The recovered 2026 snapshot contains 1,140 projects across 183 live organizations but remains non-final for several fields.

Official Google GSoC pages are the authority for current organization selection, program rules and published records. The independent dataset adds search, cross-year normalization and derived views.

Use the official program archive and current GSoC documentation to verify claims. A community mirror can cross-check gaps but should not silently override the primary source.

Record source URL, retrieval time, program year and expected state for every import. Preserve raw input separately from normalized output.

An annual source record describes one organization as published for one program year. A normalized profile connects records believed to represent the same continuing organization across years.

Never overwrite source names, slugs or URLs to make them tidy. Store normalized identity in a separate layer and keep the evidence for each alias.

This separation allows corrections. If two profiles were merged incorrectly, the source records remain intact and the derived history can be rebuilt.

The dataset uses annual organization, project and cross-year organization-profile grains.

An annual organization belongs to one year. A project belongs to one year and one organization identity under the current join. A profile aggregates observed years, technologies, topics and project totals across reconciled annual identities.

Metrics should not cross grains without an explicit join. A profile technology tag cannot automatically classify each project. An annual organization count cannot be summed into unique organizations.

Write the grain beside every analysis table.

Identity reconciliation uses exact source identifiers, known slug aliases, official websites, repository ownership and historical descriptions. Similar names alone are not enough.

Umbrella organizations complicate the process. A foundation-level profile and a subproject can be separate legitimate participants. Merging them would erase program structure.

Keep ambiguous records separate and add a review note. False separation is visible and correctable. A silent false merge contaminates histories, streaks and project totals.

Technology and topic labels contain capitalization, synonyms, misspellings and combined values. Preserve the source string, then map it to a canonical vocabulary for filters.

Exact alias sets support reproducible analysis. For example, a Go comparison can union lowercase go and golang. Fuzzy substring matching would create false positives.

Do not split a combined label unless the meaning is clear. Record vocabulary version so a changed alias map explains changed counts.

Missing, zero, empty, not applicable and not yet archived are different states. Use null or completeness metadata for unavailable fields.

The 2026 snapshot currently marks projects, contributors and descriptions available. Mentor names, code URLs, project tags, difficulty, status and timestamps remain incomplete.

Reporting zero mentors would be a factual error. Reporting “mentor data unavailable in this snapshot” preserves the boundary and invites a later refresh.

An annual cohort can change after announcement. Store announcement count, live count, withdrawn count and the effective date.

For 2026, Google announced 185 organizations. Two later withdrew, producing 183 live profiles in the reconciled view.

Use announcement counts for announcement-day questions and live counts for current participation. Never mix them within one rate.

Every project should join to the correct annual organization. Validate year, source identifier, normalized slug and reachability.

Flag orphan projects, duplicate IDs, duplicate year-and-title combinations and organization slugs absent from the annual cohort. Investigate rather than dropping records silently.

Compare project counts computed from records with stored yearly metrics. A mismatch blocks publication until its cause is documented.

A metric contract contains name, question, unit, inclusion rule, exclusion rule, formula, denominator, time window, snapshot state, source and limitations.

For “2026 returning share,” the unit is live normalized organization profile. Include profiles active in 2026 with an earlier observed year. Exclude withdrawals. The formula is 166 / 183 × 100 = 90.7%.

The contract prevents a number from being reused as applicant acceptance probability or lifetime organization history.

The 2026 project mean is 1,140 / 183 = 6.2 after rounding. The median organization has 4 projects.

The difference signals a right-skewed distribution with larger profiles and umbrellas. Neither statistic measures project quality or mentor attention.

Publish the raw count and denominator with an average. Use a median when describing a typical position in an uneven distribution.

A first appearance means first within the covered and normalized window. The archive begins in 2016, so all 178 profiles in that row are mechanically first in local data.

Do not call them genuinely new to GSoC without earlier history. For 2026, 17 live profiles have no appearance from 2016 through 2025, which supports a bounded first-time claim.

The first-time organization guide shows how identity uncertainty affects the result.

A current streak counts consecutive appearances backward from 2026. Total appearances count all observed years. Gaps equal the inclusive observed span minus total appearances.

These metrics require normalized identity and a named end year. A five-year streak ending in 2021 should not be presented as current continuity.

The returning organizations guide publishes the algorithm and interpretation limits.

Accumulated profile tags support statements about matching organization profiles. They do not support current project-language counts.

Our documented unions find 98 live profiles carrying C or C++, 40 carrying Java, 31 carrying Android-related tags, 26 carrying AI or ML tags, 23 carrying Rust and 19 carrying Go or Golang. Groups overlap.

The programming-language methodology explains why these percentages cannot be added or treated as project shares.

Automated checks should verify schema, required identifiers, uniqueness, year bounds, counts, join integrity, URLs and generated-page reachability.

Run transformations deterministically from raw inputs. Check generated files into the appropriate data pipeline only when project policy allows. Save a drift report when current sources differ from stored snapshots.

Automation catches structural errors. It does not resolve semantic identity or misleading interpretation, which still require review.

URL audits should test reachability without erasing provenance. Check status, redirects and canonical destinations, but preserve the original source field when it has historical meaning.

Remove broken external links from public navigation only after confirming the failure and considering an official archive. Do not replace a dead project URL with an unrelated homepage merely to achieve HTTP 200.

Record audit date and result. Reachability does not establish correctness, ownership or safety.

Collect only public fields needed for discovery and program history. Do not assemble behavioral profiles, private communications, sensitive proposal content or identity-linked analytics.

Contributor names published by the official archive can be part of source records, but reuse should remain purpose-limited and respectful. Do not infer nationality, gender, location or selection traits from names.

Aggregate analysis where possible. Public availability is not unlimited ethical permission.

A refresh log should list sources, retrieval dates, schema changes, new and removed records, withdrawals, identity decisions, vocabulary changes, completeness changes and validation results.

Recompute dependent pages after a normalized slug or alias changes. Verify internal links and sitemap entries. Do not update an article date for a mechanical reformat with no factual change.

The organizations and projects by year provides the current annual series.

Researchers can reproduce derived metrics from the stated snapshot, cite primary sources and preserve method notes. Product builders should treat generated profile data as a discovery index and verify current facts.

Never use these records to claim personal acceptance odds, low competition, mentor quality or country-based selection patterns. The required denominators and ethical basis do not exist.

When a question cannot be answered, publish the missing data and a safer proxy rather than manufacturing a number.

Before publishing a metric, confirm source authority, unit, window, normalized identity, snapshot state, missingness, formula, denominator, overlap, reproducibility and privacy.

Ask a second reviewer to reconstruct one sample from source records. Verify that the surrounding prose cannot be read as a guarantee or ranking. Link the method beside the result.

A GSoC open data methodology earns trust by making uncertainty inspectable. Preserve raw facts, normalize cautiously, publish limitations next to metrics and let official current sources override any stale local representation.

Every public record needs a way to report a source, identity or calculation error without exposing private information. Require the affected URL, expected value, primary evidence and observation date.

Review the correction against raw input and transformation code. Fix the earliest incorrect layer, regenerate derived outputs and record the changed metrics. Avoid one-off edits to generated JSON.

A visible correction log strengthens the dataset because it distinguishes revised evidence from silent drift.

Re-run link, sitemap and metric checks after every correction. A fixed source record is not complete until every dependent view reflects the same identity and value.