Google Summer of Code
We’re all aboard the coding train with the Google Summer of Code.
What do you do when you code like you’re from the Nordics? My entire scientific career I’ve been programming with my blinders up - not really contributing to other packages or toolboxes. In part, I’m very driven on my own work, more so than maintaining or improving the work of someone else. But primarily, it’s trepidation. A subconscious avoidance of any kind of potentially unwanted interaction that could be taken as fear or cowardace.
Google Summer of Code seeks to break that down.
The world, believe it or not, runs on open-source. Without Linux, server infrastructure wouldn’t be half of what it is. Wikipedia is open to all and transparent about everything with a hearty community of editors that make the pages good enough to cite (though the ‘never believe wikipedia’ ethos of my childhood still has some validity). Millions of actions go thanklessly throughout the world’s cyberinfrastructure to keep things running and safe.
One of those open-source projects belongs to the U.S. Integrated Ocean Observing System, or IOOS. They developed the QARTOD (Quality Assurance/Quality Control of Real Time Oceanographic Data) toolbox, which is used by many groups for various ocean observing platforms today. However, it’s one of those cases where it serves a greater community and only volunteers can normally maintain, enhance, or assess it. Until GSoC came along.
In oceanography, it can be hard to build up both the interdisciplinary science background to know what to do as well as the engineering wisdom to know how to best do it. In my career, my work has very rarely seen the light of day or been ready for someone else to take over if I had an accident. It was always for internal use. I’ve been missing the wisdom to become a ‘unicorn’ of sorts that can maintain scientific toolboxes built by our predacessors. I work with some incredibly talented people now that are unicorns - they look around online, find something that fits their use case, and they use it. But furthermore, they get involved. They make pull requests. They sit in on meetings. It’s important to them because it’s important to the community. That’s where I want to be.
I applied for the GSoC project idea as listed in GitHub GSoC 102 after a suggestion by one of the unicorns in my group.
The application required a number of different things.
First, to get familiar with the QARTOD aspect of the ioos_qc toolbox and tinker a little.
My ability to read code and use the package would be a mandatory aspect of applying.
Next, I needed to write a proposal.
This consisted of:
- Technical description of the work to be done.
- Statement of intent during the community bonding period.
- A schedule of deliverables.
- A description of documentation, demonstrating learning.
According to the requirements listed in the project idea, I was able to put together the following timeline using the Google due dates:
| Stage | Stage specifications | Time required | Start-End |
|---|---|---|---|
| 1 | Learn about the community and note shortcomings or additional toolboxes, such that the wheel need not be reinvented. | 3 weeks | May 1 - May 24 |
| 2 | Begin test assessments and complete Group 1 “required” tests. | 4 weeks | May 25 - June 21 |
| 3 | Complete Group 2 “Strongly Recommended” tests. | 2 weeks | June 22 - July 5 |
| 4 | Complete Group 3 “Suggested” tests. | 3 weeks | July 6 - July 26 |
| 5 | Explore other tests and finalize documentation. | 3 weeks | July 27 - August 16 |
This is all before the final week of GSoC, wrapping up the week of August 17th.
The proposal process wasn’t difficult - once I knew my mentor it was a slam dunk. However, it is easy to get discouraged. The world is filled with zealous computer-science majors. Folks that are innately talented with the coding practices and theory to effortlessly make big contributions. Weeks before I got my proposal in, I saw numerous pull requests going into the repository that I was applying to help with. Admittedly, some of them were written by AI. Others appeared misguided or needed work. But they were showing incredible initiative by simply making the contributions, to show that they knew how the codebase worked. Meanwhile, I was sitting back in my sheltered mindset doubting myself. How can I compete with this guy, who strung together 20 well-organized commits and created a PR with no errors? I can’t act as efficiently as they can.
In my case, though, my application wasn’t in too much doubt. But it was reassuring to hear from my mentor that the goal of GSoC isn’t to create some S+ tier product (though that’d be nice). It’s to create unicorns. Many of the other applicants are looking to add GSoC to their resume but in the long run, it’s unlikely that they’ll get an oceanography degree to really be able to engage with the user base. Meanwhile, this is a package that I hope to use in my workplace. It’s relevant to me. It’s relevant to the community that I want to support.
So far, I’ve learned a lot. About the community. About the history of the software that I’m looking to assess and improve. I’m picking up some of the street smarts that will (hopefully) make me a good collaborator and responsible coder. I’m coming into this as a person with basic coding skills to get experience. Don’t be discouraged from engaging with your community - the world is full of work to do and too few hands to do it. If we work together, the load is lighter. And when it comes time to pass a torch, transparency and education prepare the next generation to make it bigger and better than it was before.