Putty maintainer on his attitude towards security and open source
andrewducker.dreamwidth.org
andrewducker.dreamwidth.org
After spending hours looking for solutions that were purpose built for this kind of thing I gave up took PuTTYs source and made some tweaks to the UI.
The source was so easy to work with and I was so grateful that the license allowed me to do this.
The custom client only ran for a couple of years because the web replaced green screens. And being a *nix guy I don’t get much need for PuTTY in my day to day. But I’ll always be grateful for PuTTY for making that particular job possible (and secure).
ssh [letter][tab] gets me a list with my Zsh config. I looked briefly one time and couldn't find what I was looking for.
I have a fairly large SSH config file, and needing to open it to copy and paste hostnames from the file is the main reason I just use WSL.
I recently switched from about 20 years of Putty use (some years more than others, I ran Linux on the desktop for a long time) to Windows Terminal and the windows included openssh. There are pros and cons. The new windows terminal is very nice but there's still a few annoyances. Having an actual ssh config and almost all the capabilities (no ControlMaster/ControlPath because no files as sockets) is very nice.
I probably would have been fine staying with Putty though if pageant hadn't started having reliable (but weird) problems when handling more than a few auths from remote in a short period, making Ansible unusable when running from my work VM with agent forwarding.
https://docs.microsoft.com/en-us/windows/terminal/tutorials/...
Some screenshots to get the idea of its ui: https://www.google.com/search?q=winsshterm&tbm=isch
There was some sort of v4 -> v5 open-source -> commercial switch.
Commercial version: http://www.poderosa-terminal.com/
OSS version homepage: http://poderosa.sourceforge.net/
Source (last change in 2019): https://github.com/poderosaproject/poderosa
Releases (last release also 2019): https://sourceforge.net/projects/poderosa/files/releases/4.4... (also on GitHub too, switch to the "tags" tab)
Seems to be .NET based, and relatively simple in terms of available functionality and featureset.
It actually works on unix, which is usually uninteresting but I used it once when I needed a serial console client and wanted a friendly GUI. So it can* be useful:)
The main point being that, with the log4j issue (and others before that), the thing that's struck me when maintainers complain about not being appreciated or that they are working as hard as they can, unpaid, is that maintainers are under no obligation to respond at all, and that you can't control how other people will react.
As someone who's dealt with anxiety for a long time (and as a former opensource primary maintainer), I can most definitely commiserate with feeling burdened by the expectations of others, but one of the best things I learned from therapy is that you can't control others emotions, you can only attempt to understand why you react as you do in certain situations.
One of my takeaways from the log4j issue is that the log4j devs should have never accepted the patches to add LDAP urls in the first place. Or perhaps, they should have removed that feature when it became burdensome. I would have. There’s a pressure to accept whatever patches come your way as an opensource developer, but actually, you’re under no obligation to do any such thing. Open source also means the source is available - so people are free to take your code, mix in their patches and maintain it themselves. And if they can’t be bothered doing that, why should I shoulder that burden?
I think us opensource devs should get more comfortable saying no. “I hear that this feature is important to you but it doesn’t solve a problem I (or anyone else I know) cares about. Please maintain those patches in your own fork.”
- you can't rearchitecture your software beyond a certain amount without breaking the plugin API
- if a plugin crashes, people will blame the host, no matter how you attempt to deflect this
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.
(Note: If your answer is "well, send them an invoice", the problem is that you'll probably have to contact a lawyer to make sure that the invoice is legal. You don't want to fraudulently imply a preexisting contract or run into some other legal gotcha that you wouldn't even know about.)
I favor a response along the lines of "that falls outside the scope of our current maintainer-user relationship, but I'd be happy to discuss a development and support contract that would cover that effort for $X USD".
Be perfectly forthright to cover your costs, including costs of attorney, tax preparer, bookkeeper, first line support (don't forget whether support is best effort or follow the sun, or something in-between), forex conversion rates, money transfer conversion rates, and so on. Do not cave to threats ("I'll tell everyone I know your software sucks", "I'll post everywhere you are a terrible coder!") or inducements ("I have a million YouTube subscribers, I'll plug you!", "I'll make sure you are credited in our awesome game credits scroll!"). Do be nice and professional.
Learn how to say in the nicest, most professional way, "Fuck you. Pay me." [1]
To give yourself a sense of scale, proven coders with a consistent track record of delivering when they say they will, to within an order of magnitude of original delivery (to account for a hobby open source project), for an established codebase that is relied upon by the user in production and would cost them >$300K USD in fully-burdened cost across five years to rip and replace, can justifiably charge $40K USD for an enhancement that takes them a week to code up (including documenting it on both developer and user end) and a week to validate with the client. And I'm sure there are others here who can whip up an IRR spreadsheet to tell me that's charging on the low-end.
Add another $12K to support just that feature for a year after passing validation and open-sourcing it right away. Charge something on the order of $100K per year to support if if they want to own the source patch instead of it open-sourcing but still want you to maintain it; maintaining separate forks doesn't come cheap to commercial customers, the code being open source means no different. Charge for taking back in the source patch later if they want to make it private, want to stop paying support after the first year, then change their minds later. Charge for delaying open-sourcing it. Charge for changes that will take you longer than 15 minutes (including every associated task like documenting and validating) to throw in, charge for more than four of those kinds of changes. Doing anything different than just developing and open-sourcing the new feature costs you time; estimate that time, pad it for mistakes, and quote a fee. Enterprise software generally won't even begin a discussion of a forked change private to a specific client, and conversations of a feature developed for a specific customer will only start at around $1M USD, feature made available when it is finished, and the vendor owns the code.
Don't shortchange yourselves if you really know how to code, code for a specific problem domain and communicate with users in that domain in their lingo, gather requirements, set validation criteria, support technical customers, and can put up with the hassles of running a side business. You lose nothing by "firing" these customers who demand freebies with no compensation, except the Asshole Aggravation Factor in your life. Your IRL is filled to the brim with assholes. There is no need to let your open source hobby get filled with it, too.
I feel the Open Source community would be well-served by a standard boilerplate that comes right alongside the source license for charging fees for services, to set expectations that any participation by maintainers is a precious, unexpected gift at their sole discretion and whimsy. All other interaction first paid by cash.
[1] For those unfamiliar with US/Western pop culture, see https://www.urbandictionary.com/define.php?term=fuck%20you%2...
So I own a postcard that says words to the effect, “nobody has ever asked me for an autograph before”. It is framed.
> I'm often amused that people compliment me on things like PuTTY by telling me how much of their time it saved, whereas people compliment me on my puzzle game collection by telling me how much of their time it wasted.
Nowhere there does he claim authorship, merely possession of a collection. Without knowledge of his webpage or the games, there is more than 1 logical conclusion.
My current timewaster is 'patterns',a nonogram puzzle
I assume that the interest in games and the hostname of his webserver are very much related.
If you can think of a non-card solitaire game, it's probably implemented.
Here they are playable online on Tatham's site: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
And here's the Android version: https://f-droid.org/en/packages/name.boyle.chris.sgtpuzzles/
'unruly' and 'signposts' are neat little timewasters, but devolve into a lot of counting at larger sizes..
'flip' with random shapes is a great fidget-style toy
'galaxies' at 'unreasonable difficulty' gets pretty crazy
and plenty more, eg 'solo' provides every version of sudoku that you might want
Boy if that doesn't ring true. Kudos to PuTTY's author for making it so easy and low cost to do the right thing that those profit-seeking automatons we call "companies" actually will.
0. Those who release their code under an open source license, in the hope that it will be useful to others in some way.
1. Those who do the same as above, with the additional hope that they will be paid for in some ill-defined way. And when they are not, take to twitter and blogs to proclaim, "somebody should really do something about this!"
But that's almost orthogonal to the issue of whether the original developer should be paid because their code turns out to be useful to lots of people.
I think a better approach is to encourage more smart developers contributing time. And if companies find an individual or a percent of a person’s time on a project that’s actually funding. But it’s very different from trying to replicate direct funds.
Not sure that's a solid affirmation, especially given how there are many open source projects receiving funding that often outcompete their commercial counterparts. In particular I would point out the major open source backing foundations such as the CNCF and Linux Foundation who help to fund their own projects. Would you say that these two organizations and their projects are not serving their purpose or are being outcompeted by commercial offerings?
Plenty of commercial code is barely looked after, and if it's closed and broken, it's a lot harder to fix.
There seems to be a hesitance to fork abandoned or slow moving software to update/fix issues
When we release code under a free software license, we are giving the software to the user, entirely. If you're using software that you own, not just merely have a license to, it is yours, be prepared to maintain it, and if you're not prepared to maintain it, maybe relying on free-as-in-freedom software is a bad decision for you.
ie good, but comes with responsibility
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.
"There seems to be a hesitance to fork abandoned or slow moving software to update/fix issues "
And it is often easier to reimplement something from scratch, than taking up some underdocumented mess and trying to make sense of it.
So I would rephrase that to
" using OSS means we can own and maintain the software whether the original community/author does or not."
If each individual licensee is itching their own scratches, then there's a really good chance the entire codebase gets love.
Absolutist approaches are the death of all good things. "Some" is better than "none."
Agreed. Hence "can" and not "must".
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.
Yeah, that is why I rephrased it, to with OSS you can own and maintain your full stack.
Op said "must".
Sure I didn't have to but isn't that the point of open source?
People (sysadmins) have been doing this for years--it's nothing new. Software doesn't break that often. You generally start with wherever you're hitting the bug. Maintaining, running, and operating software is significantly different than writing from scratch (and generally less labor intensive)
What do you do when you hit a bug in production caused by some OSS? Throw your hands up and tell management you opened an issue on the issue tracker?
So many folks come in with a chip on their shoulder, missing the forest for the trees. If every developer modeled themselves after Tatham's attitude, we probably wouldn't be having most of these conversations around open source right now. And issue trackers might be a more peaceful place.
edit: fixed the author!
The conversations can get a little geeky. :-)
"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. Most of those companies who mistake me for a contracted vendor are prepared to recognise their mistake once I point it out, and the more self-aware ones even apologise. I've not even found it necessary to be especially rude: a plain statement of the facts of life normally does the job. If one of them is rude to me, then the quintessentially British approach of a faint frown and a tone of mild reproof (or its email analogue) generally gets good results – probably a lot better than mouthing off like a sweary 13-year-old in return."
It is easier if you are a native English speaker, because you have a wide range of expressions at your disposal to express disdain or irritation without going nuclear.
It is also easier if you are the single author and not fighting with others in the same code base.
So I don't think easy in general to react maturely, especially if you have made large contributions to a shared code base and some pushy person comes along and makes demands (sometimes the impolite person is another contributor, which makes things worse).
EDIT: Perhaps you meant that the person making requests should not be a jerk, in which case of course I fully agree.
This! I - non-native myself - worked with fellows who learned English late in life and sadly to some share from the wrong sources (action movies and rap music, I'm afraid). Naturally, at times they appeared quite immature. Otoh, I had the good fortune to work with some British fellows, which, at times, was quite educational.
That is a very wise comment.
A colleague said "I love it, and hate myself for loving it".
The new "async/await" features appearing in numerous languages encode this pattern -- i.e., result in substantially the same object code -- in a more robust way, but Putty works fine.
https://noncombatant.org/2014/03/03/downloading-software-saf...
Link and text from the Putty FAQ below.
https://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#...
A.9.2 Would you like me to register you a nicer domain name?
No, thank you. Even if you can find one (most of them seem to have been registered already, by people who didn't ask whether we actually wanted it before they applied), we're happy with the PuTTY web site being exactly where it is. It's not hard to find (just type ‘putty’ into google.com and we're the first link returned), and we don't believe the administrative hassle of moving the site would be worth the benefit.
In addition, if we did want a custom domain name, we would want to run it ourselves, so we knew for certain that it would continue to point where we wanted it, and wouldn't suddenly change or do strange things. Having it registered for us by a third party who we don't even know is not the best way to achieve this.
It was like 20 years ago. Even then it was obvious that they don't want any fancy domains, just that the work is done and putty.exe delivered where it's needed.
People forget one simple fact - WHEN YOU ARE PAYED, U ARE NO LONGER FREE.
There is no substitute for passion work, where YOU are the man, and there is 0 chance somebody will influence you.
> In fact, the most recent commercial fork caused us to get a worried email or two – the company's publicity made at least some users worry that the PuTTY team might have been subjected to one of those "buyout and radical change of project direction" scenarios I mention above, and they weren't happy about the idea. [Emphases added -- CRC]
So there is a "team" besides mr Tatham. That's good to hear; I always thought it was just he himself.
> a labour of love becomes a chore if you can't temporarily put it down when you're running low on love. - simon.t
I love this.
[0] Same pub as frequented by the guy who proved Magic The Gathering is Turing complete, because Cambridge is tiny.
I only use it privately now because our work doesn't allow it anymore since openssh was included with Windows. But I still prefer it.
> 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.
However, what would happen if that were not so?
What would happen if he Could not, Would not, or were Unable to work?
It would all fall apart. And that is the inherent fragility in these small critical opensource projects.