Some More Thoughts On The Collaborative Development Of OpenJUMP

I am pleased to report that I received some positive feedback about having more collaborative development of OpenJUMP. I heard from at least 2 or 3 different groups that are working with OpenJUMP that said they would be interested.

Some of the developers I spoke to seem to be pushing the idea of a merged core. This issue has come up before, and I have discussed it on my blog. I want to revisit it again in the context of this discussion on collaborative development.

I would first like to say that I think the idea of a “merged” OpenJUMP core that could be used by several different JUMP branches would be a great thing. I think we should have that as our eventual goal at the JUMP Pilot Project. Notice that I said “eventual” goal. I believe it would be a mistake to rush into cobbling together chunks of code and bonus features from all the different JUMP brands out there. I don’t say this as a criticism of the work of those brands developers. But I do think there are some real dangers about breaking things in OpenJUMP if we were to embark on that course. We need to remember that stability is a very important feature of OpenJUMP, and one that we want to preserve.

I’d like to propose the following steps in our course of action to encourage more collaborative development of OpenJUMP, keeping in mind our long-term, not short-term, goal of merging the cores of the different OpenJUMP/JUMP brands.

[1] Establish a package naming convention for Java Packages that can be followed by participating projects and developers.
[2] Finalize the Core Changes Proposal.
[3] Create a section on the JUMP Pilot Project Wiki for collaborative development. This section of the wiki will store a Java Package Map and change history for each of the participating projects. It will also identify current changes that have been made to the core that the project developers feel should also be made to OpenJUMP’s core.

It will probably take me a few weeks to get those 3 steps accomplished. After this has been done we can begin to examine, one at a time, the changes in each “brand’s” core that we would like to make to OpenJUMP’s core. When a project wants to implement a new change, they will have the choice of making a proposal to implement the change in OpenJUMP’s core.

I am prepared to maintain the wiki section on collaborative development with a little help from each participating project. I am also prepared to write the Core Changes Proposal for each change we would like to make in OpenJUMP’s core for other developers to review.

After a few months of this process, I think we will be at a point where many development teams of the JUMP “brands” feel they can migrate completely to OpenJUMP’s core. On the other hand, I can see many reasons why a team would want to maintain their own separate core, as this would allow for somewhat faster development.

The Sunburned Surveyor