RE: display-buffer-alist simplifications

[Stephen J. Turnbull]

Drew Adams writes:

 > Why not?  What real deadline does free software development have?

Self-imposed ones.  There are things that are real that are
intangible, as someone who works with software experiences every day.

 > There might be practical limits such as the lost opportunity of
 > someone not being available to help after some date, but it's not
 > like you have to deal with contracts and paying customers.
 > 
 > Let's not exaggerate.  You can do anything you want wrt development
 > schedules.

So can a commercial enterprise, and many failures occur as a result.
But those failures aren't important per se, except to owners; there is
some friction, of course, but the productive resources which have been
freed are reasonably soon applied in new, and on average more
productive, activities.  The real problem here is that users (aka
customers), both current and potential, are suffering while the
company languishes.

The same real problem occurs in a non-profit.  If clients are not
served promptly, something is being wasted.  It's just that measuring
"what is wasted" and "the right thing to do" is much harder if you
don't have profit as a measure, and trading off "different what"s is
much harder.

That doesn't mean non-profit activities are a bad idea; just that
socialism sucks as a management tool.  Still, that's no reason for
abdicating management entirely.

 > Which is why features that are not ready get pulled from a release.
 > But the timing of releases is typically based on concerns and
 > constraints (e.g.  commercial) that Emacs is for the most part not
 > burdened with.

Actually, the only such concern that Emacs is free of is labor
quitting because its pay is in arrears.  But even there, releases are
an incentive for many volunteer hackers.  Seeing your code published
is one example.  The other concerns that commercial enterprises worry
about are merely made much harder to measure in a non-profit because
of lack of concrete management information like "revenue" and "cost",
leading to inefficiencies in decision-making (aka "bike-shedding").

You pride yourself on human factors, Drew.  Economics (and I don't
mean "commerce") is one.  You should learn more about it (at least to
the point where you realize that there's more to it than "contracts
and paying customers".)