[HN Gopher] "Critical" projects and volunteer maintainers
___________________________________________________________________
"Critical" projects and volunteer maintainers
Author : mooreds
Score : 54 points
Date : 2022-07-15 19:11 UTC (3 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| SoftTalker wrote:
| Volunteers abandon projects when the dam breaks. They work, and
| adapt, and take on more and more, and then one day one small new
| thing (that an outsider would see as totally reasonable) breaks
| the dam, all their motivation is washed away, and they quit.
|
| I've seen this happen much more often than I've seen volunteers
| gracefully leave a project with a smooth transition to a
| replacement person or persons.
|
| If you are using volunteer-maintained software in a "critical"
| part of your business, you should be prepared for this.
| vba616 wrote:
| Those who belong to a small volunteer-based, mostly offline
| organization, know how hard it is to keep people who will do
| essential administrative work for free.
|
| You can hold elections, people can have fancy titles, but
| frequently there's still only one person _if you 're lucky_ who
| will "run" for office. And so they can't be fired, and if/when
| they burn out and quit, the organization may crumble.
|
| When I think of the sort of person who is unreasonably
| demanding of an open source maintainer, I think of the sort of
| person who is on LinkedIn and has padded their resume/profile
| with various wholesome volunteer gigs.
|
| But this is a contradiction - because if the latter is true,
| they should be intuitively aware of the dynamic.
|
| Also, another expectation I would have is that anyone with more
| than a year or two of corporate experience would know that
| _even when people are being paid_ little attention is given to
| preparing for transitions, people quitting, people retiring,
| and so on.
|
| Clearly there are some significant false premises buried
| somewhere.
| yakak wrote:
| > even when people are being paid little attention is given
| to preparing for transitions, people quitting, people
| retiring, and so on.
|
| I was looking at some contract jobs that seemed to be
| examples of a manager outsourcing the problem of finding a
| replacement that will somehow take responsibility while
| probably no longer having any access to the skills to
| interview them.. So in corporations there's a kind of
| eventual consistency if the replacement is actually
| essential.
| pessimizer wrote:
| > You can hold elections, people can have fancy titles, but
| frequently there's still only one person if you're lucky who
| will "run" for office. And so they can't be fired, and
| if/when they burn out and quit, the organization may crumble.
|
| I think that in these cases you don't actually have an
| organization, you have an elaborate ritual to convince a
| single person to facilitate the activity that you wish to
| happen.
| EwanG wrote:
| I'd argue this is true for paid positions as well -
| particularly ones where work keeps getting dumped on one or two
| individuals to keep up the whole artifice while others move on.
| Eventually one or both of them have had enough, and then
| there's no one left who remembers why the spangle is always
| switched to the left on a daily basis...
| bhaak wrote:
| > Paul Moore noted that marking it as deprecated did not work,
| nor did ceasing releases in 2015; "I'm not at all sure 'tell
| people not to use it' is a viable strategy for getting marked as
| 'not critical'."
|
| Apparently you need to encode some dead man switch in your code
| if you want to stop supporting it.
|
| Like blowing up X years after the last release or deliberately
| not working on some future version of Python/Ruby/whatever. But
| OTOH these automatisms are more code and code that might go off
| when they shouldn't. They make code more brittle.
|
| Then somebody would need to actively step in and change the code
| to make it work again.
| cpeterso wrote:
| Even a dead man switch is not enough. jwz added a "WARNING:
| This version is very old! Please upgrade!" time bomb message to
| xscreensaver's about dialog and Debian removed the warning code
| instead of upgrading to the fixed version of xscreensaver.
| Google "I would like Debian to stop shipping XScreenSaver" for
| details.
| drexlspivey wrote:
| https://xkcd.com/2347/
| armchairhacker wrote:
| Maybe we should have security-interested folks develop their own
| versions of popular open-source software which can then be
| "critical", with formal methods. It's hard to audit or verify an
| existing codebase, it would likely be a lot easier to just start
| from scratch.
|
| It would give security and formal-methods people something to do
| kjellsbells wrote:
| Im not an OpenBSD insider, but this feels very much like what
| that team have reluctantly and yet repeatedly concluded that
| they need to do. LibreSSL and OpenNTPD and pf, for example.
|
| There's also the risk implicit in a stack with no single
| authority, which is a difference between a combined OS and
| runtime like the BSDs and the Linux distros. RH and Canonical
| do the lords work keeping up, but its never really going to be
| the same as the BSD people and their tight coupling.
|
| This probably makes me sound like a BSD bigot, which is not my
| intent, but it does seem to me that there is a cost to all this
| flexibility that Linux pays a high price for.
| jackson1442 wrote:
| I see no problem with mandating 2FA for all PyPi users,
| potentially offering free security keys to maintainers of
| Critical projects as an incentive to adopt even more secure
| practices.
| ctur wrote:
| It is interesting seeing the evolution of open source maintenance
| in the light of new (or increasing) supply chain attacks and acts
| of political protest. There always has been a "what is your
| obligation to quickly respond to a security issue?" expectation
| around the code and now similar obligatory expectation questions
| arise on the maintenance process itself.
|
| We also see what seems like rather balkanized approaches (npm,
| pypi, cargo, ...). It would be great if broader consensus arose
| on what the ideal standard should be for package management and
| distribution that then those projects could adhere to. Similar
| about commit access to repos and what the requirements there
| should be.
|
| It's also peculiar how much stronger the guarantees you get from
| your operating system vendor are w.r.t. signatures on packages vs
| what the underlying projects themselves have. OSs have had this
| pretty well handled for decades, but no common best practices
| like 2fa, signatures, etc seem to have emerged.
___________________________________________________________________
(page generated 2022-07-15 23:00 UTC)