Re: [Gnu-arch-users] [OT] funding free software R&D

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    > >>>>> "Barak" == Barak Zalstein <address@hidden> writes:

    >     >> In short, I think that companies like those listed above
    >     >> should, in effect, just give people like me a bunch of money.

    >     Barak> I think that the real problem is still that no one is
    >     Barak> willing to pay for something that he can get for free
    >     Barak> (well, almost),

    > That is not true.  People regularly pay for things that they can get
    > for free, such as Red Hat Linux, Berkeley db, the X Window System,
    > etc.  Sometimes they use the bundled fringe benefits (support, etc),
    > but often they do not.

Maybe that's a misleading way to look at it.

At today's prices, RHAT's in particular, I think people _are_ paying
for something that they use, even if they never call the support
number.

For one thing, they're paying for security patches.   I may disagree
with the engineering of how they're provided -- but it's not like
anybody else is doing much better.

For another thing, they're paying to have an enterprise infrastructure
that's defined in terms of the products of a credible vendor rather
than in terms of the unique expertise of in-house IT staff.  At a
certain level you do better career wise by getting your employer to
give some of the IT budget to services that make you easily replaced.
(I.e., the services that customers are paying for here, and that they
make use of, is (a) deployment of the skill and personal advantages of
RHAT execs at reputation-building; (b) RHAT's ability to host a
certification training business.)

In some cases, they're paying to get access to Oracle or WebSphere or
other products on a cheaper-than-Solaris/AIX platform.  They're paying
RHAT to have the opportunity to pay Oracle without having to also pay
Sun.  (And this returns to the capabilities and social position of
RHAT execs.)

I don't know that much about smaller customers, the ones mostly below
RHAT's radar, but I do know that among the entrepreneurial small
businesses that consult with them, I've had a surprising number
fishing around with me with the idea of adding some arch support or
services to their bid.  (Nothing's quite worked out yet -- but if I
were working on web tools or interconnect tools to Windows or
whatever, I'll bet something could have.)   My sense is that a lone
guy going in there to make a bid can do better if he's saying "Ok,
here's what my alliance of providers can do for you,"  -- another
variation on getting ahead by making yourself replaceable.



    > The real problem is that people are unwilling to pay for something
    > they don't want.  What people want is a better CVS; what people want
    > is something that will reduce the annoyances they have to deal with
    > without changing what they do.  (Robert Anderson's request for
    > Reply-To munging is a case in point.)  If you can give them that, and
    > the real benefits of arch, too, that would be great.

It would be weird, then, that, at least arguably, nobody is providing
a better CVS or even working on one.   A "different CVS", perhaps.

I'm starting to believe that, in reality, there _isn't_ much real
commercial demand for revision control.  What little demand there is
isn't for "a better CVS" at all -- mostly it's for a system that runs
on both unix-family and msft-family platforms;  a small part of it is
for a system that has the establishment sheen of a Rational or
Perforce product, at significantly less cost.

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

There's some commercial demand, irc rumour has it, for "a better CVS"
that I would call accidental and driven, at this point, by momentum.
A few customers who accepted that line item in a larger bid, a while
ago.

(And please note that "commercial demand" and "what hackers in the
free software community talk about wanting" are very different
things.   Evidence, as good as any, of the _failings_ of RHAT execs to
align their business model with the available resources.)


    >     Barak> instead of aiming toward elite programming.

    > As I understand it, arch is not aimed at "elite programming."  It's
    > aiming at a real (large and growing) hole in support for some of the
    > things that should be every-day activities of small-scale developers,
    > not limited to large companies that can afford non-developer technical
    > staff to support the developers.

I'd like to think it's both.  I'd like to think it's aimed at being a
good fit for every-day use and small-scale developers, that it (to an
extent now and soon much more so) scales to huge projects, and that
among its other virtues, it helps programmers think in new ways that
make them better programmers (I know it did that for me).

But there's nearly no commercial demand for better programmers --
there's demand for systems engineers (a perfectly honorable
profession, of course).  What little demand there is for programmers
at all is demand for average, predictable, easily replaced,
programmers.  This is a side effect of their being no commercial
demand for better software -- there's demand mostly for the same
software at cheaper prices.

This situation isn't going to get better anytime soon unless something
surprising happens.  Companies like Microsoft have given creativity
and innovation in software a bad name by equating them with the
message: "The product you use is becoming unsupported.  You must
upgrade.  By the way, we've changed our terms."  It's a message that
determines not only their licensing and business model, but also their
software architecture -- the two are inseparable.

The rule of thumb for the tech industry is "something surprising will
happen".  I think that rule of thumb is a bit like Moore's Law: it
wears out -- in our lifetimes -- soon -- and only serious investment
can postpone that.  It wears out because, whereas in the early 1980s,
"something surprising" could fit in 48K RAM and be distributed on a
180K floppy -- over time, the complexity of surprising things goes up
and up.  To keep things going, I think, programmers need to return to
the meta-issues of building technology that makes them much, much more
productive.  And who's got time for that?


"Looking back and forth between the arch patch queue and my new lisp,"
-t