[Gnu-arch-users] [OT] Architectural renovation [was: funding free software R&D]

[Stephen J. Turnbull]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Tom> I think it's because there's not much demand for software
    Tom> development and, consequently, tools that help make software
    Tom> development _better_ are anthema.

    >> There's plenty of demand for software development.  On the one
    >> side, there are the big proprietary firms and the inhouse IT
    >> organizations.  But for them a few hundred seats of Rational
    >> license is a non-issue.

    Tom> I suppose "plenty" is your weasel-word there.  Have you
    Tom> _seen_ the unemployment figures?  The revenue figures?  I
    Tom> wouldn't expect you to but I suppose you also aren't thinking
    Tom> about the big cultural changes, _not_ limited to but
    Tom> certainly acute in silicon valley where, not all that long
    Tom> ago, employers were fostering new software projects as fast
    Tom> as they could get them.

Don't be thil-ly.  I'm an economist, remember?  I have seen the
figures.  The bubble broke, that's all.

For technical (ie, cashflow) reasons, this means that a lot of the
demand is not "effective", thus unemployment.  I know many _employed_
software people who are screaming under the burden they bear,
supporting obsolete software abandoned by the vendor, and I know a
few "IT executives" (not in the software development industry, but
ass't VP IT, that kind of thing) who are _all_ well aware of what they
are being forced to do to their companies by the cash crunch.  There
is latent demand, it will express itself.

The pain that the currently unemployed feel is not correlated with the
long term issues of investment that you're talking about.  The problem
for investment is cash flow (which will fix itself, and in the process
a reasonable fraction of the unemployment) and poor allocation
decisions by management (which is what we should discuss how to fix).

If you want to talk about how to employ more programmers, that's fine,
but I thought we were talking about restructuring the way the industry
works.  In My Somewhat Informed And Becoming More Expert As Time Goes
On Opinion, there is enough demand to support the needed restructuring
concurrently with the application-level development.

What needs to be done is to take those CTOs and MIS VPs and show them
there's a better architecture.  Look, these guys were impressed by the
cottage industry that sprang up around Visual Basic.  OK, later they
learned better, that GUI/RAD and robust internal architecture are not
the same thing.  But Lucid? long buried; BeOpen.com ditto.  [lx]?emacs
doesn't impress these guys (although there are at least three 4-letter
investment houses suspected of running proprietary variants of XEmacs).
But zope.com (which escapes the BeOpen.com debacle, please note) seems
to be weathering the storm.  So there's some evidence that they can be
educated.  :-)

Now, you're claiming that radical improvements over current best
practice should be possible.  I believe you, your intuition is good,
but I can't explain it.  We've got to explain in the kinds of terms
that Eric Raymond did, or nobody is going to listen.  Raymond got
attention from the big houses; even if you don't like his message,
you've got to respect his sales ability.  Telling the truth may be a
little less effective, but style really counts here.

    Tom> Same old, same old.  Some software architectures give hackers
    Tom> more inspiration to participate and generate value than
    Tom> others.

Tell me more.  I don't see it.  XEmacs _today_ has the "Emacs
architecture," supports internal graphics, embedded toolkit widgets,
sound, and we're working on smell :), supports DSOs, supports drug and
drip.  It provides a reasonably robust and simple to maintain package
manager.  We move another submodule out of C and into Lisp every few
weeks.  The architecture is there.  It needs some of the burls hacked
off and sanded down (not to mention polished up).

Where are the hackers?  More at GNU Emacs (which of the above has only
the internal graphics support, and a dedicated GNU-camp third-party
maintainer tells me it still sucks) than at XEmacs, and GNU Emacs is
way understaffed for its role IMO.  Evolution probably has as many as
the Emacs projects combined, at least guesstimating from list traffic.

I'm not discounting your _intuition_; I respect that highly.  But the
_words you say_ make me think "XEmacs" (ok, ok, to a guy with a hammer
everything looks like a thumb, or whatever), and I just don't see the
interest.  So something else is needed.

Even once we've got that "something else", there's another hurdle.
That is the belief that integrated architectures enhance market power
(Microsoft taught us that).  So we _also_ need a business model that
turns that on its head, somehow.

    Tom> Yes, it will take a lot of work to make a new one with enough
    Tom> performance and eye-candy, and graphics features to have
    Tom> impact

Starting from today's XEmacs, three man-years.  The features you
mention are there, and performance is not a problem on today's 512MB
RAM, 1 GHz machines.  But calendar time?  A decade, unless "management"
pushes really hard in that direction.  So tell me why I should push!

The dedicated hackers are not personally interested in going in that
direction.  They already have their hacking platform.  Casual hackers
would rather work in C# (or SWIG private libraries and call that an
API) than harangue us to make existing features more accessible.  But
without casual hacker input[1], the core developers can't prioritize
which features to make accessible, and typically thus don't work on
accessibility at all.  The users want their eye-candy ready-to-eat and
individually wrapped, which the dedicated hackers actually resist
working on.

Python, Perl, Ruby are feasible, even superior, alternatives for
non-text-intensive applications.  I've never much liked Perl or Ruby,
so I can't give examples for them.  But Python-libglade allows hacking
up reasonably good-looking GUI quickly.  People I know say you have to
wrap your brain into a Klein bottle to hack Zope (just like Lisp), but
once _you're_ properly twisted, hacking _Zope_ is straightforward.
Mailman, for all its OOTB design issues, is eminently hackable.

But it seems like C-level hacking of GTK and the OS kernel and stuff
is where dick-length gets measured.  Up to Mutt, OK, there was sh (but
mh ain't bad at all) and Perl (my recent close encounters of the third
kind have all been in /var/lib/dpkg/info, and my skin crawls... :) and
Scheme (which I think is elegant but scrambles some people's brains).

And although it has nothing to do with calibration of secondary
gender-specific characteristics, even you turned to C to reimplement
Arch.  Why not Python, or XEmacs Lisp (yes, we would very likely
swallow a Lisp binding that linked to libarch as an option)?  Or Guile
or systas scheme or scsh or clisp or Perl or Ruby?  Something deep is
going on here.


Footnotes: 
[1]  Jamie Zawinski and David Kastrup deserve kudos here.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.