[squeak-dev] [Election 2008] More answers collected!

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 Semaphores!)

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 there.

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 bigtime.

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.