[Lazarus] Is Lazarus project in a downward spiral?

[Tom Lisjac]

On Sun, Mar 7, 2010 at 3:24 PM, Graeme Geldenhuys
<graemeg.lists at gmail.com> wrote:
> On 7 March 2010 20:55, Michael Van Canneyt wrote:
>>
>> Which is exactly why I think that the person who started this thread has
>> tunnel-vision problems. The glass is half-full for me.
>
>
> I now understand what you meant with that statement, and I think you
> are right. ;-)
> Lazarus is an impressive product, I'm not arguing that. And obviously,
> it is fantastic to hear stories like Daithi's one. This does make me
> take note of what Lazarus has already accomplished. I guess I have
> been too long around Lazarus and simply take the features for granted.

>From my experience, a certain amount of tunnel vision is part of every
successful, goal oriented developer's toolbox. :)

Everyone agrees that Lazarus and FPC are unique, highly capable and
excellent in their current releases and it's clear that the project is
in a highly advanced state. Volunteers are needed now more then ever
to fix bugs and clean up the howto's, code examples and obsolete wiki
tutorials. Support funding would also be encouraging to the people
that have worked so tirelessly on the IDE and compiler for over a
decade.

Graeme started this thread with a question about plans for stability.
It hasn't been answered, but is still relevant because the project is
so close to being production ready. If it continues to be perceived as
"almost stable", many potential volunteers will continue to hold back
and "wait a little longer" until it is... and we've seen comments like
that in this thread. After all, who wants to convert components,
revise examples, rewrite tutorials and update webpages that will
quickly become obsolete and need fixing over and over again?

The "almost stable" perception is real and frequently reinforced on
this list. Recently one of the compiler devs said that "constant
change" to the projects would typically require website and
documentation revisions every 3 months. Hey, evolutionary changes are
good and to be expected, but as this tool moves and more into the real
world, minimizing their impact on existing, production code in the
long term becomes a very real concern.

So how can the core team continue to enjoy working on new stuff while
attracting developers and volunteers who want a "stable" tool that
they can confidently promote to their employers and use for personal
projects? For Lazarus, would it be possible to define a specific
feature and bug set for 1.0? Can the critical path bugs be posted so
"waiting volunteers" can see them as an obstacle to the stable version
they're waiting for? On the compiler side, adding language features is
to be expected, but if those changes are going to impact existing
code, can they be made available via a switch that is off by default?
Can any changes to the language be clearly separated from the detailed
internals changelog so they'll be easily visible to developers?

There's been a considerable amount of time and energy invested by a
lot smart people in this and previous threads, but no specifics have
been suggested for addressing both the core team and community
concerns about development freedom versus production stability. I'd
like to see something tangible come out of all this effort rather then
the thread concluding with everyone simply agreeing to disagree. :)

Thanks,

-Tom