|
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103 |
- ---
- 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
|