Subject: Re: impolitic statements (business model clues for the clueless
From: Tom Lord <>
Date: Wed, 17 Oct 2001 11:57:40 -0700 (PDT)

	Forrest Cavailier

	>> Tom Lord <> wrote:

	>> I don't understand why OSDN and RH don't get together and
	>> give us a web service I'd really want to use.  I might even
	>> pay for it, if I had any money.

	> Providing a service you really want to use costs real money,
	> but you admit you don't have any.

	> So you inadvertently identified the problem: OSDN and RH are
	> very good at attracting "customers" who don't spend money.

We aren't disagreeing.  Beyond the "customers", where are the

If I had a project budget for some number of engineers, and if there
was a site with the functionality of FM at its core, but with good
packaging technology, ancillary contact, preferred links to
developers, filtered and well-chosen package content, and a few
additional service tweaks, then it would be a good use of my project
budget to buy subscriber IDs for my engineers for that site.

If the site managed to displace some proprietary tool solutions, well
-- there's the money for the subscriber ids.

If the site's offerings were relevant, well built, not tied to just
one platform, well organized, and tastefully integrated, it would save
my engineers time and help them to do a better job.  It would cost
less than having to hire someone just to maintain basic tools locally
(as sometimes happens), or piggybacking that responsibility
unaccountably on various engineers' official responsibilities (as more
often happens).  It would reduce a bunch of risks.  If my subscriber
fees were well spent, it would help the tool-set evolve more fluidly.

Now it's not as if it would take a whole new level of spending to
create a site such as I'm describing.  Much of the needed engineering
effort already takes place (though not all under one roof).  But
there's a lack of unifying strategy and corresponding coding and
interoperability standards -- elements whose importance seems second
nature to me; I'm not sure how to explain why they're missing in
practice.  "Open source processes" are, so far, more theory than


"Some people, whenever they have a problem to solve, say ``Let's use
XML!''.   Then they have two problems."