[conspire] Why some computers don't get updated.

[Rick Moen]

Quoting Paul Zander (paulz at ieee.org):

> At CABAL, as usual, we talked about many things.  Only later did my
> mind connect dots between two seemingly unrelated topics.   The second
> topic was about people not updating their software.  For sure, some
> people have unlicensed copies and can’t access updates.  And others
> find it bothersome.    But there are also people who don’t want
> upgrades because upgrades sometimes break things.

Sure.  For the benefit of people who weren't there, on the CABAL Jitsi
Meet conference, I was talking about how it's not a good idea to run
obsolete, long-unmaintained releases of public-facing software such as
full-featured Web browsers -- which then lead me to a realisation I'd
had:  A key reason why Microsoft Windows is associated with so many
security meltdowns is software piracy:  People run old MS-Windows
versions and instances without update support because they don't want to
pay (which category includes newer, beefier hardware required to support
current OS releases).  It's a great deal easier to keep an open-source
OS under security maintenance as long as enough maintainers care to do
the work: The perverse incentive to take crazy risks just to avoid
paying money is much less present.

> Suppose a business had developed some important internal software that
> was based on XUL.  Then Mozilla decides to end support for XUL. 
>  After a seemingly innocent upgrade to Firefox this software has
> stopped working and the company has to scramble.  

Yes.  In fairness to Mozilla Corporation, they _did_ give quite a bit of
advance notice that XUL/XPCOM/XBL were being phased out.

I meant to post (when I covered this matter about a week ago) some of
the technical reasons that drove Mozilla to EoL the XUL
(https://en.wikipedia.org/wiki/XUL), XPCOM
(https://en.wikipedia.org/wiki/XPCOM), and XBL
(https://en.wikipedia.org/wiki/XBL) APIs.  Unfortunately, I don't have
that handy and have only a hazy recollection.  Here's a pretty clear take,
from 2015 when Mozilla first moved towards that decision:
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

  XPCOM and XUL are two of the most fundamental technologies to Firefox.
  The ability to write much of the browser in JavaScript has been a huge
  advantage for Mozilla. It also makes Firefox far more customizable than
  other browsers. However, the add-on model that arose naturally from
  these technologies is extremely permissive. Add-ons have complete access
  to Firefox’s internal implementation. This lack of modularity leads to
  many problems.

  A permissive add-on model means that we have limited flexibility in
  changing the foundations of Firefox. The add-on breakage caused by
  Electrolysis is an important example of this problem. Technologies like
  CPOWs help us to work around add-on problems; however, CPOWs have been a
  huge investment in effort and they are still slow and somewhat
  unreliable.

  Without a fundamental shift to the way Firefox add-ons work, we will be
  unable to use new technologies like Electrolysis, Servo or browser.html
  as part of Firefox.

  The tight coupling between the browser and its add-ons also creates
  shorter-term problems for Firefox development. It’s not uncommon for
  Firefox development to be delayed because of broken add-ons. In the most
  extreme cases, changes to the formatting of a method in Firefox can
  trigger problems caused by add-ons that modify our code via regular
  expressions. Add-ons can also cause Firefox to crash when they use APIs
  in unexpected ways.

  Consequently, we have decided to deprecate add-ons that depend on XUL,
  XPCOM, and XBL. We don’t have a specific timeline for deprecation, but
  most likely it will take place within 12 to 18 months from now. We are
  announcing the change now so that developers can prepare and offer
  feedback. Add-ons that are built using the new WebExtension API will
  continue to work. We will also continue supporting SDK add-ons as long
  as they don’t use require(‘chrome’) or some of the low-level APIs that
  provide access to XUL elements.

  A major challenge we face is that many Firefox add-ons cannot possibly
  be built using either WebExtensions or the SDK as they currently exist.
  Over the coming year, we will seek feedback from the development
  community, and will continue to develop and extend the WebExtension API
  to support as much of the functionality needed by the most popular
  Firefox extensions as possible.

Basically, I believe them when they said that they had sound technical
reasons for the change to the WebExtensions API.

Part of this was apparently that HTML5 w/JavaScript had become an
attractive alternative to the legacy XUL/XPCOM/XBL structure for browser
extensions, and Google proved this with Chromium/Chrome, which stole
most of Firefox's market share during the 2010s.  Mozilla's newer
WebExtensions API is deliberately almost the same as the
Chromium/Chrome/Opera extensions API, such that it is easy to make an
extension cross-browser compatible.  Even Apple is bending to the logic
of this move:  The upcoming 14.x releases of Apple's Safari browser will 
conform to the Chrome API as part of the OS X v. 11 ('Big Sur') update. 

Anyway... things change.  XUL is damned old for an API.  It goes all the
way back to Netscape Corporation, in 1997.  Twenty-three years ago.
And, well, HTML5 killed it by being a better idea.