diff --git a/content/posts/drive-by-contributions.md b/content/posts/drive-by-contributions.md
new file mode 100644
index 0000000..6c689fc
--- /dev/null
+++ b/content/posts/drive-by-contributions.md
@@ -0,0 +1,103 @@
+---
+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