Ramblings of a Tampa engineer
CSS code on a screen
Photo by Sai Kiran Anagani / Unsplash

Whether you know it or not - a huge chunk of technology runs from code bases that are developed in the complete open space. What I find fascinating is the dependency tree that results in more and more complex software - a business may depend on some piece of software that 1 individual has been supporting for a decade without a dime. XKCD has an excellent comic for this exact situation which helps drive home the point.

So lets break this into 3 buckets and dive in:

  • Companies helping Open Source projects
  • Individuals who interact and work with Open Source projects
  • Individuals who support or maintain an Open Source project

Companies helping Open Source

Lets start with Mozilla - a company that spawned from the open source and free software of popular programs like Firefox and Thunderbird. As they grew they realized it made sense to give back to the community they started from. They started a repository and started to give money to fund projects to resolve issues from tools they either use or feel as a company to monetarily support.

Sentry is a company in a similar boat that leverages a ton of open source software like every other company so they gave back as well. They had some cool napkin math where they estimated that each engineer gains approximately $2,000 of value from open source labor. So they simply donated $2000 times number of employees or $150,000.

I think this is something that should be normalized and just expected as part of companies worldwide. I understand it isn't easy though - giving money from a company to a collection of open source projects isn't the easiest. Sure, you could use GitHub sponsors, but then you are sponsoring a person instead of a project. If you sponsor a project - how can you assure the money will be used in good faith for the success of the project?

I just think that the entire success and purpose of some companies are built off the success of open source offerings. It should either be encouraged or allowed for either engineer support on open source projects or monetary contributions.

Individuals who interact with Open Source

Now I joke about GitHub a lot that there is no bug tracker, but only a support ticket system and that is no joke. If you interact with GitHub you'll either lead to the stress of the maintainers or not. I find that in its your best interest to follow whatever requirements exist when submitting a pull request or issue. Lets take an example.

An update to Fastlane was done, including all the plugins in order to add support for the changing App Store Connect. Running the build failed due to something I couldn't quite pinpoint.

[10:52:13]: error: true: IO error for operation on true: No such file or directory (os error 2)
getsentry/sentry-cli - issue 1002

It failed on a Sentry step, so presumably that was at fault. Before doing anything, I filed an issue report where I thought the issue was. Doing so because if a maintainer immediately can understand the details and save time, energy and money its worth it. At that point - it was time to dig into myself. I could not revert Fastlane, because the build was broken and required the new version.

However, I could revert the only plugin (sentry-fastlane-plugin) update from v1.8.3 back to v1.8.1. This resolved the issue so I could have stopped there, but did not.

Diffing the versions with a simple GitHub URL feature, I dug through a language I'm not entirely familiar with and noticed this just wraps the sentry-cli tool. One line in particular looked interesting as a parameter was updated to include a value, when it did not require one. I understood the issue, found the regression and put up a pull request to resolve. The fix was merged and the next release (v1.8.4) had the problem resolved. I closed my original issue and the entire ordeal was over.

This sounds like a lot, but probably amounted to less than an hour. So now future folks searching the web might land on the issue or the pull request and have their solution. I'd say this is the way that engineers should solve problems - documenting the issue, attempting to resolve said issue and following all requested criteria for the repository in question.

What you often see is the complete opposite. You'll see bug reports that are clearly support requests with the entire issue template destroyed. You'll see folks just spewing pure anger and refusing to help a project that is free. You'll see people that seem personally insulted from a maintainer asking someone to check x,y,z. It all leads to my next and final section about the point of view of an open source maintainer.

Individuals who maintain Open Source

Maintaining an open source project changes you - there is no doubt about it. I wrote about this in 2017 in a lot of detail. I do notice every so often that there are folks that I think are still really piecing together how to effectively run an open source project and others that should take a step back entirely. A few folks are just toxic in and out - I remember one maintainer from my early Minecraft programming days. Wrote some good stuff, but was never a fun interaction with this individual.

I've witnessed another individual and project basically pull the same thing that reminded me of the release of Python 3. I don't think anyone could argue that Python 3 wasn't better, but the breaking changes and upgrade path was pretty less than desired - the ecosystem was basically split between the versions. So in this different occurrence - A package I depended on would not support PHP8 on the existing version, instead pushing folks to an Alpha build of their next major release.

It would be unfair for me to say the package could have simply supported 8 on the existing - I don't know. I do know however, pushing folks to a new major version with no upgrade information, no documentation and still to this day (almost a year later) is still is not out of beta. I tried to help the project, I tried to submit fixes and reports, but it was a stressful situation. Things were closed because they weren't understood. Beta 24 may have included a fix I included, then Beta 26 broke it again.

I kept trying, but every project upgraded to PHP8 that used this dependency ran into new issues. I ended up abandoning the project for an alternative, I don't think this package handled a new language version correctly.

All in all, open source software is everywhere. I think companies and engineers themselves should put themselves in positions to help these projects. Not all circumstances will be easy, but the more of us that support any project will be for the good.

You’ve successfully subscribed to Connor Tumbleson
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.