Grokking Open Source Contributions

• John Vandivier

In the past two weeks, I've gotten two PRs merged to major open source projects, and a third issue that I raised was solved by another person's PR. This article documents what those contributions are, but more importantly, it also gives tips about how you can get started contributing to open source.

I. What Were the Contributions?

  1. Supabase PR, feat: allow twitter profile #94, which allows developers to build successfully when using the Twitter social sign-on button from Supabase.
  2. Next.js PR, feat: concise card code #348, which removed extraneous code in some implementations of the ProductCard component.
  3. Next.js Issue, DRY isAllowedMethod util #25590, which noted that there was some duplicate code that could be extracted to a common utility.

II. Tips for Getting Merged and Making Other Good Contributions

  1. Approach open-source as a user first
    1. Developers can nitpick open-source code, but these improvements are often low-value. High-value improvements solve problems for users.
    2. Instead of searching for where you can contribute, start building something and use open-source products as a dependency. Then, if that dependency has an issue, fix it. If your PR wasn't accepted you still improved your own stuff, and if it is accepted then you helped a bunch of people!
    3. As an aside, I ran into all of the issues this article describes while building a gamified store called Futurecaster, and the development is recorded on video in a series of so-called The Moonlogs:
      1. https://futurecaster.vercel.app/
      2. https://github.com/Vandivier/futurecaster
      3. The Moonlogs YouTube Playlist
  2. Start with Issues, not PRs
    1. You will get your PR prioritized if it closes an issue, so even if you have the code ready you should still make an issue.
    2. Issues by themselves without code can still be valuable. The community can discuss and vote to see if many people want the solution or if it can be tweaked in a way that makes many people happy or nah. You may find that your issue is already being tracked and/or is related to things people are already working on. Contribute with votes and comments too!
    3. In open-source and also in normal programming, you will often win social consensus and save technical effort by talking about your approach before coding it. This almost bleeds into a social norm, where GitHub maintainers
  3. Minimally scope PRs - start with a single component
    1. I saw multiple cases of duplicate code, but note that I did not put all the changes in one PR. That might have gotten my Next.js PR rejected if I did that.
    2. As you gain familiarity and reputation for contributing to a repo this can totally change, but it's definitely a good way to start, and tbh even after you're the cooliest it still doesn't hurt.
  4. Know the Lingo
    1. This is arguably optional but I think it will signal to other people that you know what you're doing and therefore make them more inclined to agree with you in discussion and merge your stuff or take your suggestions seriously.
    2. For example, 'grok' in this article title is dev lingo. 'PR' is dev lingo, and I use dev lingo in my PR titles when I use the 'feat' prefix.
      1. By the way, if something can be called a feature or a fix then go ahead and call it a feature. This is an example of using communication in a way that ingratiates your work with software devs. If you PR with something you call a fix and it doesn't actually fix a critical bug, people might get annoyed and think you are calling their software buggy when it isn't, or that you otherwise don't know what you're doing.
      2. For example, some people might consider my code for 'feat: allow twitter profile #94' to be a bugfix, because it does fix a type error and it resolved broken builds and so on, however I know that those issues only came up because it was a new feature that was not yet completely implemented. So it could equally be considered completion of a feature-in-progress, and this is a nicer way to communicate the work.
    3. Finally, this will just flat out help you technically. If people really do want to debate the implementation then you need to be able to understand what they are saying and respond in a \"normal\" (from a dev perspective, which is to say including tech vocabulary) way.