[squeak-dev] [Election 2008] More questions answered
Andrew P. Black
black at cs.pdx.edu
Wed Mar 5 08:33:26 UTC 2008
First, I have to apologize for not being on time with my election
campaigning. Too many things to do for my "day job", and some
unexpected medical visits last week ...
Before I answer the questions, let me say how excited I am that we
have such a great slate of candidates running for the board. I'm
willing to serve again because I feel that having spent a year
getting "up to speed" on the issues, I owe it to the community to
spend another year capitalizing on what I've learned. However, with
such strong candidates running, if I'm not reelected, I will be happy
that Squeak is in good hands.
Now for the questions, with thanks to Goran for assembling them.
1. Approximately, how much time do you plan on spending on Squeak
during the coming year (in any kind of unit)?
A fair bit, but focussed on my teaching and writing new chapters for
a successor to the Squeak book. That means a couple of hours per
week, which may go up to a day per week if I'm teaching with Squeak.
But that's not time that in which I can do what I want; my "free"
time is going to be limited. I don't even have time to read this
list regularly any more. I have been a pretty regular attendee at
board meetings, and will keep that up if re-elected.
2. What are in your mind the three most important issues (not
necessarily technical) we need to address in the coming year?
I think that moving forward means getting us an equivalent of Linus.
Dan Ingalls played that role for many years: he gave Squeak a
conceptual coherence. Getting to that point will require some
money, and raising money will require getting the licensing situation
cleaned-up. So I'm with Tim, Bert, Craig, Igor, Randal and others
that we have to start with licensing.
3. What is your view on fund raising and how any such collected money
should be dealt with?
As Randal says, needs must be identified before one can try to raise
money to meet them. The two main sources will be foundations and
companies. Money is out there if we can paint a vision of where we
want to go. Unfortunately, getting the image cleaned up and our
processes organized are not fundable activities. Developing a
concurrent Smalltalk, for example, might be: I mean a parallel VM and
an enhanced language with real concurrency primitives (I don't count
4. What is your view on the ongoing process of making
SqueakFoundation a not-for-profit legal entity?
Craig has done the lion's share of the work here, and deserves a lot
of the credit. He has summarized the situation nicely. We've been
pickup up a lot of downed logs and finding some creepy crawly
critters under them, and the "clean" version of Squeak may not be as
full of features as we had once hoped, but I think that we will get
5. Do you think the Team model is appropriate for organising our
efforts or should we come up with something else?
Teams are the only way that things get done. That said, the release
team has become a point of contention. The fault is not with the
team members, but with the process. It reminds me of when I worked
for Digital: one day someone observed that no one had ever managed
two releases of VMS. Sometimes the release manager quit the company,
sometimes they had a nervous breakdown, sometimes they just refused
to ever do it again. I think that one release team leader may have
even committed suicide.
XP teams avoid the stress and work of doing a release by releasing
all the time. One of my frustrations with Squeak is the enormous
amount of work required to get a fix or enhancement into the release—
and I'm not talking about the programming and the testing. So, I
think the problem is not so much with the teams, but with the task
that we ask some of the teams to undertake. If the process requires
super-human effort, we can either look for super-humans to undertake
it, or we can change the process.
6. Do you have any specific views on how the Squeak board and the
Squeak community should work together with the Squeak satellite
communities (Croquet, Seaside, Sophie, Squeakland, Scratch etc), also
referred to as "stakeholder communities"?
I see that our role is having a stable release that keeps getting
better all the time. I don't mean more features: I mean more
stability, more reliability, fewer bugs, and better programming
tools. And mechanisms that make it easy for the stakeholders to
migrate to the next, better, Squeak, rather that making things so
difficult for them that they say: "my project is based on Squeak 3.8,
and it ain't gonna move", because each time that I move, it costs me
7. The squeak.org release is our most important asset. How do you see
it evolving over the next few years?
Craig and Tim have already pointed out that the community, not the
release, is our greatest asset. Look at the discussion on squeak-
dev, and compare it with almost any other internet community! I
disagree with Tim, though: we don't need revolution. We do need to
decide where to go, but we will get there by gradual change, not by
burning the disk packs and starting over. Nevertheless, when we are
done, none of the original code may be left!
I think that my most important contribution recently has been the
work that I did with Oscar, Stéphan, Damien et al on the book "Squeak
by Example". If we are going to gain mindshare, we have to create a
path for newbies to get into Squeak. It has to be easy to start
developing, which means that the tools have to work, and that there
has to be documentation. My greatest frustrations in writing the
book were the following. First, that I didn't know what I could
assume was in the image that the reader was using! The "standard"
release didn't have most of the development tools that I needed, and
those that were there mostly didn't work. We even had trouble
amongst ourselves (the authors) deciding on which version to use, and
when to go back and revise a chapter because the image had been revised.
My second frustration was that once I found a bug — and it might be a
trivial bug, like a tool being called one thing in a menu, a
different thing in a flap, and a third thing in the code — it was
impossible for me to fix it. Documenting a system shows up bugs like
this, because you have to explain them to the reader. It's faster
and better to just fix them! But only if it's possible to release
the fix into the common code base with one click. A squeak.org
release that fixes these frustrations would make me very happy.
8. Do you have any thoughts on the current relicensing effort?
I've never been very exited about licenses, but that's because
neither I nor my employer have any money, so we aren't worth suing.
In the real world, we just have to make the relicensing happen: it
has taken almost all of the board's time over the last year, and will
take more. Kudos to Craig, who has done the lion's share.
9. How would you like Squeak to be positioned in the open source
world in year 2012?
My interest in Squeak is in propagating the Smalltalk programming
style. This would be easier if Squeak were perceived as being useful
for "real" applications. Students do program better in Squeak than
in Java, but it's hard to get them to want to try to learn Squeak,
because they think that Java is "real", and Squeak is "a toy".
Seaside is a great step in the right direction. A framework that
makes it easy to build a shrinkwrapped app would be another great
step. A framework that make Squeak a viable scripting language,
maybe combining some of the ideas from F-script with real
programmability (new classes, subclases and methods). Any of these
has the potential to turn Squeak into a better Ruby.
10. What do you see as the overall role of the board?
I think that the board should be more active in providing technical
leadership. We have had a very "hands off" approach over the last
year, focussing more on licensing. Of course, the community may not
want to follow where the board leads. That's effectively a vote of
no confidence: it means that you elect a new board.
Beyond that, the board has to raise money to make the vision real.
11. What actions would you take to promote Squeak as an environment
for professional software development?
First, a solid core with excellent development tools that don't give
you walkbacks all the time. Then, and I hate to say this, a native
windowing package for the major platforms. I think that if we want
professional developers to use Squeak produce applications for
Windows, or for MacOS, then the end product has to look and behave
like a WIndows or MacOS product. Once we have this, Squeak will get
the documentation, the tutorials, more books, more consultants, etc.,
because they will be able to make a living out of it.
That's all folks (woops, wrong cartoon).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev