Posted by
Raymond Martin-2 on
Dec 14, 2009; 3:12pm
URL: http://imagej.273.s1.nabble.com/ImageJ-development-involvement-contributions-tp3690030p3690043.html
Dear Dimiter,
> 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.
> 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.
Good idea. Some kind of table with parameters indicating status, last update,
and so on that the maintainers of the plugins can edit also.
Cheers,
Raymond