🚀 go-pugleaf

In article <BASHFORD.93Jan7194947@zippy.scripps.edu> bashford@scripps.edu (Don &) writes:
>noah> There may be any number of reasons why nobody else has developed
>noah> any GPL'ed "applications" yet.  A large part of it, in my
>noah> speculative opinion, is that it's a fairly new idea and most
>noah> companies don't yet accept that it could work.  Very few radical
>noah> ideas have met with overwhelming approval at their introduction.
>
>Its not the newness or radicalness of the idea, its the smallness of the
>profits to be had.  The GNU Manifesto is up front about the fact that free
>software is not as profitable as hoarded software.  Very few companies
>have any sort of social vision other than profit as their basis, so they
>cannot be expected to produce free software unless something like a GPL on
>a piece of code they want very much to use drives them to it.  That's
>capitalism in the pre-post-scarcity world!

I have no delusions that free software will completely replace proprietary
software as long as we have any "scarcity" at all, for precisely the
reasons you state.  But I think there might be a growing market for
consulting-based services in which there is an advantage to GPL'd software.

Take for instance Russ Nelson's GPL'd packet driver software.  He sells
support for this software and derivations.  Because his software is GPL'd,
the program gets widespread distribution, and he gets support contracts
from people who need it.  The GPL specifically works to his advantage in
that he can get the source for any 3rd-party modifications and still have
the right to modify and redistribute those versions for the purpose of
support (or anything else for that matter).

The reason why 3rd-party modifications are likely to occur even at the
expense of not getting exclusive rights is that there is some interest in
not reinventing wheels all the time.  The fact that various companies are
willing to port free software like GCC indicate that these companies think
hoarding software is not necessarily going to maximize profits.  There are
development costs to consider as well as the attractiveness to consumers of
software which is compatible with many other systems.  Unless a company has
an overwhelming advantage in a particular industry, consumers are generally
smart enough not to lock themselves into proprietary and incompatible
systems when equally-useful open standards (or widely ported versions of
the same program) are available.

In a world where software piracy is rampant, it may be that you can't
practically maximise your profits for certain kinds of programs.  In that
case, offering quality support instead, and chucking the copying
restrictions, may work to your advantage.  If your programs are going to be
copied anyway, you could try what Russ Nelson has done: let people copy to
their heart's content, and hope that many of those people come back to you
for other services.

Any market can be flooded, obviously.  But the present market for decent
support of most software is not anywhere near is carrying capacity.  There
is a chance to make money from this. 

Crynwyr is not the only company operating primarily on support.  There are
several others I personally know of: Wingnut (Japan), Signum Support AB
(Sweden), Cygnus Support (CA and MA), and Hundred Acres Consulting
(Nevada).

>noah> We'll see if Oleo takes off when it gets into better shape. 
>
>Is there a WISYWYG word processor in the works?

   Not that I'm aware of.  Mad processor in the works?

   Not that I'm aware of.  Maybe Emacs 19 would be a satisfactory WYSIWYG
editor if someone were to work on some pull-down X menus or something, and
disable most of the keybindings.  Some of the features in Epoch, like being
able to display bitmaps and such in regions, would also be a good idea.
I'm not sure if complications have caused the emacs maintainer(s) to put
this off until version 20 of the FSF's version or not.  But Lucid Emacs 19
and Epoch have some of these features already.  In any case, a technical
discussion about how to make emacs WYSIWYG belongs in another thread.