[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 29 Jan 2008 02:04:30 -0800
Thunderbird 18.104.22.168 (X11/20060808)
* ESR's effort to initiate process reform for GNU Emacs sparked
some larger conversation about the GNU project generally. A
resulting idea has reached the "half-baked" stage in my mind
and I would like to share it before I explore it further (and
to help decide whether I should).
Please forgive me for not trying to attribute every point made
in the list conversation and I note for the record that the
mailing list archives for the past month or so should make it
easy to figure out who exactly I am "quasiquoting," so to
speak. I am freely combining my own ideas with several that
have passed on this list. I have some original thoughts here,
I suppose, but they are intertwingled with what others have
* The aim of the GNU project is to develop an operating system.
This goal has not yet been met.
GNU has achieved "most" of the goal, in some sense. Using
little besides GNU software and a kernel, usually the Linux
kernel, of course, a free software operating system can be
Yet, the GNU project does not itself distribute an operating
system. Users must either do a lot of work to assemble
their own, or rely on Debian or on one of the commercial
GNU/Linux vendors, or rely on a small number of poorly
resourced hobbiest or volunteer projects. No commercial
vendor of free software is delivering applications advertised
to run on "the GNU operating system". GNU's early objectives
of unix-but-then-a-more-lispy-environment lie by the wayside.
* Though there was once a fairly clear "target" for what the GNU
system would one day be, both technology and free software
have advanced so far, in the meanwhile, that there is no
longer any clear picture of the GNU project's target.
Early on, GNU was defined by a simple task list that (more or
less) listed the differences between what GNU was already
distributing and the then contemporary versions of unix. GNU
had "info" and "tex" but needed an nroff, for example. GNU at
one point needed a good shell program. GNU would need a
window system, just as the unix vendors had such. For fun,
the GNU task list asked for a flight simulator. Most of these
boxes got checked off (i.e. "done enough, for now"). Some
slapstick craziness delayed a kernel. The linux kernel
arrived. Commercialization happened. And a mere decade and a
bit later the definition of "operating system" (in the sense
of what people expect when they install one) has expanded
greatly. The task list has not kept up. This is no surprise
* A strictly volunteer project has difficulty catching-up or,
better, leap-frogging the contemporary definition of an
operating system, because today there is commercial demand for
free software hackers.
When GNU began, jobs describable as "developing free software"
were almost non-existent. I, for one -- and I'm sure I am not
alone -- volunteered to try to shrink the GNU task list partly
to force a point. "We," (if I may), sought to create a
complete, useful, truly free operating system *in part*
because that would help create something in scarce supply at
the time: a professional career path in which we would not be
obligated to collaborate in somebody's plan to seize power
over users (at least in the sense of the "four freedoms").
So, "we" (some of us, at least) "worked for free" in part so
that later we might be able to work professionally without
sacrificing our ethics.
Times have changed and while there are still (it seems, from
reading the trade press and studies) more programmers who
*want* to write only free software than there are who are paid
to write free software -- still -- demand for very talented
free software programmers is fiercely competitive. Very few
people with lots of established talent need to struggle to
find employment writing free software. Therefore, almost
everyone with lots of established talent has only limited time
to volunteer for GNU, other than where such volunteerism
happens to coincide with the wishes of their employer.
* The definition of "GNU project" has become confusing.
With an unclear target, and extremely limited volunteer
resources, GNU is in a rough spot when it comes to leading
cooperation on building -- well -- "the GNU operating system".
The GDB project should work with the project to improve
the Emacs interface to GDB, for example -- but there is
no obvious way (other than catch-as-catch-can) to decide
the priority between that work and work on "tabs" support
in Emacs. The obligations of GNU maintainers have some
firm rail-guards -- but there seems to be no clear way
to settle priorities with respect to clear goals.
* In the name of freedom, GNU needs to complete its work.
Debian and, even more the commercial GNU/Linux distributions
have, on balance, positively advanced the cause of software
freedom -- at least for now. They are not, however, clearly
reliable sources of software freedom, at least in the GNU
sense. The original GNU vision has yet to fully materialize
and no project, aside from GNU itself, seems to want to
* The FSF ("owner" in some sense of GNU) remains, after all of
these years, a qualified leadership.
I need not rehearse, I hope, but merely refer to the FSF's
very long term continuing success in fostering sister
organizations around the world, in influencing relevant
legislation, in GPLv3 consensus-building, in simply
remaining afloat, in spreading the word about software
freedom generally, and on an on.
* RMS is neither immortal nor does he possess infinite
Recent messages from RMS highlight his personal and
singular role in defining what "the GNU project" means.
This is appropriate in many senses but it is not a lasting
solution, nor one that can any longer secure sufficient
volunteer labor to complete GNU.
* I propose the creation of gnu.com, a for-profit majority owned
subsidiary of the FSF, roughly analogous to mozilla.com.
The purpose of gnu.com shall be to define, complete, distribute, and
support the GNU operating system, on a for-profit basis.
The for-profit but only majority owned structure enables
fund-raising to pay GNU developers competitive wages without
sacrificing the cause of software freedom.
* Chartering the organization will be difficult, of course.
Probably similarly difficult to making GPLv3. Perhaps similar
techniques of consensus-building will apply.
* The FSF's approach to labor appears from the outside these
days to be exemplary. E.g., it is a pro-union shop and
offers decent benefits (as far as I can tell). gnu.com
should do no less. Moreover, as majority owner, FSF can
ensure that gnu.com does its fair share to support FSF
workers (or if not FSF, the union :-).
* Reformulating the vision and then drilling it down to
a task list for GNU is an exciting project -- the danger
is that it may be *too* exciting with people seeking influence
for all kinds of disagreeable reasons. The success of
the GPLv3 project gives some hope here to keep an orderly
* Though current commercial GNU/Linux vendors are not
exempt from criticism -- gnu.com is not "against" these
vendors. Rather, it should be understood as resuming
the project from which they got there start, and further
advancing the kind of forward-looking development project
from which they took their opportunities.
This message is not precisely on-topic for the emacs-devel
list, yet I have not witnessed any better audience and this
one seems ripe for it. Forgive me if I accomplish nothing
other than either wasting bandwidth on an igored message or
starting a flame-war. I hope the outcome is otherwise.
I volunteer to pay attention to what people say in response
to this admittedly "half-baked" idea either on-list or in
private responses -- and to try to do something intelligent
in response, presuming a general agreement about the cause of
software freedom and the value of the GNU project. People
can contact me at address@hidden
Yes, of course I want a personal stake in this -- a substantial
role and ample rewards. The idea, however, stands on its own
-- with or without me.
|[Prev in Thread]
||[Next in Thread]|