Pauls missive has inspired me to put down some thoughts that have been 
percolating for a while:

I have been watching this Squeak list for about 6 months, and was hoping to 
see real evidence that we could consider Squeak for our next generation 
product (see winetech.com).  We currently have software written in a 
combination of Visual Basic, C++, and the Microsoft Jet Engine for the 
Access database.   Squeak initially looked promising as a platform for the 
future, but I am gradually and  sadly reaching the conclusion that it is 
may never be usable for software like ours.  Here are the issues:

1. No current orientation toward application deployment at Squeak Central.
2. No stable GUI that provides critical tools for manipulating large slabs 
of data (particularly Grids that show multiple records and Rich Text boxes 
that display and edit text while using multiple fonts and 
colors).  Although I realize that many on this mailing list regard these as 
old-fashioned and boring, they are still necessary for many purposes.  We 
would like to use Squeak's wonderful capabilities in addition to these 
tools, but we cannot start development without them.
3. No database ( We currently have about 50,000 records across two 
databases, taking up about 100 megabytes).  We need fast access from a 
variety of different indexes.
4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
5. Poor documentation.

While it looks like Squeak has tremendous pluses (Innovative, open source, 
great functionality, machine independence) , these seem to primarily 
benefit teaching and research, and not actual application developers like 
ourselves.

I admire Paul's effort to develop a deployable Squeak application, and 
would consider any success he has as great evidence that we may be able to 
use Squeak also.

Sincerely
Douglas Flower
Douglas at winetech.com


==========================
(From Paul Fernhout)
At 06:15 PM 6/25/00 -0400, you wrote:
>All-
>
>I am trying to determine the extent to which it is feasible to
>create and maintain an application deployment kit for Squeak, and how
>much others would be willing to cooperate in doing so.
>
>While we're not committing to anything yet, here is a note to sound out
>interest.
>
>At the moment we (my wife and I) are seriously considering making
>version 2.0 of our PlantStudio (Botanical Illustration Software that
>produces 3D models of plants) product in Squeak so we can also have Mac
>and Linux versions. I personally would do the bulk of the conversion
>work from Delphi. The effort might possibly start in a couple of months.
>We would expect that project to take four months or so.
>
>However, I think Squeak as it is needs several changes before it can be
>used to deploy a "commercial" application to an internet audience (in
>this case, of graphic professionals). I'm trying to decide if these can
>be fixed with a reasonable amount of effort that still lets me finish
>the application in four months.
>
>To me, the most important changes to do for deployment are:
>* Making Squeak event driven at the VM level to eliminate those
>occasional weird mouse drags
>* Creating a "lockable" GUI w/ common data entry widgets
>* Producing a small footprint image with all "clutter" removed
>* Doing odds and ends related to stability and testing
>* Having reliable VMs for Linux (which?), Windows (NT, 2000, 95, 98),
>and Mac (PPC, Which OS Revs?)
>* Developing an install process for all platforms (might be platform
>specific; maybe could live with ZIP file install)
>* Replacing the fonts (to meet license obligations)
>
>Things I want but could live without:
>* Single EXE
>* Namespaces
>* Image buildable from scratch
>* Consistent exception handling
>* GUI builder
>* One-click deployment building
>
>Things I don't need for my application (but others might want, or I
>might want in the future):
>* Printing
>* Sound
>* Reliable sockets
>* HTML viewing
>* Reentrancy
>* Better development tools and version control
>
>I haven't done much with 2.8 so it may be improving in these areas. It
>certainly sounds like pluggable primitives have come a long way.
>
>I think Squeak would need significant work to get it into shape for
>shipping "shrink-wrap" quality applications. I would like to do this
>without forking Squeak, but I don't know if this is possible. I think it
>would require maintaining a seperate line of development for a while.
>
>This isn't specifically a dig at SqueakC (well maybe a little :-) , but
>I think supporting a version of Squeak intended for shipping (ANSI)
>Smalltalk apps in a boring but predictable GUI is a fairly different
>activity and set of priorities than supporting a version for
>experimenting (Pink vs. Blue planes). SqueakC may want a Pink (Blue?)
>version or not, but it is clear (to me) that that a version of Squeak to
>support applications is not where their priority is right now. I don't
>fault them for this. But I do see a void which has remained since the
>first OOPSLA '97 Squeak BOF where half the people in the room wanted an
>experimental version and half wanted a stable version. The reality as I
>see it is that the half wanting a stable version of Squeak for apps or
>utilities mostly don't stick with Squeak. (Obviously there are some
>noteable exceptions.) But the reality (for me) is that even when a
>client doesn't care if I use Squeak for a simple utility, I know Python
>or C++ or Java gives them what they want faster. I'd like to change that
>situation.
>
>My last posts about this issue to the Squeak list were in February 2000
>(just before the NASDAQ meltdown) when I proposed a Squeak/Pro of
>"SqueakHat". Several people wrote to me saying they or their company
>had considered something similar or might consider participating in this
>somehow. Some offered the possibility of funding; some offered to work
>for pay or as partners. I decided not to pursue that proposal at the
>time in part because of a concern of tearing either the community or my
>relationship to it apart. The Squeak list is a precious resource and
>things can often get ugly when money changes hands.
>
>So here is something I am thinking about (but not yet committing to)
>which I hope will fit well with the Squeak community and open source
>philosophy:
>* Putting up a forked version of Squeak which is specifically for
>deploying utilities and applications for the PC, Linux, and Mac.
>This might be done on SourceForge.
>* Coordinating the minimal changes (mostly removals!) required to make
>this a stable deployment platform from a "make it reliable for the end
>user" point of view.
>* Possibly jettisoning much of Morphic and maybe also MVC and having a
>hybrid GUI framework perhaps with parts of both useful for typical
>commercial GUI type tasks (text box, combo box, button, image, etc.).
>This GUI might have a "game-like" look. This is probably the most
>controversial part, and I could reconsider this if another approach
>using Morphic somehow was less work and looked nice and was stable for
>an application. I like what Morphic wants to be; I just think the first
>try needs to be refactored or redone for simplicity and stability in an
>application. This GUI part is the highest risk part of the effort (after
>ensuring reliable VMs on multiple platforms).
>* Putting all this under the Squeak license (or similar compatible open
>source licenses for add-ons determined by their contributor).
>* I as a tool-kit user would build on top of this deployment kit for
>applications for sale.
>
>The question to the list is:
>* Am I out of my mind to think of using Squeak at this point to make a
>GUI-based application for sale?
>* Am I wildly underestimating the work involved?
>* What am I forgetting?
>* Is it likely this fork would just get ignored even if I maintained it
>in the face of continual evolution along a main line?
>* If this is a good idea, what sort of cooperative framework makes sense
>to maintain a deployable version of Squeak for multiple platforms?
>* Would people on this list be upset if this effort used this mailing
>list for coordination, posting of fixes, etc. given that they would
>pertain to an essentially forked version?
>* Would others contribute substantially to this deployment platform --
>since its needs might differ from the mainline of Squeak development?
>
>The last is most important to me because I don't have the current Mac or
>Linux set-up to support these platforms without a big investment in
>time and new software and equipment. Maintaining the image and codebase
>on one system is easy; testing VMs on multiple platforms and
>configurations is hard. It is not clear to me that the current VMs would
>be appropriate for deployment. At the very least changes to make them
>even driven would be needed.
>
>Let me be clear:
>* We're not asking for help developing the application, and the
>application would itself most likely not be open source, and that
>creates a bit of a conflict between where the deployment kit stops and
>our application begins (e.g. is our 3D turtle part of the kit?)
>* We have no funds to pay anyone for their contributions or their time.
>* We have no interest in selling Smalltalk development tools or the
>deployment kit.
>* We might release other applications on top of this framework -- like
>our two other products, and perhaps later something related to an email
>client, news reader, web client, and knowledgebase.
>* By coordinating such an effort, we might gain a commercial advantage
>over others in publicity, which would be valuable in gaining consulting
>contracts helping others transition their applications to Squeak. This
>has the potential to create conflicts (hopefully friendly rivalries).
>* We probably won't make any money from this unless PlantStudio ships
>and people like it enough to register it (i.e. "tip" us), or consulting
>comes along related to helping others deploy apps with the Squeak
>toolkit.
>
>Does this sound like the beginnings of an approach that would produce a
>stable version of Squeak for commercial apps and utilities, with no
>money changing hands, and without posing a big threat to the beautiful
>thing that is the Squeak community?
>
>I'd also appreciate frank and informed commentary on why what I propose
>won't work (for technical, effort, or social reasons) if that is your
>belief. Alternate suggestions or pointers to work in progress
>(especially on a VM with events) would be appreciated.  Replies to the
>list would generally be preferred so all may comment on them.
>
>-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