[squeak-dev] What is Forking Squeak
Locked
[squeak-dev] What is Forking Squeak
 
|
Hello Everyone, This is not quite the same thread so I thought I’d
start a new one. Squeak is alive and well and in better shape then even I
could have imagined. Yes it looks forking disorganized but it is in no way
foundering. I see tremendous progress with Igor and Eliot working on the VM. I
see fantastic progress with Andreas, Brad, Josh, Howard, Greg, and David at
Qwaq on Croquet, plus Julian et al. with Cobalt. There is fantastic work going
on with Philippe, Lukas, and Avi with If that is not progress I don’t know what is. The
only things missing in my opinion are Tim (vacation is over time to come back!),
I want to see more success with Sophie, Plopp and Scratch and the licensing
issue is hard but I see hard work going into it which is great. What is needed to move forward? I’ve given this some
thought and I’ve come to the conclusion that Andreas and Avi were right.
We need to play well with others. We need to be able to integrate Apache,
OpenSSL, Ruby, PHP and Python. The solutions to today’s problems are not
only solved with Squeak. I think we need to learn to live with this distributed
development and learn to play well with each other. Once we learn the lessons
of integrating our own code we can apply those lessons to integrating with others.
In that line I think the work with Installer, MC2, Delta Streams, SqueakMap,
and Spoon are all on the right track. Something will eventually tie us and other
platforms too back together. It may be a strange time but it is a great time for Squeak!
I would think that Randal called it correctly this was the year of Squeak and
it has been a terrific success. We should all be proud, not of one fork but of
all of them. We are still one community and we are a strong one thanks to the
terrific efforts of Ken, Göran, Edgar, Keith, and
Mathew. Plus there is great work being done by everyone I didn’t
mention! Ok I have to get back to work now. Ron Teitelbaum |
Re: [squeak-dev] What is Forking Squeak
|
|
On Tue, Dec 9, 2008 at 7:24 AM, Ron Teitelbaum <[hidden email]> wrote:
> ndreas and Avi were right. We need to play well > with others. We need to be able to integrate Apache, OpenSSL, Ruby, PHP and > Python. +1 |
[squeak-dev] Re: What is Forking Squeak
|
|
In reply to this post by Ron Teitelbaum
Where I found Squeak is dramatically failing is at the core level.
The list you have been writing is from projects at the periphery of Squeak. All those project are forks of Squeak, and each fork is the symptom of a difficulty for cooperation at the core level. I don't know why, I just see as all of you the symptom. The result is diluted energy, duplication of effort, incompatibilities, all the badness you got from fork. Try to imagine each Python based projects as a Python fork, you will hardly saw that as proof of success. More like a proof of failure. I think most of the problem come from the legacy of Squeak. Was Squeak designed to be a plate forme to develop on top of it other software? I don't think so. More like a great toy but it hardly scales when you want to do serious things. Then of course the complete lack of leadership in the Squeak community does not help to aggregate... Frankly I am suprised Squeak is still alive, is it? But in fact it does not matter as there are many forks out there. |
Re: [squeak-dev] Re: What is Forking Squeak
|
|
2008/12/10 Hilaire Fernandes <[hidden email]>:
> Where I found Squeak is dramatically failing is at the core level. > The list you have been writing is from projects at the periphery of Squeak. > All those project are forks of Squeak, and each fork is the symptom of a > difficulty for cooperation at the core level. I don't know why, I just see > as all of you the symptom. > > The result is diluted energy, duplication of effort, incompatibilities, all > the badness you got from fork. > > Try to imagine each Python based projects as a Python fork, you will hardly > saw that as proof of success. More like a proof of failure. > > I think most of the problem come from the legacy of Squeak. Was Squeak > designed to be a plate forme to develop on top of it other software? I don't > think so. More like a great toy but it hardly scales when you want to do > serious things. Then of course the complete lack of leadership in the > Squeak community does not help to aggregate... > > Frankly I am suprised Squeak is still alive, is it? But in fact it does not > matter as there are many forks out there. > > +1 :) That's why i think 3.11 team does right job. We don't need just a yet-another-prebuilt-image, because it again will lead to another fork (for those who don't see it - look at 3.8-3.10 fate). We need tools for building images and integrate fixes/new/custom stuff easily. Also, i think we should focus on making easy to plug-in / easy to plug-out code with a little restriction(s) on kernel. While its easy to say, hard to do - people who tried to refactor a code to remove some global from use know what i mean. :) I dreaming, to have image where i can load a compiler into image as separate package, same for morphic & other stuff. -- Best regards, Igor Stasenko AKA sig. |
[squeak-dev] Re: What is Forking Squeak
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Igor Stasenko a écrit : > +1 :) > > That's why i think 3.11 team does right job. I am tempted to think more is needed. I mean the key of success is when the projects at the periphery, especially the big one like Seaside, Etoys, Croquet, Pinesoft, Sophie are capable of aggregating energy to build together the least common denominator. I fell only those projects do have enough knowledge and energy to build the promised land: I guess an opensource Smalltalk offering substantial advantage for business opportunities. If these projects are not capable of aggregating energy, I fell Squeak will stay as it is, probably for a long time 'cause opensource project are hard to die. Among the existing fork, so far I only see Pharo taking good direction to aggregate energy: the Pharo promise is very clear (from the web site: "we want Pharo to be the obvious choice for professional development in an open-source Smalltalk"), the lead is clear and direct, then the result is already very clear as well: indeed we can already see peripheral projects aggregating energy in Pharo. If you take a few second and think about it, for most forked project, the cost to maintain the forked image (in top of the specific project) can be important and it consumes energy. Of course it is just so easier in short term perspective to fork, but the cost increase in the long term and it could probably kill the project when the resource becomes scarce. Again I am only observing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJP3/RSAvrR6lz6PQRAiOxAJ9zUZ0W9nLjspvZDx/tKKjqrRz/KQCeNInK iRuPLU9xC9cdqE59qDIy0oI= =K1MM -----END PGP SIGNATURE----- |
| Free forum by Nabble | Edit this page |