Others have answered you quite well.  Let me just add one thing:

"Enrico Bertini" <enrico_bertini at yahoo.it> wrote:
> 4)      If a company want to begin to develop heavy commercial =
> applications in Squeak, therefore investing money and resources, what is =
> the future that awaits them? Should they develop the lacking =
> modules/parts from themselves? Should they build a new development =
> environment based on Squeak core technologies? Should they wait that the =
> Squeak becomes more mature? Or what?

If you are trying to get products out the door, then do not take on
major Squeak-improvement projects.  Language improvements have a
tendency to be much trickier than you'd expect.  I have chatted
personally with one person whose development group went down the rats
hole of trying to make their own fancy code management system, and they
spent a lot of time doing a poor job.  Their system was actually worse,
on the whole, than what Squeak comes with.

Because of this risk, I would suggest that your primariy development
process simply uses Squeak on its own terms.  You will be just fine,
especially considering all the forums that are available for talking to
existing users.

You can still do Squeak improvements, which I'll call more generically
infrastructure improvements. After all, improved infrastructure can give
you multiplicitave improvements in overall performance, so they are very
tempting to work on!  Just be sure to relegate them to a secondary,
parallel development process.  That way you greatly lower the cost of
failure, while still getting to reap the benefits of success.  Also, it
gives you a nice management subprocess that is good to have anyway.

I'm not sure what particular things would be best to work on first.  Do
be sure to allocate time for studying what is already present, though,
and for studying what existing Squeak improvement projects are
happening.  Those two items get a lot more bang for time than does
in-house development.


Lex