ImageJ project structure

[ctrueden]

Hi everyone,

With the announcement of the ImageJDev project, as well as the existence of
the Fiji project and ImageJX discussion group, there have been some
questions about how each of these efforts fit in, and how best to contribute
to ImageJ.

The ImageJDev project is designed to drive core ImageJ development as
described in our technical proposal (http://imagejdev.org/proposal). As
described in our original announcement (
http://n2.nabble.com/Funded-ImageJ-development-effort-Imagejdev-org-td4136529.html),
the mission is to drive core ImageJ development rather than produce any sort
of competing project fork. (We considered referring to the project as
"ImageJX" like the discussion group rather than "ImageJDev" but thought that
"ImageJX" sounds too much like a project fork.) That said, it is not our
goal to discourage forks in general—we simply do not believe that forking is
necessary to accomplish the ImageJDev project goals.

For now, the name "ImageJX" refers to both the Google discussion group (
http://groups.google.com/group/imagejx) and the refactoring procedure ("IjX"
for short) outlined in Grant Harris's whitepaper (
http://imagejdev.org/files/imagej/ImageJX_Mar09.pdf).

As for Fiji (http://pacific.mpi-cbg.de/wiki/index.php/Main_Page), it is well
poised to benefit from the improvements generated from the ImageJDev effort.
The Fiji developers will be actively advising the ImageJDev project, but
hopefully they will now have more time to concentrate on analysis
algorithms, visualization and other science-driven goals, and focus less on
infrastructural issues of the core ImageJ platform.

We welcome the community to participate in ImageJ development by signing up
for mailing lists of interest—see http://imagejdev.org/lists for details.
For those wishing to contribute substantial time and effort to the project,
we can arrange for commit access to the Git repository (
http://imagejdev.org/source-code) and web access to the Drupal site (
http://imagejdev.org). But please bear with us over the next month or so, as
we are still bringing the core team on board, and hammering out the
project's specific technical directions.

-Curtis

[was: ImageJ development involvement/contributions]
On Wed, Dec 2, 2009 at 2:26 PM, Raymond Martin <[hidden email]> wrote:

> I was just wondering what the situation is with development
> involvement/contributions to the code for ImageJ.
>
> I just got the code and started to upgrade some of the AWT stuff
> to Swing. It compiles and runs okay (I can load an image, etc.).
> Still more work to get rid of all the glitches, but it is a start.
>
> I can contribute this work and more.
>
> What is the project's position on this?
>

[was: ImageJX, alive, dead, or just crawling for now?]
On Thu, Dec 3, 2009 at 9:15 AM, laseray <[hidden email]> wrote:

> So what is the situation with this potential extension of ImageJ?
>
> Is anything going?
>

[was: ImageJ development involvement/contributions]
On Tue, Dec 15, 2009 at 11:18 AM, Prodanov Dimiter <[hidden email]> wrote:

> 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.
>

[was: ImageJ development involvement/contributions]
On Mon, Dec 14, 2009 at 9:12 AM, Raymond Martin <[hidden email]> wrote:

> > 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.
>
> There is a book I read a few years ago entitled "Innovation Happens
> Elsewhere". It is written by a Sun software engineer who works on Java and
> it
> is all about free open source software and the practices of the projects
> that follow it.
>
> One point that is very clear to me from that is that when you attempt to
> prevent forks you actually cause them to some degree. I have seen this in
> practice and the writer points out that the proper thing to do when faced
> with
> a fork is to welcome it, give it space on your servers, a branch in SCM and
> so
> forth. There is already some of this type of acceptance happening with
> ImageJ.
> I consider this a good thing.
>
> In other words, do not alienate potential contributors by attempting to be
> exclusionary, it does not work. To move towards curtailing forks or pulling
> development towards a core has the potential to repel as well as attract.
>
> And you are right, forking is a matter of culture. It is a central part of
> the free open source software culture. ImageJ is a part of that.
>
> I think if people want to contribute directly to the core it will happen,
> naturally. Many successful FOSS projects that exist prove this without
> using force.
>
> Also consider that forks may arise due to inability to get functionality
> into
> the core of a project. A developer may be given no alternative if they
> have desirable functionality that the core does not accept. What can
> they possibly do once they have exhausted the route of communication
> to try to convince others that the functionality is required, desired,
> useful,
> better... It becomes a decision point. Should they throw their ideas/code
> away? They would be stuck if it were a proprietary application. But for
> FOSS they have been given the freedom to fork as an option. So this
> forking is very much a safety mechanism to prevent the loss of good ideas
> and
> allow them to flow.
>
> To try to prevent forks is to cut off potential enhancements that you
> would never know exist if it were closed source software.
>