Jan-Oliver made a post to the JPP Developer Mailing List that started some interesting discussion, on at least 2 different threads. I thought it was an important discussion, so instead of tinkering with my CursorTools or working on the OpenJUMP-Ex release, I decided to share some of my own thoughts on the topic. Please remember what follows is just my opinion, and I’m just trying to think about ways we can improve OpenJUMP and the JUMP-Pilot-Project in the future.
Jan-Oliver Wagner suggested that OpenJUMP be a central repository for all of the goodies that are being added to the different “brands” of JUMP that exist. Jan asked if there was a defined procedure for this, or if there were any plans to implement this type of procedure. Stefan Steinger responded politely by reminding everyone that his time is limited, and that his role as an administrator of OpenJUMP might be limited as well.
Thinking about Stefan’s absence is scary, at least for me, although he has mentioned the possibility in passing before. I think it highlights a problem with the JUMP Pilot Project and with OpenJUMP that others outside of our project recognize. The JUMP Pilot Project lacks a group of developers dedicated to its maintenance and upkeep. Stefan has been doing a great job in this role, working very hard to keep OpenJUMP up-to-date with improvements in Vivid’s JUMP and other JUMP “brands”.
When I started the JUMP Pilot Project with Stefan one of my major goals for the organization was improving the coordination and the cooperation between the different developers working with JUMP. I never intended for there to be one or two people that tracked down all the various changes and bugs, and to perform the administrative tasks that come with running an open source project. I imagined that this would be a task that would be performed by all of the developers from the different teams working with JUMP.
While we have great participation on our mailing lists, the reality is concrete efforts at collaboration never seem to materialize. This is surely not Stefan’s fault, but it may be partly due to my shortcomings as a project administrator. We came close to having some great collaboration in the past. We formed a development committee. This was a rather informal group, but we had a body that could make decisions for OpenJUMP as a whole. I worked on a standard way to propose and adopt changes to the OpenJUMP core. All of this sort of faded away as members of the Development Committee moved onto other projects.
What does the future hold for OpenJUMP? I’m not sure if we have enough interested and willing developers that would be willing to join a new Development Committee. I don’t know if we have other people that are willing to take over some of the work that Stefan was doing. Things like fixing bugs and integrating changes from other JUMP “brands”.
I know that I plan to be involved with OpenJUMP/JUMP for a very long time. I think the program has a lot of promise, and I’m proud of what we’ve been able to accomplish as a community with OpenJUMP. I will continue to make efforts to improve the quality of the source code in OpenJUMP, and to keep up with the changes in other JUMP “brands”. However, I must honestly admit that I won’t have the ability to do all that I am currently and all that Stefan has been doing over the past few months. If there are other developers willing to help administer the JUMP Pilot Project and take some ownership of OpenJUMP, then I encourage them to let me or Stefan know. If we need to establish some procedures and rules to facilitate this we can, and some of this work has already been done.
In the worst case scenario I will slowly sink in my efforts to do all that Stefan did and care for my other OpenJUMP tasks. OpenJUMP will eventually be eclipsed by the functionality in other JUMP “brands” and we will loose the common platform for collaboration that we have now. In that case I can might try to work closely with Vivid Solutions on JUMP if they would allow it, or perhaps on one of the other JUMP “brands" if they would have me. In this scenario I think that some of the “openness” that makes OpenJUMP what it is would be gone. I don’t want to see that happen, but it takes more than two people to make a really great program like OpenJUMP into a successful open source project.
If you want OpenJUMP to be around in another year or two, we really need you to get involved soon. If you are working on or managing a JUMP "brand" and recognize the benefits of a common platform with an open development process we need you to speak up and tells us what we can do to make collaboration easier for you and your team.
The Sunburned Surveyor
Jan-Oliver Wagner suggested that OpenJUMP be a central repository for all of the goodies that are being added to the different “brands” of JUMP that exist. Jan asked if there was a defined procedure for this, or if there were any plans to implement this type of procedure. Stefan Steinger responded politely by reminding everyone that his time is limited, and that his role as an administrator of OpenJUMP might be limited as well.
Thinking about Stefan’s absence is scary, at least for me, although he has mentioned the possibility in passing before. I think it highlights a problem with the JUMP Pilot Project and with OpenJUMP that others outside of our project recognize. The JUMP Pilot Project lacks a group of developers dedicated to its maintenance and upkeep. Stefan has been doing a great job in this role, working very hard to keep OpenJUMP up-to-date with improvements in Vivid’s JUMP and other JUMP “brands”.
When I started the JUMP Pilot Project with Stefan one of my major goals for the organization was improving the coordination and the cooperation between the different developers working with JUMP. I never intended for there to be one or two people that tracked down all the various changes and bugs, and to perform the administrative tasks that come with running an open source project. I imagined that this would be a task that would be performed by all of the developers from the different teams working with JUMP.
While we have great participation on our mailing lists, the reality is concrete efforts at collaboration never seem to materialize. This is surely not Stefan’s fault, but it may be partly due to my shortcomings as a project administrator. We came close to having some great collaboration in the past. We formed a development committee. This was a rather informal group, but we had a body that could make decisions for OpenJUMP as a whole. I worked on a standard way to propose and adopt changes to the OpenJUMP core. All of this sort of faded away as members of the Development Committee moved onto other projects.
What does the future hold for OpenJUMP? I’m not sure if we have enough interested and willing developers that would be willing to join a new Development Committee. I don’t know if we have other people that are willing to take over some of the work that Stefan was doing. Things like fixing bugs and integrating changes from other JUMP “brands”.
I know that I plan to be involved with OpenJUMP/JUMP for a very long time. I think the program has a lot of promise, and I’m proud of what we’ve been able to accomplish as a community with OpenJUMP. I will continue to make efforts to improve the quality of the source code in OpenJUMP, and to keep up with the changes in other JUMP “brands”. However, I must honestly admit that I won’t have the ability to do all that I am currently and all that Stefan has been doing over the past few months. If there are other developers willing to help administer the JUMP Pilot Project and take some ownership of OpenJUMP, then I encourage them to let me or Stefan know. If we need to establish some procedures and rules to facilitate this we can, and some of this work has already been done.
In the worst case scenario I will slowly sink in my efforts to do all that Stefan did and care for my other OpenJUMP tasks. OpenJUMP will eventually be eclipsed by the functionality in other JUMP “brands” and we will loose the common platform for collaboration that we have now. In that case I can might try to work closely with Vivid Solutions on JUMP if they would allow it, or perhaps on one of the other JUMP “brands" if they would have me. In this scenario I think that some of the “openness” that makes OpenJUMP what it is would be gone. I don’t want to see that happen, but it takes more than two people to make a really great program like OpenJUMP into a successful open source project.
If you want OpenJUMP to be around in another year or two, we really need you to get involved soon. If you are working on or managing a JUMP "brand" and recognize the benefits of a common platform with an open development process we need you to speak up and tells us what we can do to make collaboration easier for you and your team.
The Sunburned Surveyor
Posts
