Conill: The long-term consequences of maintainers’ actions [LWN.net]

Conill: The long-term consequences of maintainers’ actions

Posted Sep 17, 2021 17:09 UTC (Fri) by LawnGnome (subscriber, #84178)
In reply to: Conill: The long-term consequences of maintainers’ actions by smurf
Parent article: Conill: The long-term consequences of maintainers’ actions

My experience of working adjacent to OSS projects in companies is that it's almost impossible to get resources for this kind of work in advance.

A good tech lead can advocate all they want for "$X is going to have a release in six months, and it's going to break things, and we need to start working on it now", but even well-meaning PMs hear "in six months" and decide that they can slip in a couple of other projects first because they're "high priority for customer $Y". $Y pays a lot of money. (Or, worse, promises they eventually will.) Then one of those projects slips.

After that, said tech lead gets to sit in a meeting with a couple of layers of management and be asked why they weren't ready for $X 2.0, and they have to try to not use too many creative swear words. All while the silent part of their user base suffers.

to post comments

Conill: The long-term consequences of maintainers’ actions

Posted Sep 17, 2021 18:40 UTC (Fri) by walex (guest, #69836) [Link] (2 responses)

«even well-meaning PMs hear "in six months" and decide that they can slip in a couple of other projects first [...] After that, said tech lead gets to sit in a meeting with a couple of layers of management and be asked why they weren't ready for $X 2.0»

What this means is that project managers are not accountable for deciding to ignore platform changes because they are expensive, so in an ideal world there should be no platform changes. Not exactly a news problem in organizations that turn insufficient depreciation into a "profit" stream, and there are so many in a decadent economy. The same happens on a wider scale with missing road and bridge maintenance, unwillingness to increase capacity with load etc. etc. etc.

Conill: The long-term consequences of maintainers’ actions

Posted Sep 17, 2021 19:18 UTC (Fri) by Vipketsh (guest, #134480) [Link] (1 responses)

Your analogy is very wrong.

It's more like all roads and bridges were in private hands and then law makers would, on a yearly basis, change the standards for them essentially requiring a full rebuild each and every year. Don't do it and your bridge or road gets shutdown.

While I know full well how clueless and idiots managers can be, I also can't really fault them in their thinking. When you see that every few years the team needs to spend months tweaking existing working things while making no explicit bug fixes or improvements, and the result is more buggy than before, there is real value in asking oneself if the work is really needed now or perhaps it would make sense to do the tweaks next time the dependency decides to reinvent itself. You can sell "the dependency was young, it had issues we spent a bunch of time working around, but now with the new version things will be better going forward" only so often. It becomes increasingly difficult when the dependency is 25+ years old and it's the third or fourth such situation (I'm looking at you GUI libraries).

In this case distributions are in the same position as managers and I can full well see their point.

Conill: The long-term consequences of maintainers’ actions

Posted Sep 18, 2021 17:16 UTC (Sat) by jwarnica (subscriber, #27492) [Link]

Understanding the implications of reality, and of a software life cycle, is a management responsibility though.

Begging the whiners, of course, if a developer in abused for pointing out this week's problem then it's time for them to find a new manager.

There are reasons to take on responsibility for all dependencies (safety critical systems), but they are few and far between. Software is dependent on its build tools, dependent on its platform, each on another platform, OS, hardware. It is expedient to use those systems that exist; management must understand that.

Developers should be honest up front about the expected or contracted lifecycle, and management must accept that risk.

"It's time to do the upgrade" should be met with healthy doubt, but not abuse. And once stated, its managements problem to schedule time.