Re: line-move-visual

[Mark Crispin <mrc@panda.com>]

On Thu, 10 Jun 2010, Uday S Reddy posted:
> A third suggestion is that we should start thinking of Emacs as
> mission-critical software.

It amazes me that anyone would think otherwise.

> It is really platform on which a
> number of critical services are delivered, for development of projects
> or for running of teams and organizations.  A lot rides on it and any
> changes that potentially cause corruption of files or data can be quite
> serious.

As the kids say, "well, duh!"

This discussion is rapidly leading to "is free software suitable as 
mission-critical software?".

Some people would be more comfortable is the answer is "no".  Then they 
don't have to deal with the responsibility of mission-critical software.

> Finally, and I might be a bit OTT here, I think we should think of free
> software as community-owned software.  It is not developer-owned
> software (despite the aberration caused by the existence of FSF as a
> copyright-owner).

The notion of "community-owned software" works as ideology, but not as 
reality.  If emacs was really community-owned software, I as a community 
member could revert the change in the official distribution sources.  And 
then there could be revert wars ala Wikipedia.

That existed once upon a time in the mid-1970s, at MIT (the ITS systems) 
and elsewhere.  It didn't end well.

The dichotomy between "the cathedral and the bazaar" that ESR postulated 
doesn't really exist.  The full-fledged bazaar option doesn't scale and 
never actually happened.  It's just two types of cathedrals, one run by a 
pope and the other run by a board of laymen.

But even the laymen become power-corrupted.

> Free software isn't
> "free-to-fork" software, even though the right to fork exists as a last
> resort and as a foundation for everything else.  If that right needs to
> be exercised, it is a signal that the community-ownership of the
> software has broken down and that is not good for any of us.

That is certainly true.  Again, BSD serves as an example.

Another sign of a process breakdown is when a developer's answer to user 
complaints about changes in a new version is "so just run the old 
version".  The need to revert to an old version means that the new version 
is broken.

The corrolary to this is that the standard developer's answer to 
complaints about bugs in an old version is "upgrade to the new version". 
This only works if the upgrade is a viable option.

Developers can't have it both ways.  If they create a new version that is 
unacceptable to some portion of the user community, they they have 
effectively forked the software.

Responsible developers figure this out after a while.  It takes maturity. 
Generally, they want their users to be using one, and only one, version; 
and they do what is necessary to ensure that there are no barriers to 
upgrade.

Since user interface surprise is a barrier to upgrade, they make sure 
there aren't any such surprises.

In the real world, people get fired for inflicting surprises in 
mission-critical software.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.