Posted by
Prodanov Dimiter on
Dec 14, 2009; 2:12pm
URL: http://imagej.273.s1.nabble.com/ImageJ-development-involvement-contributions-tp3690030p3690033.html
Dear Raymond,
Some of the discourse so far is based in fact on social phenomena.
1) Forking is a matter of culture. We try to avoid forking because we all support the role of Wayne as the "guru/patriarch" of ImageJ. Some people here may start arguing about Fiji. I personally admire the efforts of the Fijians to maintain a centralized plugin repository and will promote this idea for another plugin repository. But we should avoid asking Fiji to contain "everything but the kitchen sink" so I leave for it the field for 3D reconstructions, image stitching, axonal tracking etc. Fiji is clearly not meant for bio-medical imaging, which I already do for some time at IMEC and is also supported by the Santec group. It is also not meant for DB integration and results management and so on.
But what we need to preserve is the common core functionality of ImageJ so that different projects could interoperate in such way as the different Linux distros are built on top of the same kernel.
2) Pursuing 100% backward compatibility is not tenable in the long run. What we can do is to start up an new PluginPlus or whatever interface, and not touch the old ones. With time we can depreciate the old Plugin interface so that the development will turn gradually to the new pattern. So at this point I agree with Raymond.
3) In view of all said, I suggest that we have to assemble a list of plugins that need to be maintained and stop caring much about the rest. Good starting points for this are the ImageJ site plugins, the Fiji plugins and the plugins on the IJ Wiki site. Of course such a list should not be set in marble ;) and if other plugin programmers agree to upgrade/maintain their plugins a mechanism for this should be foreseen.
Best regards,
Dimiter
-----Original Message-----
From: Raymond Martin [mailto:
[hidden email]]
Sent: Sunday 13 December 2009 06:33
Subject: Re: ImageJ development involvement/contributions
Grant,
> I appreciate your concerns and share them. If ImageJ does not evolve in a
> way which the community of developers and users follows, it will fail. As
> you likely know, these concerns have been debated at length both in this
> mailing list and on the Google ImageJX discussion group
> (
http://groups.google.com/group/imagejx).
I do not think it will fail because of those reasons. It would have failed
already if known limitations were so important for users to continue using it.
> I've been working on how to refactor ImageJ for extensibility while
> maintaining backward compatibility for several years now. The best I have
> been able to do thus far still requires minor changes to plug-ins; minor
> meaning that they could be accomplished with several find-and-replace
> operations in most cases.
If that is the best that can be done my conclusion at this point is not to
bother trying to make extensibility a feature for plugins in their present
form. Add extensibility only for new plugins or upgraded ones, along with
continuing support for old plugins.
> I expect that the authors of most of the plug-ins would make these changes
> as necessary. And if not, I expect that a user of some obscure plug-in could
> find someone to make the change for them.
This is what should happen, as the assumption to maintain near 100%
backward compatibility along with extending functionality for old plugins
is not going to work in all cases. And it may become a case of diminishing
returns, where too much effort is expended to attempt to provide support
past a certain point.
There seems to be the assumption that once a plugin has been made that it
should work indefinitely through all new versions of the program and have all
the new features also, without maintenance to keep it up-to-date. That is not
reasonable (a cake and eat it scenario) since so many of the underlying
factors will change that are necessary to facilitate that in the long run.
Reality shows that hardly anybody is running software from say 20 years ago
with extra functionality that was added on to it, it either does not exist
anymore, it changed drastically, the operating system it worked on upgraded
numbers of times adding/removing functionality in the process, and so on.
Real-world computing requires periodic maintenance/upgrade of all combined
parts.
> From my experience and reading, software that succeeds in being used
> by a significant number of people eventually reaches a point where many of
> the initial design assumptions no longer hold and it becomes necessary to
> make some incompatible changes in order to evolve the software further.
> My sense is that ImageJ is at that point.
So some of the motivations that are supposed to drive the funded development
of ImageJ on imagejdev.org cannot really hold.
Maintaining near 100% backwards compatibility is one of those things.
Another is the idea of "no forks". An impossible ideas for a project that is
free software, and public domain on top of that. I really wonder why this same
though this not occurred to anyone working on that side of things. The only
way to have no forks is to have no free software, no ImageJ. Am I seeing
proprietary thinking trying to mix itself in with free software?
> If anyone can find a way to, for instance, decouple the GUI in a way that
> doesn't require any changes to plugins, I'm all ears.
I think I just mentioned it above. Provide support for old plugins, but
extensibility only for new ones.
Raymond