Those of you who read the squeak-dev mailing list will know that the list is currently going through the annual frenzy of discussion about the nature and direction of Squeak, including much to-and-fro over such topics as: the original vision of the founders of Squeak; the tangled relationship between Etoys and the rest of the Squeak environment and community; the reasons behind the Pharo project and how much its goals really differ from those of Squeak; whether children should be locked in the nursery or allowed to roam freely into every room of the house; and much more. If you have time (and some light body armour), it’s well worth reading through the hundreds of emails that have been written which explore and interpret much of the history and philosophy of Squeak.

This discussion has motivated the Squeak Oversight Board to look at one topic that caused much debate: how to manage the development of Squeak. Driven by a concern that there are many hurdles that discourage wide-spread participation in the contribution process, the Board have put forward a new community development model that they hope will “enable the community at large to improve Squeak, the core of the system and its supporting libraries”.

Based on processes that have been shown to work in commercial settings, the Board’s model includes the use of Monticello as the primary source code management system, free access for the developers to the main repositories (trunk, tests, and inbox) and an incremental update process for both developers and users of Squeak.

Obviously, such a change has sparked off its own debate, and important questions are being hammered out on the squeak dev mailing list. If you care about the health of the Squeak environment, its future direction, and the future support for your own favourite applications, this is a key moment for you to understand and contribute to the discussion which is continuing on the squeak-dev mailing list (see archives), on irc, and on the Board’s blog.