Opinions on KYLIX 3 (Delphi 4 Linux)

[Mike Meyer]

Thomas Bartkus <thomasbartkus at comcast.net> writes:

> On Mon, 18 Jul 2005 19:56:24 -0400, Mike Meyer wrote:
>
>> "Thomas Bartkus" <thomasbartkus at comcast.net> 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.

You missed my answer to this. Ok, it was oblique, so it's probably my
fault. With an orphaned open source project, you always have the
option of taking on the support role yourself - or paying someone else
to do so. That's not generally possible with closed source products.

>> 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.

Not true. Not all commercial products are closed source - though that
tends to be the norm these days. And you can contribute code to closed
source products. For instance, I did the original Python wrappers for
Perforce's binary library. That's certainly supporting the product.

>> 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.

I almost certainly overstated the case - but I've been burned a lot by
choosing technical quality over profitability or popularity. The
reality seems to be that once you reach the level of "good enough",
technical quality stops mattering, and marketing forces come into
play. My essay on the subject at <URL:
http://www.mired.org/home/mwm/good-enough.html > has more information.

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

Depends on what you're evaluating it for. In the context of the
discussion - choosing tools for commercial software development - it's
almost certainly true. If it's not, you're not charging enough for
your time. But that's hardly the only time that one evaluates tools.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.