First a bit of metadiscussion. You're the second one here hammering on
'we should this', 'we should that'.

In the context of open source projects, I really always say - *you*
should scratch *your* own itches. Period. No-one should do anything.
The community should scratch collective itches, and as far as I can
see supporting business squeak users isn't high on the list :-)

On 10/5/05, Giovanni Giorgi <giovanni.giorgi at siforge.org> wrote:
> We have two very different type of users: Squeak Developers and Business
> Squeak Developers.

I doubt it. I'm a Business Squeak Developer at daytime. A 6 figure
project. I pick a Squeak environment and stick with it during the
project, but it doesn't need to be a special morphic-less or whatever
Squeak.

> The first must have a very powerful and advanced image ("a alpha core"
> if you like)

And I also doubt that business users don't want powerful and advanced
stuff. It depends on their needs. Some Smalltalk projects may get by
with an MVC UI, some need Croquet. You choose and arrange for your own
support - do it yourself, rely on the community, or hire people.


> The illusion of  "3.9a, 3.9b, 3.9g" must be faced soon with two
> different branch, or this problem will rise again in
> the next few years and we will not find no-one to develop squeak.
>
Funny that I see more and more people making money with Squeak. And it
looks like academic use is on the rise as well.

> Ruby,perl,PHP, zope, Linux, python and even GNU Smalltalk  have a better
> policy than us.
>
<cough>. Linux has huge bloat and stability problems; Python is
constantly making vague, unfounded, and backwards-incompatible
changes. I will not even start about PHP's grand detour towards a
halfway usable object model, and GNU Smalltalk is a *lot* smaller than
Squeak, so quite a bit easier to maintain. Perl just adds every
feature under the sun (but, I admit, they have something with CPAN),
Zope has seen complete rewrites, so that maybe leaves Ruby but that's
a newcomer, let's see how development and support go in a couple of
years (15 or so. Wonder whether Ruby will still be around by then ;)).

Anyway, I think you are inventing problems that simply don't exist.
Which is good, because if you're business-oriented inventing problems
usually is a good way to make money. I've thought about launching a
commercially-supported Squeak, and yes, it would lag quite a bit
behind the bleeding edge. But that doesn't mean that we, as a
community, are doing anything wrong here by moving forward all the
time... Moving forward is one of the essences of Squeak, and if that
causes problems (I don't see them), we typically have the ability to
create simple tools that make these problems go away (like
incompatible changes that come with a rewrite-script to roll forward
all code in the image).

Businesses don't want stability in versions. They want to reduce risk.
A typical way to reduce risk is not to move, because as long as you
stand still nothing happens, but businesses are discovering that this
is not always the optimal strategy. If you'd stood still, you'd be
developing websites with Swiki or SSP instead of Seaside. I figure
that even with the regular compatibility issues we've seen in Seaside,
it'd been a sound business decision to be an early adopter and just
live with the occasional day of hacking to adapt your app to newer
versions of Seaside.

Smart businesses don't mix up means and ends...