Over on the ESUG mailing list [UPDATE: interestingly, the discussion goes on on the squeak-dev mailing list], somebody complains about “Cincom killing VSE”, a Smalltalk IDE called Visual Smalltalk Enterprise that has been officially discontinued for a very long time now.
The original poster makes it very clear that he is frustrated about the fact that Cincom is not developing VSE any further and charges “big” for fixes. There are, however, quite a few points to consider about this whole VSE affair:
- Cincom doesn’t own all the rights on the product, so it is a big risk to invest in any work on it
- The legal situation is probably complicated enough to make it impossible to open source VSE
- Cincom now has three Smalltalk products on the market, all of which are somewhat different and need to be maintained. From a business stand point, there might be very strong arguments against maintaining a fourth one
VSE has been in this state for many years now (more than 10, to be exact), and the product is still around. I know a few companies who still use it for production systems that are not particularly small or unimportant. In fact these are systems supporting their core business. There still are teams working on new features for systems that are built in an IDE that has not received any updates for more than a decade.
I’m afraid a discussion about open-sourcing VSE and persuading the owners of the IP to give it away will probably not solve any problems. Even if the IP owners have changed their minds in the last few years, there still would have to be a community to actually take the tool and modernize it. So what would be needed would either be a new vendor who invests money into VSE (if the open source license would allow this) and bring it back in shape or a community of people who work on VSE in their spare time. I personally think that even a community will most likely not be able to achieve more than bug fixes. If you are an open source type of guy and want to work in Smalltalk, you’ll probably be deep into Squeak or Pharo or GNU Smalltalk already.
So how likely is an open source community for VSE?
Well, you never know.
But I guess it is also a good idea for VSE users to think about alternatives. There are Smalltalk IDEs around that offer a lot more functionality and are being maintained, both commercial and open source. Some even offer tools that have their roots in VSE (like WindowBuilder and WidgetKit). This might help in porting quite a lot (Yes, I am thinking about VA Smalltalk here – combined with a WindowBuilder translation kit that Instantiations offers. VA even offers native widgets just like VSE – even if it could admittedly be modernized).
ObjectArts and Lesser seem to be working on a Smalltalk environment that runs VSE code seemlessly. I haven’t seen it, so I cannot really comment on it. I am also very sure that Cincom is more than happy to help you get up and running on VisualWorks or ObjectStudio (which also offers native GUIs, but also for today’s Windows versions).
There even are companies offering porting services from Smalltalk IDEs to other languages or to other Smalltalk IDEs. I have seen a system ported from VSE to VAST this way and would not recommend going that way, because your code ends up being neither fully VSE style, nor really at home in VAST. Such tools add some kind of emulation layer to the new system that pretends to the old code that it’s still running where it came from. It works, but it also causes lots of problems.
If your system needs to be maintained into the future, make it a first class citizen of the new environment, even if it means quite some manual work. It will behave strange in many ways otherwise. With today’s tools like the Refactoring Browser and its Rewrite Engine, you can automate a lot.
You also have to be cautios when rewriting a system: you will never really just do a rewrite. You will always add new or replace existing functionality. So it’s better to learn the new environment and not pretend to still be in the old one, because adding more and more functionality on top of your emulation layer will decouple you from the product. You want to adapt Seaside? You better make sure your emulation layer is not messing things up. You want the full power of modern GUI elements using a new framework? First get rid of your VSE style GUI code. The list goes on. Another example: Does it make sense to port your OR-Mapping Framework over to the new environment, just to save the effort of porting to GLORP, for example? Well, I guess the answer is a clear, sounding NO!
What will surely help in a porting effort is that most VSE projects do have quite a few very experienced Smalltalkers that will be able to work in the new environment pretty fast.
I am curious how the discussion on the ESUG mailing list continues, but I guess it won’t get anywhere.
Coming back to the post on the mailing list, I think it somewhat misses the point: Cincom is not killing VSE slowly. They are not killing anything, especially not slowly. It has been as dead as it is right now for over ten years and it was not Cincom who killed it. It was ObjectShare. Cincom does what it is allowed to, namely support VSE customers in running it, but they never made any promises to develop it further or anything.