Ship it with Squeak

Bob Arning arning at charm.net
Mon Jun 26 00:32:56 UTC 2000


Hi Paul,

On Sun, 25 Jun 2000 18:15:45 -0400 Paul Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
>* Having reliable VMs for Linux (which?), Windows (NT, 2000, 95, 98),
>and Mac (PPC, Which OS Revs?)

As far as the Mac goes, I haven't seen a difference here or on the list between any of the recent OS versions.

>* Replacing the fonts (to meet license obligations)

Fonts are simple bitmaps. If you have others that you feel free to use, the changes are not significant.

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

I'm not sure the notion of forking Squeak is a necessary one. For a projct of the timescale (4 months) you have mentioned, I would envision this approach:

1. Select a reasonably stable starting point (release 2.8 if you were to do it today, e.g.). You would be unlikely to change compilers or libraries in the midst of such a short project. Consider Squeak in the same light.
2. Develop a list of things in 2.8 that you don't want or need and build something to remove those (ala #majorShrink).
3. Develop basic enhancements (a different GUI, e.g.) that you want and build those.
4. Develop your application based on items 1 through 3.
5. Monitor the updates to the general release of Squeak for anything that might be useful. Much of this could be ignored if you have ditched the pertinent part of the system or if the improvement would not measurably affect your product. If you find something useful, fold it into step 3.

>* 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).

It would be interesting in seeing some specific examples of what's hard to do with Morphic. Granted, there's a lot there, but much of it simply does not come into play unless you want it to.

>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? 

I don't think so.

>* Am I wildly underestimating the work involved?

Other than the 4 months to port your application from Delphi, I haven't seen an estimate. Or, if 4 months is the whole magilla, it will depend on how demanding you are in the removal of the last (million, thousand, dozen) bytes of unnecessary code. It will also depend on how exacting you are in other requirements.

>* What am I forgetting?

If I were to hazard a guess, it would be which parts of Squeak could be jettisoned from the perspective of potential participants. Some would want MVC to go and Morphic retained. Some might want just the opposite. Others would want yet a different combination.

>* Is it likely this fork would just get ignored even if I maintained it
>in the face of continual evolution along a main line?

I'm tempted to say, "Build it and they will come", but I won't. 

>* 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?

Some would and some wouldn't. If your messages only improved the rendering of plants in 3D, I suspect you'd hear some howls. If they helped 3D rendering in general, your contributions might be well received.

>* Would others contribute substantially to this deployment platform --
>since its needs might differ from the mainline of Squeak development?

I suspect that would vary from item to item. There are those who might help remove dependencies on Morphic without being inherently interested in your total package. Others, similarly, might help with the deployment issue or improving the handling of mouse events.

>* 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).

I guess those are conflicts we should be so lucky to have!

>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? 

Yes.

Cheers,
Bob





More information about the Squeak-dev mailing list