My experience contributing in Google Summer of Code

FOR THOSE WHO DON'T KNOW a

• I found out about GSoC this year while looking for a part-time software development job
• GSoC has several pages about what to expect as a contributor, but I was still left with many unanswered questions
• The experience may differ widely from organization to organization
  • I'm with the Processing Foundation, working on an inclusive creative code library called p5js (try it!) I think it's a lot more beginner friendly than other organizations.
• This post covers what I had to figure out for myself and what I found interesting about GSoC in general. It's aimed at applicants and contributors who don't know what to expect. It also tells my friends what I've been up to this summer!
• If you want to dig into the specifics of my project, look at before & after demos, or see a week-by-week breakdown, that's in the shader filters post.

GSOC FACTS a

• Open-source code organizations get to onboard new contributors. The new people get money, and the organizations get a little money too
• It's like an internship but without a job afterwards. Or it's like a short contract gig, but with some handholding
• Mildly interesting: the program is sponsored by Google, so naturally several Google products are used: forms, spreadsheets, slides, videochats, account verification, mailing lists, and two Google employees
• GSoC is an international program. Some features of such a wide scope:
  • Yay! Interacting with lots of contributors from across the world. I feel cultured already
  • Yay? Mostly async work across timezones
  • Nay! Complications receiving payments. Contributors outside the US have to worry about work visas and laws and taxes and traveling. And Google isn't responsible for giving legal advice, so it's on the contributor to figure out these laws. EDIT - I still ran into a small issue with tax forms, despite American privilege. EDIT 2 - I got my tax form emailed the following February from tax1099.com - suspicious but legit
  • Nay? No 'swag'. Apparently in previous years, GSoC gave out shirts and other merch. But it became a shipping nightmare. Not that I care about a shirt, but somebody else did
• Some numbers from this year (source):
  • 43765 applicants / registrants who signed up, not necessarily sending proposals
  • 7723 proposals submitted from 5679 people, and 966 accepted
  • For comparison, the Processing Foundation accepted 8 of 91 proposals (source)
  • 171 organizations
  • Over 2000 mentors and org admins; this means 1-2 primary and 1-2 backup/niche mentors per contributor; more than usual
    • Evaluations are performed by only one mentor
    • A mentor with a lesser role was called an advisor (at least for my org)
  • In 2022, ~10% of contributors were non-students. No stat yet for 2023. For context, only students could apply before 2022.
  • ~100 contributors applied for lightning talks at the end, and ~40 were randomly accepted
• Stipend thoughts:
  • The stipend amount is mentioned somewhere deep in the docs. It's a modest amount compared to normal developer salaries.
  • GSoC offers other value besides the stipend, like mentorship and networking and a large community and a safety net, which are all particularly valuable for beginners. You also get a PDF certificate and a place in their project archives, which some people might like to share.
  • Each stipend * hundreds of contributors = a significant chunk of money for Google to give away every year.
  • Payments are handled through a third-party service called Payoneer. They needed my SSN as part of the application process - that always makes me uneasy, but I guess that's just how irl verification goes sometimes.
  • Funds are distributed from Payoneer into a bank account or a prepaid card. I heard that for contributors in India, it's bank account only.

PROPOSAL PERIOD a

• The project description should be a single line of plain text under 100 words. You might want to include hyperlinks or bullet points or newlines, but bad idea. The project description will be copy-pasted into your GSoC dashboard, into forms for your org, and into other text inputs where formatting and linebreaks are unwelcome. And you probably can't change it later.
• Each organization likely has its own convention for submitting proposals. The Processing Foundation did not have any docs regarding making proposals. But I just looked for past contributors and followed their example, which meant uploading a Google doc to the forum for feedback. No particular formatting conventions. Here's my proposal.pdf for reference. It was shorter than other proposals and it had no pictures, but it still covered the important details.
• The proposal will be uploaded as a PDF to the GSoC dashboard.
• I delved into all the relevant PRs and issues and documentation I could find. The main ones got cited in the proposal.
• I wish I made a small contribution to the codebase around this time, like opening an issue or working on a small PR. It would've given me a head start with the codebase and the organization's procedures.
• Time is fleeting! I did my best to plan a timeline for coding, but non-coding activities take a lot of time. My initial email to mentors took an hour to draft. So my conservative estimate for estimating: 1 hr of new code = 10 hrs of researching and communication and experimenting and other work.
• A baseline pace of work that I heard: 20 hrs/wk over 12 weeks

IN THE MIDDLE a

• There's a few GSoC-wide video chats throughout the program to double down on important info for contributors. There's also Q+A sessions at the end of each video chat. These meetings are usually held ~16:00 UTC (midday US time) early in the week. Not mandatory, but helpful.
• Regular communication with mentors is important. I benefitted a lot from a weekly video chat because I got a lot of feedback in a short amount of time, and I needed to talk about code. More experienced programmers may thrive on text-only communication.
• It's expected to publicly log updates throughout the project, like in a series of blog posts.
• There's a halfway and a final evaluation. An evaluation seems like an opportunity to prune out the totally unproductive contributors. For the vast majority of contributors, it's just a little questionnaire, followed by payment. Here's a list of questions for evaluations.

PERSONAL REFLECTIONS a

There are several takeaways I came up with, but first I'll start with a story: There was a week when the p5js core library and web editor both released new versions. I happened to be catching up on GSoC that weekend and noticed the web editor kept crashing on errors. (Kinda bad, like make-a-typo-and-page-turns-irreversably-white-until-refresh-bad, which is frustrating but still usable in a sense; some would say "serious". This was the public coding environment.)

Usually, as a tech user, I would search for bug reports and workarounds, and maybe wait for someone else to fix things. But now I was a contributor, and I felt like an insider, and I had enough confidence and experience and funding to dig in and fix things.

Turns out the root cause was one line in some updated dependency. Credit to @lindapaiste to figuring out the details - all I did was give logs and reproduce on my machine.

But reproducing meant initializing the new repo, which meant downloading a database tool (MongoDB) for the first time and troubleshooting that installation, and then installing 1000 packages (really 100 dependencies that spawned 1000 node_modules), and then running tests and confirming results. The fix? Downgrading the dependency from 3.5.0 to 3.2.0.

The maintainer said I could make a PR for the change if I wanted, which felt silly because it was such a small diff, and she was an experienced maintainer whereas I was just a visitor from a sibling repo. She was doing all the hard work. But maybe she was busy sleuthing further, and maybe she wanted to encourage collaboration, and so I made the PR.

The main maintainer @raclim ended up pushing fixes around midnight. This wasn't part of my paid assignment, but it's still relevant. It was fun to be around something important that broke. I was surprised how empowered I felt to contribute to that new repository. And it's a good launching point for some other reflections:

ON PEOPLE(WARE)

• GSoC showed how software can be more social than technical
• The value in that weekend update could not be measured in lines of code
• Being available and being redundant are forms of value
• Don't release on Fridays! (Because when it breaks on the weekend, people will be afk)
• GSoC was my first time talking about code to another programmer, verbally in realtime. I wish I had done it years earlier instead of learning and working in a total vacuum. Less impostor syndrome now
• Positive vibes help combat nervous feelings (ie. thanks for the encouragement)
• The amount of code a solo dev could churn out in a day is equivalent to weeks of work in open-source, where there's discussions and comments, reviews, communication gaps, and other processes
• Coordinating syncs across timezones is challenging! Shoutouts to @sosunnyproject for working with 3 American timezones, 13 hrs away
• The hard work behind good software is often done by volunteers (how do they find time and pay the bills??)
• Deadlines and reviewers change the coding dynamic, compared to solo work with little accountability
• It's nice to work in an environment that accomodates the ebb and flow of problem-solving; no hourly rates, no daily check-ins
• People like easy! The one-click code sharing link of the p5js web editor was fantastic for reproducing bugs and prototyping features, especially for people away from their work machine (ie. mentors away traveling), compared to pulling a branch and investigating locally
• GSoC is a good opportunity to for orgs to get some momentum behind important changes. For example, the feature I worked on was proposed in 2020 but sat dormant for a few years

ON COMPLEXITY

• An acknowledgement: software is messy. It must be especially hard to avoid complexity from hundreds of (javascript) contributors over several years 1
• It's hard to be onboarded into the middle of a big codebase
• I'm thinking about grug developer and the Elm architecture as the opposite ends of the complexity spectrum; keeping things understandable, even at scale
• An example of bad complexity: too many dependencies. Semantic versioning sounds like a helpful tool to manage them, but it's just a human convention (one person's minor implementation detail could be another person's breaking change). Tests might help if you thought of the right cases. But things break where you don't expect. So unfortunately it's on the maintainers to be responsible for each dependency, and that's a lot of responsibility when there's a lot of dependencies. I would prefer to keep dependencies to a minimum and lock versions as long as possible.
• It feels weird to mention accomplishments in lines of code, since more code is a maintenance burden. But I suppose the easiest way for new people to contribute is by adding features, not by refactoring or removing code

ON DOCUMENTATION

• Inline docs lead to useful automation. p5js uses a javadoc-inspired tool not just for generating reference pages, but also parameter validation and friendly error messages. It's nice to have descriptions and examples living with the code
• Contributor documentation, ie. developer docs, were very helpful for me to understand the new codebase. But they were hand crafted .md files that could easily become outdated
• p5js has all the types of docs, from API references to tutorials to getting started pages to developer docs. It's a nice place to practice writing docs
• It's hard to keep docs consistent. (eg. how to capitalize WebGL? how often to link to related resources?) A style guide is a good first step. But I wonder if there's any other tools or processes

ON TOOLS

• rgrep is my friend; I used it many times to search across files, especially since Github (the next best code search?) has bogged down its UI
• git feels more useful and less intimidating now that I've practiced creating/updating/merging branches, staging commits, and reverting commits. I even resolved my first merge conflict
• I used tig for visualizing branches, catching up to latest changes, and committing. No more git log or git add or git commit or git status for me. Looking forward to using more shortcuts
• I realized Github is good because git needs to be supplemented with conversation tools like issues and pull requests
• I got to see how dev tools performed on a medium-scale codebase: git stayed snappy, vim stayed snappy, but npm scripts got a little ...crappy. EDIT - I recently heard about other projects with hour-long build times. So I suppose I shouldn't complain about seconds/minute-long scripts
• I realized how much I value a tight feedback loop; waiting for builds and pre-commit lints killed my momentum
• On linting: I'd rather have an autoformatter than a linter that complains but doesn't make changes
• On commits as communication: I pushed updates 1-2x/week so that mentors could see my code and give feedback. But my usual stopping points were in the middle of debugging challenges where I ran out of momentum. It felt bad to leave broken commits. I think there's some git commands to redefine commit history? I didn't have time to learn those though. I also started leaving TODO comments to communicate immediate next steps
• On debugging: I'm a console.log() kind of guy. But shaders do not come with print statements, so they require special debugging tools. Canvases are similarly difficult; printing pixel values is not very helpful. If the project was bigger, I would've found or made some tools for inspecting shaders and canvases at runtime.
• When working with deadlines, there's not much freedom to fiddle with and choose tools. It's more about getting stuff done and less about maintaining my idealistic little programmer bubble. Example: I would've gone out of character and used Sourcetree, an enterprisey git gui by Atlassian, just because it was an early recommendation. But it kept crashing, so I searched for an alternative and ended up with tig (thankfully). Another example: I think the linting tool can be configured for autoformatting, but I couldn't figure it out easily. Maybe I should've invested more time at the beginning upgrading my editor and tooling

LEFTOVER THOUGHTS

• GSoC is a good opportunity to practice writing, and a good opportunity to get someone new to visit your website.
• Everyone with p5js is so artsy! Some of their personal websites:
  @aferriss - https://amf.fyi/
  @aceslowman - https://www.aceslowman.com/
  @sosunnyproject - https://sosunnyproject.github.io/
  @davepagurek - https://www.davepagurek.com/
  @limzykenneth - https://limzykenneth.com/
• Special thanks to Adam Ferriss for a great experience. He was a pleasure to work with and a big help. He seems very competent with people things and technical things. Thanks to Austin Slominski too for the useful advice and feedback. They went out of their way to be extra responsive and helpful.

FOOTNOTES a

1 The first commit was by @lmccart 10 years ago. Missed opportunity for an anniversary party...