In a thread in comp.lang.smalltalk, Eliot answers why Store was developed:

While Jim Robertson's financial info on ENVY and VisualWorks is fine that's not the reason that Glenn Krasner as VP of engineering and I as technical lead had for ditching ENVY.

First,. ENVY essentially dictated the architecture of the development environment, including things like what constituted a valid package. Once a new version of VW would come out we would have to wait about 6 months for the corresponding ENVY to come out. That gave VAST a 6 month time-to-market advantage and meant that whatever ParcPlace engineering did to enhance the programming experience was essentially irrelevant because it would be overlaid by whatever ENVY deemed appropriate.

When we came to do VisualWorks 3.0, which introduced Parcels, this was intolerable. First parcels had features ENVY couldn't model:

Parcels do "partial loading". One can maintain a large logical component in a single parcel and load it in a system that is missing some prerequisites. Any code that can't be loaded is held back until subsequent code loads make it installable.

For example let's imagine you build a distributed programming system that allows helper methods on classes to control distribution semantics for different kinds of objects. Let's say you have several loadable applications such as a multi-user drawing editor and a dungeons and dragons game which you make distributed with the system. With parcels you can put all distribution code, including helper methods, in a single file. If you try and load it into a base system that is missing the drawing editor and the d-n-d game the parcel will still load. The extension methods and subclasses get squirreled- away for a subsequent load. When you load the drawing editor the distribution methods and subclasses get added.

In ENVY and other code loading systems in Smalltalk and other languages you must subdivide the distribution package into a code set of facilities and separate fragments.

This is a real advantage when you try and break up a system into components. Partial loading means you don't have to visit all other components splitting them up whenever you extract some base functionality into a component.

Essentially it avoids a polynomial explosion in the number of components in a componentised system.

Parcels support overrides, the ability to redefine classes and/or methods on load. So a parcel can override an existing base method, which is essential if you want to add or modify kernel behaviour on load. The overridden code is remembered so that if you unload a parcel the system reverts to its previous state, allowing one to unload code, which allows one more freedom in trying components out.

We needed the facilities to make 3.0 a componentised system within the limited resources we have and these features have proved their usefulness over the years, but ENVY could not support them and we would have had to wait for years for it to do so. So we provided Store as a team programming tool that supported the new parcel concepts and facilities.

Second, we wanted to bring programmers a rich VisualWorks programming experience immediately, and not wait for ENVY to get around to doing the work. We believed (and still believe) we can do a better job than ENVY in the context of VisualWorks. By moving away from Store we have gained control of the programming environment and you can see the improvements made in recent years. Vassili would have had his hands tightly tied had we not moved out from under ENVY.

Third, Parcels allow one to add single methods, including methods defining types or external calls in external interfaces. ENVY requires an entire ExternalInterface class to be in a single package.

Fourth, and quite importantly, ENVY's model is that one is always attached to the repository. Store allows one to detach, developing in ones' own image, reconnecting to the repository when appropriate. great for plane trips.

Fifth, ENVY's versioning scheme is old-fashioned, based on ascending version numbers. Store separates the version tree from code quality. There is no implication in Store that a later version is more correct. In Store one has "blessing levels" which declare whether a given version is production quality, development quality, blue sky, etc, etc. So components can go through natural cycles of development, productization, experimentation, development and productization for version 2, etc.

So we had very strong compelling technical reasons that were the real driving factor. We had to risk pissing-off customers who were wedded to ENVY and even risk losing some of our most important accounts. But in then end VisualWorks is much better because of it.

Add in the business reasons mentioned here, and it all makes a lot of sense - and doesn't involve politics.