emacs-devel
[Top][All Lists]
Advanced

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

Re: ["agree"] Release plans


From: Thomas Lord
Subject: Re: ["agree"] Release plans
Date: Tue, 26 Aug 2008 00:16:33 -0700
User-agent: Thunderbird 1.5.0.5 (X11/20060808)

Stephen J. Turnbull wrote:
Personally, I agree with Tom: we should be going all-out to encourage
use of free software, using three main tactics: (1) emphasizing the
importance of software freedom (eg, from a code-is-law basis), (2)
emphasizing the costs both in freedom and economic value of non-free
software, and (3) providing kick-ass software that everybody wants to
use.

I'm saying an additional thing that is a bit subtle.   So, there should
be a (4) in that list.

The additional thing is a qualifier on "kick-ass software".

We want (4) Kick-ass software that is kick-ass in the specific
sense that a maximized number of users will find it personally
beneficial to themselves to study the code, modify it, and share
modifications.

That is, we want software that is not only a good choice among
software in general but, among the good choices, we want software
architectures and engineering practices that non-linearly reward
the *exercise* of software freedom by as many users as we can.
If a lot of people are fully USING software freedom, then they
and many others will come to EXPECT software freedom and
DEFEND software freedom.   Seems like a no-brainer, to me.

I would claim that API features like a dynamic loader or
tree print/read in GCC are special.   They encourage people to
get work done by studying, modifying, and sharing code -- by their
nature.   GNU should / should have run for such features rather
than ban them.   Those feature-ban decisions were pretty much
the opposite of right.

I also am saying that I can't think of any non-contrived feature
bans that wouldn't be subject to the same criticism.   At least as a
good rule of thumb, I think we could just say that, in general,
no feature is banned.   Then we don't have to spend nearly as much
time thinking about what not to implement (and always, eventually,
coming up with the null set as the best-guess answer).

-t


-t






reply via email to

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