Squeak as a Commons

Posted 20 Feb 2005 by lexspoon (Master)

Before we can organize Squeak, we must answer: "What is Squeak?" This article defines Squeak as a commons where many individual projects collaborate. The article sketches some of the subgroups using Squeak, and proposes an organizational structure based around giving representation to all of these subgroups.

"...I thought that whatever happened there would be some kind of mouse in the future of this system." - Alan Kay, on the Squeak Mailing List on 2002/03/14

Squeak as a Commons

What is this "Squeak" thing we are all using? Before we can organize the community, we need to define what, exactly, "Squeak" is, as Mark Guzdial described on the mailing list on 2004/12/12. If we decide we are a research platform, then we need to abandon legacy code and keep the codebase easy to change. If we decide we are an omniuser computing group, then the tools need to all be comprehensible to a general population and thus we need to avoid things like namespaces entirely.

These are not our only choices. Instead of picking one of these visions, we could define ourselves as a commons for many different interests. We could think of ourselves more like an operating system distribution, than like a well-defined application. We could think of ourselves like Debian or FreeBSD, supporting a very wide variety of installations. That is, we could view ourselves as one of Eric Raymond's bazaars.

Don't be dissuaded because this view is too prosaic. Yes, it is true that this vision makes Squeak drift like a caravan instead of gallop like a horseman. It means that the only answer to, "What are you guys?" is, "Mu. We just are." Still, the individual projects will be just as exciting as the are today. Croquet will continue to rethink distributed objects. The Squeakland group will continue to find ways that even children can program. If we view Squeak as a commons, then it is only the definition itself which is prosaic. It simply means that you look to the individual projects for the really exciting material -- and if we do things carefully, there will be even more of these exciting projects than there are today.

Besides, there is no pragmatic alternative. A great many people already consider themselves "Squeak" users. SqueakMap has over 500 packages listed, and SqueakSource has over 200 project areas. If we want to support all of these existing users, then what else can we do but treat Squeak as a common resource they share?

The rest of this article looks at what happens if we view Squeak as a commons. We need to arrange Squeak itself to support all of these people. We need to set up our organization, so that they are all represented, and so that Squeak drifts in a direction compatible with their needs.

Groups

I won't claim to have a full handle on who is using Squeak. We must start trying to get a handle on it, however, in order to make an effective organization to support them. Consider this section a starting point -- and if you are left off, speak up quickly!

Mutual Benefits

Before moving on, let me stress that these groups have many synergies with each other. It is not merely a drag that each group must tolerate the others. Each group is in fact helpful to the others. It is in each Squeakers self-interest to have the others around. Here are a few examples.

First, everyone benefits when general software developers contribute new libraries or improve existing ones. One of the reasons Squeak is a good research testbed is because there are many such libraries already, and thus many research ideas can be implemented with a small amount of code. It is to all of our benefit to have a variety of quality libraries readily available.

Everyone also benefits from having Squeak be good for computer media. Forget presentation software where you make a cute animation that looks like your cool software; if you do your presentation is Squeak, you can include the software itself into your presentation. If you get an unexpected question from the audience, you can show them what your software does even though you didn't make an animation for it in advance. It is to our benefit that computer media people are around giving us examples and telling us how to improve the authoring tools.

We also benefit when we have new users continually appearing. The groups using Squeak to teach OO languages, will provide continuous pressure to keep Squeak being a comprehensible system. If it takes years to learn Squeak, then we will have few new users, and our community will be weaker for it. It is to our benefit to have people reminding us to keep things simple.

Finally, we all benefit when researchers produce ever-better tools. The media authors are much better off using EToys than something uninspired like Lingo. The software developers benefit whenever the researchers find a new, improved mechanism for defining components or laying out GUI's. In short, it's good to not only have a good system today, but to have people around making an ever better system for tomorrow.

Can We Do It?

Of course, a big question is whether all of these groups can really cooperate. As two examples, Georgia Tech is using Squeak 3.5 right now, and the Scratch Project is using squeak 2.7. For either of these groups to use the current stable release, 3.7, would be a major porting effort.

To my knowledge, there are no technical barriers to all of these groups working together, and there is not a major amount of work that needs to be done to get a future version of Squeak back on track to supporting these guys. We should go for it, and see how well we can do. Squeak is extremely late bound, and should be able to support a wider variety of users than it does right now. We'll need to keep a few specific goals in mind, though, in order for this to happen.

Goals for a Commons

Specifically, here are a few goals we should set for the community in order for the wide user base to be able to collaborate.

First, we need to support shoppers at the bazaar. There should be a way for users to pick and choose among the code that others have produced. SqueakMap allows people to find code packages that exists, but with more work, people could limit their attention to reliable packages which can be expected to just work.

Second, we need to arrange for shared code to improve in quality over time. This is software engineering. We need to have testing, and we need to have project leaders who choose carefully when to put in bug fixes, and when to break compatibility in order to improve something. For example, half-completed refactorings need to be eliminated entirely; they are a worst-of-both-worlds solution that reduce reliability while also reducing the code's general design.

Third, the base image (or images) need to allow a wide variety of projects to be added. There are many specific examples that have already received attention, such as the ability to load alternative code browsers. There is work ongoing on other problems, such as the ability to write code that is agnostic about MVC, Morphic, or Tweak. This kind of work needs to continue.

Organization Bodies

Finally, let me sketch an organization that makes sense for Squeak as a Commons, based on the above discussion. There are many details for such a thing, but let me outline the offices and bodies that would form it.

We should have a president. That person acts as a spokesman, as a point of contact, and as a leader who can suggest priorities. For our group this post should be kept fairly weak. Squeak-as-commons is a slowly drifting community which does not need the ability to make major decisions on the spur of the moment.

We should have a board to give a voice to all of the groups. One possible organization, would be to use the above list of groups, and add one voting member and one or two non-voting members to the board for each group. Most real decisions for Squeak would be decided by the board, even if they are proposed by the president. It may be that we want to require unanimous agreement for most issues. This is unlikely to cause difficulties in our generally agreeble community, and it reduces some of the political nastiness of deciding how, exactly, to divide up the community into subgroups. (Though I don't see a way to avoid this entirely.)

Especially in the first few years, it looks like there will be a lot of work on various kinds of infrastructure. This work will probably happen in some kind of task groups. We should think in advance how we want to organize them. Surely, the final work needs to be approved by the board, but there are many other issues we may want to think about. For example: what kinds of issues can a group be formed around? Who is in these groups--should we have a standard mechanism for calling for interested volunteers? Should there be any rules about staying transparent as the group progresses, or is it okay to work this out on a case by case basis?

Finally, we must decide how the general community will be organized. In particular: who is a voting member, and how does the voting system work?

Different groups should have different rules for membership. The software developers might want to say that "membership" means you have fixed 1 bug and posted 10 lines of code to SqueakMap. The non-professional programmers might draw the line by saying that members requires posting one project to Bob's SuperSwiki which uses the scripting system. And so on. The threshold should be inclusive enough that most real enthusiasts are included, but restrictive enough that others in the group will feel like new members are one of them. Keep in mind that many people will be members of multiple groups. That may sound funny at first, but do we really want to have people decide which kind of Squeaker they are?

The voting system probably needs to consider the size of the subgroups. People in bigger subgroups, have a smaller vote. Othrewise, a large group can overwhelm a small group. This approach seems perfect, except for two issues. First, perhaps larger groups should have more influence, even if we don't let them have an overwhelming influence. Second, we need to watch out for the tendency of subgroups to define ridiculously high standards for membership. Probably, we want a voting system that gives some advantage to having a large membership in a subgroup, but that does not go so far as to give every member an equally influential vote. There are many issues in how to set up a good voting system, so let me leave that can of worms aside for now.

What other offices and bodies should we be thinking about, for a commons-style organization? Should we have a treasurer? A secretary? Do we need a vice-president?

Other Groups

Before moving too far, we should surely take a close look at what other commons-style organizations are doing. Debian is organized like this, I know, but I don't think they have any concept of subgroups as I've defined them in this post. On the other hand, they have a mature way for defining voting-level membership (their "new mainainer process"), and they have developed public key infrastructure and voting software to support them.

What else should we be looking at? There must be a bunch of larger commons-style open source projects at this point that we could mimick.

[ Home | Articles | Login/Account | People | Projects ]