Larry Becker made some interesting comments about OpenJUMP in a recent post to the JPP Developer Mailing List. I wanted to talk about his comments for a moment. Larry said:
“I guess the important question we have to decide is "what's next?" Are we at the project stage that could be called "mature" or "maintenance,' or are there significant features that need to be added to ensure the long term viability of the project? I suspect that the answer to that question depends on what people are using JUMP for. For GIS researchers there is one answer, and for contractors who add value, there is another. Fortunately there is enough overlap to keep cooperation going.”
I never really considered this question. My first thought was, “Do you ever stop adding features?”. There is so much that I would like to do with OpenJUMP. If don’t even know if I could list all of the features I’d like to see added.
At the same time, I have come to appreciate the need for quality code and quality functionality in OpenJUMP. It seems like our community occasionally suffers from the drawbacks of rapid development. (I know there are a lot of open source projects that probably wish they suffered from this problem.) I think part of the reason for this style of development with OpenJUMP is the type of contributor’s that we have. I believe most of our contributors are paid by third parties to develop source code for OpenJUMP. In most cases these customers are worried about functionality, and not necessarily things like good documentation, pretty source code, or even the implications of the code on OpenJUMP’s design a few months down the road. They just want it to work, and they want it to work now.
There is nothing wrong with this type of development. Without it there wouldn’t be much happening to OpenJUMP. We wouldn’t be fixing a lot of the bugs that have been fixed, or making some of the optimizations to OpenJUMP’s performance.
At the same time, I recognize the benefit of the slower development that comes from volunteers or organizations with a long term commitment to OpenJUMP and its future. These are the people that are worried about what changes will mean for OpenJUMP in a year, and they are willing to take on challenges with OpenJUMP that can’t be solved in just a few weeks time.
Are the new features and improvements added by “rapid progress developers” important. Yes it is. But so are the slower and more stable contributions to the project. I don’t think we can say definitely that OpenJUMP is a mature program, and that will only be improving quality from here on out. I also don’t think we can take the opposite view and say that were mainly concerned with adding new features to OpenJUMP as quickly as possible, and that other aspects of the program’s management aren’t very important.
Some where we need to find a middle ground. I think the recent increase in developer activity has started some conversations that will help us find a middle ground. We’ve been talking about improving the quality of new and existing code, about better developer documentation, and even about an “unstable” branch in the OpenJUMP CVS.
These are all great conversations to be having. I think they must take place as we try to find a way for all of the different development teams to work together. In the end, I hope we will have a mature program that we can carefully add new features to.
The Sunburned Surveyor