[Lazarus] Is Lazarus project in a downward spiral?

[Joost van der Sluis]

On Tue, 2010-03-09 at 02:57 -0700, Tom Lisjac wrote:
> On Tue, Mar 9, 2010 at 1:38 AM, Vincent Snijders
> <vsnijders at vodafonevast.nl> wrote:
> > Alexander Klenin schreef:
> >>
> >> On Tue, Mar 9, 2010 at 13:44, Hans-Peter Diettrich <DrDiettrich1 at aol.com>
> >> wrote:
> >>>
> >>> It's not so simple. Guess why it took me more than a year to implement
> >>> usable docking - it's not a matter of implementation, but a matter of
> >>> discussions what is *allowed* to change in a poor interface, and what
> >>> additional LCL/Delphi incompatibilities already have been introduced and
> >>> must be respected by all new code. It's almost impossible to replace an
> >>> inappropriate implementation by a better model, because some existing
> >>> code
> >>> *could* be broken by such an change - unless such a suggestion comes from
> >>> a
> >>> core developer, who simply changes his existing code.
> >>>
> >>
> >> I wholeheartedly agree with the above -- a purely theoretical
> >> backwards incompatibility
> >> issue already prevented me from contributing to at least one Lazarus
> >> subsystem.
> >>
> >
> > I wonder how such wishes can be reconciled with wishes from Tom Lisjac for
> > example to have more stable lazarus, not changing compatibility every
> > release (if that is what actually happens).
> 
> I don't remember suggesting that compatibility should never change
> between major releases. What we've been talking about in this thread
> is for stability issues to *start* being considered and to *begin*
> managing changes so version impacts on production developers and
> existing code would be minimized or at least well documented. Borland
> always did this with new version releases, so when they made changes,
> the community understood and was fully prepared for them.

Everybody understands that it would be great if we can do that.

> The "stability issue" occurs when arbitrary changes are tossed in
> randomly and without regard for their impact existing code... and with
> no documentation. This doesn't mean that there has to be total
> compatibility between a version 1.0 and 2.0 if necessary changes and
> their impact on existing code are clearly documented.

Would be great, no-one disputes that.

> It also won't be an easy or straightforward process managing
> codebreaking decisions because there will always be genuinely good
> reasons to make changes... but starting the process of managing code
> impacting changes is an essential next step if there's ever going to
> be a credible 1.0, 2.0, 3.0... etc for this project.

No-one is against that. 

> This thread was simply intended to flag a real world problem that
> developers are having when trying to create production code with this
> tool. Many of us were hoping to see a civil discussion of that topic
> that might have even lead to finding a mutually agreeable solution.
> I'm sorry that didn't happen but I'm hoping it will at a later time...
> and definitely before a serious effort is made to release a 1.0.

Only we don't need a thread to show us that all of this is missing. That
only costs energy and adds nothing. What we need are people doing all
this. Not people discussing it, or how it should be done. What we can
really miss are mails to tell others (core) to do it. 

The 'core' people are volunteers. No one can tell them what to do.
They'll do what they like. Gladly some of them like it when more people
can use Lazarus. Or they realize that attracting new developers can help
them. So they invest their free time in documentation, stability,
maintaining the fixes branch and such. But they have limited time.

Telling the 'core' team that if they'll do 'this' it will attract 'more
developers', so that they'll have more time, is counter-effective. Most
core-people are doing this for fun. So attracting more developers isn't
their primary goal. If attracting new developers is reducing the fun
they have while developing... It's all counter-productive, from their
own point of view.

And don't forget: The 'core' people can leave the project too if they do
not enjoy it anymore. 

Maybe this all is shocking for some users. And maybe even more for the
commercial ones. But eventually we'll find a way out of that. As Michael
said there are plans to offer commercial support for Lazarus/fpc. And
don't forget that this project has come this far that commercial parties
are using it or want to use it. Even with all problems of the
volunteer-driven development model of fpc and Lazarus. (I think it
should even be 'due to' the development model)

And as a last comment: realize yourself that there are conflicting
interest between different users. We all want all possible features,
with the amount of bugs of a project without features. It should contain
only a few lines of code. Which anyone can read. And it has to be
stable, but we should be able to break compatibility for some new
sideways features. This is easy-doable, as long as 'core' maintains a
separate branch for each and every user. Not enough time? Make time by
doing this, that'll attract new developers!

The 'core' team is trying to find the balance between all this. This is
difficult. Really difficult. 

Give them (us?) some credits.

Joost