Posted by
Raymond Martin-2 on
Dec 13, 2009; 5:32am
URL: http://imagej.273.s1.nabble.com/ImageJ-development-involvement-contributions-tp3690030p3690060.html
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