2 ms·

In the mid 2000s, the wireless network infrastructure at my university authenticated your device based on SSH'ing into a server. But the specific SSH server use

In the mid 2000s, the wireless network infrastructure at my university authenticated your device based on SSH'ing into a server. But the specific SSH server used at that time did not support password-less logins via keys, so it required typing in a password every time you connected (and WiFi was flakey in that environment in those days, so dropped connections weren't uncommon). I asked the IT support folks about this, and they told me that I should try adding it to the software. I figured out what it would take and wrote some patches, but then they said they couldn't run something customized like that. Years on their reasoning makes sense, but at the time it was really disappointing and I dropped the effort after that.

ggm 4y ago
I think this happens far more often than people realise. Part of the problem is ownership: It's so easy to become proprietorial about code. But another part is that people ideate solutions very differently and "style" is big in code. The gap between XEmacs and Emacs is noted in the xemacs website in all it's painful glory. It's got politics, it's got lawyers, but it's also got code style and complexity. I did a package for homebrew via git and PR, and the CI cost to make it "fit" their expectations was a multi-day iterative nightmare. I can see how it would be a barrier to entry for a lot of people. The other side, I have managed to get one-line fixes into the hands of competent coders. There are times they will simply accept it, apply it, and move on. Early in my career (1984) I accepted community patches for a body of code I was employed to maintain and imperilled it's IPR. It was a big deal at the time. I didn't think patches to C being used by the community was going to wind up there. I was pretty sure the patch submitters didn't mean to go there either (by stealth I mean, they would have been delighted if the entire body of code was in the public domain) -This was when we swapped code by 1200bpi tape reels in the post. I think "too risky to accept community patches" is an excuse rather than a real reason. They just didn't want the paperwork and hassle to adopt the code. But the negative effect I can totally believe. I would have been very de-motivated by this.

ggm 4y ago

I think this happens far more often than people realise. Part of the problem is ownership: It's so easy to become proprietorial about code. But another part is that people ideate solutions very differently and "style" is big in code. The gap between XEmacs and Emacs is noted in the xemacs website in all it's painful glory. It's got politics, it's got lawyers, but it's also got code style and complexity. I did a package for homebrew via git and PR, and the CI cost to make it "fit" their expectations was a multi-day iterative nightmare. I can see how it would be a barrier to entry for a lot of people. The other side, I have managed to get one-line fixes into the hands of competent coders. There are times they will simply accept it, apply it, and move on. Early in my career (1984) I accepted community patches for a body of code I was employed to maintain and imperilled it's IPR. It was a big deal at the time. I didn't think patches to C being used by the community was going to wind up there. I was pretty sure the patch submitters didn't mean to go there either (by stealth I mean, they would have been delighted if the entire body of code was in the public domain) -This was when we swapped code by 1200bpi tape reels in the post. I think "too risky to accept community patches" is an excuse rather than a real reason. They just didn't want the paperwork and hassle to adopt the code. But the negative effect I can totally believe. I would have been very de-motivated by this.