Interesting Rant... you might develop this a bit and submit it to
Freshmeat... worth a t-shirt I'll bet. :)
On Tue, 19 Sep 2000, Bob Miller wrote:
> Seth Cohn wrote:
>
> > Sloppy coders are laughed at in the open source world because of the
> > sloppy code, and so they are loath to even put stuff out there, because
> > in a closed source environment, nobody knows how bad the code is, but when
> > everyone can review and patch, bad code sticks out like a sore thumb.
>
> <RANT intensity="incendiary">
>
> I currently work at a (closed source) company whose code base is
> worse than most. I've had occasion to think about why it's so
> rotten. It's not the developers' fault, for the most part, it's
> management's.
hmm... not so much management as the nature of software marketing/sales?
> Software management has two incentives to minimize the amount of
> engineering done on a program. The lesser incentive is the expense,
> and the greater incentive is time to market.
Neither of which most free software faces, so I agree...
> Anything worth doing has to pay back more than
> $250/hour.
What about support costs? If it's poorly written, it costs way more than
$250 to support. I think the total cost has to be factored
in. Supporting bad software, bad documentation, etc has support costs,
huge ones, I think, and nobody likes to look at that, or else they skimp
and then wonder why they fail. Of course, often, the product sold, so
they don't care about bad support... or they charge more for it.
[the classic Dilbert "build more bugs into the software, we'll sell the
fixes")
Free software on the other hand often has support costs, but much less, as
I said before, and it's spread out among all users, since the frequent
patches and so on often fix problems for everyone at once.
> And the other thing is time to market.
versus Free software's "Release Early, Release Often". So long as
the code works, put it out there. if it's free, it's fine to do that.
Paying for software, you expect it to work fully and completely, so it's a
little hard to do that.
> Not something that works. Just something that's shippable. I see
> decisions made every day that will cost us ten days' work later to
> save us one day now. This is the "correct" tradeoff in commercial
> software.
This is why Microsoft always needs 3 tries to make a successful
product. The first two are always rushed out the door, and it takes the
3rd time to figure out what really works.
> Obviously, software written by volunteers doesn't have either of
> these incentives working against it. That's why Windows 2000
> shipped in February, and Linux 2.4 hasn't. And it's why I won't
> wait for Service Pack 3 before I install Linux 2.4.
Linux 2.4 test kernels are often quite stable... because of the very
release early ideals. The 'final' kernel release will be when it's ripe,
regardless of the commericial pressure (and there is some now).
Debian is a good example of too long development by volunteers.
Not enough full time developers is as bad as too many in some ways.
> I would like to know how commercial open source projects handle this
> dilemma. They have the same incentives to deliver crap as commercial
> software, it's just more obvious when they do.
Redhat's rushing has caused quite a few serious security holes, much to
everyone's concern. Not very many commericial open source vendors right
now to look at.... are there?
> PS: Subversion is cool! http://subversion.tigris.org/ (Oh, okay,
> it's vaporware, but it's GONNA BE cool! (-: )
very neat. CVS is really lacking for some things....
Seth
