[squeak-dev] How to beat Andreas at his own game

Colin Putney cputney at wiresong.ca
Mon Jan 25 04:16:29 UTC 2010


Hi all,

With all the sound and fury we've had lately, I thought I'd make a suggestion for Keith, or anyone else who isn't happy with the way the Squeak community has been evolving lately.

If you think about it, the Board really has power over one thing: the name "Squeak." Even that's mostly a social convention than anything - control of the squeak-related domain names and the moral authority that comes from having been elected by the community. All Andreas did was say, "hey everybody, I've set up a repository that you can commit to, and I plan to follow process X for releasing images based on what you submit."

If you don't like process X, the way to persuade the community not to follow Andreas is to provide an alternative. Keith, it sounds to me like you've got clear ideas about what a better alternative would be, and have the tools realize that vision. To that end, I suggest the following steps:

* Pick a name for your project. "StableSqueak" has been used already, but what about "SolidSqueak?" From a marketing perspective, you want to emphasize your commitment to compatibility.

* Create a web site. No need for anything fancy, just put a page up at solidsqueak.org that explains the process you espouse. You've posted numerous explanations to this list, so it should be trivial to pull together something coherent. 

* Provide some infrastructure. This depends a bit on your process, but from what I understand you'll want an issue tracker. Maybe the existing Mantis database will serve, but you could create your own. Maybe you want a mailing list. All these things can be had for free from various places - lots of folks have found Google Code projects to work out well for Smalltalk, even though we don't really need their source-code repository.

* Make releases. If I understand correctly, there's already a lot of work done, and Bob can automatically build images based on various versions of Squeak and incorporating a whole raft of fixes from Mantis. That's a great place to start. 

* Eat the dog food. Make your own work available through this process, both as an example of how it should be done and to work out the kinks.

* Talk it up. When you produce new release images, post announcements on this list, make blog posts touting the fixes and new features that are included. Announce improvements to the process too - new releases of Bob or Sake, new integration proceedures, new base images supported etc.

* Provide support. As folks become interested in what you're doing, they'll want to try things out. Answer questions about how to participate, encourage experimentation and be receptive to new ideas. Above all, try to help people use your system to achieve their own goals. After that they'll be happy to contribute back to the community you've created. 

If you think this sounds like a lot of work, well, yeah, it is. Leadership and community-building *is* a lot of work. Andreas has demonstrated that he's willing to work hard at it. The Seaside guys are doing that work, and so is the Pharo team. You've already put a lot of work into building out your tool set and articulating your vision, so you've obviously got what it takes. As the benefits of your process start to become clear, more and more of the community will follow your lead, and the trunk will languish, just as other failed initiatives have done over the years. You may find yourself elected to the board, and SolidSqueak folded back into Squeak proper, or simply that SolidSqueak is so successful that you don't really care what goes on with the board and their moribund process. Either way, you win. 

Colin






More information about the Squeak-dev mailing list