[Squeakfoundation]Discussion on vision!
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Tue Sep 23 14:42:23 CEST 2003
Hi fellow Guides and all others!
NOTE TO ALL: Please do NOT crosspost this post to squeak-dev. It is
meant as a seed for discussion and if stuff like this gets immediately
crossposted to squeak-dev then it will make it much harder to use this
list as an open discussion channel for the Guides.
Once upon a time (the squeak-dev thread called "[IMPORTANT]Concrete
promised that we Guides should come up with something like a Vision.
Now I have taken some time to actually formulate *my personal* Vision of
Squeak and our future.
So this is a "seed for discussion" and is (I repeat) *my personal
thoughts* on the matter.
Let's throw some thoughts around and try to condense this into something
(AsbestSuit on: self) wear
PS. This was about the Vision. A totally different chapter is the Guides
There are three things I want us to do in that respect:
1. Get some Vision out there. The stuff here was my best first shot.
2. Get some form of decision process in place.
3. Rotate at least one Guide, maybe more.
My personal Vision on Squeak
To me *all* the different directions, views and visions that live inside
the Squeak community have great value. I want Squeak to be a platform,
call it whatever you like - that is as versatile and universally useful
as possible. The vision outlined here may though be perceived by some as
too vague or general. But I truly believe that many of the great virtues
of Squeak and its community come from this diversity.
Currently I use Squeak for my email, my private experiments in
programming, our Swikis in our company, as the development environment
of choice for my web apps and other projects that don't need "business
UIs" and sometimes as a presentation tool.
But I also "use" Squeak for personal fulfillment - the Squeak community
is packed with ideas, creativity and interesting people from all over
the world. Following the squeak-dev list is hard work, but it pays off
by teaching me things almost every day. I also enjoy being a part of the
community, getting to know people, collaborating and simply solving
A recent example of this is that Daniel Vainsencher and Andreas Raab
visited Stockholm for a few days and to meet Squeakers in the real world
is always inspiring.
During this visit Daniel and I discussed the Guides "model", the
community and how it works and much more. We didn't solve the issues of
course - but for me personally it did clear my head about *my* vision
for Squeak. It turns out that I actually can explain this vision using
#1 The universal tool
I want Squeak - the tool - to improve in any and all areas possible.
Better performance, more ports, more and better libraries, more
possibilities for user interfaces, more implemented standards (typically
communication) and so on. I want to be able to choose Squeak as my tool
of choice for *any* development task.
This also includes evolving Squeak the language. I am in favour of
looking at for example Traits or implementing new and modern Collection
classes. ANSI compliance is good - but IMHO it should never be allowed
to stand in the way of the evolution of Squeak. Smalltalk is a dead
language, if we consider the standard at least - Squeak on the other
hand is very much alive. Being somewhat compatible with other Smalltalks
is also a nice thing - but again, I don't think we should let it stand
in our way
into the future.
So as I said in the introduction above - I don't want to point at any
specific area to be more important than any other. The more diverse
people and interests we can satisfy the more interesting solutions and
cross-domain ideas we may find.
BUT... for the tool Squeak to scale as a universal tool and platform -
we need better infrastructure. And we are getting there slowly.
SqueakMap has been a success - very much so to my personal satisfaction.
Now we need to get the next version up as soon as possible, and that is
still my first priority.
But we also need other things - one thing is a Test server, and I happen
to know that some people are working on that. A Test server could
automatically run unit test suites for different packages and
combinations of packages - and thus act as the big guardian of
robustness and quality. After having seen Daniel Vainsencher describe
how rules about dependencies in our code actually can be expressed as
Unit tests (the package MudPie) a Test Server suddenly sounds like a
really great addition to our infrastructure. (Note: Just saw Daniel's
posts on this subject on the list)
Another such thing that is missing is a big cross-reference server - and
AFAIK nobody is yet working on that. SqueakMap2 will of course be a
fundamental prerequisite for such a beast. Imagine a server that knows
about all the package releases on SqueakMap and can reliably answer
questions like for example "all senders of..." and "all implementors
of..." *globally* for all known packages.
In short - we need better tools. The above two servers are just pieces
of the puzzle. There are other tools we need too - like Monticello
servers for team development on packages, some bug report tool for
keeping track of bugs grouped by package and so on.
Some people think that the current trend with partitioning Squeak into
packages with appointed maintainers/stewards is making it harder to
maintain Squeak as a coherent environment. Yes, the new scheme demands
more of our infrastructure - but I am convinced that this move is
healthy and will make Squeak scale and be able to sustain a much higher
speed of evolution through parallellism.
But this current direction also demands something from all of us - we
learn to delegate and *trust* other Squeakers to take decisions in the
areas. This is something we need to work on and we Guides should take a
in and try to finally establish different areas of responsibility using
previouslly outlined concept Stewards.
Finally I want to note the importance of all the other projects going on
the moment - KCP, MCP, m17n, Squeakland and many others come to mind.
All these projects make Squeak better.
#2 Collaboration and communication
Currently Squeakers collaborate using a mailinglist, a number of Swikis,
an ftp site, SqueakMap and to very little extent IRC. We do publish
Projects for people to play with but that is still just a way of
publishing a document - not much interaction going on there between
Maybe I missed a thing or two but essentially IMHO we aren't using
Squeak itself to its full potential. I want us to start thinking about
building infrastructure for tying the Squeak community together in more
real time. There have been numerous ideas in this respect and I hope to
see more of it.
Squeak is a great platform for groundbreaking new ways to collaborate
and communicate. We are also in a unique situation since when we are
using Squeak we are also *running it* - we are living inside the object
space. So we can easily add various collaborative mechanisms to actually
make Squeak stand out *even more* compared to other development
SqueakMap2 will actually lay the base for such mechanisms and ideas.
How? It extends the map to not only keeping track of packages, but also
keeping track of Squeakers. Eventually we will actually be able to track
a single element of Squeak, say a method - to an SM package and thus to
one or more Squeakers.
Having such a model of the community itself is the first step towards
more advanced communication than the mailinglist. Let the brainstorming
When all words have been said this is in fact the most important thing
for me. I want to have fun. Squeak is fun. The community is full of fun
ideas and fun people. I wouldn't be in the Squeak community if it wasn't
as fun as it is. :-)
One early peer reviewer of this text mentioned that Fun should be #1 and
not #3. But I saved it for last to make it a better finish. :)
Many people view Squeak as a vehicle for a cause - it may be to build a
new 3D environment (Croquet) to create new possibilites for
communication. It may be to create and spur a new way of learning (eToys
All these ideas are very interesting, inspiring and important. But the
thing that makes them that - to me at least - is that they are fun. It
is *great* fun to see kids explore, laugh and enjoy the buzzing
fulfillment of creating something on their own. We also know that kids
learn best through playing - having fun.
It is also great fun to play around in 3D and imagining how such an
awesome environment like Croquet can change the way we build systems and
"places" on the net.
Again, when I talked to Daniel when he was here we realized that we
really could have more... "fun events" in the community.
Daniel and I have loosely been cooking up one idea for such an event
that would take place during a full weekend, 48 hours. Exactly what it
would entail is the topic of a different post - but it is just pure fun.
So my final word is - whatever we do to move Squeak into the future -
let's make sure we have fun doing it. :)
More information about the Squeakfoundation