Google Summer of Code 2026's 12-week timeline wrapped final evaluations at the end of August, with shorter projects finishing earlier. This post reads the official projects page and Google's program announcements for scale, acceptance rates, and what is marked complete versus still active. It then ranks mentoring organizations by volume and highlights where the largest slots landed. The centerpiece is a personal list of 50 completed projects from orgs including Apache, Debian, Django, Git, the Linux Foundation, OWASP, and PSF. Bias is declared up front: security-related work, hardware, frameworks I use, and communities I am close to.

Part 1 covered preparation and choosing an organization. This part focuses on contribution and communication -- the habits that make technical skill visible to maintainers. It covers Git and GitHub Flow, keeping forks current, and pull-request hygiene that respects review bandwidth. There is also guidance on reading project guidelines, handling feedback, and using AI responsibly without dumping unowned volume on mentors. The closing thread is how to talk to communities clearly so your work gets noticed for the right reasons.

Unsolicited, low-effort pull requests burn maintainer attention on open projects, and AI made that volume cheaper to produce. This post starts from OWASP Nest queue pressure around mentorship seasons and the project's issue-first, assignment-before-code workflow. It then contrasts the archived check-pr-issue-action -- an assignee gate with an issue-link prerequisite -- with check-contribution-action's multi-check maintainer DX. The newer action adds selectable gates, selective auto-close, optional DCO and commit signatures, and safer wiring guidance for pull_request_target. Context also spans OWASP Nettacker and the Open World Holidays Framework, without pretending the bots can detect AI.

Over a few years of mentoring for OWASP and the Python Software Foundation, I have watched contributors succeed and stall in Google Summer of Code. This first part starts with what GSoC really is -- remote open-source work under mentors, not a traditional internship -- and what evaluations actually reward. It then covers how to choose and research an organization, including why smaller orgs can be a smarter bet than the most competitive names. From there it walks through joining the community early, making real contributions before proposals are due, and shaping a standout application. The through-line is preparation and relationships, not last-minute proposal writing alone.

security.txt (RFC 9116) is a small, predictable file at /.well-known/security.txt that tells researchers where to report vulnerabilities -- contact, policy, expiry, and related fields. The format is simple and widely referenced, yet adoption is uneven: some flagship sites ship rich signed files, while others omit Expires or skip the file entirely. This post covers the well-known location rules, what good-enough looks like in practice, and a curated look at live examples worth opening in a tab. It also walks through a practical shipping checklist and the file this site now publishes. An update from September 2026 adds a European software-vendor adoption scan to the picture.