As part of my recent babbling on collaborative development of OpenJUMP I repeatedly emphasized how I thought we should incorporate improvements and new features from JUMP “brands” like SkyJUMP and Kosmo into OpenJUMP. I said I thought we should do this as plug-ins rather than changes to OpenJUMP's core. I got the feeling that some of the other developers disagreed with me.
I wanted to take some time to explain my point of view, and give some reasons why I believe sticking to a pluggable design is very important. Please remember what follows is only my opinion, and is not intended to be critical or demeaning to the developers that feel differently than I do. :]
I was first introduced to the concept of a plug-in when I began using JUMP. However, I didn't really understand the concept of a plug-in until I started using Eclipse. I even bought an early book on Eclipse development, which took me a lot farther down the “Eclipse Plug-In” road than I ever intended to go. This journey did have some benefits, and I came to appreciate the real value of a plug-in system in modern software applications. After working with programs like JUMP and Eclipse, I found that I began to yearn for a plug-in system in all of the programs I was using on a daily basis. The best part of this learning process was that I realized JUMP's plug-in system was the best I had seen, even better than the one that is used in Eclipse. JUMP's plug-in sysem was simple but still allowed the plug-in developer to access the guts of the program without recompilation.
Still, JUMP's plug-in system has its limitations. I ran into some of those limitations myself when designing or thinking about the possible design for OpenJUMP plug-ins. That's part of what led to the hatching of Plan “A” for supporting plug-in dependency. I think these limitations of the plug-in system might be partly responsible for the proliferation of the different JUMP “brands”. If you can't implement your new change or new feature as a plug-in you have to modify the core, and it's a lot easy to just maintain your own fork of the code than it is to bother getting your change approved by the other OpenJUMP developers.
Although this “fork-the-core” approach to implementing new features and changes may be better in the short run, in the long run I think it is foolish. Some fragmentation is inevitable in an open source project, but now doubt everyone recognizes the less fragmentation the better off everyone is.
We shouldn't implement new features in OpenJUMP by making modifications and additions to the core unless it is absolutely necessary. Neglecting this type of policy leads to the “fat and happy” program that has every feature you need. (Not to mention it can lead to some pretty heated discussions when one developer's “essential” feature is another developer's “totally unnecessary” feature.) If people want a “fat and happy” GIS program they should pick up an ESRI ArcGIS license. At $2500 an extension they can be ransomed for all the extra functionality they need in a couple of bloated downloads.
We don't have ESRI's budget. We don't have their resources. We don't have there army of developers. We can't compete with “fat and happy”.
I think we can compete if we stick to developing an OpenJUMP that is “lean and mean”.
The OpenJUMP core should offer only the bare essentials of a functioning GIS program. Everything else should be packaged as a plug-in. This will keep our total program size smaller, and will give the user the opportunity to choose the functionality they need, not the functionality we think they need. This system will also force us to develop and maintain a plug-in system that really works well, because if it doesn't work well we will know about it. This will give OpenJUMP an edge over other similar programs that don't offer a plug-in system, or offer a plug-in system that functions poorly. You might summarize it this way, "If a user want's the all-in-one tool for GIS they'll choose a commercial program like ESRI's ArcGIS. If they're looking for a small and fast desktop GIS that they can easily customize for they're needs, they'll go with OpenJUMP."
A good plug-in system is important for another reason. It allows the “curious” developer or user to add functionality to the program in small steps, learning about the program code “as-they-go”. Trying to understand all of OpenJUMP's code, and to then trying to get it building and running successfully would be a great challenge to the novice developer. Plug-ins are the “training wheels” that take this type of novice developer and gives them the knowledge and confidence they need to make larger contributions and improvements.
If you want to add a new feature to OpenJUMP, do it with a plug-in. If it seems like your new feature can't be implemented as a plug-in, take another look. Pretend for a minute that you didn't have access to the source code in the core, and still had to come up with an implementation. If it still seems like your new feature can't be implemented as a plug-in, think about changing the core. But don't change the core to implement your new feature. Change the core so that your new feature can be implemented as a plug-in when you are done.
(As an example, I wanted to see if I could add a new renderer to OpenJUMP. This wasn't possible without modifying OpenJUMP's core. Instead of modifying the core to “hardwire” my renderer into OpenJUMP I found a way to make renderers “pluggable”. This meant the next guy would be able to implement his new renderer as a plug-in, instead of hardwiring his addition into the core as well.)
Remember, we want “lean and mean”, not “fat and happy”. If you don't beleive me, just ask any of those pretty girls at the beach. They'll tell you what they prefer. :]
The Sunburned Surveyor
I wanted to take some time to explain my point of view, and give some reasons why I believe sticking to a pluggable design is very important. Please remember what follows is only my opinion, and is not intended to be critical or demeaning to the developers that feel differently than I do. :]
I was first introduced to the concept of a plug-in when I began using JUMP. However, I didn't really understand the concept of a plug-in until I started using Eclipse. I even bought an early book on Eclipse development, which took me a lot farther down the “Eclipse Plug-In” road than I ever intended to go. This journey did have some benefits, and I came to appreciate the real value of a plug-in system in modern software applications. After working with programs like JUMP and Eclipse, I found that I began to yearn for a plug-in system in all of the programs I was using on a daily basis. The best part of this learning process was that I realized JUMP's plug-in system was the best I had seen, even better than the one that is used in Eclipse. JUMP's plug-in sysem was simple but still allowed the plug-in developer to access the guts of the program without recompilation.
Still, JUMP's plug-in system has its limitations. I ran into some of those limitations myself when designing or thinking about the possible design for OpenJUMP plug-ins. That's part of what led to the hatching of Plan “A” for supporting plug-in dependency. I think these limitations of the plug-in system might be partly responsible for the proliferation of the different JUMP “brands”. If you can't implement your new change or new feature as a plug-in you have to modify the core, and it's a lot easy to just maintain your own fork of the code than it is to bother getting your change approved by the other OpenJUMP developers.
Although this “fork-the-core” approach to implementing new features and changes may be better in the short run, in the long run I think it is foolish. Some fragmentation is inevitable in an open source project, but now doubt everyone recognizes the less fragmentation the better off everyone is.
We shouldn't implement new features in OpenJUMP by making modifications and additions to the core unless it is absolutely necessary. Neglecting this type of policy leads to the “fat and happy” program that has every feature you need. (Not to mention it can lead to some pretty heated discussions when one developer's “essential” feature is another developer's “totally unnecessary” feature.) If people want a “fat and happy” GIS program they should pick up an ESRI ArcGIS license. At $2500 an extension they can be ransomed for all the extra functionality they need in a couple of bloated downloads.
We don't have ESRI's budget. We don't have their resources. We don't have there army of developers. We can't compete with “fat and happy”.
I think we can compete if we stick to developing an OpenJUMP that is “lean and mean”.
The OpenJUMP core should offer only the bare essentials of a functioning GIS program. Everything else should be packaged as a plug-in. This will keep our total program size smaller, and will give the user the opportunity to choose the functionality they need, not the functionality we think they need. This system will also force us to develop and maintain a plug-in system that really works well, because if it doesn't work well we will know about it. This will give OpenJUMP an edge over other similar programs that don't offer a plug-in system, or offer a plug-in system that functions poorly. You might summarize it this way, "If a user want's the all-in-one tool for GIS they'll choose a commercial program like ESRI's ArcGIS. If they're looking for a small and fast desktop GIS that they can easily customize for they're needs, they'll go with OpenJUMP."
A good plug-in system is important for another reason. It allows the “curious” developer or user to add functionality to the program in small steps, learning about the program code “as-they-go”. Trying to understand all of OpenJUMP's code, and to then trying to get it building and running successfully would be a great challenge to the novice developer. Plug-ins are the “training wheels” that take this type of novice developer and gives them the knowledge and confidence they need to make larger contributions and improvements.
If you want to add a new feature to OpenJUMP, do it with a plug-in. If it seems like your new feature can't be implemented as a plug-in, take another look. Pretend for a minute that you didn't have access to the source code in the core, and still had to come up with an implementation. If it still seems like your new feature can't be implemented as a plug-in, think about changing the core. But don't change the core to implement your new feature. Change the core so that your new feature can be implemented as a plug-in when you are done.
(As an example, I wanted to see if I could add a new renderer to OpenJUMP. This wasn't possible without modifying OpenJUMP's core. Instead of modifying the core to “hardwire” my renderer into OpenJUMP I found a way to make renderers “pluggable”. This meant the next guy would be able to implement his new renderer as a plug-in, instead of hardwiring his addition into the core as well.)
Remember, we want “lean and mean”, not “fat and happy”. If you don't beleive me, just ask any of those pretty girls at the beach. They'll tell you what they prefer. :]
The Sunburned Surveyor
Posts
