“Merging the Cores”…That almost sounds like the title of a science fiction movie. :]
There has been a lot of discussion on the JPP Developer’s list about the possibility of merging the “core” of OpenJUMP and the "core" of JUMP that is maintained by Vivid Solutions. I said I would try to discuss this in a posting on my OpenJUMP Blog. First, I want to explain exactly what the “core” of OpenJUMP is. Then I want to talk about how it is different from JUMP’s “core”. Then I want to talk about why I don’t think a merge is going to happen anytime soon.
The original JUMP created by Vivid Solutions was designed to be extendable without the need to recompile the source code for the entire program. This makes it very easy for developers and users to extend the functionality of JUMP. One great thing about this system is that it allows for functionality to be quickly “plugged” and “unplugged”. (I guess that is how they get the term plug-in. Sometimes applications will use the term module or snap-in, but it basically means the same thing.) If someone has a feature you want to add to JUMP you just “plug it in”. If it turns out to be broken or doesn’t do what you want, you just “unplug it”.
A lot of modern programs are using this type of extendable design. Eclipse is a great example of a program that does this. In Eclipse “everything” is a plug-in. JUMP doesn’t take the whole plug-in design to this extreme. It has what developers like to call the “core”. These are parts of the program that are necessary for JUMP to run. These parts of the program can’t be unplugged. (At least, not without some major surgery.)
OpenJUMP has inherited this extendable architecture from the original JUMP. It also has a “core”. This core is maintained by OpenJUMP developers on the JPP CVS repository hosted at SourceForge. There are some minor, but important differences between OpenJUMP’s core, and the core of the current JUMP maintained by Vivid Solutions. For one thing, OpenJUMP’s core has been internationalized, which means that it supports languages and locales from around the world. Even as an American, I think this is pretty cool, and I hope that it something we continue to support in OpenJUMP. (I’m committed to internationalizing all of my own plug-ins for JUMP and OpenJUMP.)
The important thing to realize at this point is that OpenJUMP’s core and JUMP’s core are now slightly different. That causes some problems for people like me, who want to share as much code as possible between JUMP and OpenJUMP. We want to take a plug-in for OpenJUMP and have it work in JUMP. This is a good arrangement because it allows Vivid to benefit from the work of the OpenJUMP community, and for the community to benefit from Vivid’s work. One way to avoid all this trouble with compatibility between the two programs would be to “merge the cores” of the two programs. Once this was done developers wouldn’t have to worry about problems with compatibility, they could just concentrate on creating or improving JUMP’s features.
So what’s the hold up? Why not just merge the core’s and get on with other things?
There’s a least a couple of reasons why I don’t think this is going to happen in the near future. Please remember that I’m not necessarily against merging the cores. I’d support that under the right circumstances, I just don’t see it taking place in the current situation.
To understand this you need to realize why there is an OpenJUMP in the first place. Some people that were using JUMP a long time ago decide to do what developer’s call “forking the code”. We took a copy of JUMP’s code that was being maintained by Vivid Solutions and started maintaining our own version, which we called OpenJUMP. OpenJUMP is then a “fork” of JUMP. Why would we want to do a crazy thing like fork JUMP’s code? After all, look at all the problems it causes now.
In almost all cases, forks of a program are a bad thing. This is for some of the problems I mentioned above, and for other reasons. We realized this when we chose to fork JUMP, and we decided to do it anyways. The reason for the fork is one of the reasons why I think a merge of the two cores can’t happen now.
You need to remember that Vivid Solutions, the company which develops and maintains JUMP, is a private company. They have there own goals and agenda. I’m thankful that they support our community, and that they support open source development. We need more companies like them. (If this was the case we'd be developing software in completely different ways than we are today.)
But when you boil it all down, Vivid Solutions controls JUMP. They have the final say as to what goes into JUMP’s core, and to what stays out of it. They set the agenda for JUMP development, as well as the schedule or pace of that development. When we created OpenJUMP there were numerous other forks of JUMP popping up all over the place. These forks were created for the same basic reasons:
[1] Development of JUMP by Vivid Solutions at that time had stopped or slowed greatly.
[2] Developers were frustrated with Vivid Solutions policy of integrating third-party changes and contributions back into JUMP.
A few of us decided that one fork would be a lot better than 20. So despite the drawbacks we knew would come in the future, we organized a single forked “core”. That’s basically what OpenJUMP is.
It appears that development of OpenJUMP by Vivid Solutions has picked up a bit. But remember why we forked JUMP in the first place. Development of JUMP by Vivid Solutions could slow again. I personally think the company has gotten a lot better about interacting with the JUMP community, but that could change as key employees leave and join the company.
You need to remember something else. Vivid Solutions needs to make money to pay its electric bill. (Among other bills…) We don’t pay Vivid Solutions for the time it takes to manage and interact with the OpenJUMP community. It certain situations the problem may not be that Vivid Solutions doesn’t want to integrate a contribution or change into JUMP, it may be that they don’t have the time, people, or money to accomplish it at the time.
OpenJUMP is “open” because some of these restraints to the development process have been removed. I think OpenJUMP development will be quicker and more flexible as a general rule. (We do have other challenges that Vivid Solutions does not. For example, controlling the quality of OpenJUMP’s source code with so many contributors.)
I don’t think a merge of OpenJUMP’s core and JUMP’s core is going to happen anytime soon. I don’t think Vivid Solutions has the manpower or the desire to do that at this moment. This is an important fact, because they will need to do it. They control JUMP’s core, the community doesn’t.
I’m not even sure if that is the best thing for the OpenJUMP community right now. Yes, it would alleviate or remove some development challenges. But I think that the advantages of maintaining OpenJUMP outweigh these challenges for the time being.
I think we need to work to cultivate a good relationship with Vivid Solutions, and to make sure the cores of OpenJUMP and JUMP stay as similar as possible. I will be working personally to make sure this happens, and that more of OpenJUMP’s code makes it back into JUMP. (This will happen as Vivid Solutions has time to approve and assimilate our contributions, of course. I’m already working on getting some changes to the rendering system submitted to JUMP.)
I hope this blog post will answer some questions about why we have 2 “cores”, and why this will probably remain the situation for the near future.
The Sunburned Surveyor
There has been a lot of discussion on the JPP Developer’s list about the possibility of merging the “core” of OpenJUMP and the "core" of JUMP that is maintained by Vivid Solutions. I said I would try to discuss this in a posting on my OpenJUMP Blog. First, I want to explain exactly what the “core” of OpenJUMP is. Then I want to talk about how it is different from JUMP’s “core”. Then I want to talk about why I don’t think a merge is going to happen anytime soon.
The original JUMP created by Vivid Solutions was designed to be extendable without the need to recompile the source code for the entire program. This makes it very easy for developers and users to extend the functionality of JUMP. One great thing about this system is that it allows for functionality to be quickly “plugged” and “unplugged”. (I guess that is how they get the term plug-in. Sometimes applications will use the term module or snap-in, but it basically means the same thing.) If someone has a feature you want to add to JUMP you just “plug it in”. If it turns out to be broken or doesn’t do what you want, you just “unplug it”.
A lot of modern programs are using this type of extendable design. Eclipse is a great example of a program that does this. In Eclipse “everything” is a plug-in. JUMP doesn’t take the whole plug-in design to this extreme. It has what developers like to call the “core”. These are parts of the program that are necessary for JUMP to run. These parts of the program can’t be unplugged. (At least, not without some major surgery.)
OpenJUMP has inherited this extendable architecture from the original JUMP. It also has a “core”. This core is maintained by OpenJUMP developers on the JPP CVS repository hosted at SourceForge. There are some minor, but important differences between OpenJUMP’s core, and the core of the current JUMP maintained by Vivid Solutions. For one thing, OpenJUMP’s core has been internationalized, which means that it supports languages and locales from around the world. Even as an American, I think this is pretty cool, and I hope that it something we continue to support in OpenJUMP. (I’m committed to internationalizing all of my own plug-ins for JUMP and OpenJUMP.)
The important thing to realize at this point is that OpenJUMP’s core and JUMP’s core are now slightly different. That causes some problems for people like me, who want to share as much code as possible between JUMP and OpenJUMP. We want to take a plug-in for OpenJUMP and have it work in JUMP. This is a good arrangement because it allows Vivid to benefit from the work of the OpenJUMP community, and for the community to benefit from Vivid’s work. One way to avoid all this trouble with compatibility between the two programs would be to “merge the cores” of the two programs. Once this was done developers wouldn’t have to worry about problems with compatibility, they could just concentrate on creating or improving JUMP’s features.
So what’s the hold up? Why not just merge the core’s and get on with other things?
There’s a least a couple of reasons why I don’t think this is going to happen in the near future. Please remember that I’m not necessarily against merging the cores. I’d support that under the right circumstances, I just don’t see it taking place in the current situation.
To understand this you need to realize why there is an OpenJUMP in the first place. Some people that were using JUMP a long time ago decide to do what developer’s call “forking the code”. We took a copy of JUMP’s code that was being maintained by Vivid Solutions and started maintaining our own version, which we called OpenJUMP. OpenJUMP is then a “fork” of JUMP. Why would we want to do a crazy thing like fork JUMP’s code? After all, look at all the problems it causes now.
In almost all cases, forks of a program are a bad thing. This is for some of the problems I mentioned above, and for other reasons. We realized this when we chose to fork JUMP, and we decided to do it anyways. The reason for the fork is one of the reasons why I think a merge of the two cores can’t happen now.
You need to remember that Vivid Solutions, the company which develops and maintains JUMP, is a private company. They have there own goals and agenda. I’m thankful that they support our community, and that they support open source development. We need more companies like them. (If this was the case we'd be developing software in completely different ways than we are today.)
But when you boil it all down, Vivid Solutions controls JUMP. They have the final say as to what goes into JUMP’s core, and to what stays out of it. They set the agenda for JUMP development, as well as the schedule or pace of that development. When we created OpenJUMP there were numerous other forks of JUMP popping up all over the place. These forks were created for the same basic reasons:
[1] Development of JUMP by Vivid Solutions at that time had stopped or slowed greatly.
[2] Developers were frustrated with Vivid Solutions policy of integrating third-party changes and contributions back into JUMP.
A few of us decided that one fork would be a lot better than 20. So despite the drawbacks we knew would come in the future, we organized a single forked “core”. That’s basically what OpenJUMP is.
It appears that development of OpenJUMP by Vivid Solutions has picked up a bit. But remember why we forked JUMP in the first place. Development of JUMP by Vivid Solutions could slow again. I personally think the company has gotten a lot better about interacting with the JUMP community, but that could change as key employees leave and join the company.
You need to remember something else. Vivid Solutions needs to make money to pay its electric bill. (Among other bills…) We don’t pay Vivid Solutions for the time it takes to manage and interact with the OpenJUMP community. It certain situations the problem may not be that Vivid Solutions doesn’t want to integrate a contribution or change into JUMP, it may be that they don’t have the time, people, or money to accomplish it at the time.
OpenJUMP is “open” because some of these restraints to the development process have been removed. I think OpenJUMP development will be quicker and more flexible as a general rule. (We do have other challenges that Vivid Solutions does not. For example, controlling the quality of OpenJUMP’s source code with so many contributors.)
I don’t think a merge of OpenJUMP’s core and JUMP’s core is going to happen anytime soon. I don’t think Vivid Solutions has the manpower or the desire to do that at this moment. This is an important fact, because they will need to do it. They control JUMP’s core, the community doesn’t.
I’m not even sure if that is the best thing for the OpenJUMP community right now. Yes, it would alleviate or remove some development challenges. But I think that the advantages of maintaining OpenJUMP outweigh these challenges for the time being.
I think we need to work to cultivate a good relationship with Vivid Solutions, and to make sure the cores of OpenJUMP and JUMP stay as similar as possible. I will be working personally to make sure this happens, and that more of OpenJUMP’s code makes it back into JUMP. (This will happen as Vivid Solutions has time to approve and assimilate our contributions, of course. I’m already working on getting some changes to the rendering system submitted to JUMP.)
I hope this blog post will answer some questions about why we have 2 “cores”, and why this will probably remain the situation for the near future.
The Sunburned Surveyor
Posts
