Re: the future of Linu(s/x)

["Stephen J. Turnbull" <turnbull@example.com>]

M. Engel writes:

 > http://www.techweb.com/wire/story/TWB20010126S0013

None of these industry journals "get it," not even with respect to
ordinary proprietary development processes, let alone OSS.  The fact
that downstream vendors are bitching is interesting, but there's no
point in reading the rest of the article if you haven't yet.  :-)

 > --------------
 > Some Linux solution providers view the
 > constantly evolving process of the posting of
 > Linux libraries, patches, and updates to the
 > Internet as inefficient and cumbersome
 > ...
 > "I don't believe open source works well for
 > commercial companies because they can't control
 > schedules,"
 > --------------

This is bullshit.  They have as much influence over Linus's scheduling
as they do over Gates's.  Which is to say, if they can provide a good
reason for the boss to move the schedule, he will.  Linus can be
bought, but not with money.  You can buy him with code, though!  Gates
on the other hand cannot be bought with code, and boy would you need a
lot of money.

Also, they're getting the product at zero cost, which should cause
them to think about the tradeoff they're making before bitching.

Darren Cook writes:

 > I think the companies are forgetting they can't control schedules for
 > software development. Open source has little to do with it.

I'm in a position to say from direct experience that this is false.
Schedule can be controlled.  I'm doing it successfully so far with
XEmacs, and see no reason to suppose we won't release on schedule on
March.  And this is the first time I've ever tried anything like this.
And XEmacs _is_ comparable in complexity to the kernel, although not
as reliable, and with far fewer developers.

It's like Boyle's law about temperature, volume, and pressure.  If you
want to control schedule, you have to make concessions on features,
cost, or quality.  (In about 48 hours I'm going to find myself forced
to make an announcement that two features and the increment in the
major version number are getting lopped off our release plans.  But I
am in control of the schedule.  ;-)

 > They also seem to be forgetting they're free to fork the kernel
 > development.

This is the crucial point.  If they need a feature, they don't have to
wait for Linus.  If you wanted ReiserFS, you had it---what, two years
ago?  Sure, Reiser's code would be better (to some greater or lesser
degree) today if it had been released and tested with the kernel
starting two years ago.  But that's another issue.

 > I'm sure Redhat would use IBM's or Compaq's linux kernel if
 > it was better than the official linus one.

I doubt it.  But remember, Red Hat doesn't has never used the official
Linus kernel, or the official Ulrich glibc for that matter, anyway.
(And both Cox and Drepper are Red Hat employees!  Disgusting, isn't
it?  Or you could take the attitude that this is exactly the glory of
OSS.)  And Red Hat's kernel series is arguably worse for many purposes
than the official Linus kernel series.  It must be better for someone,
though, or the big corporate customers would tell them to cut it out.

Jonathan Shore writes:

 >    - ability to set priorities

No problem.  You just have to agree with Linus's priorities.  Or
fork.  Which even Red Hat has done, as a matter of policy,
apparently.  Note that they always resynch over time, at least so
far.  But they seem to have no desire whatsoever to _ever_ distribute
a vanilla Linus kernel.

This has _got_ to be cheaper than starting development from scratch,
or begging MSFT to do it.

 >    - accountability

The freedom to fork is the ultimate certification of accountability.
Linus is accountable to his desire for relevance.  And even if he
doesn't give a shit about relevance, the code is all free.  He's still
accountable!!  This has actually happened.  To rms.

Gates, on the other hand, is accountable to nobody smaller than IBM
(didja notice the screams of pain when MSFT's DNS went down? obviously
MSFT don't read TLUG, 'cause Jonathan & Chris have advised any number
of newbies to make sure that your secondaries for all network services
are on different subnets from your primaries, and MSFT blew that!)
And if Gates turns out to be crazy, too bad---he's still relevant
precisely because the code is not free.

 >    - quality control

No, you can buy quality assurance, eg, from Red Hat.

 > The last bullet may be contentious - you may be able to manage quality as
 > part of an open source effort if you have all of the cards right (big if):
 >    - able to attract great developers
 >    - are in a position to manage the OS project
 >    - have a group with common vision, not too discordant

None of these are sine qua non.

* Great developers?  A few competent developers, yes.  But that's no
different from any other development organization.  And open source
has a great advantage in attracting a decent share of the best
developers' attention: they can do what they want with it, and get
it published.

Some problems need full-time work (I suspect The Great VM Fuck-up is
one of those) from a hot developer.  But the "many eyes" approach can
help even here (even the stupidest monkey can occasionally type in
come correct code).  And what people in the industry (I'm talking
about intelligent observers, like Steve "Code Complete" McConnell)
have not really caught on to is that free software is not just about
"many eyes", it's also about "many tries".  The odds are in favor of a
solution if it's open source.  The odds are in favor of a dead
project, with closed source (don't believe me, go look it up; any of
the decent project management gurus will give statistics).  You can
put your code where your mouth is, on your own machines, anyway.  And
if you're persuasive, other people will try it on theirs.

At least at XEmacs, most of the posters on the beta list do not
hesitate to change their personal binaries, even though quite a few of
them used to be hesitant to submit a patch.  (They write things like
"I tried this and it seemed to fix the problem for me."  Nowadays they
mostly have shed the embarrassment, and submit the patch even if they
think it's probably unacceptable from the point of view of the Review
Board.  Nobody gets on them for it; instead, it's considered very
desirable because it's a precise way of explaining what you did.)

I bet the percentage of posters on kernel-activists who patch their
own kernels is even higher.  "Many tries."

* "Manage the OSS project?"  As Richard Nixon didn't say, "We are all
managers now."  Hell, I actually have become one myself.  (I still
don't believe it, but that's another story.)  Just fork, and you're
God.  (Doesn't guarantee you any worshippers, but that's another
question.)

* Common vision?  Fear of forking is overrated, even in hashi-using
countries.

All that said, I admit that neither I, nor the "intelligent observers"
(Brooks, McConnell, Humphreys, ...), nor the open source navel-gazers
(Raymond) know how to manage an open source project yet.  What little
we know is mostly about managing projects in the proprietary context.

However, one thing I find fascinating about open source is that
managing its _development_ is likely to be substantially _easier_ than
managing the development of proprietary products, especially if you
need to keep the latter secret.  The point is that so many of the
"best practices" so far identified for proprietary development
organizations are (1) automatic, (2) easy to implement, or (3) hard to
resist or subvert (by the developers or the project management) in an
OSS context.  There are none, that I can think of, that are more
difficult in OSS.  Code 'n' fix may be more common in OSS at present,
but that's because so few OSS projects have any management at all.

It's still true that finding a business model for OSS (ie, the
_strategic_ aspects of management) is very hard.  But that's a very
different problem from managing the development process, and I believe
the problems are separable.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."