help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: line-move-visual


From: Mark Crispin
Subject: Re: line-move-visual
Date: Wed, 08 Dec 2010 15:12:58 -0000
User-agent: Alpine 2.00 (OSX 1167 2008-08-23)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]