Putty maintainer on his attitude towards security and open source

The best way to respond would be to pretend there was a contract, and that the company was in arrears on its payment obligations. "I cannot act on any changes until you remit past-due payments."

That sends them on a wild goose chase for their copy of the contract, because they cannot admit they don't have it. Eventually they run into the person who tells them there is no contract, there are no delinquent payments, and there is no excuse for pestering the author.

It's in a postscript attached to a sentenced about how giving away software is what helps him sleep at night. I'm not sure how you can reach any other logical conclusion without throwing out data from the article in favor of completely off-topic items.

>No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there.

Seems a little disingenuous to assume that GP meant that everyone should fully maintain their own OSS stack, when their comment could be read far more reasonably as a solution for when those processes aren't serving your needs entirely.

I once wrote a tool in C# that used Putty behind the scenes to connect to routers (and hop through them) and collect interface metrics. Back in 2009 :)

What I got from this was a tiny wake-up call to realize/remember/not lose sight of: the OSS relationship is the one scalable model we've yet found that lets the problem being solved remain the focal point of the effort, deliberately at the cost of everything else:

> Often I feel as if some particular correspondent of mine has simply forgotten that I'm not a paid software vendor who has a multi-million-dollar contract with their employer, and hasn't quite figured out that as a consequence I have no incentive to drop everything and solve their particular problem. [...]

> But I've always been able to deal with this by pointedly reminding the most demanding people that I'm not at their beck and call. [...]

> And if someone keeps pestering in spite of every clue you try to impart, well, there's always the 'just stop replying' option. [...]

> When it comes to companies depending on my stuff, I take the same no-nonsense attitude, because in every free software licence agreement (even the maximally permissive MIT, my usual choice) is that all-important "NO WARRANTY" clause, and it's there for exactly this reason, and I'm happy to push back if people try to ignore that.

We're so sensitive to that inversion effect that can happen when some core technical fascination loses ground to the humdrum of always turning up somewhere 5 days a week, rain, hail or shine... always be checking the bugtracker, always be working on the next feature or component, always be maintaining everything and keeping it together. The regularity and predictability of that continuous process can be reassuring... as long as it remains fundamentally interesting. But as soon as the interestingness fades, everything suddenly feels like a scary monster from a nightmare you can't shake off. It seems to be a ratified status quo that everyone is just expected to deal with this.

While the description doesn't quite relate to the remunerative relationship of the workplace, I generally describe the above as "club mentality": people start out by gathering together, drawn together by the focus of some shared interest; then after some time the focus switches to "we should definitely get together every fortnight", then on some fortnights noone knows what to talk about... aaand before anyone realises it, the incentivization structure that previously drove everyone to bring their best to the table is gone.

Sometimes the meeting-every-fortnight bit happens to further the shared interest - making the process of identifying the switchpoint even harder.

But it's always there - there's a point at which everyone kinda gets less interested, but feels compelled to continue the meetings. These turn out to be filled not with awkward pauses; there's somehow always still something to do, something to go on with. But anyone fresh would take one look at the situation and immediately call it busywork - it's not furthering the bigger picture, it's just playing Dodgem cars within the sandbox that's been carved out. The kinetic aspect of that makes it easy to believe that impact is being made, provided you don't look too closely at the bigger picture.

The correct but fiendishly difficult response is of course to never lose sight of the bigger picture, and for everyone to be honest with each other about when they've lost interest.

Sometimes that's easy, like when a "band" gets together only for everyone to collectively realize music isn't all that fascinating after a couple months. Disappointing retrospective memory? Doesn't matter, the alternative would have been much more depressing.

It's sad that the difficulty and complexity of writing software means you pretty much have to live through a multi-month or -year period of hum-drum boringness before getting to a reasonable closure point. The only workaround I've yet found is to frequently switch roles, which doesn't really provide closure unless the roles are extremely small-scale, and always tends to be very abrupt in any case.

If you can make it work financially, OSS does indeed provide the most viable scalable solution for this whole problem. Heh. At all costs.