104 lines
5.4 KiB
Markdown
104 lines
5.4 KiB
Markdown
---
|
|
title: "Drive By Contributions to Open Source Software"
|
|
date: 2020-10-11T13:58:00+01:00
|
|
draft: false
|
|
---
|
|
# Intro
|
|
A few weeks ago an Microsoft employee made some statments that relying on email
|
|
is [a barrier to entry](https://www.theregister.com/2020/08/25/linux_kernel_email/)
|
|
to develop on the linux kernel. A lot of people didn't like that comment -- for
|
|
whatever stupid reasons (microsoft? female? really liking email?)
|
|
|
|
There have been arguments in either side. I personally liked [this](https://www.labbott.name/blog/2020/09/01/emailgateway.html)
|
|
and [this](https://lobste.rs/s/0jt525/relying_on_plain_text_email_is_barrier#c_bv3txg]) one best.
|
|
|
|
But I assume that most open source contributitor do not want to be long term,
|
|
core members of that project. They are first and foremost users who happend
|
|
to stumble upon a problem and just want to fix it. They want to a) fix that
|
|
problem and right now (for themselves) and continue working on their actual
|
|
work and b) save others from running into the same problem again.
|
|
|
|
They are drive-by contributers, who _need_ an easy, common way to submit their
|
|
issues and patches.
|
|
|
|
# My contributions to other software
|
|
|
|
1. I was annoyed by thunderbird being slow to filter many mails[0] so I switched
|
|
to another email client. It wasn't very stable but it was fast. It had a bug when
|
|
replying to mails from an famous, not to be named, email client starting with "ou"
|
|
and ending with "ook". I filed the bug but because I wasn't familiar with the
|
|
language the mail client was written in I didn't send in a patch myself. but it
|
|
got fixed anyhow and all was well.
|
|
|
|
2. To help people write code for embedded systems I was supposed make the emulator
|
|
easier to grasp. That meant adding an GUI where you could see the blinkenlights.
|
|
And because it was meant for university students it had to run on what people
|
|
actually use -- windows. (If only this story had took place in 2021, the year
|
|
of linux on the desktop). The emulator was almost cross platform -- there was only
|
|
one linux specific path left. I filed an issue, sent in the patch. It was merged
|
|
and all was well.
|
|
|
|
3. In another instance I had a bug where some customers could not be allow-listed
|
|
in a popular CMS. Turns out that allowlist checked IPv6 addresses case
|
|
sensitive. I filed a bug, sent in a patch. It got merged and all was well.
|
|
|
|
4. My earliest contribution to open source was in an TLS library which only connected
|
|
to the first IP of an domain. I sent in a patch request, it wasn't up to the
|
|
coding standart. I didn't care much, since I had my local fork. Some time later
|
|
that code in the library was rewritten anyway and all was well.
|
|
|
|
5. An freelancer did large portions for $PRODUCT in my company. His code wrapping
|
|
the Zend/Laminas Framework had an error where for plaintext only mails it still
|
|
sent multipart/alternative which meant that no mail client could show the content.
|
|
I sent in the patch, it got fixed and all was splendid.
|
|
|
|
In none of these cases did/do I intent to become a maintainer. I wouldn't rule it
|
|
out to become a maintainer[1] but all these projects are just building blocks used for
|
|
whatever my actual job at that time is.
|
|
|
|
# How DID I submit patches to these projects?
|
|
|
|
Now what where the barriers of entry to each and every single one of these projects?
|
|
It would be ludicrious to try and see anything meaningful for all (FOSS) projects
|
|
in the world from such a small sample size, so I am only going to give my very
|
|
subjective view.
|
|
|
|
In all but two cases the whole communication happend on github (I will talk about
|
|
github in a minute). One was the freelancer where I could do anything from writing
|
|
an email, filing an issue on gitlab to just driving over to his house. The other
|
|
one was a "proper" email based workflow.
|
|
|
|
Many people have already stated what they think the barriers to entry are for
|
|
sending patches over mail, there is no need to rehash them. Let me just say that
|
|
for some misguided non-sexual fascination with masochism I wanted to learn mutt
|
|
at that time and still found it hard to send in the patches. I actually practiced
|
|
sending them to another account of mine first. And all that only after *finding*
|
|
in outdated wiki pages where the mailing list is in the first place.
|
|
|
|
For the rest I have used github (and similar). Github has by no means a perfect
|
|
UX. But things like issue templates, a interface which I am accustomed from the
|
|
last one thousand, three houndred and forty seven projects I checked out do help
|
|
people to submit a ok-ish issue easily.
|
|
|
|
# Conclusion
|
|
|
|
I think the discussion about Sarah Novotny's plea/suggestion to move away from
|
|
an email only way of submitting issues & patches missed the point that most
|
|
projects have a long tail of single-issue contributers. I personally am one of
|
|
these drive by contributors.
|
|
|
|
Personally I don't think that everyone should migrate over to Microsoft owned,
|
|
working with ICE github. Such an huge concentraion of basically all software on
|
|
one single platform is never good. HOWEVER even with all those flaws it would
|
|
solve the issue at hand: removing barriers to entry for first time contributors
|
|
to open source
|
|
|
|
|
|
# Footnotes
|
|
[0] think an outage causing a couple hundred mails to be sent out during the
|
|
night. Then as I walk into the office, hearing about the outage and opening up
|
|
Thunderbird having it freeze for multiple seconds as it sorts these mails into
|
|
the "cron & other junk folder". Seconds which make me very nervous as I can't
|
|
start to figure out the actual incident.
|
|
[1] well I shouldn't be let near the TLS Library
|