I saw it happen to me. At work I wrote some libraries, which would be seen by just a couple of coworkers, and I thought I worked hard on them. Years later I wrote a small JavaScript function to put on Github, and I just couldn't leave it alone, cleaning it up, tweaking it here and there, knowing that smart people from all around the world might see it and judge me by it.
I have an open source project that got quite popular lately, and I can tell you that I just spent 100+ hours to add 2 lines of "code." No, they were not code, they are two lines of configuration to make a piece of hardware work. 100+ hours. Two episodes of headaches. Two new pieces of hardware purchased out of pocket. Two weeks of waiting. From kernel driver code, dkms to ALSA. Pages and pages of manuals. Asked for help on tons of places from forums, reddit, github, emailed, only a few suggested what I already knew. No one knows the answer. Two lines made it work, and I had to figure it out on my own.
That's the level of optimization that I have been doing with a project that has only hundreds of users but are building momentum for something I believe in. I know people will need it, use it, and enjoy it, and it teaches me things.
I certainly wouldn't have done so if I knew it only affects one or two users.
It makes a Pi an Android Auto head unit. Google expects the head unit to have a microphone to support voice input. Although technically the phone can use its microphones, but we can't expect Google to help us lifting that (artificial) limitation. It's a RE'd protocol and app. What will we say to them? We made this Frankenstein totally-unauthorized reverse-engineered distro that sorts of encouraging people to DIY their car hardware so they can use Android Auto and it totally won't cause you troubles if anything happens to the users. Please help us by allowing the phone to take microphone input for OK Google on Android Auto?
So, in short, we need a microphone for the head unit. The Pi doesn't have built-in support for microphones. So I wanted to support the Adafruit MEMS mic which is a very simple and cheap mic that works on the I2S bus. Otherwise, we would have to buy a USB microphone/an expensive DAC and waste another USB port to achieve the "OK Google" functionality.
Using the USB mic/dac means we can't realistically use a Raspberry A+ and Zero either, because we have to use the only available port for the phone connection, not the mic. That I2S mic is $6, the BOm is perhaps $2 and thus can be easily integrated into other boards.
The problem: Low volume. It needs something called the ALSA softvol which boosts the volume level for it to work. But I couldn't figure out how to implement a volume boost for the mic. I have documented the behavior here: https://github.com/htruong/snd-i2s_rpi. Adafruit's solution to boost the volume for ALSA programs: https://learn.adafruit.com/adafruit-i2s-mems-microphone-brea.... Too bad it doesn't work with applications that expect the microphone to work out of the box, and anything that uses pulseaudio doesn't work either. Without a configuration that works out of the box for Pulse, we can't say we support that configuration. We can't design a cheap hardware that will have the mic integrated.
I have tried to look at the kernel module code and see what I could do. I have looked at a number of other sound cards to see how they implemented it to fix it from the source -- and still got stuck. Along the way, I made the module DKMS-compatible, planning to push the code upstream to the RPi kernel. I have bought additional DACs to see if I could learn anything from them, and see if is there any way I could come up with a simpler/cheaper DAC hardware. I have asked for help. I have emailed people to see if anyone knows the answer.
I tried fixing ALSA.conf for like 10 hours to make it take the "boosted microphone" as the default mic. It sort-of worked for ALSA programs, but it broke Pulse. Which means I got back to square 0.
Turns out I can neither easily fix the hardware nor the kernel driver nor ALSA.conf. It's just Pulseaudio that needs two lines of code for it to use the mic with boosted volume.
Looking back, fixing Pulse seems like the obvious solution to take, but somehow it didn't seem that way to me when I faced it. For me, to discover every single paragraph I wrote above, it took me at least 5-10 hours each. The hindsight is 20/20, and you can say someone who knows Pulse would know that's the obvious answer. But I didn't know Pulse - I needed to learn linux driver, i2s, rpi, alsa, kernel, pulse all at the same time to come up with that answer.
If I ever get to 1000 people on this planet to adopt my software, then I think that'd be somewhat worthy. I'd argue that I will save each of them at least $4 compared to buying a USB DAC+mic, so that's $4000 saved. Which gets me to $40/hour rate... :)
Yes, but for different reasons. If I write a small tool for myself, I'm willing to live with some idiosyncrasies. But if I'm Going to release it to the siteId, then I need to fix those issues. It is the 80-20 rule. I'm willing to do the 80% for myself, but a release takes the other 20%.
I don't think this has anything to do with open source. Just whether you will release the product to the world.
I've noticed the same. Code for me - if there's a weird bug but there is a workaround, I'll probably just use the workaround. Code that others _might_ use - I'll fix the bug, and often end up with better (structured) code as a result.
I write better open source code because I take as much time as I like to feel satisfied with the result, which isn't an option in a proprietary corporate setting.
Although having an audience also motivates me to keep my standards high for what I'm satisfied with.
Definitely. I spent a while in a context where we did pair programming (with frequent pair rotation) and continuous delivery, so that every commit went live if the tests passed.
I loved both of these. The pairing and collective code ownership helped me keep things in good shape even when tired. Any mess I made wasn't something I could clean up when I got to it; it would quickly become everybody's problem.
The continuous delivery did the same thing on a product level. It eliminated the mystical time of "before release" where in theory something might get fixed. If we committed code, users would see it.
With exception of few large projects, you can be fairly sure no one will look at your code. And in a work, people you do know are pretty much guaranteed to look at your code, one way or the other.
It probably does, but to my understanding it’s a QA effect. If you know your work will be reviewed by an “audience” you are likely to deliver better results.
