# gsoc-organizations: a scraped, filtered view of the GSoC archive > gsoc-organizations is a Gatsby site that collects the organizations participating in Google Summer of Code, filters the scraped data to fix duplicates and misspelled technologies, and serves it as a browsable site plus a JSON API. It suits students and mentors picking where to apply, and it is a data curation project as much as a web app. **nishantwrp/gsoc-organizations** — A site for viewing and analyzing the info of the organizations participating in Google Summer of Code. - Repository: https://github.com/nishantwrp/gsoc-organizations - Website: https://www.gsocorganizations.dev - Stars: 750 · Forks: 116 - Language: JavaScript - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/nishantwrp-gsoc-organizations ## A lookup table for past GSoC participation gsoc-organizations is a site for viewing and analysing the information of the organizations participating in Google Summer of Code, and filtering them by various factors such as years of participation and categories. The homepage is at gsocorganizations.dev. The framing is worth pausing on. This is not a project-management tool for GSoC, and it does not track open issues or mentor availability. It is a retrospective index: which organisations have taken part, in which years, and what they work on. For a student choosing where to apply, that is a genuinely useful question, because the official GSoC archive is organised by year and project, and a per-organisation view across years is not something the archive gives you. The stack is two pieces and both are named in the project documentation. Gatsby is the frontend framework used for developing the site, and Redoc is used for generating the API docs. The topics list also carries gatsby, github, redoc, hacktoberfest, open-source and student, which reflects a project that is a students' and contributors' artefact rather than a commercial product. The primary language is JavaScript, the licence is GPL-3.0, and the repository is not archived. The last push was on 2026-05-14, which is worth remembering when you judge how current the data is: the site is regenerated from a scraped archive, so its freshness is bounded by that regeneration, not by the archive itself. ## The filters are the project, and they are meant to be edited The data displayed is scraped from the official GSoC Archive, and the project says plainly that there may be some errors in the data. The response to that is a set of custom filters defined in the api/filters directory, and the contributing guide says the filters can be improved a lot and invites contributions to them. Two examples are given, and they show the two different kinds of error the filters deal with. The first is duplicate organizations on the site, caused by organisations appearing under different names. The name filters in api/filters/name-filters.js exist to collapse those into one entry. If a project appears as "Apache Software Foundation" in one year and "ASF" in another, a per-organisation view would show two organisations that are the same one, which quietly corrupts any count you make. The second is technology tags, where some are modified because they contain spelling mistakes or for the sake of better filtering. The example given is that javascript/html/css has been broken down into javascript, html and css as three separate values. That is a normalisation, and it has a consequence for anyone querying the data: a technology value is a controlled vocabulary now, not a free-text field, so searching for the combined string returns nothing while searching for javascript returns the projects that use any of the three. The filters all work in the same way, and the guide asks for contributions to any of them where you see scope for improvement. This is the most attractive part of the project to contribute to, because the work is concrete and the effect is immediately visible on the site. ## Two deployments: the site and a separate API The site and its API are deployed separately, and the deployment badges make that explicit. The main site is a Netlify deployment for the Gatsby front end, and the API docs are a second Netlify deployment, gsoc-organizations-api, whose badge is shown under its own heading. That split has a purpose. The main site is a static Gatsby build, and the API is a separate bundle with its own documentation site, so the two can be versioned and deployed on their own schedule. For a consumer, it means the JSON data is available without scraping the site. The repository layout reflects it. There is a gatsby-config.js, a gatsby-node.js and a gatsby-ssr.js, plus gatsby-browser.js, which is the standard Gatsby set for site configuration, data sourcing and server-side rendering. The src/ directory holds the React components, static/ holds images and other assets including the logo and favicon that get copied into the API distribution, and api/ holds the OpenAPI specification, the filter files, the data and the Redoc template. There are scripts/, with the data generation script among them, and a wrap-with-provider.js file at the root for the Redux provider. The application state lives in Redux Toolkit, and the filtering and search in the browser use fuse.js, a fuzzy search library, with a debounce package to keep the search from running on every keystroke. Charts are handled by chart.js with react-chartjs-2, and the icon set is FontAwesome, including a GitHub button component. ## The Makefile is where the data pipeline is visible The api target in the Makefile is the most informative file in the repository, because it is the whole data pipeline in a dozen lines. It starts with a yarn install, then bundles the OpenAPI specification with redoc-cli using a Handlebars template, then clears and recreates the api-dist directory, copies the static Redoc HTML page into it as index.html, copies the contents of api/data into the distribution, runs the data generation script, and finally moves the resulting organizations.json into the distribution, formats it with prettier, and copies the logo and favicon across. Two details in that sequence are worth noting. The data generation step runs after the raw data is copied, which means the transformation happens at build time rather than at request time, and the output is a single organizations.json file that the front end and any API consumer both read. And the prettier run on that file means the generated JSON is committed in a normalised form, so a diff in the repository shows a real change in the data rather than a formatting change. The same tooling appears in the package.json scripts. The build is gatsby build, the development server is gatsby develop, and there is a serve script for gatsby serve and a clean script for gatsby clean. The redoc script serves the API specification directly with redoc-cli serve api/openapi.yml, which is the quickest way to read the API contract while working on the filters. The dependency set is large for a data site, which is the cost of building on Gatsby. The site also carries analytics and advertising plugins, the Google Adsense plugin and the Google gtag plugin, and an offline plugin and a sitemap plugin. ## Contributing, tooling and the shape of the repo The contributing guide lists three kinds of help wanted, and the first is the filters, then UI and UX improvements, then new features, with the last one routed through an issue for discussion rather than a pull request. The tooling in the repository is worth noting because it is more elaborate than the code. There is a .husky/ directory and a .lintstagedrc.json file, with husky and lint-staged in the dev dependencies and a prepare script that runs husky install, so commits are formatted and linted automatically. There is a .prettierrc file, a .prettierignore, a .npmrc and a .nvmrc, which pins the Node version the project expects. The lint script is a prettier check across js, jsx, ts, tsx, json and md files, and there is an .agent/ directory at the top level. The repository is private in the package.json sense, with a version of 1.0.0 and a yarn.lock, so yarn is the package manager of record even though the scripts use npm run as an alias. The Makefile confirms that, since the api target calls yarn install. Two further things about the project's scope. The description says contributions are welcome, whether reporting an issue or sending a pull request, and the readme carries a PRs welcome badge and a lint checks workflow badge, so the continuous integration is there to enforce the contribution standards. And the licence is GPL-3.0, with the LICENSE file at the root of the tree. ## Where gsoc-organizations is the wrong tool The first limit is authority. The data is scraped from the public archive, and the project says outright that there may be errors in it. The filters are a mitigation, not a guarantee. If you are making a decision that needs a correct number, such as how many projects a foundation ran in a given year, this site is a good way to find the projects and a poor way to produce the number, and the GSoC archive itself remains the source. The second limit is that the site is retrospective. The description talks about organizations participating, and the filters normalise names across years. Nothing in the project describes current year application status, mentor openings or issue trackers, so a student looking for a project to work on this summer would use it to research an organisation and then go to that organisation's repository. The third is the filter model itself. Normalisation is a one-directional decision. Splitting javascript/html/css into three values is right for filtering, but a consumer who wanted the combined tag has to re-join them, and a project that genuinely used a stack called javascript/html/css as one technology is now three rows. The same applies to the name filters: one organisation may become several, and the site offers no way to see the pre-filter list. The fourth is that this is a Gatsby site, and Gatsby is a large dependency with a build pipeline that has to succeed for anything to deploy. A team that wants a small static dump of the same data could scrape the archive directly and keep a JSON file, and the project itself shows that path in its Makefile, where the raw data lands in api/data and a generation script produces organizations.json. The value the site adds over that is the browsing, the search and the API, and if you need none of those, the site is more than you need. ## Conclusion gsoc-organizations is worth using as a lookup and as a reference implementation if you want to know which projects took part in Google Summer of Code in a given year, because the filtering work is the value and the filters are open for contribution, so a student looking for organisations working on a particular technology can either search the site or add the filter that makes the answer visible. It is the wrong tool if you need authoritative programme data, since the data is scraped from the public archive and the filters exist precisely because it contains errors, and it is the wrong tool if you want to browse current year applications rather than past participation. Before you rely on it, check the three things the project itself tells you to check: that the organization you are looking for is not a duplicate entry renamed, which is what the name filters exist to catch; that the technology tag you searched is the normalised one, since javascript/html/css is deliberately split into three separate values; and the freshness of the archive, since the last push to the repository was on 2026-05-14 and the site reflects whatever the archive contained when it was last regenerated. ## FAQ ### Where does gsoc-organizations get its data from? The data is scraped from the official GSoC Archive, and the project notes that there may be some errors in it. A set of custom filters defined in the api/filters directory corrects for duplicate organization names and for technology tags that are misspelled or need splitting for filtering. ### How do I contribute to gsoc-organizations? The contributing guide asks for help in three areas: improving the custom filters in api/filters, improving the UI and UX, and adding features, with feature ideas routed through an issue for discussion. The filter files are the most concrete starting point, with name-filters.js and technology-filters.js as examples. ### What is the tech stack of gsoc-organizations? Gatsby is the frontend framework and Redoc is used for generating the API docs. The package.json adds Redux Toolkit for state, fuse.js for fuzzy search with debounce, chart.js with react-chartjs-2 for charts, FontAwesome for icons, and the OpenAPI specification in api/openapi.yml is bundled with redoc-cli. ## Sources - [Issues](https://github.com/nishantwrp/gsoc-organizations/issues) - [License: GPL-3.0](https://github.com/nishantwrp/gsoc-organizations/blob/master/LICENSE) - [nishantwrp/gsoc-organizations on GitHub](https://github.com/nishantwrp/gsoc-organizations) - [Project website](https://www.gsocorganizations.dev) - [README](https://github.com/nishantwrp/gsoc-organizations/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nishantwrp-gsoc-organizations