[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

> >>>>> "Stéphane" == Stéphane Rollandin <[hidden email]> writes:
>
> Stéphane> I would suggest you switch to Pharo: it's there exactly to fit your
> Stéphane> expectations. Then you can let Squeak live its life, be it overly eccentric.
>
> For some, what I'm about to say is obvious.  But for others, this might be a
> deal killer.
>
> Once Squeak core is included as part of the SFC, it will be a lot easier for a
> business to base its work on Squeak.  If there's a question of code heritage,
> the SFLC will assist to provide "we stand together" support.
>
> For Etoys, this has already happened, in that VPRI is willing to put *its*
> legal resources behind the current code base.
>
> I know Pharo has just announced "mit license for everything", but there's
> no organization with other-than-volunteer resources that can certify that.
>
> And given that Pharo is derived from the same original apple-licensed
> code that had troubled Etoys and now taints Squeak core (until the 4.0
> effort is complete), I see this as a problem.
>
> For me, that means I cannot recommend Pharo for business development.
>
> What I would *like* to see, and am working towards as a member of the
> Squeak Leadership Team is:
>
> (a) squeak core gets clean MIT license, and joins SFC
> (b) Pharo's license-known updates get rewritten to apply to squeak core
>
> This would make something that is equivalent to Pharo, but with a clean
> license history.
>
> In essence, I'd like to bring Pharo "back into the fold", because there *are*
> advantages to having a clean license history that *is* supported by someone's
> paid lawyers, just as there are advantages to have "modernized" the legacy
> Squeak look-and-feel.

> I agree with what Juan and K. K. Subramaniam wrote. Squeak needs a goal, a
> statement what it is supposed to be. One thing I miss from the old days is
> the kitchen sink image. Neither Etoys nor Pharo have the goal for delivering
> such an image. So that could be a good raison d'être: Show what can be done
> with Squeak, and show what is done with Squeak. Something inclusive, a place
> for showing off all the cool, interesting, blue plane stuff, which is
> possible with such a dynamic environment. This attracted me to Squeak in the
> first place, and I think it still has the potential to attract newcomers.
> I miss Connectors, MathMorphs, Alice, Games, ThingLab, Genie, Nebraska and
> all the other cool things that were once. But maybe it's just me. ;-)

> Thanks for your attention.
> Cheers,
> Bernhard
>
> Am 28.06.2009 um 20:02 schrieb K. K. Subramaniam:
>
> What Squeak lacks is a clear enunciation of its value proposition. The
> opening
> para of squeak.org is too general and leaves gaps. A short para that crisply
> answers all the following questions:
>
>   what is it primarily? - a programming environment, runtime, a kernel, a
> research workbench for virtual machines?
>   who is the intended audience? researchers? industrial programmers?
> advanced
> programmers?
> what is the primary purpose? prototyping? demos? test beds?
>  what are its nearest competitive technology? Java? Flash?
>  What is uniquely different (and much better) from these?
>
> Such a para will serve to set expectations early and clearly.
>
> Am 28.06.2009 um 16:08 schrieb Juan Vuletich:
>
> Squeak doesn't have a set of objectives and an agenda that is meaningful for
> developers. And it hasn't had it for a long time. Pharo is new. But Tweak,
> Croquet and Etoys forked looong time ago. Now you also have Pharo and Cuis.
> Most developers are contributing to forks, and we only send our stuff for
> Squeak as a side-effect.
>
>
> Am 28.06.2009 um 14:57 schrieb Juan Vuletich:
>
> Squeak needs an agenda badly. Something along the lines of the old "Where is
> Squeak headed" from Dan. Without that, Squeak can't advance in any direction
> at all. People choosing a Smalltalk for their projects can not know what to
> expect. Forks can not know if they are needed or not.
>
> Most forks have clearly defined objectives. Etoys, Croquet, Cuis do have
> them. The objectives for Pharo are broader, and less defined. But Pharo guys
> know where they are going, and they have some developer time and
> organization to advance.
>
> Squeak has nothing of this.
>
> The Squeak community needs to define objectives and an agenda for Squeak, or
> decide that we don't have them, and that the Squeak branch will not be
> developed further.
>
>
>

> 2009/6/28 Mariano Martinez Peck <[hidden email]>:
>> Why don't you just subscribe to both mailing lists?
>
> http://wiki.squeak.org/squeak/608
> Is this list up-to-date?
>
> Provided that the community is continuously shrinking, and that is a
> fact rather than just a feeling, the community should probably
> consider to shrink its infrastructure as well.
>
> Squeak is spread all over the place. The SWiki is a prime example of
> our infrastructure gone wild. It grew out of proportion and has become
> unusable. The community has everything to gain to centralize, focus if
> you prefer, its efforts toward something that will inject a constant
> flow of energy and restart the momentum.
>
> Simplification, by any mean, could partially salvage the situation.
> Consequently, if it's possible to merge some resources available to
> us, I am voting for it.

> Hi Keith,
>
> Thank you for the detailed and thoughtful answer. All you say here is
> important. I was aware of the new process. I was not aware of some of the
> details for 3.11 and 4.0. Thanks for all this.
>
> However, I am not asking about the this. What I'm after is the general, long
> term objectives of Squeak. The kind of statement the Board should come with,
> with the endorsement of the Board.
>
> For example, Pharo says:
> - a progressive, open-source Smalltalk platform for professional use
> - a flexible environment to support the research of new language concepts
> - We will really favor evolutionary and incremental changes. We want to be
> able to experiment with important new features or libraries.
> - Beauty to learn from
> - Not backward compatible
> - Clean, lean and fast
>
> Cuis says:
> - Close to the ideas in Smalltalk-80 and "Design Principles Behind
> Smalltalk".
> - Include only kernel functionality.
> - Included stuff should be in very good shape.
> - Include a greatly simplified version of Morphic as the main UI.
> - Easy to fix and extend.
> - Cuis is yours to extend it to suit your needs.
> - Stable. Smalltalk kernel should not change much.
> - Compatible to a reasonable degree with packages intended for other Squeak
> distributions.
> - There will be optional packages available for Cuis, if people start
> building or using them. We don't want to control that process.
>
> For Squeak, along these lines, from your email I select
> - We have more backwards and forwards compatibility now than we ever had
> before. The crux of the difference between squeak and pharo philosophies has
> been the issue of backwards compatability.
> - The stated goal has been for at least 3 years to work towards a kernel
> image, with which people can build up the custom image
> - The proposal is to have a range of deliverables for different goals, from
> minimal images to fully loaded images for testing. that they want.
>
> These kind of stuff should be at the top of Squeak.org, so people (even old
> timers like me) can know where is Squeak headed.
>
> Thanks,
> Juan Vuletich
>
>

>> For example, Pharo says:
>> - a progressive, open-source Smalltalk platform for professional use
>> - a flexible environment to support the research of new language concepts
>> - We will really favor evolutionary and incremental changes. We want to be
>> able to experiment with important new features or libraries.
>> - Beauty to learn from
>> - Not backward compatible
>> - Clean, lean and fast
>
> once we remove from this list general statements like "we want it good and
> nice and better than Squeak" and keep only precise, specific items, what is
> left is:
>
>> - Not backward compatible
>

> On Sun, 28 Jun 2009 23:09:25 +0200, Igor Stasenko wrote:
> ...
>> Isn't that made clear to anyone these days: a days of bloated images
>> which includes everything and where everything is working is passed.
> ...
>
> This so true Igor. And people must stop talking (stop moving the  
> target) how that can be achieved, so that contributors can see the  
> very reason for their working on things.
>
> Otherwise people will continue to go away.

> Am 28.06.2009 um 22:50 schrieb Mariano Martinez Peck:
>> Yes, it's true. But there is people that are in Pharo and don't want
>> to be in squeak, and viceversa. Perhaps another idea is to have
>> another mailing list, more general, where you can send things related
>> ONLY with BOTH projects.
>> Take also into account that Pharo mailing list is used for the
>> development. It is very high traffic.
> Ah, that is a misunderstanding. I was not referring to merging
> Squeak-dev and the Pharo mailing list. I was referring only to the
> Squeak mailing lists, e.g. Squeak-dev, Release, Webteam, V3dot11. Not
> all, but some of those here:
> http://lists.squeakfoundation.org/mailman/listinfo
>
> By the way, by merging I mean posting to the mailing list: "Guys &
> Gals, due to the low traffic, let's discuss our issues over at
> Squeak-dev in the future." Should someone post there answer it on
> Squeak-dev and tell them. Remove references to the list from
> squeak.org and the wiki.
>
> Cheers,
> Bernhard
>

>
> Am 28.06.2009 um 23:44 schrieb Klaus D. Witzel:
>> On Sun, 28 Jun 2009 23:09:25 +0200, Igor Stasenko wrote:
>> ...
>>> Isn't that made clear to anyone these days: a days of bloated images
>>> which includes everything and where everything is working is passed.
>> ...
>>
>> This so true Igor. And people must stop talking (stop moving the  
>> target) how that can be achieved, so that contributors can see the  
>> very reason for their working on things.
>>
>> Otherwise people will continue to go away.
> I tried to explain in my response to Igor that I think the opposite  
> is true. We lost a lot of people because we did not value their  
> contributions to the full image enough.

> Dear Juan,
>> Ok. So, what does that set of objectives and agenda say about:
>> - Backwards compatiblity
> We have had Installer, and LevelPlayingField for ages. The purpose of
> which is to make some compatability possible between different images,
> and ongoing changes to API's can be back ported to other images thus
> preserving backwards compatability, and providing forwards  
> compatability
> where possible.
>
> We have more backwards and forwards compatibility now than we ever had
> before.
>
> The crux of the difference between squeak and pharo philosophies has
> been the issue of backwards compatability.
>> - Removal (or not) of stuff
> All tools we are using for 3.11 are not reliant upon a gui. This is
> explicitly because the stated goal has been for at least 3 years to  
> work
> towards a kernel image, with which people can build up the custom  
> image
> that they want.
>> - Addition (or not) of stuff
> The proposal is to have a range of deliverables for different goals,
> from minimal images to fully loaded images for testing.
>> - Modularity
>> - Any concrete statement (about the software, not the process!) so
>> people can know what to expect
>> ?
> This statement has been that 4.0 would be as 3.10 with minimal changes
> for relicencing purposes.
>
> 3.11 has been proposed as an image with minimal changes, that would be
> proof of concept for the new process.
>
> a) Readies the image for automated build and testing - i.e. release
> early and often will be properly possible at last
> b) Readies the image for our automated/open mantis integration for  
> bug fixes
> c) Hopefully includes atomic loading for making radical changes to the
> image possible (i.e. new gui/compiler etc)
> d) Readies the image for future releases that are assembled by a
> selection of components, working to a design proposal rather than by  
> an
> infinite set of incremental changes by one or two control freaks.
>
> (p.s. I need help someone to test and debug (c))
>
> The actual "design" as to what 3.11 results in has been in the form of
> executable code for over a year, in the ss/Tasks repository. This is
> probably looking a bit stale now since I have been working on bob.
>> When was it approved by the community or the elected leadership?
> ages ago.
>
> http://installer.pbworks.com/Squeak311Proposal
>> Was there a decision process involving the community?
> http://installer.pbworks.com/Squeak311
>
>
> Keith
>
>
>
>

>
> Am 28.06.2009 um 23:44 schrieb Klaus D. Witzel:
>> On Sun, 28 Jun 2009 23:09:25 +0200, Igor Stasenko wrote:
>> ...
>>> Isn't that made clear to anyone these days: a days of bloated images
>>> which includes everything and where everything is working is passed.
>> ...
>>
>> This so true Igor. And people must stop talking (stop moving the  
>> target) how that can be achieved, so that contributors can see the very  
>> reason for their working on things.
>>
>> Otherwise people will continue to go away.
> I tried to explain in my response to Igor that I think the opposite is  
> true. We lost a lot of people because we did not value their  
> contributions to the full image enough.
>
> Peace ;-),