A New Community Development Model


Edit: Updated 11/4/2009 regarding Unit Testing.

In the board meeting today we had a nice discussion about how to move forward with a new community development model for Squeak. Here is an overview of the model and what will happen next:

The goals

The goal of this process is to get rid of as many hurdles as possible in the contribution process. We are trying to enable the community at large to improve Squeak, the core of the system and its supporting libraries.

To do this, we are adopting processes that have been shown to work in commercial settings: The use of Monticello as the primary source code management system, free access for the developers to the main repositories, an incremental update process for both developers and users of Squeak.


We will be setting up the following Monticello repositories:

* http://source.squeak.org/trunk

This will be the main repository for ongoing development. New code will be committed here, the repository will be world-readable and writable for the core-dev group.

* http://source.squeak.org/tests

This is the main repository for unit tests. It will be world-readable AND world-writable. We encourage everyone to write more tests and commit them, improve the existing tests and bring in entirely new test suites.

* http://source.squeak.org/inbox

This repository is intended as dropbox. It’s usage will depend on what we make it out to be. The idea is to have it world-readable and world-writable, too.


In accordance with our goal of joining the Free Software Conservancy, all code submitted to the repositories must be licensed under the MIT license.

Developer access

The board will manage developer access to the repositories at source.squeak.org. In the next days we’ll send out a few “you are pre-approved” messages to people who have proven to be active developers in the past in order to invite them to become a core developer.

If you can’t wait and absolutely want to be in on the action you can register yourself at http://source.squeak.org/ and send message to the board asking for access but most of the regular contributors (you know who you are) will be invited anyway.

Rules of Engagement

If you have used Monticello in projects with more than two developers in the past you already know the drill. If not, here are some useful guidelines:

* Merge often. In particular when you pick up work and right before you intend to commit.

* Exercise caution. This is a running system and breaking it needlessly is generally frowned upon.

* Restrain yourself. Getting developer access doesn’t mean you are free to put in every pet extension you always wanted to have without discussion.

* If in doubt, ask. This is the corollary to the restrain yourself rule. You’re not under pressure to ship a product, so you have the time to send a note saying “hey, I’m planning to fix this old issue and it may have some side effect here or there. Anyone having a problem with that?”

>>> I’ll add a Squeak-dev exception here: Any response from any non-developer can be entirely ignored in this context.

* You break it, you fix it. If you change something you are generally expected to take care of the consequences, though there are some exceptions. If in doubt, ask 😉

* Do good and talk about it. When you’re done with whatever it is you’ve been working on let people know about it. It can be as short as a note to Squeak-dev saying “hey, some of you might care that I’ve fixed the long standing bug with xyz. Update and enjoy”

* Unit Testing. Unit tests are an essential part of maintaining the reliability of our releases. New units tests are always welcome. Keep in mind that a unit test should take as little time to run as possible.  Maintaining the reliability of Squeak is always easier when the tests are all green: if you break something the appearance of a new failure or error is immediately obvious and the cause is more easily found. To that end fixes for failures or errors are extremely valuable and please avoid submitting changes that cause new failures or errors.

I think that roughly covers it. Basically you will be working with a dozen (hopefully more) other developers on Squeak and we’ll all have to learn how to make this work successfully.


We are in the process of developing an update process that can work seamlessly with Monticello. An early experiment is described here. We are evaluating alternative approaches, in particular the use of Installer since there are some shortcomings when using Monticello Configurations.

Existing Work

It is important to note that we will be trying very hard not to lose any work that is being done for Squeak 3.11. We will start with the package set that was used in the 3.10 release, then we will issue package updates to cover the missing delta up until 3.10.2. Following which we will reissue any changes done for 3.11 into the repositories.

10 Responses to “A New Community Development Model”

  1. BackOrder Says:

    It’s an exciting news, Andreas! Thank you.

    Would it be possible to not show emails of registered members for people not logged in http://source.squeak.org/ ?

  2. Damien Cassou Says:

    > * Merge often. In particular when you pick up work and right before you intend to commit.

    I think you will have better results by commiting before, then merging and finaly commit again. That way, your fix is independent of previous fixes. Moreover, it is easier to distinguish your work from others work.

  3. Ken Causey Says:

    Note that there is a lot more discussion going on in the squeak-dev mailing list. Archive of the thread starts at


  4. SOB lays an egg – what will emerge? « The Weekly Squeak Says:

    […] 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 […]

  5. Ken Causey Says:

    Note that this has been edited to clarify that all submissions must be licensed under the MIT license


  6. Meeting Report for 9/16/2009 « The Squeak Oversight Board Blog Says:

    […] the promotion and visibility of Squeak, particularly the recent activity surrounding the trunk and New Community Development Model work.  Related to that we are working on arranging another appearance for some of the Squeak […]

  7. New Development Model, two months on. « The Weekly Squeak Says:

    […] September, 2009 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 […]

  8. Meeting Report for 10/21/2009 « The Squeak Oversight Board Blog Says:

    […] unit testing in Trunk and the increasing level of failures and errors.  Ken Causey will update the New Community Development Model document with a basic policy regarding unit tests and will investigate providing a roughly weekly […]

  9. Meeting Report for 11/4/2009 « The Squeak Oversight Board Blog Says:

    […] started today’s meeting discussing an addition to the New Community Development Model regarding Unit Testing which will be added to the document shortly.  We also discussed the future […]

  10. Bleeding Edge Squeak (aka The Trunk) « BloBlo Says:

    […] Tags: Smalltalk, Squeak trackback Since last year the development of Squeak is done following the New Community Development Model, which was published by the Squeak Oversight […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: