Before deciding how I should do something, I like to step back and think
about why I should be deciding in the first place. In the case of this
year's election, the most basic issue is that there are three things of
great value associated with the name "Squeak":

1) the software
2) the community
3) the brand recognition

The software itself has its good points and its flaws, and it would be
nice if it could be improved. Since Squeak has always been fully open
source (the license issues didn't change that fact) anyone can change
anything about it that they like.

Community is very important to me and can easily outweigh technical
details. When I wanted to install a Unix clone on my PC back in 1994,
BSD was superior to Linux but the latter had a larger and more active
community and, as I guessed it would, this let it evolve more rapidly.
There are many very different groups that are part of the Squeak
community and any individual or group can do whatever they want. At one
point in time there were more people using the SmallLand fork of Squeak
than the official one.

And there always should be an "official" one. What the name Squeak
actually means should be decided by the community as a whole. We could
have a direct democracy and have a vote for any issue related to the
name (like I said above, any other issue can be decided by random
individuals and so they should "vote with their feet" instead), but this
would take up too much of everyone's time. An alternative is a
representative democracy where you vote for some people and then they
vote for the issues in your name. This will work well if you can either
guess how your representatives will vote on each issue (which is why I
am writing this - so people can see whether I think like they do or
not), but often you just have a general trust in your representative to
do "the right thing". This is important since discussions among the
leadership themselves or with other people in the community might make
them change their minds (see 4.0/5.0 plans this year for what I think is
a positive example of this process in action).

What kinds of issues should the leadership be deciding on? Obviously, in
 any releation to entities outside the community (creating a foundation
or associating with the SFC, hiring hosting for "official" Squeak
websites, making some deal with SugarLabs) as well as parts of the
community itself (EToys users, Croquet, Sophie, Seaside/Aida, previous
developers whose code we wanted to relicense) there should be some
person or group of people who have the authority to speak for the whole
group.

Given that the community was formed around a technical object, it is no
wonder that technical issues are often our highest priority. One option
would be for the leadership to initiate projects to improve Squeak.
Another would be for them to accept proposals and "bless" some of them.
Yet a third choice would be for them to limit themselves to selecting
some finished improvement and declare that to be the next official
Squeak.

My own preference is to have mostly the third path with some very rare
deviations into the second option, which unless I am mistaken is the
current situation. The third path has caused us problems in the past:
people hesitate to commit to some project if there is the danger that it
will be "rejected" when it is done. Adding an exception framework to
Squeak is a good example of this. Getting the last few details right in
a project takes far more work than the rest of the project and many
people feel they need official support before it is worth doing that
extra work. On the other hand, there are many wonderful plans and
half-finished projects lying around. Betting the Squeak brand on them
would have had very painful results.

Even with this far more limited role, there is a lot of room for
deciding how fast or slowly the official Squeak should evolve. In this
regard, I take backwards compatiblity very seriously but given that
older versions of Squeak continue to be available even as newer ones are
released, I don't think that radical changes should be ruled out. I am
in favor of adding Traits to Squeak and adopting the Spoon stuff, for
example. I am typing this in a Squeak 3.9 image while chatting on IRC
using a Squeak 3.8 image and developing VM stuff in a 3.10.2 one. I
still run 2.x images as needed and very rarely even 1.x ones.

Not everyone knows me, so here is a short history. I got interested in
Smalltalk when I read the famous August 1981 issue of Byte magazine and
started working on Smalltalk computers (initially with the Motorola
68000 chip) in 1984. Brazil is far from Xerox PARC, of course, so I had
at most one or two articles a year as my community. Starting in 1988 I
was able to chat with Smalltalkers around the world (first with the BIX
- Byte Information eXchange service, then with the BITNET and finally
through the Internet). When the Self dialect of Smalltalk was created I
become very interested in that and was a very active participant in that
community. Since, as Mario Wolczko said, "Self is like Smalltalk, only
more so!" I was puzzled that some Smalltalkers had such a negative
reaction to it. This was the early 1990s when most Smalltalkers worked
in financial institutions and came from Cobol backgrounds and were too
scared of C to try C++, so I just assumed that their idea of Smalltalk
was different than mine due to this.

When Self was first killed at Sun, John Maloney invited me to the new
Squeak community that was starting up. The early days were very exciting
and being familiar with Squeak as it existed in a given date didn't mean
you had a clue of what it would be like a month later. All projects slow
down considerably as they mature, of course. So a few years later it
seemed like Squeak was stuck in the same place while Slate was zooming
forward at unbelievable speed. And so on. Given how fast Squeak was
changing back in 1998 and how much energy the community had, I sent a
few emails to see what the reaction would be to adding some Self-like
features to Squeak and makes some other radical changes. I was surprised
at how negative some people were ("if I wanted to program in Self I
wouldn't be using Squeak" was expressed by several people) and certainly
didn't wish to take the community where it didn't want to go (I still
don't) and so dropped the subject. I remained a participant in the
Squeak community but worked on my own Smalltalk (until last september,
when my project became based on Squeak).

What I would like to see is a better integration between all projects
that use Squeak. I wrote above that we can count to the old images to
partly handle the needed backwards compatiblity (specially if some extra
care is put into them, like Keith's Level Playing Field efforts). On the
other hand, I am counting on Viewpoints Research to handle the radically
different future. So for "official Squeak" I want to see a middle ground
where we move nicely forward without leaving anyone behind.

Though I wrote that I don't think it is the role of the leaders accept
wild plans or half finished projects, this doesn't mean that I can't
have my own wild plans. Here is an example of something that would help
groups work together even while moving in different directions:
http://wiki.squeak.org/squeak/584

As a leader I wouldn't vote for what is just text and drawings. But I am
trying to get some funding to get this "Chunky Squeak" implemented. That
is also not the role of a leader. if/when it is actually working and can
be tested against any alternatives that bring us similar advantages,
then I would be very happy to vote for including it into the Squeak
roadmap.

Cheers,
-- Jecel