What does it take to buy in to Squeak (was RE: Stef's departure from the SqueakFoundation board)

> From: David T. Lewis
> I really don't know how the board would be able
> to accomplish this without pissing somebody off.  A strong benevolent
> dictator would be required, and we do not have that.

And this is a central issue.  Look at the big OS efforts - Linux, Perl, Python are examples.  Each effort formed around a central figure that matches David's view of a strong benevolent dictator.

We had dictators, arguably benevolent, in SqC.  We have had a power vacuum since SqC dissolved, with no person or group strong enough to carry the community with them - indeed, with some members of the Squeak community hanging on every word out of Alan Kay, Dan Ingalls and the rest of ex-SqC and treating those with greater reverence than the present board.

Unless we have a shared vision of where we're going (difficult with a mature system like Squeak as it can be used in so many ways) or a person/group to act as a proxy for our strong vision (there's no evidence the community regards SqF in this way), we'll fragment as a community.  I don't know how to get to the shared vision or the trusted person/group from here, and I expect the Squeak community to fragment.  Parts will coalesce around strong projects such as Croquet and Spoon, if the Croquet group are open enough to allow the developer community to grow and if Craig is willing/able to accept distributed developer assistance.  Some newcomers will come in, especially around projects that are newcomer-friendly.  The rest will probably drift to other systems over time.

Here's an interesting question for the list members: what would it take for you to "buy in" to a central governance model for Squeak?  What would it have to look like, who would have to be in it, what would it have to be doing?

My answer to the above (so that I'm not posing questions in the abstract): to buy in to a central governance model, it would have to be taking Squeak in the direction of a fast, modular, cheap runtime with good development tools; it would have to involve or have stated buy-in from my perceived major players in that arena (Bryce for Exupery, Craig for Spoon and Naiad, Tim for VMMaker, plus an appropriate module system and archive such as SM2 + MC2); and it would have to be committed to regular, incremental releases of the smallest possible core plus a cloud of modules that are allowed to be behind the bleeding edge.

As always, my £0.02.

                - Peter

On 8/19/06, Peter Crowther <[hidden email]> wrote:
> Here's an interesting question for the list members: what would it take for you to "buy in" to a central governance model for Squeak?  What would it have to look like, who would have to be in it, what would it have to be doing?

Here's another question: why would you want a central governance model
for Squeak?

As I've been advocating for years, I'd *like* Squeak to fragment. A
children's Squeak, a 3D platform Squeak, a web developer's Squeak, a
Win32 app developer's Squeak, etcetera.

So, all I can see SqF doing is to make sure that people don't
duplicate too much work, by defining some minimal core, and maybe a
clearing house for patches or something like that. But certainly not
some sort of central governance model - let the bits of community
organize themselves, it seems to work just fine...

On 2006 August 19 15:49, Peter Crowther wrote:
<snip:>
>
> Here's an interesting question for the list members: what would it take for
> you to "buy in" to a central governance model for Squeak?  What would it
> have to look like, who would have to be in it, what would it have to be
> doing?

As one of about 300(?) people who voted the SqF members, I'd say that each of
us "bought in" the program of each of the Squeak Foundation board members (by
voting for our candidates).

But, as the choice was about 7 members out of 9 candidates (BTW I just
unsuccesfully tried to find a page on squeak.org listing the board members),
and only few candidates provided an "agenda", I will try to be more specific
in answering your question ("The Board"="The central governance model you ask
about that I'd buy in"):

        1) "The Board" would start with defining what Squeak is - "Squeak" as a small
"SqueakCore" plus "Packages"  - Unfortunately I can only be intuitive here,
not saying I know what should be in "SqueakCore", likely it would be much
smaller than current Squeak, without Morphic, MVC (UI loadable, is that
possible?)

        2) "The Board" would steer the community to achieve separating the
"SqueakCore", and promote _tools_ that help achieving the separation, and
"re-loadability" of some most important packages.

        3) Once the separation is done, "The Board" would be repsonsible for steering
"SqueakCore" _only_.

        4) At this point, "The Board" would _promote_ forking SqueakCore into
"BackwardCompatibleSqueakCore" and "ExperimentalSqueakCore" , and promote and
work on tools that would enable porting packages from
"BackwardCompatibleSqueakCore" to "ExperimentalSqueakCore".
                - The "ExperimentalSqueakCore" would be:
                        - based on Spoon
                        - support Tweak loadability :)
                        - maybe as Goran suggested use Pepsi as VM :)
          - Chances are that, at this point, multiple "ExperimentalSqueakCores" would
be created, forking the core further, hopefully some forks would merge and
fork further, and so on, creating multiple "Boards", which of the forks would
retain the honour to be named Squeak .. maybe there would be SqueakSmallland,
SqueakSqueakland, SqueakDevelopers etc.

milan

Milan Zimmermann <[hidden email]> writes:

Sounds good to me.  I would like to see a body organizing Squeakers
more than anything else, and this is the way to do it.  I wouldn't put
it so strongly, though: in addition to arbitrating the maintenance of
the core part, there is a place for helping people exchange their
Squeak addons.

Also, Squeak would continue to evolve the Squeak we know.  Discussions
about tossing it and starting from the ground up are interesting but
off topic.  If you want to do that, then you are free, but Squeak's
organization should take care of Squeak.

-Lex

I have proposed the SqueakCore ideas about two years ago, at the end of 2004
See
 http://people.squeakfoundation.org/article/41.html
As I proposed six years ago to have more then one mailing list and
it finally happen but with a lot of latency.
I think we are too late now.
Devloping in Python or Ruby si much fast, productive and funny.
And the lack of new strong developers (like Avi or Chris Muller) is
under your eyes and is very bad.


On 21 Aug 2006 11:04:09 +0200, Lex Spoon <[hidden email]> wrote:
--
Software Architect
http://www.objectsroot.com/
Software is nothing

> Milan Zimmermann <[hidden email]> writes:
>>     1) "The Board" would start with defining what Squeak is - "Squeak" as a
>> small
>> "SqueakCore" plus "Packages"  - Unfortunately I can only be intuitive here,
>> not saying I know what should be in "SqueakCore", likely it would be much
>> smaller than current Squeak, without Morphic, MVC (UI loadable, is that
>> possible?)

Giovanni Giorgi puso en su mail :

> I have proposed the SqueakCore ideas about two years ago, at the end of 2004
> See
>  http://people.squeakfoundation.org/article/41.html

This is SqueakKernel.image and Pavel is doing it for a while.

And Spoon is older and backed by Craig mastery.

My SqueakLight is the most tiny working set what have Morphic and could grow
and dated of 2003.
It's a beginner exercise about dependencies, what the several Squeak
"pieces" should like for reach a particular purpose, what was needed for
have any code originated in any Squeak could run, etc

I have at this time a working system, what could grow until understand
complicated .sar produced by regular 3.9.
Not only this, the same .sar could load in 3.9 or SqueakLight,
(Rompecabezas, LogicCircus,SqueakRailRoad) is running.
And I could have MorphicWrappers, MathMorphs, Monticello and friends
(including Monticello 2), Comanche + HttpView + Seaside, IRC.

What is needed is merge all in one killer SqueakCore , but at some time in
future this happen.

Edgar



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

????

It seems to me that you do not read the seaside dev mailing-list or  
you take a strange angle at it.
There you get a lot of smart guys into squeak.

> And the lack of new strong developers (like Avi or Chris Muller) is
> under your eyes and is very bad.
>

On 2006 August 21 05:04, Lex Spoon wrote:
Yes that makes sense. I felt uneasy commenting on this given I am barely a
weekend squeaker, but got encouraged by the original question "what would it
take for you[squeak-dev list member] to "buy in" to a central governance
model for Squeak".

>
> Also, Squeak would continue to evolve the Squeak we know.  Discussions
> about tossing it and starting from the ground up are interesting but
> off topic.  If you want to do that, then you are free, but Squeak's
> organization should take care of Squeak.

What I had intuitively in mind (by saying it would make sense to encourage
alternative cores) would be their existence would show the API to the core is
well-defined and hopefully stable. In a way similar to ability to run (a
large set of) packages such as KDE on both Linux and FreeBSD shows there must
be well-understood API to the cores (perhaps with different adapters but
still defined).  Apart from that clarification I agree talking about
alternatives was off-topic.

Milan

>
> -Lex

I have little time but I am a Software Architect.
So if you (=the community/board directors)  like I can draw some
guidelines for the SqueakCore project.
For instance we can draw together some basic rules for API
deprecation, unit testing and so on.
Drop me an email  :-)
My 4 cents (yes I am a bit more  rich :)


On 8/26/06, Milan Zimmermann <[hidden email]> wrote:
[...]


--
Software Architect
http://www.objectsroot.com/
Software is nothing

On 2006 August 28 10:50, Giovanni Giorgi wrote:
> I have little time but I am a Software Architect.
> So if you (=the community/board directors)  like I can draw some
> guidelines for the SqueakCore project.
> For instance we can draw together some basic rules for API
> deprecation, unit testing and so on.

Hi Giovanni,

Thanks for commenting, and sorry for my late reply, I marked this thread as
"todo", but then never looked back until now, with discussions about
Strongtalk, I remembered I left something on my "todo/reply" that is related.

I do not have much to add, while I continue liking the idea of defining
modularity and well-defined interfaces (and possible interchangeability)
between VM[Current, Pepsi, Strongtalk]<-->Core[Current, Spoon]<-->Packages,
(which themselves would be loadable/unloadable starting with the "lowest
level" such that Tweak/Morphic/NativeUI), I am simply not qualified enough to
drive such SqueakCore effort, or have enough time to help significantly.
Having said that, if someone, or the board, goes this direction, and such
modularization effort is established, I will try to participate and help to
the best I can (which may amount to well below 1 cent :) )

Milan