I attended MumbaiFOSS last month and had several discussions on open source software. The most painful part was listening to discussions about how to contribute to FOSS. Plenty of college students attend these conferences[0]. Naturally, they want to get some FOSS contributions under their belt because our colleges and industry professionals now use that as a filter for hiring.

I zoned out during the panel discussion because I don't agree with the premise itself... by making FOSS contributions a metric, we have screwed up the whole point of it a.k.a. Goodhart's Law.

Problem

There is enough slop out there, my understanding is 95% of almost anything out there is crap. The same goes for open source contributions. I've reviewed and merged 100s of open source contributions over the last 4 years as an open source maintainer on fairly popular projects. Based on my experience, I broadly see three types of contributors:

1. Students/new engineers who want to land a few FOSS contributions.
2. Users who happen to be developers wanting to fix/add something upstream to solve their problem.
3. Employees of businesses who have a long-term commercial incentive to work on the project.

I very strongly prefer 2 and 3. Users are good contributors because, well, they've used the project. They have a better idea of why some change might be required. They'll spend more time testing and making sure their changes work. They'll spend more time going through the initial process to ensure their changes are merged. Businesses that have long-term vested interests are also more likely to vet their changes and do quality control. These contributors often become long-term partners in the project that benefits both parties.

From the maintainer's POV, one-off contributors who just need to pad their resumes are an extra burden with little benefit. I've spent hours getting people to follow basic things specified in the contributor's guide, writing tests, or even ensuring that the proposed change actually does what it's supposed to do.

I don't like nitpicking, but it HAS to be done for new contributors or the quality of what is accepted degrades over time, aka cough cough Broken windows theory[1]. All in all, usually it takes more effort on my side to merge a contribution like this than it'd take me to make the change myself.

Prescription

All of this is quite cynical... what should I do then?

I don't have any policy prescription that will solve all the problems in the tech industry; it's saturated now, so the bar for getting hired will keep going higher. I just have one suggestion: Use FOSS before contributing to it. At MumbaiFOSS, I saw close to 3/4th of developers using Mac or Windows... same thing happens where I work, we produce 100% FOSS software, and more than 3/4th of the team uses Macs and all kinds of proprietary software. If you have not bought into the whole idea, then please don't try to preach it; the hypocrisy is visible from miles away.

How does using FOSS help? Take Linux desktop environments as an example. Devs avoid using it because it's hard to use or is sometimes buggy and annoying... well, guess what? THOSE are exactly the FOSS contribution opportunities that you should be aiming for.

Microsoft and Apple have highly polished outcomes by sheer force of billions of dollars invested in those products. If we want FOSS counterparts to reach that level of polish, we have to get more developers to use it first.

Anecdote

I have a very simple example of how using an unknown FOSS project led me to my first truly valuable FOSS contribution.

Long before I had a software job or even a CS degree, I was a mechanical engineer. My day job involved evaluating 100s to 1000s of technical drawings and specifications every month. This industry doesn't have sophisticated VCS tools that we have, so changes are logged somewhere, but there's no way to verify that those are indeed the only changes that took place... there's no diff.

We were burned multiple times before when technical drawings changed with no changelog, so I wanted a diff for drawings. After some searching, I stumbled upon diff-dwg. It allowed diffing PDFs and highlighting the changes. Using this tool, I could very clearly see the differences between the two versions. This is how it looks[2] :

Over time, I discovered a few bugs and missing features.

• This tool used to get stuck randomly on some prompt, which turned out to be a small fix in the Python script, so I sent a PR for it, and it got merged!
• I wanted to diff multi-page PDFs, and only single-page PDFs were supported. Supporting multi-page diffing required a bit more work that I had to do on my Linux machine... that made me add Linux support. It was just a few lines of changes to replace hardcoded Windows-style paths with OS agnostic interfaces.
• I also eventually added support for bulk diffing. All of my fairly real problems were solved, and I contributed something useful, albeit small, to upstream.

That was the end of my interaction with the project... it just worked and any further contribution from my side would be made-up work to add more greenery on GitHub heatmaps.

Those small contributions are likely my biggest FOSS contributions. I've made a few other small contributions, but all of them are to projects that I've actively used.

Where to go?

There's a saying at where I work: "There's 90% of work and then there's the remaining 90% of work that will take forever to complete". FOSS projects need help with that remaining 90% of work - polish, edge cases, onboarding, bugs that aren't even reported yet, issues that can't be reproduced easily, UX or compliance problems that only end users truly understand. All of these are far more valuable than "good first issues". While "good first issue" will get you onboarded on a project, it will take a lot more than that to truly add value to the project.

- I want to contribute to FOSS.
+ I want to add value to FOSS.

--

[0] My guess is that more than ~60% audience were college students.
[1] I know there are different takes on this when it comes to crime, but I've seen this apply to software firsthand. Badly written software invites more badly written software.
[2] The example is from a publicly available version of LIGO schematics.