ImageJ development involvement/contributions

[Prodanov Dimiter]

First, Thanks Johannes for the citation remark ;)

Dear Raymond,

What you are describing is indeed very interesting.
I view forking for the sake of novelty primarily as dissipation of resources.
After all most of us are scientists dragged into ImageJ development
(although we all love doing it) by simple necessity.
If the development process is conducted in a structured manner then all good/interesting
functionality can be reintegrated in the main stream.
This is at least what happens in ImageJ.
So far the ImageJ community always welcomes such improvements.
Thank you for the book reference. It is very interesting to read.

Dimiter

[Raymond Martin-2]

Dear Dimiter,

> What you are describing is indeed very interesting.
> I view forking for the sake of novelty primarily as dissipation of
>  resources. After all most of us are scientists dragged into ImageJ
>  development (although we all love doing it) by simple necessity.
> If the development process is conducted in a structured manner then all
>  good/interesting functionality can be reintegrated in the main stream.
> This is at least what happens in ImageJ.
> So far the ImageJ community always welcomes such improvements.
> Thank you for the book reference. It is very interesting to read.

Thank you, Dimiter.

I appreciate your comments.

Best regards,

Raymond

[Adrian Daerr-2]

On 15/12/09 5:56, Paul Johnston wrote:
> I agree with Raymond, people should not resist or fear change.  To
> demand 100% backwards compatibility forever ultimately would doom any
> software project

I agree as well. This list is one of the strongest arguments that
experiments need not be feared, even if a couple of plug-ins break: I
have always been impressed with the extremely fast reaction to bug
reports (including from Wayne of course, but not only!). So I believe
that if a few percent of currently used plug-ins stop working due to a
deep design change and despite a backward compatibility layer, and those
plug-ins are not updated by their original authors spontaneously,
chances are high that a post on this mailing list will solve the problem
within hours. So in my opinion, instead of "100% backwards
compatibility", a new design should "simply" (quotes because it'll be
hard enough to do even then) strive at providing a compatibility for
most plug-ins and such that the broken ones can be fixed by as little
changes as possible. I am optimistic that this list will take care of
users with no programming knowledge as it has in the past.

Good luck to those (on both sides of the current dispute ;-)) who are
working on making ImageJ evolve, I look forward to seeing what you come
up with.

Adrian

[Grant Harris]

Adrian -
Thanks for that contribution - that is a good articulation of my view -
plugins that matter can and will be made to work and the odd one that
doesn't is likely to be fixed in short order if someone has the need.
-- Grant Harris

[dscho]

Hi Grant,

On Tue, 15 Dec 2009, Grant Harris wrote:

> Thanks for that contribution - that is a good articulation of my view -
> plugins that matter can and will be made to work and the odd one that
> doesn't is likely to be fixed in short order if someone has the need.

I would agree that backwards compatibility needs to be shed, if it were
necessary.  But it is not!  We can just keep the existing interfaces, and
add new ones, deprecating the old ones.  That way, old plugins will work
(however, in the process they might become slower due to additional
proxying).

That way, you can appeal to developers without losing our most valuable
assets: our users.  (Remember: we only continue to get funding if we keep
being popular.)

Ciao,
Dscho