Smalltalk is a wonderfully open environment. Some or all of the source code is available to developers, and can be changed to do almost anything. From an experimental point of view this is wonderful. We can “burn the disk packs” and invent our own new language and environment. Unfortunately, the people who are paying us may have more prosaic goals in mind.

Our changes may need to be reviewed every time there's an upgrade or a patch to the basic class libraries. Inadequately tested extensions can be more trouble than they're worth, and managers of large projects with many developers are often reluctant to have every developer soup up his or her personal environment.

If we make changes to base classes, they may conflict with third-party products, with other teams in the organization, or even with customers if we're distributing development tools. System changes also scatter code around. If we modify a class in Kernel, then our system's configuration map will have to include our special version of Kernel. Before long we're loading dozens of applications, each containing only a few lines of our code. These all have to be managed by Library Supervisor, complicating maintenance.

On the other hand, changing system code offers very significant advantages. Sometimes the system is wrong. It may have bugs, or be missing functionality that requires changes to existing classes. Power-users like to extend their environments because it makes them more productive.