On Mon, 18 Jul 2005 19:56:24 -0400, Mike Meyer wrote:

> "Thomas Bartkus" <[EMAIL PROTECTED]> writes:
>>> > Re-train on a new platform,
>>> > and re-write from scratch?
>> What do you do when an open source project you were using gets
>> abandoned?
> cvs import -m "sources for orphaned project" <myprojectname>
> <productname> <initial>
>> Hard to see much difference here.
> Doing support for object-only distributions is *much* harder than doing
> it for source distributions.
> I have a habit of picking products based on technical superiority, not
> popularity. As a result, I have a nice collection of orphans. That's
> because technical quality has little or nothing to do with
> profitability.
> On the other hand, since starting to use open source projects, I've
> never had one I depend on fail. I've had some I contributed to fail, but
> that's a different thing.

I didn't suggest that orphaned open source projects were a problem.  I
simply point out that they are no more, nor less, of a problem than an
orphaned (and paid for!) commercial product.

> I suspect that technical quality in open source projects contributes to
> their attracting people to support them.

Perhaps.  And there is no way to support a commercial product other than
by becoming an employee.

> This makes them ever so
> much more attractive than proprietary solutions, where technical quality
> seems to be irrelevant to longevity.

This last statement sounds too much like a canard. It is difficult to deny
that commercial products either put some significant value on the table or
go bust. Although people can be, and sometimes are, swindled few can
afford to simply throw their money away. IOW - technical quality is
*never* irrelivant to longevity.  And one must also consider that
technical merit, by itself, is rarely sufficient.  The open source world
is awash with much that is high on technical merit but commercially
unviable. There is much out there that one would gladly pay good $ for if
only for lack of that last (but most difficult!) 5% effort that would
bring many of these projects to fruition.

Which brings me back to the point that the difference between free and
$500 (or $1000!) amounts to virtually *nothing* when evaluating a tool.

You use what is most effective to get the job done.
Thomas Bartkus


Reply via email to