GSoC_archive_2025: a folder of accepted proposals, one directory per organisation

What is actually in the repository

This is the accepted GSoC 2025 proposals archive for reference and inspiration from the community, and the README describes it as a community archive that exists to help future contributors see real, successful proposals and learn from them.

The repository structure makes the format clear without opening a file. The top level is a list of directories named after organisations, one per organisation that has at least one accepted proposal: AOSSIE, Alaska, AnkiDroid, BeagleBoard.org, CHAOSS, CNCF, Chromium, CircuitVerse.org, Debian, Drupal Association, Google DeepMind, JdeRobot, Kornia, Learning Equality, Machine Learning for Science, OWASP Foundation, Open Science Initiative for Perfusion Imaging, OpenAstronomy, Pharo Consortium, Project Mesa, Rocket.Chat, Society for Arts and Technology, SymPy, TARDIS-SN, The JPF team, The Julia Language, VideoLAN, cBioPortal for Cancer Genomics, kro and omegaUp.

Each of those directories holds the proposal PDFs for that organisation, which is the whole content model. There is no application, no index, no metadata. The primary language in the repository metadata is recorded as unknown, which is the honest answer for a directory of PDFs.

The project is MIT licensed, the default branch is main, there are no GitHub releases, and the last push was on 2026-09-05. It is a repository of documents rather than of software, and evaluating it means evaluating the shape of the archive rather than the quality of the code, because there is no code.

One small detail in the tree is worth a mention, because it tells you the repository is maintained by people rather than by a tool: there is a `.DS_Store` file at the root, which is the macOS Finder metadata file that nobody remembers to add to a `.gitignore`.

The organisation list, and what it says about the programme

The org submission checklist in the README is the most informative document in the repository, and it is worth reading as a list of the kinds of projects that take GSoC students.

Several entries are the large foundation projects, and the directories for CNCF, Chromium and Debian are where a student would look to see how a proposal is written for an organisation with a formal process. Debian and CNCF in particular have a culture of well-scoped, upstreamable work, and reading their accepted proposals is a lesson in what that looks like.

Others are scientific and academic. SymPy, The Julia Language, TARDIS-SN, Kornia, which is a computer vision library, cBioPortal for Cancer Genomics, the Machine Learning for Science organisation, OpenAstronomy, and the Open Science Initiative for Perfusion Imaging are all research-adjacent projects, and their proposals show what a summer-sized research contribution looks like when it has to be scoped to three months.

And several are community and platform projects rather than codebases in the usual sense. AOSSIE is a student community, Learning Equality, Pharo Consortium, Project Mesa, the Society for Arts and Technology, Alaska, and omegaUp are the kind of organisation where a student proposal may be about documentation, a website, a curriculum or a community tool rather than a library feature.

That last category is the most useful thing to notice, because it is the one a prospective contributor is least likely to expect. GSoC proposals are not all about writing code in a large project, and a student with a documentation or tooling background may find a more receptive organisation in this list than in a browser engine.

The proposal count, and why the number in the README is not the number on the website

There are two counts in play, and they do not agree, and the discrepancy is informative rather than a mistake.

The README's Proposal Count section says the total proposals submitted is 43. The website section at the top says the platform explores organisation-wise accepted proposals, 120 or more proposals, from past years, along with curated blogs, tips and resources to maximise your chances.

So the website is a broader thing than this repository. The archive is the 2025 proposals, and the site aggregates across years and adds advice, tips and resources. The 43 is the count of what is in the folders here, and it is generated rather than typed, because the README carries a note saying it is automatically updated and that the proposal count, the organisation list and the contributors are maintained by GitHub Actions whenever new proposals are added or pull requests are merged.

That is a good design for an archive. A hand-maintained count drifts, and a count that is regenerated from the tree cannot. The same mechanism keeps the org checklist and the contributor list current, which is why the checklist is a set of ticked boxes rather than a list of links.

The lineage is documented too. The inspiration for the repository came from aritra8438/GSoC_archive, which holds proposals from 2024 and earlier years, and for more 2025 accepted proposals the README points at a blog post from 100xDevs.

So if you want the full picture of what was accepted in 2025, this repository is the core of it but not the whole, and the archive from the previous year plus the blog post fill in the rest.

The contribution workflow, and why a PDF is the right unit

The contributing instructions are a nine-step Git workflow, and the interesting part is step seven.

You fork the repository, clone your fork, add the upstream as a remote, sync with the main repository, and create a branch named after the organisation:

git clone https://github.com/YOUR_USERNAME/YOUR_FORK.git
cd GSoC_archive_2025
git remote add upstream https://github.com/SammanSarkar/GSoC_archive_2025.git
git pull upstream main --rebase
git checkout -b add-proposal-<org_name>

Then you add your proposal: create a folder named after the organisation if it does not exist, and place your proposal PDF inside that folder. Then commit, push and open a pull request.

The branch naming convention is the mechanism that makes the automated README possible. A workflow can look at the branches and pull requests and know which organisation a contribution is for, which is what lets the org checklist be regenerated rather than edited.

The choice of PDF as the artefact is deliberate and correct for the purpose. An accepted proposal is a document with a specific format, submitted to a specific organisation, in a specific year, and a proposal that is rewritten into another format loses the thing that makes it useful as an example, which is that it looks exactly like what that organisation asked for.

The downside is that the archive is not searchable in any structured way. You cannot ask which organisations asked for projects touching a particular technology, you cannot compare the scope of proposals across years, and you cannot diff two proposals. For a human reading one or two PDFs, that is not a problem. For anyone who wants to analyse the programme, it is a wall.

The companion site, and what it adds to the archive

The README leads with the website, GSoC Guide at gsocguide.vercel.app, and describes it as a comprehensive platform to help you succeed in Google Summer of Code, with organisation-wise accepted proposals from past years and curated blogs, tips and resources to maximise your chances.

The distinction between the two is the useful thing to hold on to. The repository is the raw material, PDFs of accepted proposals from one year, and it is authoritative in the sense that it is what was actually submitted. The site is the interpretation layer, with the same proposals organised for browsing, spread across years, and wrapped in the advice that a site about succeeding at GSoC would carry.

That is a sensible division, and it is also the standard shape for this kind of community project. Somebody with a good index and a good interface builds the site over an archive that a set of contributors filled with documents. The repository is the durable artefact, because the site can be rebuilt from it, and the site is the convenient one.

The site is deployed on Vercel, which is visible from the domain, and the repository contains a `.github/` directory for the workflow that keeps the README in step.

For a student, the practical path is to find the organisation you are applying to in the checklist, read one of its accepted proposals from this repository, and then use the site for the process advice, the tips and the wider context. The archive tells you what the finished article looks like, and the site helps you write it.

Where this archive is the wrong thing to rely on

The first wrong case is a project that needs the whole programme indexed. The repository holds one year, and the proposals are PDFs with no metadata, so there is no way to query across organisations, technologies or years. The website is the tool for browsing, not the archive for analysis.

The second is a student who treats an accepted proposal as a template. An accepted proposal is one that worked for one project in one organisation in one year, with that organisation's conventions and that mentor's expectations in mind. Copying its structure without understanding what the project needed is a common way to end up with a proposal that reads like a form and convinces nobody.

The third is an organisation looking for trends. If you want to know what a project is being asked for year over year, you would want the 2024 archive and the one before it, and you would want to compare them, and this repository is one year of PDFs.

The fourth is anyone expecting the README to be the documentation. It is a generated index, and the real content is in the folders, and the real guidance is on the site.

The fifth is a contributor who expects their proposal to be accepted into the archive. The instructions say to submit it if your proposal was accepted, so the archive is by definition a record of successes. A rejected proposal, which is the more common outcome and arguably the more instructive document, does not go in.

What the repository does well is narrow and real. It is a small, verifiable, public pile of real examples, contributed by the people who wrote them, in a format that shows exactly what was submitted, and it costs a contributor one pull request to add to.

Editorial conclusion

GSoC_archive_2025 suits a student writing a GSoC proposal who wants to see what a real accepted proposal for the same organisation looks like, rather than a template, and it is more useful still if you read the PDFs for several organisations rather than one. It does not suit anyone expecting a maintained index of the whole programme, since it holds 2025 only and points elsewhere for other years, and it does not suit a project that needs structured data, because the content is PDFs with no metadata to query. Before you rely on it, look at the proposal count in the README against the number of directories, and remember that an accepted proposal is a proposal that worked once, not a template that fits your project.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. SammanSarkar/GSoC_archive_2025 on GitHub