I agree.
It also looks like many people on this list agree with the following principles:
1. Squeak should be open and usable by everyone, with base class/VM changes submitted for everyone's benefit.
2. A modular Squeak, built up from a core functionality using images or plugins.
3. A packaging utility which strips unnecessary classes from the distribution and wraps some installation functionality around a shipping product.
I would like to add the following principles:
a) Fully documented classes. If we are taking the time to create the class/method, surely we can take a few minutes to describe its purpose.
b) The ability to lock your image when you are distributing a product, to prevent reverse engineering of code.
*** Please note: this is only for a production image. This does not apply to the development image and contributions made to it.
c) The ability to combine the VM and the image file into one executable for shipping a product. This may help with b).
d) Leveraging the "update from server" functionality as a way to update customers with new features or patches.
My personal position is this:
1. I would like to see that Squeak becomes a viable tool for creating software products for sale. An open source version of Smalltalk is a powerful competitor to Java, C++ and commercial Smalltalk.
2. As open source, we would still freely contribute new functionality to the base class or VM.
3. Right now, today, I still find more functionality in public domain versions of Java/IDE than Squeak. And yet, Squeak is a better environment for development.
4. It appears that Squeak suffers from class bloat and bolt-on functionality through categories. I saw this start to happen with Java after version 1.0.
My spirit is with Squeak, but my wallet is still with Java. This won't change until Squeak incorporates the changes outlined above, to become a superior language to Java, C++ and others.
Thanks,
John.
Paul Fernhout pdfernhout@kurtz-fernhout.com on 06/29/2000 10:17:47 AM
Please respond to squeak@cs.uiuc.edu To: squeak@cs.uiuc.edu cc: Subject: Belling the cat of complexity (was: Ship it with Squeak)
Squeakers-
There is an old story of how a bunch of mice get together and a have a long debate about what to do about the cat who they live in terror of. The cat is so quiet it can sneak up on a mouse before it knows it and devour it. After long deliberation they hit upon a great idea -- if the cat had a bell around its neck, they would all hear when it was coming and could scurry to safety in advance. The mice relax, all satisfied, until one of them asks, "Well, who is now going to bell the cat?"
Squeak complexity in 2.8 has become a complex cat from the simple kitten complexity of 1.13(?) in 1996. Back then, Dan Ingalls wrote on 10 Nov 1996 those prescient words: "The Squeak team has an interest in doing the world's simplest application construction framework, but I suspect that we will get sucked up with enough other things that this won't happen in the next two months (but who knows...)."
Squeak 2.8's complexity is now quiet (in terms of walkbacks) and stealthy (in terms of growing between releases without a complaint). And the complexity could be deadly. Witness the recent issue Stefan raised about some Squeak fonts possibly violating a Microsoft EULA. The question should never even arise of the legal integrity of the core release. We might as well just leap right into those jaws of complexity.
I appreciate all the comments on "Ship it with Squeak". There were many, many useful suggestions and comments. I have read them all with great interest. Les Tyrrell put the issues very eloquently, and makes me realize this issue for shipping is really best put as "managing complexity in Squeak to reduce the risk of unexpected behavior in an application to an acceptable level".
The complexity in Squeak comes in two areas: code issues and license issues. The complexity of the code mudball has been discussed at length. The complexity of the license issue comes up occasionally, and Stefan's point about licenses is an example. Using software without a clear "title" is like buying a house without a "title search" -- someone can always come along later and make a claim against the house. People can always make claims, the issue is that a title search (and related insurance) reduces the risk to the point to reasonable levels.
I would recommend looking at the (older) Python submission guidelines for some ideas on what to ask from contributors: http://www.python.org/patches/bugrelease.html http://www.python.org/patches/wetsign.html These are basically statements of originality and disclaimers of contributor's liability. If all contributions to Squeak came with such disclaimers, the licensing concerns would be greatly reduced. The legality of contributions flows through from contributors to CNRI to official legal releases. Now that Guido has moved to the private Pythonlabs, things have changed to: http://www.python.org/patches/ and I don't know the exact status of what is signed to ensure the contributions legal. Who would replace CNRI here in the Squeak case (if anyone) is an issue.
A mouse probably can't bell a cat. It's just too hard. But maybe, just maybe, a mouse could bell a kitten.
I brainstormed some with Doug Flower about steps to bootstrap Squeak towards usability in business. What came out of that was a sense that a Squeak useable in many of the same areas of Perl might be a good start. He and many others who know Smalltalk have an immediate business need for such sorts of activity. Such a system would be useful if it only was able to read, write, and process text files. And enhanced version might handle sockets and other text streams. Ideally, this system would have an end-user GUI useable for setting parameters for such operations (in dialog fashion), but that is less essential since parameter files could handle this.
The reason why this application area is interesting is that it is of real business need, but it does not have all the deployment issues that shipping applications does. A Squeak operating in this area can have more rough edges and still be very useful. People are already doing this with Squeak, and might see the benefit to a smaller size system they could leave with clients or carry on a floppy. So that is what I think makes a good first step towards belling the cat of complexity -- trying to first bell the kitten of file handling utility applications.
How should I proceed on this? Here is one approach, although obviously it may have problems and another might be better.
Think of this as a "harvesting" process. The Squeak community has generated much useful work -- the time is ripe to harvest it into a stable, legal platform. My first impulse is actually to go all the way back to the first Squeak release (or possibly the last one done at Apple if it is pure Apple code with just minor patches). Then, that version can be reintegrated with later patches that people have made, as long as the contributors are willing to agree to something like the Python disclaimers. Note, these disclaimers might be rewritten to be just general disclaimers, not specific to giving special rights to a company. The disclaimers might also put rights under a Squeak-like license, not as broad a license as Python, depending on what people on this list have to say.
One reasons for going all the way back to Apple code is that frankly, I don't know what license Disney changes are really under. Unlike the GPL, the Squeak license names a company. I don't think just including the Apple license with a distribution really says anything about the licensing of your changes. I raised this issue a year or two ago on this list and don't recall getting a decent answer. That uncertainty is probably acceptable for playing around but makes business use harder to accept or promote.
[Optional: Of course if one goes back that far (to the orginal release), perhaps one might ask Apple to change the license to one more like Python's so Squeak could be more easily used in embedded systems with specialized VMs. I had a problem with this in terms of legal approaval -- an awkward workaround is to use pipes to communicate from the VM to services, but ultimately the real workaround was to use Python with a less restricitive license. Python shows you don't need a draconian license to get people who want to contribute to contribute. The value to Apple is simply in making a system that helps keep the Mac on a level playing field with all other systems. Also, then Squeak would finally be compatible with GPL'd code.]
Such a system would have as its first priority modularizing the image. Such an effort might include tools to assist this process, such as the wonderful effort by the 4th Estate.
The effort to manage complexity would take precedence over bug fixes, GUIs, event handling, or anything else. It would also include building the image from scratch -- where every last byte was known and accounted for.
Once this old Squeak was modularized, then fixes would be made purely from the standpoint of stability. These would focus primarily on stability of utility related code, and secondarily on stability of development tools. Code would need to be added to handle common text manipulations, including XML input and output. GUI changes would be a minimum needed to control file manipulation.
Later, after this stable base existed, one could add all sorts of bells and whistles -- in a modular fashion.
I'm sure people will say this would be a lot of work -- perhaps too much for one person. You might be right. Frankly, I still may personally decide that working in another platform instead might be easier, or might say being cross-platform has too high a cost for the rewards. In that case, putting a Squeak-like cross-platform GUI underpinning to Python might be another choice, because I can control the code I write -- I can't control what others do with their license. So it may make sense in the end to just start instead from a system with a clear legal standing and go from there adding Squeak like features. I love Smalltalk -- I'd rather make Squeak work. It is just that the effort does seem substantial.
It's easy to say "just do it and it's done" when your salary and your employees' salaries are paid for with other people's money, where those deep pocketed people actually expect you to do unexpected things and trust you to accomplish them whatever it costs. It's also easy to say "just do it and it's done" when there are no legal complexities to worry about -- e.g. you're not in the risk situation where you do it and it's not done because you legally can't ship it.
Also, reprising Squeak's evolution Squeak from the start would entail bothering a lot of people on the list to submit patches they already submitted, and even trying to get people making major contributions to sign some sort of actual paper document (exact form to be decided). This certainly isn't fun work for an introvert. I just don't see another way to proceed that handles issues related to the code and legal complexities of producing a minimal Squeak useable for things like XML processing or rewriting text files. There most likely needs to be a legal audit trail of the legitimacy of submissions, and that trail must be guarded by someone who would not let stuff like Microsoft fonts in no matter what the EULA says.
The Squeak development process so far has been great in terms of generating code, but not so great in terms of managing complexity of that code or the surrounding legal issues. So maybe now has come the time to harvest the results of all that productive effort? And as any Object Tech Center person would say, Object harvesting is itself a time-consuming process.
In summary: If we can't even get together a simple and reliable version of Squeak without a substantial GUI for text file handling which does not have substantial legal issues, then there is no hope for a version of Squeak for shipping cross-platform apps with GUIs. If a utility version of Squeak that is legally sound can be produced, it might serve to bootstrap a more substantial system which could be used to deploy applications. And, hopefully, every time complexity increased in that release, a little bell would ring and we'd know what was coming.
More comments appreciated. Thanks again for those who responded to the last post.
-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com
---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
A modular Squeak, built up from a core functionality using images or plugins.
A packaging utility which strips unnecessary classes from the distribution
and wraps some installation functionality around a shipping product.
Purely in a spirit of minor nitpicking in order to try to keep things simple, I must point out that a decent solution to 2) makes 3) unneccessary.
squeak-dev@lists.squeakfoundation.org