It has been two months since the Squeak Oversight Board first put forward their “New Community Development Model”. At the time the proposal caused a lot of heated debate on the squeak-dev mailing list, with concerns being expressed that similar efforts in the past had had little lasting impact, and had caused great frustration for those pushing those earlier efforts.

The motives of the Board were to “get rid of as many hurdles as possible in the contribution process [and]¬† to enable the community at large to improve Squeak, the core of the system and its supporting libraries”.

So, two months down the line, how’s it doing?

If sheer volume is any criterion, it looks like a great success with over 500 packages uploaded as patches to 3.10.2 and over 40,000 downloads from the trunk (see bottom of the linked page for up to date statistics).

The results of all this activity are available to use and test in the daily updated image published at http://ftp.squeak.org/trunk/ (needs a recent VM). If you want to contribute, you can add new patches at http://source.squeak.org/inbox/, or ask one of the current developers for access to the developers repository at http://source.squeak.org/trunk.

If you just want to get an idea of what’s going on, check out the commit logs that are getting posted to the squeak-dev mailing list, and to the #squeak irc channel on freenode.

phoenix

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.

Lukas Renggli is looking for willing volunteers to complete work on a project that he has been working on. OB-Tools is a package that aims to build the remaining development tools on top of OmniBrowser. It currently includes working versions of the Inspector, Object Explorer, Debugger, Process Browser, File Browser, Transcript and Workspace. It’s already progressed to the point where Damien Cassou is planning to include it in his Squeak Developer Images. It’s also being used by¬†Gwenael Casaccio in his Google Summer of Code project Squeak GTK.

Lukas asks: “I wonder if anybody would be willing to take over the effort? I don’t have much time to work on it and I think it would be a pity to let the code rot. The core is relatively stable, and there are only very few things missing compared to the original morphic tools. It would be cool to add tests similar to what we have for OB-Standard.”